La gestion de l’état Gestion de l’état

Comme évoqué plusieurs fois déjà, les fonctions Lambda sont nativement sans état. Cela signifie que, vu le processus d’extension expliqué plus haut dans ce chapitre, il serait impossible de garantir qu’un état conversationnel, appelé aussi « affinité », soit établi avec des clients, de manière à ce que des requêtes émanant du même client soient systématiquement traitées par les mêmes instances Lambda. En d’autres termes, il serait irraisonnable de considérer que l’état local d’une fonction Lambda lors d’une certaine requête, c’est-à-dire le contexte présent en mémoire ou sauvegardé au niveau du file-system, soit le même que lors d’une autre requête. C’est donc dans ce sens que l’on dit que les fonctions Lambda sont sans état.

Néanmoins, il existe des méthodes non natives pour créer et partager un état externalisé. Autrement dit, si on veut maintenir un état conversationnel à travers deux ou plusieurs requêtes, on doit le faire en le sauvegardant explicitement dans une base de données, dans des fichiers, dans un container S3, dans un cache, etc. Et s’il s’agit de fonctions Lambda synchrones, alors cet état doit être renvoyé en retour...

Pour consulter la suite, découvrez le livre suivant :
couv-EIAWSL.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Le démarrage à froid
Suivant
VPC (Virtual Private Cloud)