Lambda ou Kubernetes ? La mauvaise question
C’est le débat qui revient dans chaque comité d’architecture. Serverless ou containers ? Lambda ou Kubernetes ? La réponse courte : ça dépend. La réponse longue : les deux ont leur place, souvent dans le même projet.
Le vrai danger, c’est le dogmatisme. Tout mettre en serverless parce que c’est “moderne”. Tout conteneuriser parce que c’est “contrôlable”. Les deux approches résoudent des problèmes différents. Comprendre quand utiliser chacune est ce qui fait la différence entre une architecture solide et une architecture souffrance.
Serverless : ce que c’est vraiment
Le serverless ne signifie pas “sans serveur”. Les serveurs existent, vous ne les gérez pas. Le modèle est simple : vous déployez du code, le cloud provider l’exécute quand un événement le déclenche, vous payez à l’exécution.
Les services serverless principaux :
- Compute : AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers
- API : API Gateway, Cloud Endpoints
- Base de données : DynamoDB, Firestore, PlanetScale, Neon
- File d’attente : SQS, Pub/Sub, EventBridge
- Storage : S3, Cloud Storage (déjà serverless par nature)
Le serverless, c’est un modèle opérationnel, pas une technologie. L’objectif : zéro gestion d’infrastructure, facturation à l’usage, scaling automatique.
Containers : ce que c’est vraiment
Les containers empaquettent une application avec toutes ses dépendances dans une image portable. Docker a démocratisé le format, Kubernetes orchestre l’exécution à grande échelle.
L’écosystème containers :
- Runtime : Docker, containerd, Podman
- Orchestration : Kubernetes (EKS, GKE, AKS), Docker Swarm, Nomad
- PaaS containers : Cloud Run, ECS Fargate, Azure Container Apps, Fly.io
- Registry : ECR, GCR, Docker Hub, GitHub Container Registry
Le modèle containers vous donne le contrôle total sur l’environnement d’exécution, le networking, le scaling, et le déploiement.
La matrice de décision
Plutôt que de débattre dans l’abstrait, voici les critères concrets qui orientent le choix.
Latence
Serverless : les cold starts sont réels. Sur AWS Lambda, comptez 100 ms à 1 seconde pour un cold start (plus pour Java/C#). Les solutions existent (provisioned concurrency, SnapStart) mais ajoutent du coût et de la complexité.
Containers : pas de cold start. Le container tourne en permanence, la latence est prévisible et constante. Pour les APIs avec des exigences de latence strictes (P99 < 50 ms), les containers gagnent.
Coût
Serverless : imbattable pour les workloads intermittents. Une fonction qui s’exécute 1 000 fois par jour pendant 200 ms coûte quelques centimes par mois. Zéro trafic = zéro coût.
Containers : plus économique à partir d’un certain volume. Quand vos fonctions Lambda tournent en permanence, vous payez le prix fort du compute serverless. Le seuil de bascule se situe généralement autour de 30 à 40% d’utilisation continue.
Le serverless est moins cher quand ça dort. Les containers sont moins chers quand ça tourne.
Complexité opérationnelle
Serverless : pas de serveurs à gérer, pas de patches, pas de scaling à configurer. Mais la complexité se déplace vers l’orchestration des fonctions, la gestion des événements, le debugging distribué et le monitoring.
Containers : la complexité est frontale et visible. Kubernetes a une courbe d’apprentissage raide. Mais une fois maîtrisé, le modèle mental est cohérent et prédictible.
Compétences d’équipe
Serverless : accessible aux développeurs sans background infra. Un développeur backend peut déployer une Lambda en une heure. Mais l’expertise en architectures événementielles devient nécessaire à l’échelle.
Containers : nécessite des compétences DevOps/SRE. Docker est simple, Kubernetes ne l’est pas. Comptez un investissement formation significatif.
Vendor lock-in
Serverless : fort. Votre code est intimement lié aux services du provider (API Gateway + Lambda + DynamoDB + SQS). Migrer vers un autre cloud demande une réécriture significative.
Containers : faible à modéré. Un container Docker tourne partout. Kubernetes est un standard. Le lock-in vient des services managés périphériques, pas de l’orchestrateur.
Durée d’exécution
Serverless : limité. Lambda plafonne à 15 minutes, Cloud Functions à 60 minutes. Pour les traitements longs, il faut découper en étapes (Step Functions, Workflows).
Containers : pas de limite. Un container peut tourner indéfiniment. Les traitements batch de plusieurs heures, les workers de longue durée, les connexions WebSocket — tout passe.
Quand le serverless gagne
Architectures événementielles
Le serverless excelle quand le trigger est un événement : un fichier uploadé, un message dans une queue, un webhook reçu, un cron job. Le pattern est naturel et le coût optimal.
Trafic imprévisible ou en pics
Une API qui passe de 10 à 10 000 requêtes par seconde en 2 minutes ? Le serverless scale instantanément (ou presque). Pas besoin de pré-provisionner, pas de risque de sous-dimensionnement.
MVPs et prototypes
Besoin de valider une idée en 2 semaines ? Le serverless élimine toute la complexité infrastructure. Vous vous concentrez sur le code métier. Si le produit décolle, vous pourrez toujours migrer vers des containers.
Microservices légers
Des fonctions simples — un webhook de paiement, une transformation d’image, un envoi d’email — sont des candidats idéaux. Le ratio valeur/complexité est maximal.
Backend mobile et IoT
Les backends mobiles avec des patterns d’usage sporadiques (l’utilisateur ouvre l’app 5 fois par jour) bénéficient directement du modèle pay-per-use.
Quand les containers gagnent
Applications stateful
Les applications qui maintiennent un état en mémoire (sessions, caches, connexions persistantes) ne fonctionnent pas bien en serverless. Les containers avec leur durée de vie longue sont adaptés.
Charge constante et élevée
Un service API qui traite 500 requêtes par seconde en continu est moins cher en containers qu’en serverless. Le calcul est simple à faire, faites-le.
Workloads complexes
Les applications avec des dépendances lourdes (ML models, binaires compilés, runtimes spécifiques) se conteneurisent facilement. En serverless, les contraintes de taille de package et de runtime limitent les possibilités.
Multi-tenancy et isolation
Kubernetes offre des primitives d’isolation (namespaces, network policies, resource quotas) qui permettent de faire tourner plusieurs tenants sur le même cluster avec des garanties fortes.
Traitements de longue durée
Tout ce qui dépasse 15 minutes : entraînement ML, ETL lourd, génération de rapports complexes, transcodage vidéo. Les containers n’ont pas de timeout.
L’architecture hybride : la réponse pragmatique
En pratique, les architectures les plus efficaces combinent les deux approches. Voici un pattern qu’on déploie régulièrement.
Le coeur en containers
L’API principale, les services métier critiques, les bases de données — tout ce qui doit être rapide, prévisible et toujours disponible tourne en containers (Cloud Run ou Kubernetes selon la complexité).
Les périphériques en serverless
Le traitement d’images uploadées, les notifications push, les webhooks de paiement, les jobs de synchronisation, les pipelines de data — tout ce qui est événementiel et tolérant à la latence tourne en serverless.
La glue en événements
Les deux mondes communiquent via des événements (Pub/Sub, EventBridge, SQS). Le découplage est maximal, chaque composant utilise le modèle d’exécution optimal.
Le cas Cloud Run : le meilleur des deux mondes ?
Google Cloud Run (et dans une moindre mesure AWS Fargate et Azure Container Apps) brouille la frontière. Vous déployez un container, mais le modèle opérationnel est serverless : scaling automatique (y compris à zéro), facturation à la requête, pas de gestion de cluster.
Cloud Run résout le problème des cold starts (le container est déjà construit), élimine le vendor lock-in du code (c’est un container standard), et offre le scaling du serverless. Les limites : pas de WebSocket natif, max 60 minutes par requête, et moins de contrôle sur le networking que Kubernetes.
Pour beaucoup de projets, Cloud Run est le point de départ optimal avant de migrer vers K8s si la complexité l’exige.
Le vrai coût : une comparaison honnête
Prenons un cas concret : une API REST qui traite en moyenne 100 requêtes par seconde avec une latence cible de 200 ms.
En Lambda : environ 800 dollars par mois (128 Mo, 200 ms par invocation, 260 millions d’invocations). Plus les coûts API Gateway (environ 900 dollars). Total : environ 1 700 dollars.
En containers (Cloud Run) : 2 instances always-on + autoscaling. Environ 150 dollars par mois.
En Kubernetes (GKE) : cluster Autopilot avec 2 pods. Environ 200 dollars par mois (compute) + 74 dollars (cluster fee). Total : environ 274 dollars.
À charge constante, le serverless est 5 à 10 fois plus cher. Mais ajoutez la gestion opérationnelle de K8s (temps ingénieur), et l’écart se réduit considérablement.
Les cold starts : mythes et réalité
Les cold starts sont le principal grief contre le serverless. Mettons les chiffres à plat.
AWS Lambda :
- Python/Node.js : 100-300 ms de cold start
- Java : 500 ms - 3 secondes (sans SnapStart)
- Java avec SnapStart : 100-200 ms
- Provisioned Concurrency : élimine les cold starts mais coûte cher
Cloud Run :
- Min instances = 1 : pas de cold start pour la première requête
- Scale from zero : 1-3 secondes (le container doit démarrer)
En pratique, pour la majorité des APIs web, un cold start de 200-300 ms est invisible pour l’utilisateur. Le problème se pose pour les APIs internes à faible latence (P99 < 50 ms) et les chaînes d’appels synchrones où les cold starts s’additionnent.
Checklist de décision
Avant de choisir, répondez à ces questions :
- Votre trafic est-il constant ou sporadique ? Constant -> containers. Sporadique -> serverless.
- Quelle latence est acceptable ? < 50 ms P99 -> containers. < 500 ms -> les deux fonctionnent.
- Quelle est la durée d’exécution ? > 15 min -> containers. < 15 min -> les deux.
- Votre équipe a-t-elle des compétences K8s ? Non -> serverless ou Cloud Run. Oui -> containers.
- Le vendor lock-in est-il un problème ? Oui -> containers. Non -> serverless acceptable.
- Votre budget permet-il du DevOps dédié ? Non -> serverless. Oui -> containers.
Si la majorité des réponses pointent dans la même direction, le choix est clair. Si c’est 50/50, l’architecture hybride est probablement la bonne réponse.
FAQ
Le serverless peut-il remplacer Kubernetes pour une application de production ?
Oui, pour certains types d’applications. Les architectures événementielles, les APIs avec un trafic variable, et les backends mobiles fonctionnent très bien en full serverless. En revanche, pour les applications stateful, les traitements de longue durée ou les systèmes avec des exigences de latence strictes, Kubernetes reste plus adapté. La clé est de ne pas forcer un modèle sur un cas d’usage qui ne s’y prête pas. Si vous découpez votre application en fonctions de 15 minutes maximum et que vous acceptez la latence des cold starts, le serverless fonctionne en production.
Comment gérer le vendor lock-in du serverless ?
Le lock-in serverless est réel mais souvent surestimé. Trois stratégies pour le limiter : premièrement, isoler la logique métier du code d’intégration cloud (pattern ports and adapters) pour que seule la couche d’infrastructure soit spécifique au provider. Deuxièmement, utiliser des standards ouverts quand ils existent (CloudEvents pour les événements, OpenTelemetry pour l’observabilité). Troisièmement, considérer Cloud Run ou des alternatives basées sur des containers comme un compromis entre le modèle opérationnel serverless et la portabilité des containers.
Quel est le coût réel du serverless à grande échelle ?
Le serverless devient coûteux à charge constante et élevée. Le point de bascule varie selon le provider et le service, mais en règle générale, au-delà de 30 à 40% d’utilisation continue, les containers deviennent plus économiques en coût d’infrastructure pur. Cependant, le calcul total doit inclure le coût opérationnel (pas de serveurs à gérer en serverless) et le coût d’opportunité (les développeurs passent du temps sur le produit, pas sur l’infra). Pour une startup avec une petite équipe, le serverless peut rester moins cher globalement même à charge élevée, car le coût humain de Kubernetes est significatif.
Cloud Run est-il une bonne alternative à Kubernetes ?
Cloud Run est une excellente alternative pour 80% des workloads qui seraient déployés sur Kubernetes. Il offre le scaling automatique (y compris à zéro), la facturation à l’usage, et accepte n’importe quel container conforme. Ses limites : pas de support natif pour les WebSockets longue durée, pas de volumes persistants, timeout de 60 minutes par requête, et moins de contrôle sur le networking. Si votre application ne nécessite pas de communication inter-services complexe, de stockage persistant local ou de traitements de plus d’une heure, Cloud Run simplifie drastiquement les opérations tout en gardant la portabilité d’un container standard.