Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Simplification des opérations
Pour simplifier davantage les efforts opérationnels nécessaires à l'exécution, à la maintenance et à la surveillance des microservices, nous pouvons utiliser une architecture entièrement sans serveur.
Déploiement d'applications basées sur Lambda
Vous pouvez déployer votre code Lambda en chargeant une archive de zip
fichiers ou en créant et en téléchargeant une image de conteneur via l'interface utilisateur de la console à l'aide d'une URI d'image Amazon ECR valide. Toutefois, lorsqu'une fonction Lambda devient complexe, c'est-à-dire qu'elle comporte des couches, des dépendances et des autorisations, le téléchargement via l'interface utilisateur peut s'avérer fastidieux en cas de modification du code.
L'utilisation de AWS CloudFormation and the AWS Serverless Application Model (AWS SAM
Pour déployer, spécifiez les ressources et les politiques d'autorisation dans un CloudFormation modèle, empaquetez les artefacts de déploiement et déployez le modèle. SAM Local, un AWS CLI outil, permet le développement local, le test et l'analyse d'applications sans serveur avant leur téléchargement vers Lambda.
L'intégration avec des outils tels que l' AWS Cloud9 IDE et AWS CodePipeline rationalise la création AWS CodeBuild AWS CodeDeploy, les tests, le débogage et le déploiement d'applications basées sur le SAM.
Le schéma suivant montre le déploiement de AWS Serverless Application Model ressources à l'aide CloudFormation d'outils AWS CI/CD.

Figure 2 : AWS Serverless Application Model (AWS SAM)
Abstraction des complexités liées à la multilocation
Dans un environnement mutualisé tel que les plateformes SaaS, il est essentiel de rationaliser les subtilités liées à la mutualisation, afin de permettre aux développeurs de se concentrer sur le développement des fonctionnalités. Cela peut être réalisé à l'aide d'outils tels que AWS Lambda Layers, qui proposent des bibliothèques partagées pour répondre à des préoccupations transversales. La raison d'être de cette approche est que les bibliothèques et les outils partagés, lorsqu'ils sont utilisés correctement, gèrent efficacement le contexte des locataires.
Cependant, ils ne devraient pas s'étendre à l'encapsulation de la logique métier en raison de la complexité et des risques qu'ils peuvent introduire. L'un des problèmes fondamentaux des bibliothèques partagées est la complexité croissante des mises à jour, qui les rend plus difficiles à gérer par rapport à la duplication de code standard. Il est donc essentiel de trouver un équilibre entre l'utilisation de bibliothèques partagées et la duplication dans la recherche de l'abstraction la plus efficace.
Gestion des API
La gestion APIs peut prendre beaucoup de temps, en particulier lorsqu'il s'agit de plusieurs versions, d'étapes du cycle de développement, d'autorisations et d'autres fonctionnalités telles que la limitation et la mise en cache. Outre API Gateway
La figure 3 montre comment API Gateway gère les appels d'API et interagit avec les autres composants. Les demandes provenant d'appareils mobiles, de sites Web ou d'autres services principaux sont acheminées vers le CloudFront point de présence (PoP) le plus proche afin de réduire la latence et d'offrir une expérience utilisateur optimale.

Figure 3 : flux d'appels API Gateway