Gardez le côté chaud chaud et le côté froid froid.
Vous vous souvenez peut-être (si vous êtes assez vieux et non, ne vous inquiétez pas, je ne vous demanderai pas de lever la main) d’une campagne menée il y a quelques années par McDonald’s faisant la promotion d’emballages de certains de ses produits qui gardaient « le côté chaud chaud et le côté froid froid ».
Le concept était assez simple, en fait : séparer le chaud et le froid mais le garder dans un seul récipient pour faciliter le transport.
Cette notion de séparation au sein d’un même « conteneur » est en réalité la base de ce qui fait d’un proxy d’application, eh bien, un proxy. Conserve le côté client et le côté application… app.
Bon, ça ne se traduira peut-être pas aussi bien que je le souhaiterais après tout.
Néanmoins, le concept est valable et important pour comprendre un proxy d’application.
Fondamentalement, un proxy est un logiciel qui est logiquement positionné entre deux participants à un échange de communication. Un proxy d’application se situe entre une application et un client. Or, tous les proxys ne sont pas des proxys complets . Un proxy complet nécessite une séparation interne des deux côtés ; un proxy complet possède essentiellement deux piles réseau indépendantes contenues dans un seul périphérique. Le côté client (le côté chaud) et le côté application (le côté froid).
Je sais, l’analogie ne fonctionne pas vraiment bien, n’est-ce pas ? Travaille avec moi, c’est tout ce que j’ai pour l’instant.
La raison pour laquelle cela est (ou devrait être) une exigence pour un proxy d’application est que cela donne au proxy la possibilité de participer à l’échange entre le client et le serveur. Cela est nécessaire pour fournir des fonctionnalités telles que la minification (qui améliore les performances des applications) et des fonctions de sécurité (comme le nettoyage des données) et le multiplexage TCP (optimisation) ainsi qu'un large ensemble d'autres services.
C’est dans cet « espace » interne entre le côté client et le côté application que la magie opère. C’est là qu’interviennent de nombreux services, depuis l’équilibrage de charge rudimentaire jusqu’au pare-feu d’application avancé en passant par le contrôle d’accès aux applications. Les demandes sont effectivement terminées côté client d’un proxy d’application. Après cela, un processus très similaire au chaînage de services se produit, sauf que tout se passe en interne, à des vitesses de bus et de processeur internes (qui sont presque toujours plus rapides que celles du réseau). L'inspection s'ensuit. Les politiques sont appliquées. Des transformations se produisent. Des décisions sont prises. Une connexion distincte entre le proxy et l'application est établie et la demande est envoyée.
Lorsque cette demande revient au proxy, l’inverse se produit. L'inspection s'ensuit. Les données sont nettoyées. Les politiques sont appliquées. Ensuite, il revient du côté client où il peut être transféré au client.
Et tout cela se produit en moins d’une seconde, car tout est interne au proxy.
Étant donné que l’objectif d’un proxy d’application est de fournir une large gamme de services d’application (disponibilité, sécurité, mobilité, identité et accès, et performances), il doit vraiment s’agir d’un proxy complet. Seul un proxy complet est conçu pour participer à chaque demande et réponse. Les proxys simples (qui sont en réalité des proxys sans état si vous voulez entrer dans les détails) ne participent qu'à la conversation initiale, lorsque la connexion entre le client et l'application est créée. Son objectif est de sélectionner une instance d’application, puis de « coudre » la connexion entre les deux. Après cela, le proxy ne participe plus. Il voit un « flux » (une construction TCP de couche 4 que vous avez peut-être entendue en discutant de SDN, ce qui est encore une autre discussion pour une autre fois) et transmet simplement les paquets dans les deux sens, mélangeant le chaud et le froid sans distinction. (Voir? Je savais que l’analogie fonctionnerait éventuellement.)
Ceci étant dit, un proxy d’application moderne (et évolutif) doit être un proxy complet et avoir trois caractéristiques clés : la programmabilité, les performances et les protocoles.
La programmabilité est essentielle dans les centres de données modernes et dans le cloud pour prendre en charge l’automatisation, l’orchestration et la standardisation. Il est également essentiel dans le chemin de données pour permettre la sécurité et les services qui offrent une valeur unique aux entreprises et aux opérations, permettant la prise en charge des protocoles personnalisés et l'augmentation des protocoles existants. Les performances semblent simples, mais ce n’est pas le cas. Parce qu'un proxy d'application interagit avec chaque requête, il doit non seulement être rapide, mais incroyablement rapide. Il doit faire ce qu'il doit faire rapidement, sans ajouter de latence qui tuerait l'expérience de l'application à l'échange. Ce n’est pas aussi simple qu’il y paraît, surtout lorsqu’il existe une telle volonté d’utiliser le calcul à usage général comme base de déploiement.
Enfin, les protocoles sont importants. La première chose à laquelle nous pensons lorsque nous disons « application » est probablement HTTP. Ce n’est pas une surprise : HTTP est le nouveau TCP et la lingua franca d’Internet. Mais ce n’est pas le seul protocole utilisé, et surtout pas à l’ère des communications via Internet. Il existe également SIP et UDP. Sans parler de SMTP (vous envoyez toujours des e-mails, n'est-ce pas ?) et LDAP. Et qu'en est-il de SSL et TLS ? Avec l'accent croissant (et l'urgence) d'obtenir SSL partout, eh bien, partout, il est encore plus impératif qu'un proxy d'application parle SSL/TLS - et le parle très couramment. Car sinon, cette exigence de performance pourrait ne pas être satisfaite.
Un proxy d'application peut fournir la plate-forme dont les centres de données modernes ont besoin pour relever les défis de sécurité et de performances, pour automatiser et orchestrer leur chemin vers des coûts d'exploitation réduits et pour garantir une expérience d'application optimale pour les clients consommateurs et entreprises. Mais il doit s’agir d’un proxy d’application complet avec programmabilité, performances et prise en charge de protocoles pour garantir qu’aucune application ne soit laissée de côté.