27 juin 2024

3 min de lecture

L’essentiel en bref

  • Le serverless va au-delà de Lambda/Functions : bases de données, files d’attente, stockage, inférence ML – tout est disponible en serverless
  • Le paiement à l’exécution permet d’économiser 60 à 80 % pour des charges de travail sporadiques, mais peut devenir plus coûteux que les instances de calcul pour des charges constantes
  • Les démarrages à froid restent un problème pour les applications sensibles à la latence – la concurrence provisionnée comme solution de contournement
  • Le vendor lock-in dû aux modèles d’événements propriétaires (EventBridge, Cloud Events) – la portabilité nécessite des couches d’abstraction
  • Le serverless-first comme principe d’architecture : seul ce qui ne peut pas être serverless est déployé sur du calcul

Le serverless a trouvé sa place – mais différemment de ce qui était attendu. AWS Lambda, Azure Functions et Google Cloud Functions étaient le point de départ. En 2026, le serverless est un principe d’architecture, pas un service unique : bases de données serverless, conteneurs serverless, inférence ML serverless. La question n’est plus de savoir si le serverless est utilisé, mais dans quelle mesure.

Au-delà des fonctions : l’écosystème serverless en 2026

La première vague serverless (2015-2020) était centrée sur les fonctions : petits fragments de code, déclenchés par des événements, payés à l’invocation. L’écosystème en 2026 est beaucoup plus large : DynamoDB et Aurora Serverless (bases de données), SQS et EventBridge (messagerie), S3 et EFS (stockage), SageMaker Serverless Inference (ML) – tout sans planification de capacité.

Le changement de paradigme : au lieu de se demander « Quel serveur ai-je besoin ? », la question devient « Quel service la cloud propose-t-elle pour mon cas d’utilisation ? ». La réponse est de plus en plus : un service où l’on ne s’occupe pas de l’infrastructure.

CHIFFRES CLÉS
80 pour cent
pour des charges de travail sporadiques, mais peut devenir plus coûteux pour des charges constantes
97 pour cent
Pour des charges constantes, le calcul s’inverse : un Lambda, car
50 pour cent
d’utilisation rend le serverless plus économique. Démarrages à froid : le per

Quand le serverless est moins cher – et quand il ne l’est pas

La mathématique des coûts est claire pour des charges de travail sporadiques : une fonction Lambda qui s’exécute 10 000 fois par jour pendant 200 ms coûte moins de 1 €/mois. Un petit serveur EC2 pour la même charge de travail : 30-50 €/mois. Économie : 97 pour cent.

Pour des charges constantes, le calcul s’inverse : un Lambda qui fonctionne 24/7 avec une forte concurrence devient plus coûteux qu’une instance EC2 dédiée. L’analyse du point mort dépend de la fréquence d’appel, de la durée d’exécution et des besoins en mémoire. Règle générale : en dessous de 50 % d’utilisation, le serverless est plus économique.

Démarrages à froid : le problème persistant

Lorsqu’une fonction serverless est appelée pour la première fois après une période d’inactivité, l’environnement d’exécution doit être initialisé – c’est le démarrage à froid. Python/Node.js : 100-500 ms. Java/.NET : 1-5 secondes. Pour les API avec des besoins de latence inférieurs à 200 ms, c’est problématique.

Solutions : Provisioned Concurrency (AWS) maintient les fonctions actives – élimine les démarrages à froid, mais aussi l’avantage de coût. Snap Start (Java) et Tiered Compilation réduisent le temps d’initialisation. La tendance : les environnements d’exécution deviennent plus rapides, les démarrages à froid deviennent plus courts – mais ne sont pas éliminés.

Le serverless-first comme principe d’architecture

Les architectes tournés vers l’avenir commencent par la question : « Est-ce que cela peut être serverless ? » Seul ce qui ne peut pas être réalisé en serverless (processus longs, charges de travail GPU, exigences réseau spécifiques) est déployé sur des instances de calcul ou Kubernetes.

Ce principe maximise la part de l’infrastructure qui est entièrement gérée. Moins de travail opérationnel, mise à l’échelle automatique, paiement à l’utilisation – les avantages opérationnels l’emportent dans la plupart des cas sur les limitations. L’architecture doit s’adapter (événementielle, sans état, idempotente), mais ce sont de toute façon les meilleures pratiques pour les systèmes évolutifs.

Questions fréquentes

Le serverless est-il uniquement pour les petites charges de travail ?

Non. Netflix, Coca-Cola et LEGO exploitent des architectures serverless massives. Le serverless est conçu pour évoluer jusqu’à des millions d’exécutions simultanées. La limitation ne réside pas dans l’évolutivité, mais dans l’architecture : sans état, pilotée par les événements et processus de courte durée.

Comment gérer l’état dans le serverless ?

L’état est externalisé : DynamoDB/Redis pour l’état de session, S3 pour les fichiers, Step Functions pour l’état de workflow. C’est une discipline architecturale, mais elle impose des bonnes pratiques qui sont également sensées dans les architectures non-serverless.

Qu’en est-il du Vendor Lock-in ?

Réel, mais gérable. Les modèles d’événements et les configurations de déclencheurs sont propriétaires. La logique de la fonction elle-même (Python, Node.js, Go) est portable. Des frameworks comme Serverless Framework et SST abstraient partiellement les spécificités des fournisseurs.

Puis-je migrer des applications existantes vers le serverless ?

Monolithes : difficile à impossible sans réarchitecture. Microservices : oui, progressivement. Recommandation : construire de nouvelles fonctionnalités en serverless, migrer progressivement les services existants. Utiliser le Strangler Fig Pattern comme stratégie de migration.

Qu’est-ce que les Serverless Containers (Fargate, Cloud Run) ?

Des conteneurs exécutés sans gestion de cluster. Ils combinent la flexibilité des conteneurs (runtime propre, charges utiles plus grandes) avec le modèle opérationnel du serverless (pas de gestion de serveur, paiement à l’utilisation). Pour de nombreuses charges de travail, c’est le juste milieu entre Lambda et Kubernetes.

Source de l’image de couverture : Pexels / Steve Johnson

Recommandations de la rédaction

Plus du réseau MBF Media

SecurityToday | MyBusinessFuture | Digital Chiefs

Aussi disponible en

Un magazine de Evernine Media GmbH