Le rythme des innovations dans le domaine du cloud computing ne faiblit pas, AWS ayant récemment dévoilé des fonctions persistantes pour Lambda. Cette initiative pourrait avoir des implications importantes sur la manière dont les entreprises conçoivent et orchestrent des workflows sans serveur complexes. Ayant suivi et analysé l'évolution du cloud pendant des décennies, nous considèrons cette proposition d'Amazon comme une preuve de la maturation des pratiques serverless et comme une opportunité pour les entreprises de réévaluer l'adéquation et les risques d'une intégration plus poussée avec l'écosystème serverless d'AWS. Une critique courante du cloud computing serverless est sa capacité limitée à orchestrer des workflows en plusieurs étapes ou de longue durée. AWS Lambda, sans doute le service de calcul serverless le plus connu, excelle dans le traitement de tâches uniques, sans état et de courte durée, telles que le traitement d'images, la transformation de données ou les API back-end légères. Cependant, pour les opérations complexes telles que le traitement des commandes, l'intégration en plusieurs étapes ou les décisions basées sur l'IA qui s'étendent sur plusieurs heures ou semaines, le modèle Lambda existant nécessite un code personnalisé important ou des outils d'orchestration externes, tels que AWS Step Functions ou même des plateformes tierces.

Les fonctions persistantes d'AWS Lambda répondent directement à ce problème grâce à la gestion native des états, la création automatique de points de contrôle et l'orchestration des flux de travail. Les développeurs peuvent désormais définir une séquence d'étapes et introduire des délais d'attente pouvant aller jusqu'à un an sans frais supplémentaires pendant les pauses, ce qui améliore l'efficacité des flux de travail comportant des retards ou des dépendances. Il s'agit d'un avantage économique significatif pour les flux de travail soumis à de longs retards ou à des dépendances externes. Ce type d'orchestration différencie les applications serverless de type « proof-of-concept » des systèmes résilients en production qui résistent aux pannes partielles, se remettent des interruptions et restent rentables tout au long de leur cycle de vie. Les fonctions persistantes offrent une gestion des états basée sur des modèles, une gestion des erreurs intégrée et une récupération robuste en cas de panne, ce qui réduit la charge de travail des ingénieurs. Par conséquent, le serverless devient plus adapté aux applications de niveau entreprise centrées sur les workflows, où la fiabilité et l'agilité sont essentielles.

Une étape importante, mais pas une panacée

Toutes les entreprises devraient-elles donc se précipiter pour repenser leurs applications autour des fonctions persistantes de Lambda ? Comme toujours, la réponse dépend des circonstances. Du côté positif, les fonctions persistantes étendent le modèle serverless aux entreprises qui utilisent déjà Lambda, en offrant une prise en charge de premier ordre pour Python (3.13, 3.14) et Node.js (22, 24), ainsi qu'une intégration avec l'interface CLI, le SDK et les outils d'orchestration d'AWS. Elles réduisent les barrières à l'entrée pour les équipes déjà familiarisées avec AWS, en simplifiant le développement d'applications qui reposait auparavant sur des architectures basées sur des conteneurs ou des machines virtuelles traditionnelles. Les équipes qui privilégient l'agilité, la logique métier et l'expérimentation rapide tireront probablement une valeur significative de l'abstraction de l'infrastructure et de l'orchestration offerte par les fonctions persistantes.

