Cet article décrit comment l’équipe Microsoft Commercial Software Engineering (CSE) s’est associée à un détaillant international pour déployer une solution serverless hautement disponible sur les plateformes cloud Azure et Amazon Web Services (AWS), à l’aide de Serverless Framework.
Architecture
Téléchargez un fichier Visio de cette architecture.
Dataflow
- L’application utilisateur peut provenir de n’importe quelle source capable de se connecter au cloud. Dans cette implémentation, l’utilisateur se connecte à une application de passerelle qui équilibre la charge des requêtes de manière égale entre les clouds Azure et AWS.
- Toute réponse est également routée par le biais de la passerelle du gestionnaire d’API, qui l’envoie ensuite à l’application du demandeur.
Composants
Serverless Framework
Cette solution utilise Serverless Framework, disponible auprès de Serverless, Inc. La version gratuite de Serverless Framework comprend une interface CLI, des plug-ins supplémentaires et des services de monitoring limités. L’édition Pro offre des fonctionnalités opérationnelles sur plusieurs clouds, telles que la supervision et des alertes avancées. Le framework prend en charge les langages Node.js et Python, ainsi que les hôtes de cloud AWS et Azure.
Pour utiliser Azure avec Serverless Framework, vous avez besoin des éléments suivants :
- Node.js, pour empaqueter des microservices
- Azure Functions, pour fournir des fonctionnalités comparables à celles d’autres plateformes cloud
- Serverless Framework, pour prendre en charge le déploiement et la supervision multiclouds
- La bibliothèque multicloud serverless, afin de fournir des API de runtime normalisées pour les développeurs
- Le plug-in serverless Azure Functions, afin de prendre en charge le déploiement multicloud. Ce plug-in n’était initialement pas au niveau du plug-in AWS Lambda comparable, et a été étendu pour ce projet.
L’illustration suivante montre le pipeline de traitement. Les couches middleware représentent les fonctionnalités intermédiaires nécessaires avant d’atteindre le gestionnaire.
API indépendantes du cloud
L’implémentation serverless sur chaque plateforme prend en charge des fonctions individuelles en tant que microservices, une par nœud de machine virtuelle fonctionnel, et exécute le traitement en fonction des besoins. Chaque fonction AWS Lambda a une fonction Azure Functions correspondante. La bibliothèque multicloud serverless génère des microservices analogues à partir de l’un ou l’autre cloud dans une API REST normalisée indépendante du cloud que les applications clientes peuvent utiliser pour interagir avec l’une ou l’autre plateforme. Étant donné que la couche d’API abstraite fournit du code afin de traiter les microservices correspondants pour chaque plateforme, les transactions n’ont pas besoin de traduction. L’interface indépendante du cloud permet aux applications utilisateur d’interagir avec le cloud sans se soucier ou connaître la plateforme cloud à laquelle elles accèdent.
Le schéma suivant illustre ce concept :
CI/CD avec GitOps
L’une des principales fonctions de Serverless Framework consiste à faire abstraction de tous les aspects de l’infrastructure liés au déploiement d’une application dans le cloud. Grâce à une approche basée sur manifeste, Serverless Framework peut gérer tous les aspects du déploiement, ce qui permet d’automatiser le déploiement en fonction des besoins pour prendre en charge GitOps.
Bien que ce projet initial utilisait des déploiements manuels, il est tout à fait réaliste d’implémenter des builds, des tests et des déploiements serverless basés sur manifeste dans ou entre des clouds. Ce processus peut utiliser un workflow de développement GitOps : génération à partir de Git, utilisation de barrières qualité pour les tests et l’évaluation, et envoi (push) des solutions serverless sur les deux fournisseurs de cloud. L’exécution de tous les déploiements à l’aide de Serverless Framework dès le début du projet est la manière la plus efficace de procéder.
Gestionnaire d’API
Le gestionnaire d’API peut être une application existante ou personnalisée. Le gestionnaire d’API Apigee™ dans cette implémentation agissait seulement en tant que routeur afin d’équilibrer la charge des transactions de manière égale sur les deux plateformes cloud, et ses fonctionnalités étaient sous-exploitées.
Le gestionnaire d’API doit pouvoir :
- Être déployé dans ou en dehors d’une plateforme cloud en fonction des besoins.
- Router les messages vers et à partir des deux plateformes cloud.
- Journaliser les requêtes de trafic afin de coordonner le trafic asynchrone des messages.
- Relayer les requêtes et les réponses à l’aide de l’API REST commune vers et à partir de l’application utilisateur.
- Superviser l’intégrité des deux déploiements de framework serverless cloud afin de valider leur capacité à recevoir des requêtes.
- Effectuer des vérifications automatisées de l’intégrité et de la disponibilité sur chaque plateforme cloud, afin de prendre en charge le routage et la haute disponibilité.
Autres solutions
D’autres langages tels que Python peuvent implémenter la solution, à condition d’être pris en charge par les implémentations serverless des plateformes cloud, AWS Lambda et Azure Functions dans le cas étudié ici. Ce projet utilisait Node.js pour empaqueter les microservices, car le client avait une prédilection pour Node.js et les plateformes AWS et Azure le prennent en charge.
La solution peut utiliser n’importe quelle plateforme cloud qui prend en charge Serverless Framework, pas seulement Azure et AWS. Actuellement, Serverless Framework est compatible avec huit fournisseurs de cloud différents. La seule exigence est de s’assurer que les éléments qui prennent en charge l’architecture multicloud ou son équivalent sont disponibles sur les plateformes cloud cibles.
Le gestionnaire d’API dans cette implémentation agissait seulement en tant que routeur afin d’équilibrer la charge des transactions de manière égale sur les deux plateformes cloud. Le gestionnaire d’API peut incorporer d’autres logiques métier pour des scénarios spécifiques.
Détails du scénario
Dans l’informatique serverless, le fournisseur de cloud alloue dynamiquement des ressources de microservices pour exécuter du code, et ne facture que les ressources utilisées. L’informatique serverless effectue l’abstraction du code d’application de l’implémentation de l’infrastructure, du déploiement du code et des aspects opérationnels tels que la planification et la maintenance.
Comme pour les autres services, chaque fournisseur de cloud a sa propre implémentation serverless, et il est difficile pour les clients d’utiliser un autre fournisseur sans impact significatif sur le fonctionnement et les coûts. Les clients potentiels peuvent considérer cette situation comme affaiblissant leur agilité et position concurrentielles. Le verrouillage du fournisseur est l’un des plus grands obstacles à l’adoption du cloud d’entreprise.
Le Serverless Framework open source est une interface cloud universelle pour le développement et le déploiement de solutions informatiques serverless entre fournisseurs de cloud. Les API communes et open source pour les fonctions serverless permettent aux fournisseurs, clients et partenaires de créer des solutions interclouds pour des services de qualité optimale. Serverless Framework réduit les obstacles à l’adoption du cloud en résolvant les problèmes de verrouillage du fournisseur et de redondance de fournisseurs interclouds. Les clients peuvent optimiser leurs solutions en fonction du coût, de l’agilité et autres facteurs.
Les équipes de produit Azure et CSE ont réécrit ensemble l’interface CLI serverless afin de prendre en charge de nouvelles fonctionnalités Azure Functions telles que les fonctions Premium, Gestion des API et Key Vault. L’interface CLI serverless fournit désormais une interface standard pour le déploiement GitOps sur Azure et AWS. L’équipe a également développé la bibliothèque multicloud serverless, qui fournit une API de runtime normalisée pour déployer des applications serverless sur AWS et Azure.
Cette conception offre une haute disponibilité avec un basculement actif-actif entre plusieurs plateformes cloud, par opposition à un basculement actif-passif. Si le service d’un fournisseur de cloud n’est plus sain ou disponible, cette solution peut rerouter les requêtes vers une autre plateforme cloud.
Ce projet répond aux objectifs techniques suivants :
- Création d’une solution inter-sectorielle.
- Utilisation de la bibliothèque serverless multicloud pour prendre en charge une API indépendante du cloud qui procure une interface avec des microservices, où qu’ils soient déployés.
- Prise en charge d’un workflow de processus CI/CD GitOps pour le développement, les tests et le déploiement sur toutes les plateformes cloud prises en charge.
- Utilisation de l’accès basé sur API par le biais d’une passerelle cloud authentifiée, et équilibrage de la charge entre les plateformes cloud en utilisant la passerelle comme routeur.
Voici d’autres avantages potentiels de l’utilisation de Serverless Framework :
- Prévention ou réduction du verrouillage du fournisseur
- Réduction de 40 à 60 % du code lors du développement à l’aide de la bibliothèque serverless multicloud
- Développement de solutions de pointe qui combinent différents services de fournisseurs de cloud
- Élimination de la plupart des exigences en matière de maintenance et de complexité des plateformes et des infrastructures
- Simplification du partage de données et de la comparaison des performances et des coûts, et possibilité de bénéficier d’offres spéciales
- Haute disponibilité actif-actif
Cas d’usage potentiels
- Écriture d’applications côté client pour plusieurs plateformes à l’aide d’une API indépendante du cloud à partir de la bibliothèque multicloud serverless
- Déploiement d’une collection de microservices fonctionnels dans un framework serverless sur plusieurs plateformes cloud
- Utilisation d’une application indépendante du cloud sur différentes plateformes cloud sans avoir à se soucier ou à connaître la plateforme qui l’héberge
Considérations
Cet article ne décrit pas les solutions de sécurité, bien que le déploiement initial les incluait. Il existe de nombreuses solutions de sécurité, certaines dépendantes de la plateforme, et ce framework doit prendre en charge toute solution raisonnable. L’authentification utilisateur est la sécurité minimale supposée.
Étant donné qu’il est difficile d’expliquer les différences entre les offres fonctionnelles serverless AWS et Azure, les efforts initiaux doivent être axés sur le mappage des fonctions disponibles sur chaque plateforme cloud et sur l’identification des exigences relatives aux transformations nécessaires. Vous pouvez développer une API indépendante de la plateforme à partir de ces informations.
L’utilisation d’une solution open source peut entraîner des risques, en raison de la maintenance à long terme et des défis en matière de support liés à tous les logiciels open source.
Dans la version gratuite de Serverless Framework, la supervision se limite principalement au tableau de bord d’administration. Le monitoring est disponible dans l’offre professionnelle payante. Actuellement, le plug-in serverless Azure Functions n’offre rien en matière d’observation ou de supervision, et nécessiterait une modification pour implémenter ces fonctionnalités.
Cette solution pourrait utiliser des métriques afin de comparer les performances et les coûts entre les plateformes cloud, permettant ainsi aux clients d’optimiser avec fluidité l’utilisation parmi les plateformes cloud.
Déployer ce scénario
Un déploiement traditionnel bleu-vert développe et déploie une application dans deux environnements distincts mais identiques, bleu et vert, renforçant ainsi la disponibilité et réduisant les risques. L’environnement bleu est généralement l’environnement de production, qui gère habituellement le trafic en direct, tandis que l’environnement vert est un déploiement de basculement disponible en cas de besoin. En règle générale, le pipeline CI/CD déploie automatiquement les environnements bleu et vert au sein de la même plateforme cloud. Cette configuration est considérée comme une configuration actif-passif.
Dans la solution multicloud, le déploiement bleu-vert est implémenté dans les deux plateformes cloud. Dans le cas serverless, deux jeux de microservices dupliqués sont déployés pour chaque plateforme cloud, l’un en tant qu’environnement de production et l’autre en tant qu’environnement de basculement. Cette configuration actif/passif au sein de chaque plateforme cloud réduit le risque de défaillance de cette plateforme, améliorant ainsi sa disponibilité autorisant une haute disponibilité actif-actif multicloud.
Un avantage secondaire du déploiement bleu-vert est la possibilité d’utiliser le déploiement de basculement sur chaque plateforme cloud en tant qu’environnement de test pour les mises à jour de microservices, avant de les publier dans le déploiement de production.