Gestion des API hybrides et multi-cloud : défis et choix

1. Multi-Cloud et Hybrid Cloud

Les microservices sont devenus une méthode d'architecture logicielle populaire où les organisations décomposent leurs produits en microservices individuels en fonction de leur compréhension de leur propre activité et en utilisant des méthodes scientifiques telles que la conception pilotée par le domaine. La structure organisationnelle est également ajustée pour s'aligner sur l'architecture des microservices, conformément à la loi de Conway, afin de soutenir le développement itératif de l'activité.

Dans le passé, les organisations construisaient leurs propres centres de données pour déployer leurs produits. Ces centres de données pouvaient être situés dans des installations louées ou achetées, et les organisations étaient responsables de la gestion de l'infrastructure complexe, telle que les commutateurs, les serveurs, le stockage, les racks et autres matériels. Elles devaient également faire face aux problèmes causés par les pannes de courant, les températures élevées des racks, les plantages de serveurs, etc. Gérer de tels problèmes nécessitait souvent beaucoup de ressources humaines et financières sans obtenir de bons résultats. Par conséquent, le SLA (accord de niveau de service) des produits propres des organisations ne parvenait souvent pas à respecter les promesses faites aux clients, entraînant des compensations.

Avec l'essor du cloud, les gens se sont de plus en plus habitués à déployer leurs activités sur des clouds publics. Les clouds publics aident les utilisateurs à abstraire les détails de l'infrastructure matérielle, permettant aux ingénieurs de se concentrer sur le déploiement, la maintenance et le développement de leur activité. Cependant, en plus de la commodité offerte par le cloud, son essor et son utilisation posent également d'autres problèmes pour les utilisateurs :

• Enfermement : Lorsqu'un produit d'un fournisseur de cloud est profondément intégré à une activité, il devient très difficile de déplacer cette activité vers un autre cloud ou de quitter complètement le cloud. Cela est particulièrement courant pour les produits PaaS ou SaaS qui ont un lien fort avec l'activité. Malheureusement, cela se produit souvent lorsque l'activité est en période de croissance rapide et que les décideurs négligent l'effet de liaison de l'utilisation des produits cloud.
• Problèmes de disponibilité : Le principe de diversification s'applique ici, ce qui signifie que nous ne mettons pas tous nos œufs dans le même panier. Pendant la phase de montée en puissance d'une activité, les organisations donnent souvent la priorité au lancement rapide des produits et à la capture de parts de marché, en négligeant l'infrastructure. Cela peut entraîner des pannes de courant ou des coupures de câbles dans une région cloud, ce qui a un impact négatif sur l'activité.

Par conséquent, les gens s'habituent de plus en plus à utiliser plusieurs clouds publics ou à construire des clouds privés en plus d'utiliser des clouds publics pour éviter les problèmes mentionnés ci-dessus. Cette approche est communément appelée "multi-cloud" et "hybrid cloud".

