Serverless

Le serverless (ou « informatique sans serveur ») est un modèle d'exécution du cloud computing dans lequel le fournisseur cloud gère dynamiquement l'allocation et le provisionnement des serveurs. En tant que développeur, vous n'avez plus à vous soucier de l'infrastructure sous-jacente : vous écrivez du code, vous le déployez, et il s'exécute. Le terme est trompeur — il y a bien des serveurs quelque part — mais vous n'avez jamais à les gérer, les dimensionner ou les maintenir.

C'est un changement de paradigme majeur dans la façon dont on conçoit, déploie et opère des applications. Plutôt que de provisionner des machines virtuelles ou des conteneurs tournant 24h/24, vous décomposez votre logique métier en fonctions qui s'exécutent à la demande, facturées au temps d'exécution réel.

Les fondamentaux du serverless

Du serveur physique au serverless : une évolution naturelle

Pour comprendre le serverless, retraçons l'évolution de l'hébergement :

1. Serveurs physiques (bare metal) : vous achetez, installez et maintenez vos propres machines. Coût fixe élevé, scalabilité limitée.
2. Machines virtuelles (IaaS) : vous louez des VMs dans le cloud (EC2, Compute Engine). Plus flexible, mais vous gérez toujours l'OS, les mises à jour, le scaling.
3. Conteneurs (CaaS) : avec Docker et Kubernetes, vous empaquetez vos apps. Plus portable, mais il faut orchestrer le cluster.
4. Platform as a Service (PaaS) : Heroku, App Engine. Vous déployez votre code, la plateforme gère le reste. Mais vous payez pour des instances qui tournent en continu.
5. Serverless (FaaS + BaaS) : vous ne déployez que des fonctions ou utilisez des services managés. Pas d'instance à gérer, facturation à l'usage réel.

Le serverless est l'aboutissement logique de cette abstraction progressive. Chaque étape a retiré une couche de complexité opérationnelle pour permettre aux développeurs de se concentrer sur ce qui compte : le code métier.

FaaS vs BaaS : les deux faces du serverless

Le serverless englobe en réalité deux concepts complémentaires :

Function as a Service (FaaS) : c'est le cœur du serverless. Vous écrivez des fonctions individuelles qui s'exécutent en réponse à des événements. Les plateformes majeures sont :

• AWS Lambda : le pionnier, lancé en 2014. Supporte Node.js, Python, Java, Go, .NET, Ruby.
• Azure Functions : l'offre de Microsoft, bien intégrée à l'écosystème .NET et Azure.
• Google Cloud Functions : simple et efficace, forte intégration avec Firebase.
• Cloudflare Workers : exécution au edge, latence ultra-faible, basé sur V8 isolates.

Backend as a Service (BaaS) : des services cloud managés qui remplacent des composants backend entiers :

• Bases de données : DynamoDB, Firestore, PlanetScale, Supabase.
• Authentification : Cognito, Firebase Auth, Auth0.
• Stockage fichiers : S3, Cloud Storage.
• Files d'attente : SQS, Pub/Sub, EventBridge.
• API Gateway : gestion des routes, throttling, authentification des API.

👉 En pratique, une architecture serverless combine FaaS et BaaS pour construire des applications complètes sans gérer aucun serveur.

Comment fonctionne le serverless en pratique

Le cycle de vie d'une fonction serverless

Quand une requête arrive sur une fonction serverless, voici ce qui se passe sous le capot :

1. Déclenchement (Trigger) : un événement déclenche la fonction — requête HTTP, message dans une file, modification en base, timer cron, upload de fichier.
2. Cold start : si aucune instance de la fonction n'est active, le provider en démarre une. Il provisionne un micro-conteneur, charge votre code et ses dépendances, initialise l'environnement d'exécution. Ce démarrage « à froid » prend de quelques millisecondes (Cloudflare Workers) à plusieurs secondes (Java sur Lambda).
3. Exécution : votre fonction s'exécute, traite l'événement, retourne un résultat.
4. Warm state : l'instance reste « chaude » pendant un certain temps (typiquement 5 à 15 minutes sur AWS Lambda). Les invocations suivantes réutilisent cette instance — pas de cold start.
5. Mise à l'échelle : si 1000 requêtes arrivent simultanément, le provider lance 1000 instances en parallèle. Le scaling est automatique et quasi-instantané.
6. Scale to zero : quand il n'y a plus de trafic, toutes les instances sont détruites. Vous ne payez rien.

Exemple concret : une API serverless avec AWS Lambda

Imaginons une API REST pour une application e-commerce. Voici à quoi ressemble une fonction Lambda en Node.js :

