Serverless ou Kubernetes : les critères que les équipes japonaises devraient vraiment regarder

La vraie question derrière « c'est quoi le serverless ? »

La plupart des gens qui cherchent une définition du serverless ne cherchent pas vraiment une définition. Ce qu'ils veulent savoir, c'est s'il faut faire basculer leurs systèmes vers le serverless ou s'engager sur Kubernetes. Cet article n'est pas une entrée de glossaire : c'est une décision d'architecture.

La conclusion d'abord : les deux ne s'opposent pas. La vraie décision est un problème de placement — quelle charge de travail sur quel modèle d'exécution — et dans la plupart des systèmes, les deux finissent par cohabiter. Dès qu'on pose la question en binaire, le débat devient une affaire de goût et les critères disparaissent.

Le serverless n'est pas une technologie, mais trois

Si ces discussions tournent en rond, c'est d'abord parce que le mot « serverless » désigne au moins trois choses différentes.

• Le FaaS — AWS Lambda, Google Cloud Functions, Azure Functions. On déploie à la granularité de la fonction, l'invocation est événementielle. Limite de durée d'exécution, contrainte de taille de package et environnement d'exécution peu ouvert font partie du contrat.
• Les runtimes de conteneurs managés — Google Cloud Run, AWS App Runner, ECS Fargate, Azure Container Apps. On confie une image de conteneur et on délègue la gestion des nœuds et du scaling au fournisseur. La liberté sur le runtime est celle de n'importe quel conteneur.
• Les bases de données serverless — Aurora Serverless, DynamoDB en mode on-demand et équivalents. On abandonne le pré-provisionnement de capacité pour une facturation à la consommation réelle.

Ces trois familles n'ont ni les mêmes contraintes, ni la même structure de coût, ni les mêmes points de rupture opérationnels. « Le serverless plafonne la durée d'exécution, donc ça ne passe pas » est vrai du FaaS et faux des conteneurs managés. « Le serverless enferme dans un fournisseur » s'affaiblit beaucoup quand l'artefact livré est une image de conteneur. Les confondre revient à écarter des options viables avant même d'avoir commencé l'analyse.

Ce que Kubernetes apporte réellement

Kubernetes n'est pas « une façon de faire tourner des conteneurs ». C'est un socle pour construire sa propre plateforme déclarative. La valeur, c'est d'avoir ordonnancement, service discovery, mises à jour progressives et contrôle des ressources derrière une seule API. Le prix, c'est la propriété permanente des montées de version du cluster, des politiques réseau, des certificats, de l'observabilité et de la gestion des accès.

La décision Kubernetes n'est donc pas une question de supériorité technique. Elle se ramène à une question d'organisation : existe-t-il une équipe capable de porter cette responsabilité dans la durée ? Si on esquive la question, on obtient un cluster qui tourne mais que personne ne veut mettre à jour.

Critère 1 — le profil de charge

La forme de la charge est le critère le plus discriminant. Les charges qui retombent près de zéro et connaissent des pics ponctuels — outils d'administration internes, API déclenchées par événement, traitements liés à une campagne — vont bien avec un modèle qui ne facture pas l'inactivité. Les charges quasi constantes sur 24 heures permettent de tenir une capacité réservée à un taux d'utilisation élevé, ce qui favorise les instances et les node pools.

Regardez le rapport entre pic et creux et la durée des pics, pas les moyennes. Raisonner sur un nombre moyen de requêtes fausse à la fois l'estimation de facture et la compréhension du scaling.

Critère 2 — cold start et exigences de latence

Le cold start s'évalue à l'endroit où il apparaît, pas à son existence. Un délai sur un chemin synchrone qui bloque un utilisateur n'a rien à voir avec un délai caché derrière un traitement asynchrone. Pour un batch ou un consommateur de file, la latence de première invocation est en général sans objet.

Même sur un chemin synchrone exigeant, ce n'est pas tout ou rien : nombre minimal d'instances, sortie de l'initialisation du chemin de requête, runtimes à démarrage léger. Commencez par définir qui voit réellement ce délai.

Critère 3 — durée d'exécution, réseau, état

• Durée d'exécution — le FaaS plafonne la durée d'une invocation, ce qui force les batchs longs, le transcodage vidéo et les grosses transformations de données dans une conception découpée. Les conteneurs managés ou les exécuteurs de jobs expriment cela beaucoup plus naturellement.
• Complexité réseau — connexions à des bases dans un VPC, partenaires qui exigent une IP source fixe, liens dédiés vers l'on-premise. Dès que c'est en jeu, le côté serverless réclame intégration VPC, connecteurs et conception NAT, et l'avantage « moins de configuration » s'amincit. Au Japon, les intégrations avec restriction d'IP vers les systèmes des partenaires restent très répandues : c'est à vérifier tôt.
• Besoins stateful — connexions WebSocket longues, dépendance à un cache en mémoire, traitements qui supposent un disque local. Tout cela s'accorde mal avec les modèles d'exécution serverless, et le coût d'externalisation doit être chiffré en amont.

Raisonner en mécanique de facturation, pas en prix unitaires

L'erreur la plus fréquente dans une comparaison de coûts consiste à aligner des grilles tarifaires. Les prix sont révisés et les remises dépendent du contrat. Ce qui reste stable, c'est la mécanique de facturation.

• À la consommation (serverless) — facturation sur le nombre de requêtes et sur la durée d'exécution multipliée par les ressources allouées. Le coût suit l'usage, et l'inactivité ne coûte pratiquement rien.
• Réservé (instances / node pools) — facturation sur le temps pendant lequel la ressource tourne. Le coût suit la capacité réservée, indépendamment de ce qui a été consommé.