"Multi-cloud" fait référence à l'utilisation simultanée de plusieurs clouds publics, en déployant l'activité de manière miroir ou hétérogène sur ces clouds. Il utilisera autant que possible des services standard (pour éviter l'enfermement par un fournisseur). En raison de l'utilisation du multi-cloud, lorsqu'un cloud devient indisponible, l'impact sur l'activité peut être minimisé, et il est possible d'assurer la continuité de l'activité en modifiant la résolution DNS et en activant un cloud de secours.

"Hybrid cloud" fait référence aux organisations qui, en plus d'utiliser un ou plusieurs clouds publics, possèdent également leurs propres clouds privés (ou centres de données). Dans ce scénario, certains services pourraient être déployés sur des clouds privés, tandis que d'autres peuvent être déployés sur des clouds publics. Ou tous les services sont déployés sur le cloud, et le cloud privé est responsable de la gestion et de la surveillance. Dans tous les cas, la flexibilité et la disponibilité du déploiement des logiciels sont grandement améliorées après l'adoption du modèle "multi-cloud" ou "hybrid cloud".

Cependant, la mise en œuvre des stratégies "multi-cloud" et "hybrid cloud" peut rendre la gestion des microservices basés sur le cloud plus complexe. Un défi courant est la gestion des API, car de nombreux microservices dépendent des API pour communiquer. Par conséquent, lors du déploiement des microservices, leurs API doivent être exposées à l'extérieur pour permettre des connexions avec des parties externes et fournir des services.

2. Le besoin de gestion des API dans les scénarios Multi-Cloud et Hybrid Cloud

Comme nous le savons, une bonne passerelle API est cruciale pour la gestion des API des microservices. La passerelle API permet une exposition sécurisée et efficace des API des microservices. Cependant, lors de la mise en œuvre des stratégies "multi-cloud" et "hybrid cloud", le besoin d'une passerelle API va au-delà de sa fonctionnalité de base. Plus précisément, des considérations telles que :

La prise en charge de la gestion multi-clusters

Comme mentionné précédemment, lors de la mise en œuvre des stratégies "multi-cloud" ou "hybrid cloud", les services déployés dans chaque cloud ou centre de données privé peuvent varier considérablement. Par conséquent, les utilisateurs peuvent avoir besoin de déployer des clusters de passerelles API séparés dans chaque cloud avec des configurations, des certificats et des clés API différents. Si la passerelle choisie ne prend pas en charge la gestion multi-clusters, cela peut causer des difficultés importantes dans la gestion des API, en particulier pendant les périodes d'expansion de l'activité lorsque le nombre et l'échelle des clusters de passerelles augmentent.

Dans de tels cas, un produit de passerelle API qui prend en charge la gestion multi-clusters peut réduire considérablement les coûts de gestion pour les administrateurs.

1. Les utilisateurs ont accès à une console unifiée pour sélectionner le cluster qu'ils souhaitent configurer et surveiller. Ils peuvent également mettre un cluster de passerelle en ligne ou hors ligne, en fonction de la situation actuelle du déploiement de l'activité.
2. Les utilisateurs peuvent voir l'état de fonctionnement de tous ces clusters de passerelles API sur la console, y compris le QPS courant, la latence, l'utilisation du CPU et de la mémoire des clusters de passerelles, etc.

La prise en charge de la collaboration

Avec le développement rapide de l'activité, un petit nombre d'administrateurs de passerelles API peuvent avoir besoin d'aide pour gérer et maintenir tous les clusters de passerelles API par eux-mêmes. Par ailleurs, de nombreuses configurations de passerelles, telles que l'ajout de routes et la configuration de plugins, peuvent être gérées par les développeurs, réduisant ainsi le besoin d'une implication importante des administrateurs. Par conséquent, la prise en charge de la "collaboration" devient essentielle pour la gestion.

Plus précisément, les administrateurs peuvent inviter d'autres membres de l'organisation à rejoindre la gestion du cluster de passerelles API en utilisant RBAC (contrôle d'accès basé sur les rôles) ou d'autres stratégies pour attribuer des permissions différentes aux membres de l'équipe. Par exemple, définir le rôle de Administrateur de l'organisation (capable d'effectuer toute opération) pour l'administrateur et Administrateur de service (capable de maintenir uniquement quelques services et routes) pour le développeur général. Cette approche garantit la sécurité des opérations tout en mettant en œuvre la collaboration. Elle facilite également la récupération rapide des comptes ou la modification des permissions en cas de départ d'un employé ou de changement de poste.

La capacité à fonctionner sur n'importe quelle infrastructure

Avec la maturité des technologies de conteneurisation et d'orchestration de conteneurs, de nombreux microservices passent des machines virtuelles à l'exécution sur Kubernetes. Cela signifie que les utilisateurs peuvent utiliser Kubernetes, des machines virtuelles traditionnelles ou même des machines physiques, comme dans leurs centres de données privés. Si le produit de passerelle API choisi par l'utilisateur est riche en fonctionnalités et répond aux besoins de l'activité mais est limité par l'infrastructure sous-jacente ou manque d'outils d'installation matures, cela peut créer un défi pour l'utilisateur, soit d'abandonner son utilisation, soit de réaliser des développements supplémentaires pour permettre à la passerelle API de fonctionner sur certaines infrastructures. Dans les deux cas, cela entraînera des coûts d'utilisation supplémentaires.

3. Décisions

Comme discuté, il devient extrêmement vital de choisir la bonne passerelle API dans le contexte des scénarios "multi-cloud" et "hybrid cloud". Certaines options courantes sont listées, et les utilisateurs doivent les analyser en fonction de leurs scénarios réels et de leurs plans futurs.

Différentes solutions sur différents clouds

Typiquement, chaque fournisseur de cloud public propose sa propre solution de passerelle API intégrée, et les utilisateurs peuvent envisager d'acheter une solution de passerelle API pour chaque cloud.

Les avantages incluent :

1. Un coût d'utilisation extrêmement faible, sans besoin de déploiement ou de maintenance.
2. Prend généralement en charge le paiement à l'utilisation ; une utilisation précoce peut ne nécessiter que des coûts minimaux.

Les inconvénients incluent :

1. L'utilisation des passerelles API sur différents clouds est souvent incompatible entre elles, donc compléter la même configuration nécessite des chemins différents.
2. Les fonctionnalités des produits ne sont pas symétriques entre les différents fournisseurs. Par exemple, un fournisseur peut prendre en charge mTLS tandis qu'un autre ne le fait pas.
3. Dans le scénario "hybrid cloud", il peut être nécessaire de choisir une autre passerelle API open source ou commerciale et de la déployer sur le cloud privé de l'utilisateur.

Lors de l'utilisation de cette approche, obtenir une expérience utilisateur cohérente entre les différents fournisseurs de cloud peut nécessiter une personnalisation du produit, le développement d'un outil de synchronisation des configurations et l'abstraction des détails sous-jacents. Cela peut impliquer des recherches, des analyses et des développements supplémentaires de la part de l'utilisateur. Les utilisateurs peuvent rencontrer des problèmes de compatibilité et une fonctionnalité limitée et ne pourront utiliser que quelques fonctionnalités communes des produits de passerelle API. De plus, la possibilité d'un échec de synchronisation doit également être prise en compte.

Bien sûr, les utilisateurs peuvent également répéter manuellement la configuration de chaque passerelle API sur chaque cloud (s'ils peuvent le tolérer).

Solution de passerelle API open source

Comme alternative à l'utilisation de différentes solutions sur différents clouds, les utilisateurs peuvent envisager d'utiliser des solutions de passerelle API open source telles que Apache APISIX, Kong, Tyk, Traefik, etc. Cette approche permet aux utilisateurs d'utiliser la même passerelle API sur tous les clouds, y compris les centres de données privés, évitant ainsi les problèmes de compatibilité entre les différentes solutions. Une passerelle API open source mature et robuste peut aider les utilisateurs à résoudre de nombreux problèmes dans différents scénarios. Même si elle ne couvre pas tous les scénarios, ces passerelles API permettent généralement aux utilisateurs de les étendre de diverses manières. Par exemple, Apache APISIX permet aux utilisateurs de l'étendre en utilisant des langages et des technologies tels que Go, Java, Python, Lua, WASM, etc.

Cependant, ces passerelles API open source adoptent généralement une stratégie open source Open Core, où les fonctionnalités de base du produit sont open source, mais les capacités de gestion de niveau entreprise telles que la console visuelle, la gestion multi-clusters, l'audit, SSO (Single Sign-On), etc., sont souvent payantes (intégrées dans leurs produits commerciaux). Si les utilisateurs ne souhaitent pas les payer, ils ne peuvent que choisir de développer leur propre plateforme de gestion (également appelée plan de contrôle de la passerelle) pour gérer ces passerelles API, ce qui signifie que les utilisateurs doivent embaucher un ingénieur à temps plein pour assumer ce travail de développement.

Acheter un service SaaS de passerelle API de niveau entreprise

Si les passerelles API open source répondent aux exigences en termes de fonctionnalités, mais que le coût de l'auto-recherche du contrôle n'est pas acceptable, les utilisateurs peuvent également envisager de contacter les fabricants d'origine de ces logiciels open source (tels que API7.ai derrière Apache APISIX, Kong Inc derrière Kong, et Tyk Inc derrière Tyk, etc.). Ces fabricants proposent souvent différents produits et services de support de passerelle API de niveau entreprise. Surtout dans le scénario "multi-cloud" et "hybrid cloud", ces fabricants ont successivement publié leurs produits SaaS. Les produits SaaS de la passerelle API se concentrent souvent sur le côté gestion, fournissant une console prête à l'emploi sans se soucier de l'endroit où l'instance de la passerelle API est déployée (bien sûr, certains services SaaS prennent également en charge l'hébergement de l'instance de la passerelle API, mais cela introduit souvent d'autres problèmes, tels que la latence lors du proxy des API).

Les services SaaS fournissent généralement un panneau de contrôle de passerelle privé pour chaque locataire, le connectant aux instances de passerelle déployées par l'utilisateur (ou hébergées par SaaS) en utilisant des stratégies telles que mTLS pour garantir la sécurité et la confidentialité des données, et fournir des capacités de gestion. Bien que l'achat d'un service SaaS puisse nécessiter un investissement, il peut être plus rentable que d'embaucher un ingénieur dédié pour maintenir une passerelle API et son panneau de contrôle.

Bien sûr, l'achat de services SaaS nécessite de la prudence. Par conséquent, avant de confirmer une commande, les utilisateurs doivent évaluer un service SaaS à partir des aspects suivants :

1. Ce service SaaS peut-il répondre aux besoins d'utilisation actuels et futurs ?
2. Le fournisseur de services SaaS est-il professionnel et digne de confiance ? Quels sont les cas d'utilisation qu'ils ont ?
3. Ce service SaaS est-il conforme, conforme au GDPR, et dispose-t-il de rapports d'audit SOC2 ?
4. Ce service SaaS a-t-il des termes de SLA clairs ?
5. Comment ce service SaaS est-il facturé ? Les utilisateurs peuvent-ils estimer les dépenses futures pour un an ou quelques années ?

Développement entièrement autonome

Si les solutions de passerelle API open source ne répondent pas aux besoins réels de l'utilisateur, les utilisateurs peuvent envisager de développer leur propre produit de passerelle API exclusif, ce qui peut être long et coûteux en ressources, et la stabilité de la passerelle est également une préoccupation majeure. Développer une passerelle API n'est pas aussi difficile que de mettre en œuvre une base de données relationnelle ou un navigateur, mais ce n'est pas quelque chose qui peut être fait du jour au lendemain ; par conséquent, l'auto-développement peut être considéré comme "la pire stratégie". Par conséquent, il n'est souvent considéré qu'en dernier recours.

4. Conclusion

Dans un environnement cloud-native, la gestion des API dans les scénarios "multi-cloud" et "hybrid cloud" sera un défi pour chaque organisation, même avant l'adoption de ces stratégies. Par conséquent, bien que cet article présente diverses options, il est essentiel de garder à l'esprit qu'il n'existe pas de solution universelle, et les utilisateurs doivent sélectionner l'option qui correspond le mieux à leurs besoins commerciaux spécifiques et à leurs objectifs de développement.

Pour plus d'informations sur la passerelle API, veuillez visiter notre blog ou nous contacter.