La fonction reçoit un événement HTTP via API Gateway, extrait l'ID produit des paramètres de chemin, interroge DynamoDB, et retourne le résultat en JSON. Pas de serveur Express à configurer, pas de processus Node à maintenir, pas de load balancer à dimensionner.

Le déploiement se fait via un fichier de configuration (SAM, Serverless Framework, ou Terraform) qui décrit les fonctions, leurs triggers et les permissions IAM associées. Un simple serverless deploy et votre API est en production.

Les patterns d'architecture serverless

Le serverless impose de repenser la façon dont on structure ses applications. Voici les patterns les plus courants :

1. API Gateway + Lambda + DynamoDB

Le trio classique sur AWS. API Gateway route les requêtes HTTP vers des fonctions Lambda qui interagissent avec DynamoDB. C'est le « Hello World » du serverless, mais aussi la base de nombreuses applications en production.

2. Event-driven processing

Les fonctions réagissent à des événements : un fichier uploadé dans S3 déclenche un traitement d'image, un message dans SQS lance un calcul asynchrone, une modification en base déclenche une synchronisation. C'est là que le serverless excelle, en combinaison avec une architecture event-driven.

3. Fan-out / Fan-in

Un événement déclenche plusieurs fonctions en parallèle (fan-out), dont les résultats sont agrégés par une fonction finale (fan-in). Idéal pour le traitement distribué de données.

4. Choreography (saga pattern)

Pour les workflows complexes impliquant plusieurs services, chaque étape est une fonction qui émet un événement déclenchant l'étape suivante. AWS Step Functions orchestre ces workflows avec des machines à états visuelles.

5. Backend for Frontend (BFF)

Des fonctions Lambda dédiées à chaque type de client (frontend web, mobile, partenaires) qui agrègent et transforment les données de plusieurs microservices.

Avantages concrets du serverless

Réduction drastique des coûts

Le modèle pay-per-use est le premier argument en faveur du serverless. Comparons :

• Serveur EC2 t3.medium tournant 24h/24 : ~30 $/mois minimum.
• Lambda équivalent pour une API recevant 100 000 requêtes/mois avec 200 ms de temps d'exécution moyen : ~0,20 $.

Pour les applications à trafic variable ou faible, l'économie est spectaculaire. Un side project qui reçoit quelques milliers de requêtes par jour coûte littéralement quelques centimes par mois. Le free tier AWS Lambda offre 1 million de requêtes et 400 000 Go-secondes gratuites par mois — suffisant pour de nombreux projets.

💡 Le serverless est particulièrement économique pour les startups et les SaaS en phase de lancement, où le trafic est imprévisible et souvent faible.

Scalabilité automatique

Le scaling est la killer feature du serverless. Votre application passe de 0 à 10 000 requêtes par seconde sans intervention. Pas de configuration d'auto-scaling groups, pas de métriques à surveiller, pas de seuils à ajuster. Le provider gère tout.

Cela signifie aussi que vous pouvez absorber des pics de trafic imprévisibles. Un article qui devient viral, une campagne marketing qui cartonne, un Black Friday — votre infrastructure s'adapte automatiquement.

Vélocité de développement

Sans infrastructure à gérer, les équipes se concentrent sur le code métier. Le time-to-market est réduit considérablement :