Le point de bascule est donc le taux d'utilisation. Si vous savez occuper la capacité réservée, le réservé l'emporte sur le coût unitaire ; si l'utilisation est faible ou imprévisible, c'est la consommation qui gagne.

Deux coûts sont systématiquement oubliés. Côté Kubernetes, les coûts indirects : control plane, socle de supervision et de logs, et surtout le temps humain qui maintient le cluster en vie. Côté serverless, le transfert de données et l'intégration entre services managés, qui s'accumulent à mesure que l'architecture se fragmente. Une comparaison qui ignore les deux se trompe presque toujours de conclusion.

La méthode est simple : passer votre trafic réellement mesuré dans les deux modèles de facturation. Les tarifs publics et vos propres métriques constituent une base bien plus fiable que le retour d'expérience d'un tiers.

Ce qui est propre au marché japonais

Tout ce qui précède vaut partout. Le Japon ajoute des conditions qui changent réellement la décision. Ce ne sont pas des généralités culturelles : uniquement les facteurs qui se retrouvent dans la conception ou dans le contrat.

• Résidence des données et conformité — dans la finance, la santé et le secteur public, le lieu de stockage et la capacité à expliquer l'architecture à un auditeur sont des exigences fermes. La présence d'une région domestique et la conformité aux normes de sécurité du FISC ou aux exigences d'achat public des systèmes d'information de l'État (notamment l'enregistrement ISMAP pour les services cloud) réduisent d'emblée l'éventail des options. Les services managés allègent l'exploitation, mais il faut d'abord vérifier que le fournisseur communique ce qu'un audit réclamera.
• La division du travail avec les SIer — beaucoup d'organisations japonaises externalisent la construction et l'exploitation de l'infrastructure auprès d'intégrateurs. Dans ce cas, « vous n'exploitez plus l'infrastructure » est un changement de structure contractuelle, pas seulement d'architecture. Si le contrat de maintenance est valorisé en jours-homme, l'optimum technique et l'optimum contractuel divergent. Poursuivre l'étude technique sans traiter ce décalage, c'est se bloquer au moment de l'implémentation.
• L'offre en SRE et en platform engineering — choisir Kubernetes, c'est s'engager à recruter et à retenir les personnes qui l'exploiteront. Le marché japonais du SRE est tendu, et une architecture qui repose sur une seule personne est un risque d'entreprise. Si le recrutement n'est pas réaliste, déplacer la responsabilité d'exploitation vers le fournisseur est la conception la plus saine.
• Le processus de décision ringi — au Japon, les décisions d'investissement et d'architecture passent généralement par le ringi, une validation écrite qui circule entre les parties prenantes. La décision est donc documentée et sera réexaminée. Ce qui passe, ce n'est pas « c'est nouveau » mais « nous avons tranché au regard de ces critères ». Formuler la justification en termes de profil de charge, d'exigences de latence et de capacité d'exploitation accélère l'approbation et facilite la révision ultérieure. Savoir si un coût réservé prévisible ou un coût variable indexé sur l'usage se défend mieux en interne est, en pratique, un facteur réel.
• La migration depuis l'on-premise — une part importante des systèmes de production tourne encore on-premise. Viser directement le serverless comme première cible de migration implique en général une réécriture lourde. Conteneuriser d'abord, atterrir sur une plateforme de conteneurs managés, puis déplacer vers le FaaS et les bases serverless les parties qui s'y prêtent : la répartition du risque est bien meilleure.

Un cadre de décision

En synthèse, procédez dans cet ordre.

1. Décomposer les charges de travail. Ne cherchez pas à faire entrer tout le système dans une seule réponse. Séparez API synchrones, jobs asynchrones, batchs planifiés et processus résidents.
2. Vérifier d'abord les critères éliminatoires : résidence des données, exigences réglementaires, contraintes réseau, plafond de durée d'exécution. Écartez ce qui n'est pas choisissable.
3. Mesurer le profil de charge : rapport pic/creux, durée des pics, existence de plages proches de zéro.
4. Définir les exigences de latence uniquement sur les chemins synchrones. Soyez explicite sur le fait qu'un cold start soit visible ou non pour un utilisateur.
5. Évaluer honnêtement la capacité d'exploitation. Avez-vous aujourd'hui les personnes pour exploiter Kubernetes, et pourrez-vous les garder ?
6. Passer vos chiffres mesurés dans les deux modèles de facturation. Coûts indirects inclus.
7. Documenter la justification — y compris ce qui devrait changer pour rouvrir la décision.

Les deux premières étapes ramènent l'éventail des options au réaliste, et c'est ce qui rend le reste de la discussion concret. C'est pour cela que l'ordre compte.

Là où ça atterrit en pratique

Pour la plupart des équipes, l'issue réaliste n'est pas de tout regrouper d'un côté. Les services à trafic variable et les nouveaux services vont sur une plateforme de conteneurs managés ; les traitements événementiels et les jobs planifiés vont au FaaS ; les systèmes cœur sous charge élevée et continue, ainsi que les cas où de nombreux services doivent être standardisés sur une même plateforme, vont sur Kubernetes. Ce placement maintient la charge d'exploitation dans ce que l'équipe peut porter, tout en gardant le coût explicable.

Ce qu'il faut éviter, c'est de partir de généralités : « le serverless coûte moins cher », « Kubernetes est le standard du marché ». Les deux ne sont vraies que sous conditions. La décision part toujours de la forme de vos charges et de la capacité d'exploitation de votre équipe.