L’un des concepts les plus fondamentaux de l’informatique distribuée est le point final. Nous connaissons chaque logiciel – objets, microservices, applications, etc. – par ses entrées et ses sorties, et nous appelons ces points d’interaction des points de terminaison.
Au cours de l’histoire de l’informatique distribuée, les points de terminaison se sont présentés sous de nombreuses formes : sockets, adresses IP, interfaces, services Web et entrées, pour n’en nommer que quelques-uns. Quelle que soit leur nature, d’autres logiciels doivent être capables de trouver les points de terminaison appropriés, de s’y connecter (ou de s’y lier) et d’interagir avec eux.
Les points de terminaison représentent également des trous dans notre surface d’attaque, leur sécurisation est donc toujours d’une importance capitale. À la base, les points de terminaison font partie de notre architecture informatique distribuée physique. Cependant, si nous ne devions travailler que sur des points de terminaison physiques, nous aurions peu ou pas de flexibilité et, par conséquent, une programmabilité limitée et de sévères limitations à leur utilisation. Pour ces raisons, nous avons mis en œuvre de nombreuses approches d’abstraction des points de terminaison au fil des ans. Aujourd’hui, nous devons poursuivre cette tendance à mesure que nous développons notre infrastructure cloud native.
Dans le nouveau paradigme informatique natif du cloud, cependant, les points de terminaison abstraits prennent une nouvelle signification.
Couches d’abstraction des points de terminaison
L’abstraction des points de terminaison est, en fait, à la fois banale et banale. Les serveurs DNS résument les adresses IP, attribuant des noms de domaine que nous pouvons réattribuer si nécessaire. Les équilibreurs de charge peuvent diriger les demandes vers différents points de terminaison de service ou d’application, le demandeur n’étant pas au courant.
REST se concentre sur l’utilisation d’URL (ou plus généralement d’URI) pour abstraire à la fois les points de terminaison et les opérations qu’ils prennent en charge. L’infrastructure sous-jacente peut tirer parti des serveurs Web, des équilibreurs de charge ou des passerelles API – ou une combinaison – pour résoudre les URL et diriger le trafic vers le point de terminaison physique approprié.
Le scénario REST met en évidence un principe important de l’abstraction des points de terminaison : généralement, un message peut traverser plusieurs éléments technologiques différents qui ajoutent chacun une couche différente d’abstraction des points de terminaison au mélange. Bien que ces couches ajoutent de la complexité architecturale, les avantages de l’ajout de flexibilité ainsi que de simplicité pour le consommateur final dépassent généralement les coûts d’une telle complexité.
Points de terminaison abstraits dans le cloud natif
L’informatique native du cloud – dans ce cas, Kubernetes en particulier – nécessite des abstractions de points de terminaison supplémentaires que les autres formes d’informatique distribuée n’ont pas.
La raison de cette complexité supplémentaire est fondamentale pour l’objectif de Kubernetes lui-même : offrir une évolutivité horizontale rapide et illimitée aux niveaux du conteneur, du pod et du cluster.
Les maillages de services utilisent des proxys pour acheminer le trafic « est-ouest » entre des instances de microservice spécifiques, même si le microservice demandeur ne sait généralement pas combien d’instances sont disponibles à un moment donné ou quelles sont leurs adresses IP.
En d’autres termes, les services mesh fournissent une abstraction de point de terminaison au point d’entrée essentielle à la consommation des microservices exécutés sur Kubernetes.
Le même principe s’applique au trafic « nord-sud » lorsqu’un demandeur se trouve en dehors du domaine de microservice en question. Dans ces situations, une passerelle API gère l’abstraction du point de terminaison.
La technologie sous-jacente pour la mise en œuvre de ces abstractions de points de terminaison est différente : des side-cars et des proxys pour le trafic est-ouest et des passerelles API sécurisées et basées sur des règles pour le nord-sud.
Zero Trust natif du cloud
Fournir une sécurité adéquate et appropriée aux points de terminaison abstraits introduit de nouveaux défis pour les équipes d’infrastructure et de sécurité. Compte tenu de la nature dynamique des déploiements Kubernetes et de leur prise en charge des scénarios informatiques hybrides, une approche de confiance zéro qui traite tous les points de terminaison comme non fiables jusqu’à preuve du contraire est absolument essentielle.
Un seul problème : les approches zéro confiance « traditionnelles » ne sont pas à la hauteur de la tâche. Cette approche originale de la confiance zéro associe les points de terminaison à des utilisateurs humains, et les technologies traditionnelles de gestion des identités et des accès ne sont donc adéquates que pour gérer les identités humaines associées aux points de terminaison.
Dans le monde du cloud natif, en revanche, les points de terminaison peuvent être des microservices, des API, des smartphones, des capteurs IoT ou tout autre type de technologie. Par conséquent, il n’est plus possible d’exploiter les identités humaines pour accéder à la plupart des points de terminaison abstraits. La confiance zéro native du cloud nécessite une approche différente. (Voir mon article sur la confiance zéro native du cloud pour plus de détails)
Connectivité vs intégration
Les points de terminaison abstraits dans le cloud computing natif donnent à tout autre point de terminaison (consommateur/demandeur, source ou destinataire du message, etc.) la possibilité de trouver et de se lier à ce point de terminaison, dans le contexte de l’infrastructure donnée. Cette infrastructure peut inclure Kubernetes, un annuaire de services ou une autre technologie de support.
Nous appelons cette capacité la connectivité des points de terminaison. Le terme « connectivité » représente en fait une abstraction à part entière, tirant parti des abstractions de points de terminaison existantes pour donner à ces points de terminaison la possibilité d’interagir les uns avec les autres conformément aux politiques qui définissent l’abstraction.
La connectivité, cependant, n’est pas la même chose que l’intégration. L’intégration des points de terminaison nécessite certainement une connectivité, mais nécessite également le mécanisme de déplacement des messages entre les points de terminaison. Dans le monde pré-Kubernetes, les technologies d’intégration offraient également une variété de capacités « intelligentes », notamment la transformation des données, la sécurité, l’exécution de la logique de processus, etc.
Les architectures qui dépendent d’un tel middleware d’intégration pour ce poids lourd sont ce que nous appelons des architectures de « conduites intelligentes, points de terminaison stupides ». Non seulement nous tirons parti des technologies d’intégration pour une grande partie du travail, mais nous n’avons pas non plus à nous fier aux terminaux pour faire bien plus que nous conformer à leurs contrats respectifs (contrats WSDL pour les services Web ou types de médias Internet pour les terminaux RESTful, par exemple).
L’une des leçons les plus importantes des journées SOA était que l’approche des tuyaux intelligents était trop centralisée et donc pas particulièrement adaptée au cloud. Au fur et à mesure que les architectures informatiques distribuées se sont déplacées vers le cloud et maintenant vers le cloud natif, nous éliminons le gros du travail du middleware, en nous appuyant plutôt sur des technologies de mise en file d’attente légères et d’autres approches open source d’intégration.
Si les tuyaux passent de intelligent à stupide de cette manière, il s’ensuivrait seulement que nos points de terminaison passeraient de stupide à intelligent. D’une certaine manière, ils le doivent, tant que ce que nous entendons par un point de terminaison intelligent est un point de terminaison abstrait. Après tout, le point de terminaison physique peut toujours être une adresse IP ou une API, ou une URL. Nous ne nous attendons pas à ce que ces protocoles et technologies soient plus intelligents qu’ils ne l’ont toujours été.
Au lieu de cela, nous nous appuyons sur l’infrastructure de point de terminaison abstraite pour savoir comment gérer la transformation des données, la sécurité, l’application des politiques et toutes les autres fonctionnalités dont nous avions besoin des ESB et d’autres middleware traditionnels – seulement maintenant, en faisant abstraction de l’évolutivité et de l’éphémère de Kubernetes environnement.
Pouvons-nous également abstraire l’intégration ?
Disons qu’un point de terminaison est un capteur IoT et l’autre est une API basée sur le cloud. Si nous avons suffisamment abstrait ces points de terminaison, nous leur avons fourni une connectivité.
Mais nous devons toujours déplacer physiquement les messages de l’un à l’autre – une tâche qui peut inclure la 5G, un lien MPLS dédié, une sorte de middleware et une entrée dans notre cloud de choix, par exemple.
Dans le monde idéal du cloud natif, nous gérerions automatiquement l’approvisionnement, la gestion et la sécurité d’une telle intégration conformément aux politiques établies, ce qui nous donnerait la possibilité d’abstraire l’intégration ainsi que les points de terminaison eux-mêmes, ce qui nous permettrait de changer un élément de technologie pour une autre pour des raisons de performance ou de coût, l’utilisateur final n’étant pas plus avisé.
Le résultat serait ce que j’aime appeler intégration basée sur l’intention. Les parties prenantes exprimeraient l’intention commerciale pour les interactions entre les terminaux – latence, souveraineté des données, fiabilité et autres exigences – et l’infrastructure choisirait automatiquement et dynamiquement la meilleure topologie de routage et les meilleures technologies d’intégration afin de se conformer à cette intention de manière continue.
Des technologies telles que SD-WAN fournissent une partie de la solution, mais toute l’étendue de cette intégration basée sur l’intention est encore principalement sur la planche à dessin (bien que le projet open source NATS soit en bonne voie pour mettre en œuvre cette vision). Néanmoins, il n’y a aucune raison d’attendre. Les points de terminaison abstraits sont une réalité aujourd’hui, et comprendre comment les implémenter dans un scénario natif du cloud est essentiel pour tenir les promesses de Kubernetes.
La prise Intellyx
J’ai utilisé des exemples de demande/réponse tout au long de cet article car ils sont plus simples à expliquer et à comprendre que les interactions asynchrones. La vérité est que les interactions de streaming asynchrones et en temps réel sont plus la norme pour l’informatique native du cloud, tandis que le modèle demande/réponse est un cas particulier.
Il est donc important de souligner que les points de terminaison abstraits sont tout aussi importants pour les cas d’utilisation de streaming asynchrone. En fait, il existe une nouvelle catégorie de technologie de « maillage d’événements » qui généralise les capacités des maillages de services actuels à gérer des flux de données asynchrones en continu, à la fois pour les flux est-ouest et nord-sud.
La gestion de l’application des politiques, de la sécurité et de la fiabilité des firehoses de données en streaming présente bien sûr son propre ensemble de défis – élevant la barre de l’importance de l’abstraction des points de terminaison.
À mesure que l’informatique de périphérie mûrit et que les données en continu deviennent la norme pour l’informatique d’entreprise, l’abstraction des intégrations, ainsi que des points de terminaison, deviendra de plus en plus critique pour maintenir l’évolutivité, la flexibilité et la résilience promises par l’informatique native du cloud.