Quelle différence avec un firewall standard, quand tu utilise mon architecture ?
TLS offloading,
Je ne suis pas sûr de ce que tu proposes, mais la manière historique de faire c'est IPsec ; sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).
logging,
Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes...
load balancing,...
Le load-balancing est une invention inutile dans l'archi que je présente. Ou plutôt, il est « naturel » dans mon cas.
mais tu dois faire des manipulations « système » (avoir ton DNS, ajouter une interface à ta machine, t'assurer que ton routage fonctionne bien,...). Tester et reproduire tout ça n'est pas trivial.
Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.
Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.
Bien sûr, tout n'est pas rose : la situation actuelle du « blocage » du nommage et du routage — qui amène à empêcher tout déploiement « correct » de service sur Internet — est due à un problème de répartition des responsabilités. On sait difficilement en entreprise ou à la maison déléguer une partie du DNS ou du routage à d'autres : il y a les « responsables du DNS » et les « responsables du routage » qui les gèrent de manière fermée, et qui sont parfois si obtus qu'on préfère passer par d'autres moyens pour étendre le réseau de processus que d'utiliser la manière « standard ».
mais contrairement à ce qui est dit dans le journal choisir de faire un peu plus tardivement le routage ne me paraît pas forcément choquant.
Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 8.
Quelle différence avec un firewall standard, quand tu utilise mon architecture ?
Je ne suis pas sûr de ce que tu proposes, mais la manière historique de faire c'est IPsec ; sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).
Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes...
Le load-balancing est une invention inutile dans l'archi que je présente. Ou plutôt, il est « naturel » dans mon cas.
Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.
Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.
Bien sûr, tout n'est pas rose : la situation actuelle du « blocage » du nommage et du routage — qui amène à empêcher tout déploiement « correct » de service sur Internet — est due à un problème de répartition des responsabilités. On sait difficilement en entreprise ou à la maison déléguer une partie du DNS ou du routage à d'autres : il y a les « responsables du DNS » et les « responsables du routage » qui les gèrent de manière fermée, et qui sont parfois si obtus qu'on préfère passer par d'autres moyens pour étendre le réseau de processus que d'utiliser la manière « standard ».
Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.