Catégories
Start-up et applications

Pourquoi les passerelles API comptent toujours dans les déploiements de maillage de service

La plupart des organisations sont devenues assez courageuses et consacrent beaucoup de temps à la R&D pour convertir leur infrastructure commerciale sous-jacente pour correspondre à la prochaine génération. La plupart du temps, les gens se concentrent sur la refonte totale de leur architecture en choisissant d'aller avec un modèle de microservices, laissant derrière eux leur architecture monolithique. Même si cela a été la tendance, les entreprises ont du mal à franchir ce pas, car cela nécessiterait un ensemble spécifique de connaissances et de technologies, et leurs architectes et employés informatiques ont besoin de temps pour devenir des experts de ces nouvelles idées.

Avoir une expertise dans la mise en œuvre d'une architecture de microservice (MSA) et étudier différentes technologies qui offrent la capacité vous pose un autre ensemble de problèmes lorsque vous essayez réellement de concevoir votre architecture. Je vais essayer de discuter de quelques-uns de ces problèmes ici. Je vais d'abord essayer d'expliquer la transition du monolithe au microservices.

Monolithe

Dans les cas les plus courants d'architecture monolithique, il y aura une seule application qui fournira la capacité commerciale, et toute mise à l'échelle de cette application peut être effectuée dans son ensemble en fonction de la demande. Lorsque certains types de gouvernance sont requis et que la fonctionnalité métier peut être abstraite avec des API (au fur et à mesure que l'organisation se modernise pour moderniser son informatique), les passerelles d'API peuvent prendre le rôle d'exigences telles que la sécurité, l'autorisation, la limitation de débit et les transformations des différents composants commerciaux.

Transformez en microservices

L'une des étapes initiales de la transition vers un MSA consiste à décomposer l'application monolithique en services plus petits, chacun traitant une logique métier spécifique. Les services sont faiblement couplés les uns aux autres et communiquent entre eux à l'aide d'appels API typiques sur le réseau basés sur HTTP, gRPC, etc.

Mais l'étalement des microservices peut entraîner un autre problème; leur gestion et leur gouvernance. Les défis comprennent, sans s'y limiter:

  1. Surveillance des microservices pour leur intégrité, leurs mesures et leurs journaux
  2. Déploiement à chaud d'un microservice avec correction d'un bug (pour ne pas perturber les autres services qui en dépendent)
  3. Ajouter de nouveaux microservices et gérer le routage pour eux
  4. Sécuriser les communications de service à service et gérer la sécurité de manière standard dans tous les services
  5. Gérer le trafic avec coupure de circuits, timeouts et limitation de débit
  6. Ajout de nouvelles politiques pour régir les microservices et gérer ces politiques

Un moyen éprouvé de faire face à ces défis et à d'autres soulevés par l'expansion des microservices consiste à créer un maillage de service en adoptant un fournisseur de solutions de maillage de service.

Un maillage de service est un réseau de microservices qui, pris ensemble, forment la base d'une application composable. Un maillage de service fournit une infrastructure pour gérer l'interaction entre ces microservices. Il se compose d'un plan de données qui est le maillage de microservices et d'un plan de contrôle qui régit et gère le plan de données. Un maillage de service injecte un proxy en tant que side-car à chaque microservice. Ce proxy sidecar régit la façon dont les microservices communiquent entre eux et la façon dont le plan de contrôle communique avec le proxy sidecar afin de gérer le plan de données.

Le déploiement d'un maillage de service ajoute un nouvel ensemble de questions au niveau architectural. Le principal problème est de savoir où placer ma bonne ancienne passerelle API dans le maillage de service ou si j'en ai même besoin. Les passerelles API et les maillages de service résolvent-ils le même ensemble de problèmes. Par exemple:

  • Un maillage de service fournit une communication de service à service sécurisée. Ai-je encore besoin de la sécurité de la passerelle API?
  • Un maillage de service fournit une authentification de demande et identifie le client. Ai-je toujours besoin de la passerelle API pour l'authentification de l'utilisateur final?
  • Un maillage de service fournit des politiques de coupure de circuit, de délais d'expiration et de connexion. Ai-je besoin des mêmes fonctionnalités de la passerelle API?
  • Un maillage de service gère également le routage du trafic au sein du maillage. Pourquoi ai-je encore besoin du routage de passerelle API?
  • Un maillage de service fournit des métriques et une journalisation sur les microservices inclus. Pourquoi ai-je besoin d'une passerelle API pour la surveillance et l'analyse?

En surface, il semble que les passerelles API et les maillages de service résolvent le même problème et soient donc redondants. En fait, ils résolvent les mêmes problèmes, mais dans deux contextes complètement différents. Principalement une passerelle API agit en bordure du déploiement face aux clients externes, la gestion du trafic nord sud et le maillage de service gère le trafic entre les différents microservices qui est le trafic est ouest.

Essayons de décomposer la déclaration ci-dessus sous différents faits.

1. API vs microservices

L'idée de base d'un maillage de service est de fournir un écosystème pour gérer les microservices. En fin de compte, cependant, la fonctionnalité commerciale de bout en bout (par exemple: le flux de travail pour passer une commande) est un ensemble d'interfaces définies comme des API pour les parties externes et les développeurs à consommer. En d'autres termes, l'API est l'abstraction d'un flux de travail composé de plusieurs microservices qui, lorsqu'ils sont assemblés, effectuent une opération commerciale significative. Le maillage de service contrôle les microservices qui se trouvent derrière l'API tandis que l'API est un actif numérique qui peut être découvert par des parties externes / internes en bordure de votre déploiement. Pour gouverner ces API et les gérer et agir en tant que point d'application de stratégie (PEP) pour les API détectables en externe, le déploiement global nécessite donc une passerelle d'API en périphérie.

2. Sécurité

Un maillage de service typique fournirait différents mécanismes pour sécuriser la communication de service à service ou le trafic est-ouest du déploiement. Le moyen le plus courant semble être la sécurité mutuelle de la couche de transport (TLS). Les services ne peuvent donc communiquer qu'avec un ensemble de services de confiance. L'une des principales capacités du maillage de service est de gérer les certificats requis pour le TLS mutuel au sein du maillage, car les services sont mis à jour fréquemment. Un maillage de service gère ces capacités via son propre plan de contrôle en faisant tourner les certificats. Lorsqu'un nouveau microservice est déployé ou que les certificats existants expirent, le plan de contrôle met à jour tous les autres microservices en distribuant le certificat public des microservices nouvellement ajouté avec d'autres microservices. Cela permet de déployer à chaud de nouveaux services dans le maillage tout en maintenant la sécurité sécurisée de la couche de transport mutuel.

Mais une fois que ces microservices sont exposés en tant qu'API aux parties externes, il devrait y avoir un moyen d'authentifier les parties externes consommant ces API. L'authentification du trafic nord-sud est plus grave car elle provient de parties externes inconnues. Les passerelles API sont spécialement conçues à cet effet, pour agir en périphérie et empêcher le trafic non authentifié ou non approuvé d'entrer dans le système.
Les passerelles API fournissent donc des mécanismes de sécurité plus solides pour les utilisateurs finaux comme les flux Oauth2 et OIDC qui sont conçus pour identifier et authentifier les utilisateurs finaux réels de ces microservices. Une fois que la passerelle API authentifie le trafic nord-sud, le maillage de service gère la communication de service à service avec ses propres mécanismes de sécurité internes comme le TLS mutuel.

Un maillage de service peut également fournir des capacités d'autorisation. La possibilité de définir des politiques d'autorisation personnalisées est une autre caractéristique clé d'un maillage de service. Mais ces politiques sont en fait un ensemble de règles qui régissent le trafic au sein du maillage. Par exemple, autorisez le trafic à partir d'une certaine adresse IP, autorisez le trafic pour certains chemins HTTP (par exemple:: / order / {id}) uniquement, etc. Ces politiques ne se concentrent pas sur les privilèges de l'utilisateur final comme leurs rôles ou autorisations. Mais les passerelles API fournissent plus de capacités d'autorisation de l'utilisateur final avec des mécanismes tels que les vérifications d'autorisation basées sur les rôles et les autorisations en utilisant des mécanismes d'accès précis comme la portée, XACML ou via la connexion avec des agents de stratégie.

3. Gestion du trafic

La gestion du trafic est une autre fonctionnalité courante fournie par la passerelle API ainsi que par un fournisseur de maillage de service. Les implémentations de maillage de service offrent des fonctionnalités telles que les délais d'expiration de connexion, les coupures de circuits et les nouvelles tentatives de demande lors de la connexion avec des microservices. Les passerelles API fournissent également le même ensemble de capacités lors de la connexion avec des microservices.

Là où ils diffèrent, c'est dans la nature des politiques de trafic configurables. Dans un maillage de service, les politiques de limitation de débit peuvent être appliquées au niveau du microservice. Nous pouvons limiter le nombre autorisé de demandes ou la bande passante des demandes (octets par seconde) pour un microservice particulier en utilisant un maillage de service. Une passerelle API vous permet cependant de définir des politiques de trafic plus complexes en fonction de l'utilisateur final. Il peut limiter l'accès aux API pour certains ensembles d'utilisateurs selon différentes politiques de limite de débit. Ces capacités de limitation du trafic basées sur l'utilisateur final peuvent être intégrées aux moteurs de facturation afin de monétiser également les API. Une passerelle API peut également appliquer des politiques de trafic à des API significatives qui fournissent une capacité métier particulière plutôt que de les appliquer au niveau du microservice. Ces capacités des passerelles API permettent d'empêcher un utilisateur d'utiliser une API. D'un autre côté, ces types d'exigences de gestion du trafic seraient difficiles à réaliser avec les capacités fournies par un maillage de service.

4. Acheminement du trafic

Les passerelles API et les maillages de service ont tous deux leurs propres tables de routage dynamique pour acheminer les demandes vers le point de terminaison ou le microservice correct. Un maillage de service effectue un routage à deux niveaux. Premièrement, le routage au niveau d'entrée (passerelle d'entrée) pour acheminer le trafic vers le side-car ou le microservice correct et deuxièmement, dans le proxy side-car pour acheminer le trafic pour la communication de service à service.

