Reposer la décision serverless vs containers sur les fondamentaux d’architecture
TL;DR : ne choisissez pas entre serverless et containers au niveau technologique, mais au niveau des domaines métier, du profil de trafic et de la capacité de vos équipes à opérer l’ensemble. Dans la plupart des cas, vous aboutirez à une architecture hybride, avec un cœur applicatif en conteneurs et des extensions event driven en fonctions managées.
Pour un CTO, la véritable question n’est pas « serverless ou containers » mais « où placer chaque type de charge dans votre architecture globale ». Le choix entre fonctions serverless, conteneurs Docker et services managés doit articuler les contraintes de votre infrastructure, la stratégie cloud de l’entreprise et la capacité de vos équipes à opérer ces briques au quotidien. Une architecture bien pensée aligne les services techniques, les applications métier et le cycle de vie des produits numériques sur un même cadre décisionnel.
Le serverless et les containers répondent à des besoins différents, mais complémentaires, dans une architecture cloud moderne qui doit rester pilotable à l’échelle de plusieurs années sans réécriture permanente. Les plateformes serverless comme AWS Lambda, Azure Functions ou Cloudflare Workers optimisent la mise à l’échelle automatique, la gestion du serveur et la facturation à l’usage, mais elles introduisent un risque de vendor lock sur les runtimes et les API managées. À l’inverse, les conteneurs Docker orchestrés par Kubernetes ou des services managés de type Azure Container Apps, Google Cloud Run ou les container apps d’AWS offrent une portabilité accrue des conteneurs et des containers serverless, au prix d’une infrastructure plus complexe à opérer.
La bonne architecture serverless repose donc sur une cartographie explicite des domaines fonctionnels, des flux de données et des contraintes de latence, plutôt que sur un simple comparatif de coût à la requête ou de prix des machines virtuelles. Dans ce cadre, la décision d’architecture devient un arbitrage entre rapidité d’itération, observabilité, gestion des démarrages froids et maîtrise de la mise à l’échelle des conteneurs. Vous gagnez en clarté lorsque chaque fonction, chaque API et chaque conteneur est rattaché à un scénario métier précis et à un modèle d’usage du trafic variable.
Critères souvent négligés : cold start, observabilité et debugging en production
Le cold start est rarement pris au sérieux lors des premiers POC serverless, alors qu’il impacte directement l’UX et les KPI métier sur les parcours critiques. Sur AWS Lambda, Azure Functions ou Google Cloud Functions, les démarrages froids peuvent ajouter plusieurs centaines de millisecondes, voire plus, selon le langage, la taille du conteneur et la configuration de l’API Gateway en frontal. Par exemple, des benchmarks publics récents (Datadog, Lumigo, rapports AWS re:Invent) indiquent fréquemment 100–300 ms pour une fonction Node.js légère, 300–800 ms pour du Python et plus d’une seconde pour du Java ou .NET sur un runtime à froid. Ce délai devient inacceptable pour certaines API synchrones, mais reste parfaitement tolérable pour des traitements event driven ou des pipelines de données asynchrones.
Les plateformes de type Cloud Run, Azure Container Apps ou les containers serverless d’AWS réduisent partiellement ces démarrages froids en gardant des conteneurs chauds, mais le problème ne disparaît pas totalement à fort trafic variable. Vous devez donc modéliser explicitement les profils de trafic, les fenêtres de cold start et les besoins de mise à l’échelle pour chaque service, qu’il s’agisse d’une fonction FaaS, d’un conteneur ou d’un serveur applicatif classique. L’observabilité devient alors un critère clé de l’arbitrage entre serverless et containers, car le debugging en production d’une fonction serverless distribuée sur plusieurs régions cloud reste plus complexe que celui d’un conteneur unique.
Pour garder la main, beaucoup de CTO investissent dans une plateforme interne de type internal developer platform, qui abstrait les détails de l’infrastructure et unifie le cycle de vie des déploiements serverless et containers ; un bon point de départ consiste à concevoir un portail développeur qui accélère le delivery sans devenir une usine à gaz. Cette approche permet de standardiser les patterns d’API Gateway, de journalisation et de traçage distribué, quel que soit le fournisseur cloud ou le type de conteneur utilisé. Vous réduisez ainsi le coût cognitif pour les équipes tout en gardant la flexibilité d’utiliser des services managés comme Cloudflare Workers ou Serverless Framework pour les fonctions, et des conteneurs Docker pour les workloads plus lourds.
Quand le serverless l’emporte : événements sporadiques, fonctions sans état et pipelines de données
Le serverless brille dès que votre charge est réellement event driven, sporadique et difficile à prévoir à l’échelle de la journée. Dans ce cas, une architecture bien pensée permet de payer uniquement les millisecondes d’exécution de chaque fonction, sans maintenir de serveur ni de machines virtuelles en permanence. Les services FaaS comme AWS Lambda, Azure Functions ou Cloudflare Workers deviennent alors des briques naturelles pour encapsuler une fonction métier, exposer une API ou orchestrer des traitements de données.
Les pipelines de données temps réel, les intégrations entre applications SaaS et les tâches de back office déclenchées par événements sont des candidats idéaux pour une architecture serverless. Vous pouvez par exemple combiner AWS Lambda, un API Gateway managé et des services de streaming pour absorber un trafic variable sans surprovisionner l’infrastructure, tout en gardant un cycle de vie court pour chaque fonction. Sur Google Cloud, Cloud Run et les containers serverless associés offrent une alternative intéressante pour exécuter des conteneurs Docker stateless en mode serverless, avec une mise à l’échelle automatique fine et une bonne intégration aux services de données managés.
Dans ces scénarios, le vendor lock est réel mais souvent acceptable si vous encapsulez vos fonctions derrière des interfaces claires et des contrats d’API stables. La clé consiste à séparer le code métier de la colle d’infrastructure propre à chaque cloud, en utilisant par exemple Serverless Framework ou des abstractions internes pour gérer les déploiements multi environnements. C’est précisément dans ce type de contexte que les équipes de platform engineering prennent tout leur sens, comme le montre l’essor des équipes plateforme dans les grandes DSI, qui industrialisent ces patterns serverless sans brider l’autonomie des équipes produit.
Quand les containers gagnent : workloads IA, services stateful et portabilité multi cloud
Les containers reprennent l’avantage dès que vos workloads sont lourds, stateful ou fortement couplés à des ressources matérielles spécifiques comme les GPU. Les plateformes Kubernetes, qu’elles tournent sur AWS, Azure ou Google Cloud, offrent un contrôle fin sur les ressources, la topologie réseau et la sécurité, ce qui reste difficile à obtenir avec une simple architecture serverless. Les conteneurs Docker deviennent alors l’unité de base pour packager vos applications, vos services IA ou vos API critiques, avec une maîtrise complète du serveur logique et du cycle de vie de chaque conteneur.
Les avancées récentes comme l’In Place Pod Resizing, les sidecar containers en disponibilité générale et la Dynamic Resource Allocation pour les GPU renforcent encore la pertinence des containers pour les charges exigeantes. Vous pouvez ajuster les ressources sans redémarrage, gérer proprement le cycle de vie des init containers et optimiser l’allocation fine des GPU, ce qui est impossible dans la plupart des environnements FaaS. Dans une comparaison honnête entre serverless et containers, ces capacités pèsent lourd pour les plateformes de machine learning, les moteurs de recherche internes ou les services de données stateful qui exigent une latence stable et une mise à l’échelle contrôlée.
La portabilité multi cloud reste un argument fort en faveur des containers, même si le multi cloud intégral a un coût caché non négligeable pour les CTO, comme le montre l’analyse sur le coût caché du multi cloud et le retour à un cloud principal plus un secondaire. En standardisant vos déploiements sur des containers et des machines virtuelles orchestrés, vous réduisez le vendor lock au niveau des runtimes, tout en gardant la possibilité d’utiliser des services managés ciblés comme Cloud Run ou Azure Container Apps pour certains services. Cette approche hybride vous permet de combiner la robustesse des conteneurs avec la souplesse des services serverless, sans sacrifier la gouvernance ni l’observabilité.
Vers un modèle hybride : core en containers, extensions en serverless
La plupart des organisations matures convergent vers un modèle hybride où le core métier tourne sur des containers, tandis que les extensions et intégrations reposent sur du serverless. Cette approche rend la décision beaucoup plus granulaire, car chaque domaine fonctionnel se voit attribuer le bon niveau de contrôle, de portabilité et de mise à l’échelle. Les services critiques et stateful restent dans des conteneurs Docker ou des containers serverless long lived, alors que les fonctions event driven absorbent le trafic variable en périphérie.
Concrètement, un même produit peut combiner une API principale déployée sur des containers Kubernetes, des webhooks traités par des fonctions FaaS et des tâches de traitement de données exécutées sur AWS Lambda ou Cloud Run. Les API Gateway unifient l’exposition des services, tandis que des outils comme Serverless Framework ou des pipelines CI CD maison orchestrent le cycle de vie des déploiements sur plusieurs clouds. Dans ce modèle, le serveur n’est plus une machine unique mais un ensemble cohérent de services, de fonctions et de conteneurs, chacun optimisé pour son profil de charge et son besoin de mise à l’échelle.
Le rôle du CTO consiste alors à définir des garde fous architecturaux clairs, plutôt qu’à imposer un choix binaire entre serverless et containers. Vous pouvez par exemple réserver le serverless aux fonctions stateless, aux intégrations SaaS et aux traitements batch, tout en gardant les workloads IA, les bases de données et les services à forte intensité CPU dans des containers. Cette discipline permet de limiter le vendor lock, de mieux gérer les démarrages froids et de garder une vision claire de l’infrastructure globale, même lorsque les services et les applications se multiplient.
Cadre de décision pour CTO : arbitrer au delà du coût immédiat
Pour trancher sereinement, vous avez besoin d’un cadre de décision explicite qui dépasse le simple comparatif de coût à la requête ou au vCPU. Ce cadre doit intégrer au minimum cinq dimensions : profil de trafic, criticité métier, exigences de latence, besoin de portabilité et maturité de l’équipe sur chaque technologie. Le choix entre serverless et containers devient alors un exercice de scoring, où chaque service, chaque API et chaque fonction est évalué selon ces critères, plutôt qu’un débat idéologique sur le cloud.
Sur le profil de trafic, le serverless reste imbattable pour les charges event driven, les pics imprévisibles et les intégrations ponctuelles, tandis que les containers gagnent pour les flux stables, les workloads IA et les services stateful. Sur la portabilité, les conteneurs Docker et les machines virtuelles limitent le vendor lock, mais au prix d’une infrastructure plus lourde à opérer et d’un cycle de vie plus complexe. Sur la latence, les démarrages froids et le cold start des fonctions FaaS imposent de réserver le serverless aux parcours où quelques centaines de millisecondes supplémentaires restent acceptables pour l’utilisateur final.
Enfin, la maturité de vos équipes et de votre plateforme interne doit peser autant que les benchmarks de performance ou les grilles tarifaires des fournisseurs cloud. Une équipe qui maîtrise déjà Kubernetes, les sidecar containers et la Dynamic Resource Allocation tirera un meilleur parti des containers serverless et des container apps qu’une équipe encore en phase d’apprentissage. À l’inverse, une organisation très orientée produit, avec une forte culture d’API et de services managés, gagnera souvent à pousser plus loin l’architecture serverless, tant que les garde fous sur l’observabilité, la sécurité des données et la gouvernance des services restent clairement définis.
FAQ : questions fréquentes sur le choix entre serverless et containers
Comment évaluer l’impact des cold starts sur une application critique ?
La seule approche fiable consiste à mesurer les démarrages froids en conditions réelles, avec le langage, la taille de conteneur et la configuration d’API Gateway que vous utiliserez en production. Simulez des périodes d’inactivité suivies de pics de trafic, puis comparez la latence observée aux objectifs UX définis avec le métier. Si l’écart dépasse quelques centaines de millisecondes sur un parcours clé, privilégiez un déploiement en containers ou en containers serverless avec instances préchauffées.
Le serverless est il adapté aux workloads IA et machine learning ?
Le serverless pur de type FaaS reste rarement adapté aux workloads IA lourds, qui nécessitent des GPU, de grandes quantités de mémoire et des sessions longues. Les containers orchestrés, éventuellement combinés à des services managés de type GPU as a Service, offrent un contrôle bien supérieur sur les ressources et la topologie réseau. En pratique, le serverless fonctionne mieux pour l’orchestration de jobs IA ou le pré et post traitement, tandis que les modèles eux mêmes tournent dans des conteneurs Docker ou sur des machines virtuelles spécialisées.
Comment limiter le vendor lock dans une architecture serverless ?
La première étape consiste à isoler le code métier de la colle d’infrastructure propre à chaque cloud, en évitant de mélanger logique fonctionnelle et appels directs aux services managés. Utilisez des interfaces d’API internes, des adaptateurs et éventuellement des frameworks comme Serverless Framework pour structurer vos déploiements. Vous pouvez aussi définir des contrats d’API stables et des schémas d’événements neutres, afin de pouvoir ré héberger certaines fonctions sur un autre fournisseur ou dans des containers si nécessaire.
Faut il viser le multi cloud complet pour rester indépendant ?
Le multi cloud complet apporte une illusion de liberté mais un surcoût opérationnel massif, en particulier sur l’observabilité, la sécurité et la gestion des données. Une stratégie plus réaliste consiste à adopter un cloud principal, complété par un cloud secondaire pour des cas d’usage ciblés ou des besoins de résilience. Dans ce contexte, les containers et les machines virtuelles servent de couche de portabilité, tandis que le serverless est utilisé de manière plus opportuniste, là où le gain de time to market compense clairement le risque de dépendance.
Comment organiser les équipes pour gérer un modèle hybride serverless et containers ?
Un modèle hybride efficace repose souvent sur une équipe plateforme dédiée, chargée de fournir des abstractions communes pour le déploiement, l’observabilité et la sécurité, que les équipes produit consomment ensuite en self service. Cette équipe définit les standards d’API Gateway, de logging, de traçage et de gestion des secrets, tout en maintenant des templates pour les fonctions serverless et les services en conteneurs. Les squads produit peuvent alors choisir le bon runtime pour chaque service, sans réinventer l’infrastructure ni compromettre la gouvernance globale.