• Pas de provisionnement de serveurs.
• Pas de configuration de load balancers.
• Pas de gestion des certificats SSL (API Gateway s'en charge).
• Pas de patching OS.
• Déploiement en quelques secondes via CI/CD.

Un développeur seul peut mettre en production une API complète, avec authentification, base de données et stockage fichiers, en quelques heures.

Haute disponibilité native

Les fonctions serverless sont automatiquement répliquées sur plusieurs zones de disponibilité. Pas besoin de configurer de la redondance — elle est incluse par défaut. La disponibilité garantie par AWS Lambda est de 99,95 %.

Limites et défis du serverless

Le cold start : le talon d'Achille

Le cold start reste le défi numéro un du serverless. Quand une fonction n'a pas été invoquée récemment, le premier appel subit une latence supplémentaire :

• Node.js / Python : 100-500 ms de cold start typique.
• Java / .NET : 1-5 secondes, voire plus avec des frameworks lourds.
• Cloudflare Workers : < 5 ms grâce aux V8 isolates.

📌 Solutions pour atténuer les cold starts :

• Provisioned Concurrency (AWS Lambda) : vous pré-chauffez un nombre défini d'instances. Élimine les cold starts, mais augmente les coûts.
• Garder les fonctions légères : minimiser les dépendances, utiliser des layers partagées.
• Choisir le bon runtime : Node.js et Python démarrent beaucoup plus vite que Java.
• SnapStart (AWS Lambda pour Java) : réduit le cold start de Java à ~200 ms via des snapshots de la JVM.
• Warm-up schedulé : un CloudWatch Event invoque la fonction toutes les 5 minutes pour la garder chaude.

Limites d'exécution

Les fonctions serverless ont des contraintes strictes :

• Timeout maximum : 15 minutes sur AWS Lambda (900 secondes).
• Mémoire : de 128 Mo à 10 Go sur Lambda.
• Taille du package : 50 Mo zippé, 250 Mo décompressé (hors layers).
• Concurrence : 1000 exécutions simultanées par défaut (augmentable via support).
• Payload : 6 Mo pour les invocations synchrones, 256 Ko pour les asynchrones.

Ces limites rendent le serverless inadapté à certains cas d'usage : traitements de longue durée, calculs intensifs nécessitant des GPU, applications nécessitant des connexions WebSocket persistantes (bien que API Gateway supporte désormais les WebSockets).

Le vendor lock-in

C'est le risque le plus débattu. Votre code s'appuie sur des services propriétaires (DynamoDB, API Gateway, SQS, Step Functions) qui n'ont pas d'équivalent exact chez un autre provider. Migrer une application serverless AWS vers Google Cloud n'est pas trivial.

Stratégies de mitigation :

• Isoler la logique métier du code d'infrastructure (ports & adapters / architecture hexagonale).
• Utiliser des abstractions comme le Serverless Framework ou SST qui supportent plusieurs providers.
• Accepter le vendor lock-in comme un compromis conscient — en pratique, les migrations de cloud sont rares et le coût du lock-in est souvent surestimé.

Complexité du debugging et de l'observabilité

Déboguer une application serverless est plus complexe qu'une application monolithique. Les exécutions sont éphémères, distribuées, et les outils de debugging local sont limités :

• Logs distribués : chaque invocation génère ses propres logs dans CloudWatch. Corréler les logs de plusieurs fonctions nécessite des outils comme X-Ray, Datadog ou Lumigo.
• Debugging local : SAM CLI et le Serverless Framework permettent d'émuler Lambda localement, mais l'émulation n'est jamais parfaite.
• Tracing distribué : indispensable pour comprendre le flux d'une requête à travers plusieurs fonctions et services.

Serverless en 2025-2026 : l'état de l'art

Les tendances actuelles

Le serverless a considérablement mûri depuis les débuts de Lambda en 2014. Voici où en est l'écosystème :

Edge computing serverless : Cloudflare Workers, Vercel Edge Functions, Deno Deploy exécutent du code au plus proche de l'utilisateur. La latence chute à quelques millisecondes. C'est le futur du serverless pour les applications web.

Containers serverless : AWS Fargate, Google Cloud Run, Azure Container Apps. Vous déployez un conteneur Docker sans gérer de cluster. C'est le meilleur des deux mondes : la flexibilité des conteneurs avec le modèle opérationnel du serverless.

Serverless databases : Aurora Serverless v2, Neon (PostgreSQL serverless), PlanetScale, Turso (SQLite distribué). Les bases de données adoptent aussi le modèle scale-to-zero.

Full-stack serverless : des frameworks comme SST (Serverless Stack), Amplify, ou le framework Serverless v4 permettent de construire des applications full-stack complètes en serverless, avec frontend, backend, base de données et authentification.

Serverless vs conteneurs : quel choix ?

La question « serverless ou conteneurs ? » revient constamment. Voici un guide de décision :

Choisissez le serverless si :

• Votre trafic est variable ou imprévisible.
• Vous voulez minimiser les coûts opérationnels.
• Votre équipe est petite et n'a pas d'expertise DevOps dédiée.
• Votre application est event-driven ou orientée API.
• Vos traitements durent moins de 15 minutes.

Choisissez les conteneurs si :

• Vous avez des traitements de longue durée ou intensifs en CPU/GPU.
• Vous avez besoin d'un contrôle fin sur l'environnement d'exécution.
• La latence de cold start est inacceptable pour votre cas d'usage.
• Vous voulez éviter le vendor lock-in à tout prix.
• Votre application maintient un état en mémoire entre les requêtes.

👉 En réalité, les architectures modernes combinent souvent les deux. Les endpoints API critiques en serverless pour le scaling automatique, les traitements lourds en conteneurs sur Fargate ou Cloud Run.

Anti-patterns du serverless

Le serverless n'est pas une solution universelle. Voici les erreurs classiques à éviter :

1. Le « Lambda monolithe »

Mettre toute la logique d'une application dans une seule fonction Lambda géante. Vous perdez les avantages du scaling granulaire et du déploiement indépendant. Chaque endpoint ou traitement devrait être une fonction distincte.

2. Ignorer les cold starts pour des API temps réel

Si votre application nécessite des latences < 50 ms garanties (trading, gaming), le serverless classique n'est pas le bon choix. Considérez Cloudflare Workers ou des conteneurs toujours actifs.

3. Serverless pour du batch de longue durée

Un job ETL de 2 heures ne rentre pas dans une Lambda (max 15 min). Utilisez AWS Batch, Fargate ou Step Functions avec du parallélisme.

4. Connexions base de données non gérées

Chaque instance Lambda ouvre sa propre connexion à la base. Avec 1000 invocations concurrentes, votre PostgreSQL explose avec 1000 connexions. Solution : utilisez RDS Proxy ou une base serverless comme DynamoDB ou Aurora Serverless.

5. Sous-estimer la complexité opérationnelle

Le serverless élimine la gestion des serveurs, mais introduit sa propre complexité : gestion des permissions IAM (souvent des dizaines de policies), configuration d'API Gateway, limites de concurrence, gestion des dead letter queues, monitoring distribué. L'opérationnel ne disparaît pas — il change de nature.

Serverless et architecture logicielle

Clean architecture en serverless

Le serverless ne dispense pas d'une bonne architecture. Au contraire, la tentation de mettre toute la logique dans le handler Lambda est forte — et c'est un piège qui génère de la dette technique.

La bonne pratique est de séparer clairement :

• Le handler (couche infrastructure) : gère l'événement AWS, extrait les données, appelle le use case, formate la réponse.
• Le use case (couche application) : contient la logique métier pure, testable unitairement, indépendante du provider cloud.
• Les repositories (couche infrastructure) : accèdent à DynamoDB, S3, etc. derrière des interfaces.

Cette séparation permet de tester 80 % du code sans émulateur AWS, et facilite une migration future vers un autre provider ou vers des conteneurs.

Infrastructure as Code

En serverless, l'infrastructure est le code. Chaque fonction, permission, table DynamoDB, file SQS doit être décrite en code :

• AWS SAM : template YAML officiel d'AWS, simple et efficace.
• Serverless Framework : le plus populaire, multi-cloud, riche écosystème de plugins.
• SST (Serverless Stack) : basé sur CDK, TypeScript-first, excellent DX.
• Terraform : le plus flexible, multi-cloud, mais plus verbeux pour du serverless pur.
• Pulumi : Infrastructure as Code en TypeScript, Python, Go — pas de YAML.

Sécurité en serverless

Le serverless modifie la surface d'attaque mais n'élimine pas les risques de sécurité :

Ce que le provider gère : patching OS, sécurité du runtime, isolation des conteneurs, chiffrement au repos et en transit.

Ce qui reste votre responsabilité :

• Principe du moindre privilège : chaque fonction Lambda doit avoir uniquement les permissions IAM dont elle a besoin. Pas de * dans les policies.
• Validation des inputs : les fonctions serverless sont exposées à des événements de sources diverses. Validez tout.
• Gestion des secrets : utilisez AWS Secrets Manager ou SSM Parameter Store, jamais des variables d'environnement en clair pour les données sensibles.
• Dépendances : auditez vos packages npm/pip. Une dépendance compromise dans une Lambda a le même impact que sur un serveur.
• Injection dans les événements : les attaques par injection (SQL, NoSQL, commande) s'appliquent aussi en serverless.

Chez Yield Studio

Chez Yield Studio, nous utilisons le serverless de manière pragmatique dans nos projets. Ce n'est ni un dogme ni un buzzword — c'est un outil que nous déployons quand il fait sens.

Pour les logiciels métier et les SaaS que nous développons, nous combinons souvent :

• Des API serverless (Lambda + API Gateway ou Vercel Serverless Functions) pour les endpoints REST/GraphQL.
• Des traitements asynchrones via des fonctions événementielles pour le processing d'images, les envois d'emails, les calculs en arrière-plan.
• Des bases de données serverless (Aurora Serverless, PlanetScale) pour le scale-to-zero sur les environnements de staging.
• Du edge computing via Vercel Edge Functions pour les middlewares d'authentification et les redirections.

Notre approche DevOps intègre pleinement le serverless dans nos pipelines de CI/CD. Infrastructure as Code systématique, tests automatisés, monitoring avec des outils comme Datadog — nous suivons nos DORA metrics sur les déploiements serverless comme sur tout autre type d'infrastructure.

Le serverless nous permet d'offrir à nos clients des applications qui scalent automatiquement, coûtent peu en phase de lancement, et ne nécessitent pas d'équipe ops dédiée pour tourner en production. C'est un accélérateur de time-to-market que nous recommandons systématiquement pour les projets à trafic variable.