Mises à jour des Patterns d’Architecture Serverless et meilleures pratiques

8 Septembre 2021 : Amazon Elasticsearch Service a été renommé en Amazon OpenSearch Service. Voir les détails.

Alors que nous sommes presque à re:Invent 2019, nous aimerions revenir sur certaines annonces récentes que nous avons faites cette année sur le Serverless. Tous ces modèles s’ajoutent aux modèles discutés dans la session Serverless Architectural Patterns and Best Practices de la track architecture de re:Invent.

AWS Event Fork Pipelines

AWS Event Fork Pipelines a été annoncé en mars 2019. De nombreux clients utilisent un traitement asynchrone axé sur les événements dans leurs applications serverless pour découpler les composants d’une application et répondre aux besoins de concurrence élevés. Et ce faisant, ils ont souvent besoin de sauvegarder, de rechercher, d’analyser ou de rejouer ces événements asynchrones. C’est exactement ce que vise AWS Event Fork Pipelines. Vous pouvez les brancher à un topic SNS nouveau ou existant utilisé par votre application et répondre immédiatement aux besoins de rétention et de conformité, obtenir de nouvelles perspectives métier ou même améliorer les capacités de reprise sur erreur de votre application.

AWS Event Fork Pipelines est une suite de trois applications. La première application répond aux besoins de stockage d’événements et de sauvegarde en écrivant tous les événements dans un compartiment S3 où ils peuvent être interrogés avec des services comme Amazon Athena. Le second est un pipeline de recherche et d’analyse qui fournit des événements à un domaine Amazon ElasticSearch nouveau ou existant, permettant ainsi la recherche et l’analyse de vos événements. Enfin, la troisième application est un pipeline de relecture d’événements qui peut être utilisé pour retraiter les messages en cas d’échec en aval dans votre application. AWS Event Fork Pipelines est disponible dans les modèles AWS Serverless Application Model (SAM) et sont disponibles dans AWS Serverless Application Repository (SAR). Consultez notre exemple d’application e-commerce sur GitHub.

Amazon API Gateway Serverless Developer Portal

Si vous publiez des API pour les développeurs qui leur permettent de créer de nouvelles applications et des fonctionnalités avec vos données, vous comprenez la nécessité d’un portail pour développeurs. Aussi, en mars 2019, nous avons annoncé des mises à niveau importantes du portail API Gateway Serverless Developer Portal. Le frontal du portail est écrit en React et est conçu pour être entièrement personnalisable. Le portail API Gateway Serverless Developer Portal est également disponible dans GitHub et AWS SAR. Comme vous pouvez le voir dans le diagramme d’architecture ci-dessous, il est intégré aux pools d’utilisateurs Amazon Cognito pour permettre aux développeurs de s’inscrire, de recevoir une clé API et de s’inscrire à une ou plusieurs de vos API. Vous pouvez activer des scénarios administratifs à partir de votre portail développeur en vous connectant en tant qu’utilisateurs appartenant au groupe Admin du portail. Le groupe Admin a été créé lors du déploiement initial du portail sur votre compte. Par exemple, vous pouvez contrôler les API qui apparaissent dans le portail développeur d’un client, activer les téléchargements du SDK, solliciter des commentaires des développeurs et même publier des mises à jour pour les API qui ont été récemment révisées.

AWS Lambda with Amazon Application Load Balancer (ALB)

Les microservices AWS Lambda ont été créés par nos clients depuis un certain temps (2015), avec AWS Lambda et Amazon API Gateway. Lors de RE:Invent 2018 et du discours d’ouverture de Dr. Werner Vogel, une nouvelle approche des microservices serverless a été annoncée, Lambda peut fonctionner comme une cible d’un ALB.
La prise en charge par ALB des Lambda permet aux clients de déployer du code serverless derrière un ALB, juste à côté de serveurs, des conteneurs ou encore d’adresses IP. Avec cette fonctionnalité, les chemins relatifs de l’ALB et le routage basé sur l’hôte peuvent être utilisés pour diriger les demandes entrantes vers les fonctions Lambda. En outre, ALB permet ainsi de migrer à partir de serveurs legacy monolithiques ou des applications basées sur des conteneurs, vers des fonctions Lambda par simple routage.
Les cas d’utilisation des Lambda pour ALB incluent l’ajout de nouvelles fonctionnalités à une application existante qui se trouve déjà derrière un ALB. Cela peut être la surveillance des demandes en envoyant des en-têtes http aux clusters Elasticsearch ou en implémentant des contrôles qui gèrent les cookies. Découvrez notre démo de cette nouvelle fonctionnalité. Pour plus de détails, consultez la documentation de la fonctionnalité.

Livre blanc sur la sécurité d’AWS Lambda

Enfin, nous manquerions à nos devoirs si nous ne soulignons pas l’excellent travail accompli par de nombreux collègues sur la publication du livre blanc sur la sécurité d’AWS Lambda. Il s’agit d’une lecture succincte et éclairante pour tous ceux qui souhaitent mieux comprendre l’environnement d’exécution Lambda, l’isolation des fonctions ou les chemins de données pris pour les requêtes envoyées au service Lambda lors d’appels synchrones et asynchrones. Il dispose également d’un excellent aperçu de la conformité, de l’audit, de la surveillance et de la gestion de la configuration de vos fonctions Lambda. Une lecture incontournable pour tous ceux qui souhaitent mieux comprendre la sécurité globale des applications AWS sans serveur (serverless).
Nous avons hâte de voir tout le monde à re:Invent 2019 pour des annonces plus excitantes sur le serverless !

A Propos des l’auteurs

• Drew Dennis est un Solutions Architect Global AWS basé à Dallas, au Texas. Il est accroc au Serverless et a présenté la session « Serverless Patterns and Best Practices » du domaine Architecture à re:Invent au cours des trois dernières années. Aujourd’hui, il aide les entreprises automobiles à effectuer des recherches sur la conduite autonome sur AWS, des cas d’utilisation de voitures connectées et de l’électrification.
• Traduit en français par Maxime Thomas, Solutions Architect partenaires.

Source