Cependant, les entreprises doivent peser le pour et le contre d'une adoption plus poussée du serverless, en particulier avec des abstractions propriétaires telles que les fonctions persistantes. Les modèles serverless favorisent l'agilité et l'efficacité, mais peuvent également accroître la dépendance vis-à-vis des fournisseurs. Par exemple, la migration de workflows complexes depuis les fonctions persistantes AWS Lambda vers une autre plateforme cloud (ou vers une infrastructure sur site) sera coûteuse et complexe, car le code repose sur des API et une orchestration spécifiques à AWS qui ne sont pas directement transposables vers Microsoft Azure, Google Cloud ou des options open source. Il existe également une considération architecturale plus large. De par sa nature même, le serverless exige l'absence d'état et la composabilité, mais il introduit également de nouveaux modèles pour l'observabilité, les tests et le dépannage opérationnel. Si les fonctions persistantes AWS Lambda allègent l'orchestration des workflows, elles augmentent également la « magie » qui doit se produire en coulisses, rendant parfois plus difficiles le débogage et la compréhension des échecs inter-étapes. La visibilité, la conformité et le contrôle des coûts à l'échelle de l'entreprise nécessitent des investissements dans de nouvelles pratiques de surveillance et éventuellement dans des outils tiers ou propriétaires.

Avantages et inconvénients du verrouillage serverless

Certains membres de la communauté cloud ont adopté une approche myope du verrouillage des fournisseurs, tirant la sonnette d'alarme à la moindre adoption d'une technologie propriétaire. En réalité, il n'est pas possible d'éviter complètement le verrouillage, et la recherche d'une portabilité absolue peut nuire à l'accès à de véritables innovations, telles que les fonctions persistantes Lambda. Le calcul doit se concentrer sur la gestion des risques et les stratégies de sortie : la valeur apportée par l'automatisation, la récupération intégrée des erreurs et l'efficacité opérationnelle justifie-t-elle une dépendance accrue à l'égard d'un fournisseur de cloud spécifique à ce stade de votre évolution ?

Pour les entreprises qui poursuivent activement leur transformation numérique, les fonctions serveless et les services Lambda persistants peuvent s'aligner sur leurs objectifs à court et moyen terme, en leur offrant agilité, réduction des frais généraux et meilleure expérience de développement. Cependant, les investissements dans les fonctionnalités cloud native doivent trouver un équilibre entre les avantages actuels et la flexibilité à long terme. Pour les besoins multicloud étendus ou à l'épreuve du temps, envisagez d'encapsuler une partie de la logique applicative en dehors de ces constructions serveless propriétaires ou d'adopter des architectures qui dissocient les workflows du runtime cloud.

Au-delà du cycle de hype

Les fonctions persistantes AWS Lambda constituent une innovation majeure. Pour les charges de travail appropriées, elles repoussent considérablement les limites de ce qui est réalisable avec le serverless. Elles contribuent à concrétiser la vision initiale du serverless et permettent aux développeurs de se concentrer sur la logique métier plutôt que sur la gestion distribuée des états ou l'infrastructure. Cependant, elles ne constituent pas une solution universelle pour toutes les charges de travail et ne sont pas exemptes des préoccupations stratégiques qui ont toujours accompagné l'innovation rapide des plateformes.

Les architectes et les dirigeants d'entreprise sont désormais confrontés à un exercice d'équilibre familier. La clé est de reconnaître où les fonctions persistantes Lambda apportent une valeur transformatrice et où elles risquent d'entraîner votre architecture dans un schéma difficile à défaire par la suite. Comme toujours, la meilleure approche consiste à procéder à une évaluation stratégique lucide, guidée par les priorités de l'organisation, et non à adopter cette technologie pour le simple plaisir de suivre une mode.

À cette fin, les entreprises qui envisagent d'utiliser les fonctions persistantes AWS Lambda doivent prendre en compte les éléments suivants :

- Le degré de dépendance vis-à-vis du fournisseur ;
- Les coûts de migration ;
- L'adéquation avec les compétences existantes et les workflows de développement ;
- La maturité des solutions de surveillance et d'observabilité ;
- Les implications en matière de réglementation et de conformité ;
- Le coût total de possession par rapport à des alternatives plus portables ou traditionnelles.

Une adoption judicieuse nécessite plus qu'un simple enthousiasme technique : elle exige une discipline commerciale et architecturale. Les fonctions persistantes AWS Lambda constituent une évolution significative pour le serverless, mais elles ne deviennent véritablement transformatrices que dans le cadre d'une stratégie d'entreprise éclairée et équilibrée.