La passerelle API s'engage au niveau d'entrée dans le maillage de service et peut agir comme la première couche de routage plutôt que d'utiliser une passerelle d'entrée. Une passerelle API est donc parfaitement adaptée à la gestion du trafic entrant, remplaçant ainsi la passerelle d'entrée d'un maillage de service permettant uniquement un trafic sécurisé vers le maillage.

5. Outils de surveillance

Les passerelles API et les implémentations de maillage de service se concentrent sur les outils de surveillance, mais elles sont destinées à deux fins différentes. Les maillages de service fournissent des métriques liées aux microservices où chaque side car publie des données relatives à la latence, à l'utilisation des ressources et au débit de chaque microservice attaché au sidecar. Ces données sont utiles pour le personnel de Devops dont le travail consiste à identifier les problèmes dans le maillage de service et leur permet d'isoler les problèmes.

D'un autre côté, une passerelle API surveille le trafic au niveau d'entrée et fournit des informations précieuses concernant l'utilisation des API. Des exemples de ces données incluent l'API qui a les appels les plus fréquents, de quelle zone géographique proviennent les utilisateurs les plus fréquents, quel ensemble d'utilisateurs sont les visiteurs les plus fréquents, combien d'appels d'API ont réussi et combien d'appels ont échoué. Ces types de données peuvent donc être utilisés à des fins analytiques pour concevoir de futures améliorations de la plate-forme. Ils peuvent également donner une idée de la quantité de revenus générée et de la perte de revenus due à des appels défectueux.

Le diagramme ci-dessus explique comment une passerelle API s'intègre dans un maillage de service à la limite de votre déploiement. C'est donc une mauvaise idée de considérer ces deux-là comme des concurrents simplement en regardant les caractéristiques de chacun. Il est préférable de considérer les deux comme complémentaires dans les déploiements impliquant à la fois des microservices et des API.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *