Les architectes, les DevOps et les ingénieurs cloud essaient progressivement de comprendre ce qui est préférable de poursuivre le voyage avec la passerelle API ou d'adopter une toute nouvelle technologie de maillage de services. Dans cet article, nous allons essayer de comprendre la différence entre les deux fonctionnalités et exposer quelques raisons pour lesquelles l'équipe logicielle doit envisager ou non un maillage de services tel qu'Istio (car il s'agit du maillage de services le plus utilisé).
Veuillez noter que nous sommes fortement motivés par le concept deArchitecture MASAqui garantit l'agilité, la flexibilité et l'innovation de l'infrastructure pour les équipes de développement et de livraison de logiciels. En raison de notre position futuriste, nous pourrions être critiques à l'égard de la passerelle API, mais notre évaluation sera authentique et utile pour les entreprises qui cherchent à introduire une transformation radicale. Bdw, MASA - une architecture maillée d'applications, d'API et de services - fournit aux professionnels des applications techniques la fourniture d'applications avec l'architecture optimale pour répondre à ces besoins.
Examinons quelques tendances actuelles en matière de modernisation des applications.
Tendances de la modernisation des applications
- Microservices: Presque toutes les moyennes et grandes entreprises utilisent des microservices pour fournir des services au client final. Les microservices (sur les monolithes) conviennent au développement d'applications plus petites et à leur mise sur le marché.
- Nuage: Ceci n'a pas besoin d'explication. On ne peut qu'imaginer fournir des services en étant sur le cloud. En raison des réglementations et des politiques et de la sécurité accrue des données, les entreprises adoptent également un cloud hybride - un mélange de cloud public/privé et de machines virtuelles sur site
- Conteneurs(Kubernetes) : les conteneurs sont utilisés pour déployer des microservices, et leur adoption est en augmentation. Gartner prédit que15 % des charges de travail dans le monde s'exécuteront dans des conteneurs d'ici 2026. Et la plupart des entreprises utilisentconteneurs gérés dans le cloud pour leurs charges de travail.
Et l'adoption de ces technologies se fera de plus en plus dans les années à venir (Dynatrace prédit laadoption des conteneurs et du cloud de près de 127 % d'une année sur l'autre).
L'implication de toutes les tendances technologiques ci-dessus est que la transaction de données sur le réseau a augmenté. La question est la suivante : la passerelle API et les équilibreurs de charge au centre de la modernisation de l'application seront-ils suffisants pour l'avenir ?
Avant de trouver la réponse, examinons certaines des implémentations de la passerelle API.
Exemples de scénarios de mise en œuvre de la passerelle API et de l'équilibreur de charge
Après avoir discuté avec de nombreux clients, nous avons compris différentes manières de configurer les passerelles API et les équilibreurs de charge. Voyons rapidement quelques scénarios et comprenons les limites de chacun d'eux.
Tout le parcours des microservices, du cloud et des conteneurs commence par une passerelle API. Prenons un exemple pratique de deux microservices (services d'auteur et de serveur d'écho) hébergés sur le cluster EKS. (En réalité, les choses peuvent être plus compliquées, nous verrons cela dans un autre plus tard). Supposons que les architectes ou l'équipe DevOps souhaitent exposer les deux services du cluster privé au public (via le nom DNS : http://abc.com). Dans ce cas, l'un des moyens consiste à appliquer des équilibreurs de charge réseau pour chacun de ces services (en supposant que chacun d'eux est hébergé dans le même cluster mais sur des nœuds différents). Et une passerelle API telle que la passerelle API AWS peut être configurée pour autoriser le trafic vers ces équilibreurs de nœuds.
Si le cluster est dans un VPC privé, alors Vpc Link doit être introduit pour recevoir le trafic de la passerelle API vers l'intérieur du sous-réseau privé, qui peut en outre être autorisé aux équilibreurs de charge réseau. Et chaque équilibreur de nœud redirigera le trafic vers leurs services respectifs.
Fig A : Passerelle API et implémentation de plusieurs équilibreurs de réseau
L'inconvénient d'une telle architecture est qu'il peut y avoir plusieurs équilibreurs de charge et que les coûts peuvent être élevés. Ainsi, certains architectes peuvent utiliser une autre implémentation par un seul équilibreur de charge avec de nombreux ports ouverts pour servir divers services (dans notre cas, auteur et serveur d'écho). Reportez-vous à la figure B :
Fig B : Implémentation de la passerelle API et de l'équilibreur de réseau
L'une des architectures les plus utilisées est un équilibreur de charge d'application au lieu d'un équilibreur de charge réseau (voir la figure C). Dans de tels scénarios, certaines des responsabilités de la passerelle API peuvent être transférées de la passerelle API à l'équilibreur de charge d'application, comme le routage du trafic L7. En revanche, une passerelle API peut exécuter des fonctionnalités avancées de gestion du trafic telles que les tentatives et la traduction de protocole.
Fig C : Implémentation de la passerelle API et de l'équilibreur d'application
Nous avons examiné des cas d'utilisation simples, mais en pratique, il peut y avoir de nombreux microservices hébergés dans des services multicloud et conteneurs, qui peuvent ressembler à ceci :
Fig D : Passerelle API dans une configuration de microservices interdépendants
Mais quelle que soit l'architecture, il peut y avoir quelques limites à l'utilisation de la passerelle API dans votre parcours de modernisation des applications.
Limites de la passerelle API
Gestion du trafic limitée au bord
La passerelle API est assez bonne pour prendre le trafic à la périphérie, mais si vous voulez gérer le trafic entre les services (comme dans la figure D), cela peut vite devenir compliqué.
Parfois, la même passerelle API peut être utilisée pour gérer la communication entre deux services. Ceci est fait principalement pour les connexions peer-to-peer. Cependant, deux services résidant sur le même réseau mais utilisant des adresses IP externes pour communiquer créent des sauts inutiles, et de telles conceptions doivent être évitées. Les données prennent plus de temps et la communication utilise plus de bande passante.
C'est ce qu'on appelle le NAT demi-tour et le bouclage NAT (épingle à cheveux réseau). Et de telles conceptions doivent être complètement évitées.
Incapacité à gérer le trafic nord-sud
Lorsque les services se trouvent dans différents clusters ou centres de données (cloud public et VM sur site), permettre la communication entre tous les services à l'aide d'une passerelle API est délicat. Une solution de contournement peut consister à activer plusieurs passerelles API utilisées de manière fédérée, mais la mise en œuvre peut être compliquée et le coût du projet l'emportera sur les avantages.
Manque de visibilité sur la communication interne
Prenons un exemple où la passerelle API autorise la demande au service A. Le service A doit parler aux services B et C pour répondre à la demande. S'il y a une erreur dans le service B, le service A ne pourra pas répondre. Et il est difficile de détecter le défaut à l'aide d'une passerelle API.
Aucun contrôle sur le réseau à l'intérieur du cluster
Lorsque les équipes DevOps et cloud souhaitent contrôler la communication interne ou créer des politiques réseau entre les microservices et la passerelle API, elles ne peuvent pas être utilisées pour de tels scénarios.
Le trafic est-ouest n'est pas sécurisé
Étant donné que l'utilisation de la passerelle API est limitée à la périphérie, le trafic à l'intérieur d'un cluster (par exemple, un cluster EC2 ou EKS) ne sera pas sécurisé. Si une personne pirate un service dans un cluster, elle peut rapidement prendre le contrôle de tous les autres services (appelée attaque vectorielle). Les architectes peuvent utiliser des solutions de contournement telles que la mise en œuvre de certificats et la configuration de TLS, etc. Mais encore une fois, il s'agit d'un projet supplémentaire qui peut prendre beaucoup de temps à vos employés DevOps.
Impossible de mettre en œuvre la livraison progressive
La passerelle API n'est pas conçue de manière à comprendre les sous-ensembles d'applications dans Kubernetes. Par exemple, le service A a deux versions - V1 et V2 fonctionnant simultanément (la première étant la plus ancienne et la plus récente étant le canari) ; dans ce cas, la passerelle API ne peut pas être implémentée pour implémenter le déploiement Canary. En fin de compte, vous ne pouvez pas étendre la passerelle API pour implémenter une livraison progressive telle que canari, bleu-vert, etc.
Pour surmonter toutes les limitations de la passerelle API, votre DevOps peut développer des solutions de contournement (comme plusieurs passerelles API implémentées de manière fédérée) mais notez que la maintenance d'une telle configuration pourrait être plus évolutive et serait considérée comme une dette technique.
Par conséquent, une infrastructure de maillage de services doit être envisagée. Istio open-source, développé par Google et IBM, est un logiciel de maillage de services largement utilisé. La plupart des organisations avancées, telles que Airbnb, Splunk, Amazon.com, Salesforce, etc., ont utilisé Istio pour gagner en agilité et en sécurité dans leur réseau.
Présentation du maillage de services Istio
Istio est un logiciel de maillage de services open source qui extrait le réseau et la sécurité de la flotte de microservices.
Du point de vue de la mise en œuvre, Istio injecte le proxy Envoy (un side-car) dans chaque service et gère le trafic L4 et L7. Les équipes DevOps et cloud peuvent désormais définir facilement des politiques de réseau et de sécurité à partir du plan central.
Fig E : Diagramme du maillage de services Istio
Comme le trafic applicatif, de transport et réseau (L7/l5/L4) peut être contrôlé par Istio, il est facile de gérer et de sécuriser le trafic nord-sud et est-ouest. Vous pouvez appliquer des politiques de réseau et de sécurité précises au trafic est-ouest et nord-sud dans les applications multicloud et cloud hybride. La meilleure partie est qu'Istio fournit une observabilité centrale des performances du réseau dans un seul plan.
À l'aide d'Istio, l'équipe DevOps peut mettre en œuvre des stratégies de déploiement Canary ou Blue-Green à l'aide des outils CI/CD et du maillage de services Istio.
Lire toutes les fonctionnalités duMaillage de services Istio.
Comparaison tabulaire de la passerelle API et du maillage de services Istio
Veuillez suivre la comparaison de la passerelle API et du maillage de services Istio sur quelques dimensions, telles que la gestion du réseau, la gestion de la sécurité, l'observabilité et l'extensibilité.
Conclusion
La passerelle API était bonne pour l'équilibrage de charge et la gestion d'autres gestions de réseau à la périphérie. Pourtant, à mesure que vous adoptez les technologies de microservices, de cloud et de conteneurs pour atteindre l'échelle, les architectes ont besoin d'un peu de réimagination pour l'agilité et la sécurité du réseau. Le maillage de services Istio est convaincant car il est open source et est fortement contribué par Google, IBM et Red Hat.
Dans le prochain blog, nous discuterons des scénarios architecturaux avec la passerelle API et Istio de Ravi Verma (CTO, IMESH) pour la modernisation des applications.
À propos de l'IMESH
IMESH aide les entreprises à simplifier et à sécuriser leur réseau d'applications cloud natives à l'aide d'Istio et d'Envoy. Nous fournissons également une assistance aux entreprises pour le maillage de services Istio. Pour vous aider à surmonter la pénibilité de l'apprentissage et de l'expérimentation d'Istio, IMESH fournit des versions d'entreprise d'Istio. Avec IMESH, vous pouvez mettre en œuvre Istio pour vos applications cloud dès le premier jour sans aucun problème opérationnel. Nous fournissons:
- Mise en œuvre d'Istio en production
- Formation et intégration d'Istio
- Gestion du cycle de vie d'Istio avec des correctifs fréquents et des mises à niveau de version
- Améliorations telles que la mise en œuvre multicluster dans AKE/GKE/EKS, conformité FIPS
- Istio hautes performances et haute disponibilité
- SLA garantis pour les correctifs de vulnérabilité
- Prise en charge FIPS
- Plus de 50 intégrations avec des outils CI/CD
- Personnalisation pour Istio et Envoy
Parlez à l'un de nosExperts Istiogratuitement ouContactez-nouspour l'assistance Istio d'entreprise.