Le serverless ne signifie pas « sans serveur » : il signifie que l’infrastructure d’exécution est largement abstraite pour le développeur. Dans les offres managées (AWS Lambda, Google Cloud Functions), cela s’accompagne souvent d’une facturation à l’usage réel. Dans des plateformes open source comme Knative sur Kubernetes, l’intérêt principal est le déploiement simplifié, le scaling automatique et le scale-to-zero — mais vous continuez à payer votre cluster. Ce guide explique les concepts fondamentaux du serverless, le modèle FaaS, l’architecture event-driven et Knative — la solution serverless open source pour Kubernetes.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Le serverless fait partie des concepts cloud native utiles à connaître pour la KCNA, en particulier dans le domaine Architecture. Ce guide reste conceptuel — aucune installation n’est nécessaire.
- Ce que signifie serverless et ce que ce n’est pas
- La distinction entre BaaS (Backend as a Service) et FaaS (Function as a Service)
- Le fonctionnement du scale-to-zero et ses implications
- Le modèle event-driven au cœur du serverless
- Knative : le serverless cloud native sur Kubernetes
- Les limites du serverless et quand préférer d’autres approches
De quoi parle-t-on exactement ?
Section intitulée « De quoi parle-t-on exactement ? »Le terme « serverless » prête à confusion. Évidemment, des serveurs existent quelque part — mais le développeur ne les voit pas, ne les provisionne pas et ne les gère pas. Le contrat est simple : vous fournissez du code, la plateforme s’occupe du reste.
Ce modèle existe sous deux formes :
| Modèle | Définition | Exemple |
|---|---|---|
| BaaS (Backend as a Service) | Des services managés qui remplacent des composants côté serveur (base de données, authentification, stockage) | Firebase, Auth0, Amazon DynamoDB |
| FaaS (Function as a Service) | Vous déployez des fonctions individuelles qui s’exécutent en réponse à des événements | AWS Lambda, Google Cloud Functions, Knative Functions |
Dans le contexte de la KCNA et du cloud native, c’est le modèle FaaS qui est le plus pertinent.
Function as a Service (FaaS) : le cœur du serverless
Section intitulée « Function as a Service (FaaS) : le cœur du serverless »Le modèle FaaS repose sur une idée simple : du point de vue du développeur, l’unité logique de déploiement devient la fonction. En dessous, la plateforme peut tout à fait utiliser des conteneurs pour l’exécuter — mais le développeur n’a pas à s’en soucier.
Comment ça fonctionne
Section intitulée « Comment ça fonctionne »- Vous écrivez une fonction — un morceau de code qui prend un événement en entrée, le traite et retourne un résultat
- Vous la déployez sur la plateforme FaaS — sans vous soucier de l’infrastructure
- Un événement arrive (requête HTTP, message dans une file, changement de fichier…)
- La plateforme provisionne automatiquement une instance pour exécuter votre fonction
- La fonction s’exécute, renvoie le résultat et l’instance peut être réutilisée ou détruite
- Sans événement, aucune instance ne tourne — c’est le scale-to-zero
Caractéristiques du FaaS
Section intitulée « Caractéristiques du FaaS »| Caractéristique | Description |
|---|---|
| Stateless | Chaque invocation est indépendante — pas d’état partagé entre deux exécutions (principe stateless and share-nothing des 12-factor apps) |
| Éphémère | Les instances de fonction ont une durée de vie courte (secondes à minutes) |
| Event-driven | L’exécution est déclenchée par un événement, pas par un processus qui tourne en permanence |
| Scaling automatique | De zéro à des milliers d’instances, géré par la plateforme |
| Facturation à l’usage | Dans les offres managées, vous payez le temps d’exécution réel — avec Knative auto-hébergé, l’économie vient du scale-to-zero sur les ressources du cluster |
Scale-to-zero : l’innovation clé
Section intitulée « Scale-to-zero : l’innovation clé »Le scale-to-zero est la caractéristique qui distingue fondamentalement le serverless du déploiement conteneur classique.
Dans un déploiement Kubernetes classique, un Deployment maintient un nombre minimum de pods en permanence, même si aucune requête n’arrive. Avec le scale-to-zero, quand aucune requête n’est reçue pendant un temps configurable, la plateforme détruit toutes les instances. Le nombre de pods tombe littéralement à zéro.
Quand une nouvelle requête arrive, la plateforme crée une instance, l’initialise et route la requête vers elle. Ce processus d’initialisation s’appelle le cold start (démarrage à froid).
| Aspect | Déploiement classique | Serverless (scale-to-zero) |
|---|---|---|
| Pods au repos | Nombre minimum configuré (1+) | 0 — aucun pod |
| Coût au repos | Ressources consommées en permanence | Aucun coût |
| Temps de réponse | Immédiat (pods déjà prêts) | Cold start possible (de quelques ms à plusieurs secondes) |
| Scaling | HPA réagit aux métriques, avec délai | Scaling rapide déclenché par requête |
Architecture event-driven
Section intitulée « Architecture event-driven »Le serverless est intrinsèquement lié à l’architecture event-driven (pilotée par les événements). Au lieu d’un serveur qui attend en permanence des requêtes, des événements déclenchent l’exécution du code.
Les types d’événements
Section intitulée « Les types d’événements »| Source d’événement | Exemples concrets |
|---|---|
| Requête HTTP | Un utilisateur envoie un formulaire |
| Message queue | Un message arrive dans Kafka, RabbitMQ ou SQS |
| Changement de données | Un objet est ajouté dans un bucket S3, une ligne modifiée dans une base |
| Timer / cron | Une tâche planifiée (nettoyage quotidien, rapport hebdomadaire) |
| Événement Kubernetes | Un pod est créé, un ConfigMap modifié |
Le standard CloudEvents
Section intitulée « Le standard CloudEvents »Pour éviter que chaque fournisseur définisse son propre format d’événement, la CNCF a créé la spécification CloudEvents — un format standard pour décrire les événements de façon interopérable. CloudEvents est un projet CNCF graduated.
Un CloudEvent contient au minimum :
- source : d’où vient l’événement (ex:
/myapp/orders) - type : quel type d’événement (ex:
order.created) - id : identifiant unique
- data : le contenu de l’événement
Ce standard permet de connecter des sources d’événements et des consommateurs de façon indépendante du fournisseur cloud.
Knative : le serverless cloud native
Section intitulée « Knative : le serverless cloud native »Knative est une plateforme open source graduated par la CNCF qui apporte les capacités serverless à Kubernetes, notamment le scale-to-zero, le routage HTTP et l’event-driven. Créé par Google en 2018, accepté en incubation en 2022 puis promu graduated en septembre 2025, Knative permet de déployer et scaler automatiquement des workloads serverless sur n’importe quel cluster Kubernetes, sans lock-in vers un fournisseur cloud.
Knative se compose de trois composants principaux :
Knative Serving
Section intitulée « Knative Serving »Knative Serving gère le cycle de vie complet des workloads HTTP : déploiement, scaling automatique (y compris scale-to-zero), routage et traffic splitting.
Les concepts clés de Serving :
| Concept | Rôle |
|---|---|
| Service | Ressource principale — gère automatiquement les Routes, Configurations et Revisions |
| Revision | Snapshot immutable du code + configuration à un instant T. Chaque mise à jour crée une nouvelle Revision |
| Route | Mappe un endpoint réseau vers une ou plusieurs Revisions (traffic splitting) |
| Configuration | Maintient l’état désiré du déploiement |
Concrètement, quand vous déployez un Knative Service :
- La plateforme crée une Revision (version immutable)
- Si aucun trafic n’arrive, le nombre de pods tombe à zéro
- À la première requête, l’Activator intercepte la requête, demande au scaler de créer des pods
- Le pod démarre, le queue-proxy (sidecar léger) gère la concurrence et collecte les métriques
- Si le trafic augmente, le scaler crée des pods supplémentaires automatiquement
Knative Eventing
Section intitulée « Knative Eventing »Knative Eventing fournit l’infrastructure pour l’architecture event-driven. Il gère le routage d’événements entre producteurs et consommateurs en utilisant le standard CloudEvents.
Les concepts clés d’Eventing :
| Concept | Rôle |
|---|---|
| Source | Produit des événements depuis un système externe (Kafka, API Kubernetes, timer…) |
| Broker | Réceptionne les événements et les route vers les consommateurs intéressés |
| Trigger | Filtre les événements par attributs CloudEvents et les délivre au bon consommateur |
| Sink | Consommateur qui reçoit et traite les événements |
Knative Functions
Section intitulée « Knative Functions »Knative Functions ajoute une expérience développeur plus simple pour exposer des fonctions sur Knative, en générant automatiquement les artefacts nécessaires (image conteneur, manifeste Kubernetes) à partir du code source — sans écrire de Dockerfile.
Serverless vs conteneurs : quand choisir quoi
Section intitulée « Serverless vs conteneurs : quand choisir quoi »Le serverless n’est pas un remplacement des conteneurs — c’est une abstraction au-dessus. En fait, Knative déploie vos fonctions sous forme de conteneurs dans Kubernetes. La question est le niveau d’abstraction souhaité.
| Critère | Conteneurs (Deployment K8s) | Serverless (FaaS / Knative) |
|---|---|---|
| Unité de déploiement | Image conteneur + manifeste | Fonction ou service HTTP |
| Scaling | Manuel ou HPA (min 1 pod) | Automatique, incluant scale-to-zero |
| Coût au repos | Pods consomment des ressources | Zéro coût quand aucune requête |
| Cold start | Aucun (pods déjà prêts) | Possible (de 100 ms à quelques secondes) |
| Workloads adaptés | Services longue durée, trafic constant | Tâches événementielles, trafic variable ou intermittent |
| Contrôle | Total (réseau, stockage, runtime) | Réduit (abstraction de l’infrastructure) |
| Complexité opérationnelle | Moyenne (vous gérez les Deployments) | Supérieure au début (Knative à installer), puis inférieure au quotidien |
Cas d’usage idéaux pour le serverless
Section intitulée « Cas d’usage idéaux pour le serverless »- APIs avec trafic variable : un service qui reçoit beaucoup de requêtes le jour et aucune la nuit
- Traitement événementiel : un pipeline qui réagit à l’upload d’un fichier, un message Kafka, un webhook
- Tâches planifiées : nettoyage de données, génération de rapports, envoi d’e-mails
- Prototypage rapide : déployer un service sans se préoccuper de l’infrastructure
- Environnements de développement : scale-to-zero pour économiser les ressources
Cas où le serverless n’est pas adapté
Section intitulée « Cas où le serverless n’est pas adapté »- Processus long (> 10-15 minutes) : les fonctions ont une durée d’exécution limitée
- Workloads avec état : bases de données, caches persistants, systèmes de fichiers
- Trafic constant et prévisible : le scale-to-zero n’apporte rien si les pods tournent en permanence
- Latence ultra-faible requise : le cold start est un risque pour les applications temps réel
- Applications avec beaucoup de connexions persistantes : WebSockets, gRPC streaming
À retenir
Section intitulée « À retenir »- Serverless signifie que l’infrastructure est abstraite — le développeur ne gère ni serveurs ni scaling
- Le modèle FaaS (Function as a Service) exécute du code à la demande, en réponse à des événements
- Le scale-to-zero distingue le serverless du déploiement classique : zéro pod quand il n’y a pas de trafic, mais attention au cold start
- L’architecture event-driven est au cœur du serverless : les événements (HTTP, messages, cron) déclenchent l’exécution
- CloudEvents (CNCF graduated) standardise le format des événements pour l’interopérabilité
- Knative (CNCF graduated) apporte le serverless à Kubernetes : Serving (scale-to-zero), Eventing (routage événementiel), Functions (expérience simplifiée)
- Le serverless est idéal pour les workloads événementiels et intermittents ; pour les services à trafic constant ou les processus longs, les conteneurs classiques restent plus adaptés