Troisième chapitre : conception de l’architecture Serverless
Section 1 : Architecture Serverless
1.1 Introduction
On a l’habitude de développer et de déployer des applications web où on a le contrôle sur les requêtes HTTP entrantes sur nos serveurs.
Ces applications tournent sur des serveurs et on est responsable de provisionner et de manager leurs ressources, ce qui peut poser problème.
1. On doit maintenir les serveurs disponibles même lorsqu’il n’y a pas de requêtes à traiter.
2. On est responsable de la disponibilité et de la maintenance des serveurs et de leurs ressources.
3. On est également responsables d’appliquer les patches de sécurité sur les serveurs.
4. On doit ajuster les serveurs avec la charge : augmenter lorsque la charge arrive et diminuer lorsque la charge redescend.
Cela peut être très difficile à gérer pour les petites entreprises et les développeurs individuels. Cela finit par nous éloigner de notre mission initiale : construire et maintenir des applications au quotidien.
Dans les grandes organisations, cela relève le plus souvent de la responsabilité de l’équipe infrastructure et rarement des développeurs.
Cependant, les processus nécessaires pour les supporter peuvent ralentir les développements.
On ne peut pas développer d’application sans l’aide de l’équipe infrastructure. En tant que développeurs, on recherche une solution à ces problèmes et c’est là que le serverless entre en jeu.
1.2 L’architecture Serverless
L’architecture serverless est un modèle dans lequel le fournisseur de services cloud (AWS, Azure ou Google Cloud) est responsable de l’exécution d’un morceau de code en allouant de manière dynamique les ressources. Et il ne facture que la quantité de ressources utilisées pour exécuter le code.
Le code est généralement exécuté dans des conteneurs sans état pouvant être déclenchés par divers événements, notamment des requêtes http, des événements de base de données, des services de file d’attente, des alertes de surveillance, des téléchargements de fichiers, des événements planifiés (tâches cron), etc.
Le code envoyé au fournisseur de cloud pour l’exécution est généralement sous la forme d’une fonction.
Par conséquent, serverless est parfois appelé “Functions as a Service” ou “FaaS”. Voici les offres FaaS des principaux fournisseurs de cloud :
– AWS: AWS Lambda
– Microsoft Azure: Azure Functions
Google Cloud: Cloud Functions
Alors que le serverless isole l’infrastructure sous-jacente du développeur, les serveurs sont toujours impliqués dans l’exécution de nos fonctions.
Étant donné que notre code va être exécuté en tant que fonctions individuelles, nous devons être conscients de certaines choses.
1.2.1 Architecture basée sur les microservices
Le plus grand changement auquel on est confrontés lors de la transition vers un monde serverless est que notre application doit être structurée sous forme de fonctions. N
ous avons peut-être l’habitude de déployer des applications monolithiques avec des frameworks comme Express ou Rails. Mais dans le monde serverless, on doit généralement adopter une architecture davantage basée sur le microservice.
Nous pouvons contourner ce problème en exécutant l’intégralité de notre application dans une seule fonction en tant que monolithe et en gérant nous-même le routage.
Mais ceci n’est pas recommandé car il est préférable de réduire la taille de nos fonctions.
Nous en parlerons ci-dessous.
1.2.2 Fonctions sans état
Les fonctions sont généralement exécutées dans des conteneurs sécurisés (presque) sans état (stateless).
Cela signifie qu’on ne peut pas exécuter de code sur les serveurs d’applications, qui s’exécute longtemps après la fin d’un événement ou qui utilise le précédent contexte d’exécution pour répondre à une requête. On doit effectivement supposer que notre fonction est à nouveau invoquée à chaque fois.
Il y a quelques subtilités à cela et nous en discuterons dans la partie suivante.
1.2.3 Démarrage à froid
Comme nos fonctions sont exécutées dans un conteneur qui est créé à la demande pour répondre à un événement, une certaine latence lui est associée.
C’est ce qu’on appelle le démarrage à froid ou Cold Start.
Notre conteneur peut être conservé quelque temps après l’exécution de notre fonction. Si un autre événement est déclenché pendant ce temps, il répond beaucoup plus rapidement et il s’agit du démarrage à chaud ou Warm Start.
La durée des démarrages à froid dépend de la mise en œuvre du fournisseur de cloud spécifique.
Sur AWS Lambda, cela peut aller de quelques centaines de millisecondes à quelques secondes. Cela peut dépendre de l’exécution (ou de la langue) utilisée, de la taille de la fonction (en tant que package) et bien sûr du fournisseur de cloud en question.
Les démarrages à froid se sont considérablement améliorés au fil des années, les fournisseurs de cloud optimisant nettement mieux leurs temps de latence.
Outre l’optimisation de nos fonctions, nous pouvons utiliser des astuces simples, comme une fonction planifiée, pour appeler notre fonction toutes les minutes afin de la maintenir au chaud.
Maintenant qu’on a une bonne idée de l’architecture serverless, regardons de plus près ce qu’est une fonction Lambda et comment notre code va être exécuté.
Ces dernières années, les architectures en microservices ont permis de diminuer le coût de développement. Mais cette migration vient avec son lot de contraintes, parmi lesquelles la gestion lourde et coûteuse de l’infrastructure.
Un nouveau paradigme, celui du serverless vient avec la promesse de diminuer ce coût de gestion de l’infrastructure.
1.3 Serverless, qu’est-ce que c’est ?
Initié par AWS en 2014 avec son service Lambda, le serverless est un modèle de cloud-computing où le développeur n’a plus qu’à fournir son code, sous forme de fonctions, au provider de service serverless ou FAAS (pour Function As A Service).
Afin d’exécuter la logique métier contenue dans cette fonction, il suffit à l’application de requêter le Cloud Provider chez lequel la fonction est hébergée.
Résultat : c’est le CloudProvider qui va se charger de maintenir les serveurs, et de garantir que la fonction continue de répondre chaque fois qu’elle est interrogée13.
Aujourd’hui les principaux Cloud Provider du secteur du serverless sont :
