Dans la vidéo intitulée "Quoi de Mieux que les Microservices ? Les Microservices Sans-Serveur.", Alan Williams (Autodesk), Asha Chakrabarty (Amazon) et Alan Ho (Apigee) débattent à propos de l'architecture d'un microservice sans serveur construit avec des fonctions lambdas et des points d'extrémité Apigee s'exécutant sur AWS.
Chakrabarty y dit que sans-serveur est un style d'architecture relativement novateur dans lequel l'unité de calcul n'est pas une machine virtuelle mais plutôt une fonction encapsulant le code à exécuter lorsqu'un évènement se produit. Williams notait que les caractéristiques principales du modèle de calcul sans-serveur sont : concentré sur le code, pas de serveur à gérer, aucune instance EC2 à provisionner ni à administrer, pas de mise à l'échelle manuelle, pas de ressources inoccupées, pas de SSH, ni de RDP.
Le diagramme suivant illustre l'architecture simplifiée d'un microservice sans-serveur implémenté par Autodesk :
Le microservice a de multiples points d'entrée exposés comme des points d'extrémité HTTP gérés par Apigee. L'utilisateur fait un appel HTTP, sans savoir que la requête est servie par un microservice sans-serveur. Le microservice est composé d'un certain nombre de fonctions lambda écrites en Python et communiquant entre elles via des notifications asynchrones SNS d'AWS. Les fonctions lambda sont indépendantes entre elles et peuvent être développées dans des langages différents et maintenues par des équipes différentes.
Comme les fonctions lambda ont une durée de vie courte, elles doivent persister leur état quelque part, l'une des options étant les tables DynamoDB. L'accès à ces tables est contrôlé par des rôles IAM et limité uniquement aux fonctions qui doivent les lire/écrire. Cela évite une exposition inutile aux données de certaines fonctions lambda et diminue la surface d'attaque du microservice en cas de faille de sécurité. Autodesk a choisi de stocker l'état dans DynamoDB à cause de sa simplicité en passant les données en JSON, sans avoir besoin d'administrer une instance de serveur et avec le support de mise à l'échelle automatisé.
La table DynamoDB en bas du diagramme (talr-taskstatus) persiste l'état de multiples fonctions lambda et génère un flux d'évènements lorsque la table est modifiée. Ces évènements sont surveillés par une autre fonction lambda (talr-validator) qui fait ce qui est nécessaire.
Williams a mentionné les points suivants en ce qui concerne les bénéfices d'implémentation d'une architecture sans-serveur sur AWS :
- Agilité. L'implémentation n'a nécessité que quelques semaines.
- Pas d'infrastructure à administrer. Pas d'instances EC2 ou ELB. Pas de patchs de sécurité.
- Les développeurs ne doivent se concentrer que sur le code qu'ils écrivent.
- La capacité de gérer le code avec les Frameworks Sans-Serveur.
- Le coût. D'après leur expérience, exécuter la solution lambda ne coûte qu'une petite fraction (~1%) de l'approche cloud traditionnelle. Les coûts sont réduits d'autant par le fait de ne pas avoir à payer une équipe opérationnelle pour mettre en place et surveiller les instances EC2 et ELB.
Williams a également mentionné que l'architecture sans-serveur n'est pas adaptée pour exécuter des charges de travail sur une longue durée ou des applications tierces. Dans ce cas, un container est plus adapté.
La session comprend une démo sur l'organisation du code, son déploiement et son exécution sur AWS via le framework Serverless.