Kubernetes : self-hosted ou managé ? Le vrai calcul

Vous vous posez la question depuis 6 mois. "Est-ce qu'on gère Kubernetes nous-même ou on délègue à un provider ?"

Votre DevOps dit : "On peut le faire soi-même, c'est pas compliqué."

Votre CFO dit : "Ça coûte combien managé versus self-hosted ?"

Votre CEO attend la réponse définitive.

Voici les vrais chiffres. Et spoiler : si vous avez moins de 200 containers en production, le managé est presque toujours meilleur économiquement.

La promesse du self-hosted

"On installe Kubernetes nous-même, on économise l'argent que coûte un service managé."

C'est logique en théorie. En pratique ? Il y a des coûts cachés énormes.

Coûts du self-hosted (honnêtement)

1. Infrastructure compute (le visible)

Vous avez besoin au minimum de 3 nodes control plane (pour la haute disponibilité) + des worker nodes.

Configuration minimum pour une PME :

• 3x masters : t3.large
• 10x workers : t3.xlarge
• Load balancer
• Total infra : un poste modeste, vite éclipsé par les coûts humains qui suivent

2. Sécurité et patching (le souvent oublié)

Kubernetes sort une nouvelle version tous les 3 mois. Chaque version a des correctifs de sécurité. Vous devez mettre à jour vos masters et workers sans downtime.

Ça semble simple. Ça ne l'est pas. Vous avez besoin de :

• Scripts de drain et cordon (drainer les charges de travail d'un node avant la mise à jour)
• Tests de mise à jour en staging (3-4 jours)
• Plan de rollback au cas où ça casse
• Quelqu'un d'astreinte pendant la mise à jour

Coûts :

• 0,5 ETP DevOps juste pour les mises à jour
• Infrastructure de test (cluster de staging)
• Total : un demi-ETP mobilisé en continu, plus l'infra de staging

3. Monitoring et alerting (le compliqué)

Votre cluster Kubernetes tombe. Combien de temps avant que vous le remarquiez ? 5 minutes ? 30 minutes ? 2 heures ?

Sans monitoring robuste, votre première alerte peut être un client qui dit "votre site ne marche pas."

Kubernetes exige une observabilité sophistiquée :

• Prometheus + Grafana (ou Datadog/New Relic)
• Logging centralisé (ELK stack ou Loki)
• Distributed tracing (Jaeger)
• Gestion des alertes (PagerDuty)
• Total : un budget outillage récurrent, qui peut varier du simple au double selon la stack

Et quelqu'un doit entretenir ça : comptez environ 0,3 ETP DevOps supplémentaire.

4. Réseau

Vous avez 47 services qui doivent communiquer. Vous avez besoin d'un service mesh (Istio, Linkerd, Consul) pour tracer le trafic, faire du circuit breaking, des canaries, etc.

Sans ça, vous naviguez dans le noir. Avec ça, c'est complexe.

Coûts :

• Service mesh (licence + engineering)
• Load balancers (plusieurs pour le failover)
• Total : un poste récurrent, licence et temps d'ingénierie compris

5. Stockage (le stateful)

Un cluster Kubernetes a besoin de stockage persistant. Vous pouvez utiliser NFS (économique mais instable), SAN fibre (cher mais solide), ou du stockage cloud (managé mais avec latence).

Coûts :

• SAN storage ou NAS : un investissement initial lourd, plus la maintenance annuelle
• Ou stockage managé (AWS EBS, GCP persistent disks) : facturé à l'usage
• Sauvegardes (Velero, etc.) : un poste récurrent
• Total : un poste récurrent non négligeable en moyenne

6. Administration (le coût humain)

Quelqu'un doit :

• Gérer le cluster (capacity planning, ajouts de nodes, décommissionnement)
• Résoudre les problèmes (85 % de votre downtime vient de problèmes d'infrastructure)
• Répondre aux incidents (astreinte)
• Mettre à jour la documentation
• Former les nouvelles recrues

Minimum : 1,5 ETP DevOps/SRE, soit le poste le plus lourd de tout le calcul.

Total : coût du self-hosted

Et c'est pour un cluster stable, sans incidents majeurs.

Si vous avez un incident (crash de nodes, panne de stockage, faille de sécurité), ajoutez un coût d'engineering d'urgence qui peut représenter à lui seul une fraction substantielle du budget annuel.

Coûts du Kubernetes managé

Hikube.cloud, AWS EKS, GCP GKE, Azure AKS : qu'est-ce qu'ils font de leur côté ?

1. Infrastructure et control plane

Vous payez un forfait modeste pour le control plane (selon le provider). Les worker nodes, c'est votre infrastructure ou des instances que vous payez. C'est le même coût qu'en self-hosted.

Mais voici la différence : AWS/GCP/Hikube gèrent les mises à jour, la sécurité, la résilience du control plane. Vous ne portez pas le demi-ETP et l'infra de staging que cela représente en self-hosted.

Économie : tout le poste patching/mises à jour

2. Monitoring et alerting

Beaucoup de services managés incluent un monitoring de base (santé des nodes, redémarrages de pods). Vous payez moins pour l'observabilité parce que le provider maintient déjà une stack.

Économie : une bonne partie du budget observabilité

3. Réseau

Le Kubernetes managé vient généralement avec un ingress controller, du load balancing, un service mesh optionnel. Vous n'avez pas à déployer Istio vous-même.

Économie : l'essentiel du poste réseau

4. Stockage

Les services managés intègrent la résilience et les sauvegardes. C'est plus transparent pour vous.

Économie : une part importante du poste stockage

5. Personnel

Au lieu de 1,5 ETP, vous avez besoin de peut-être 0,5 ETP pour gérer le cluster (parce que le provider gère les tâches courantes). L'autre ETP ? Libéré pour innover.

Économie : un ETP complet

Total : Kubernetes managé

Vous économisez de l'ordre de 15 % par an, avant même de compter les incidents.

TCO sur 3 ans : la vraie comparaison

Le calcul annuel est une chose, mais les décisions d'infrastructure se prennent sur 3-5 ans. Voici le TCO réaliste sur 3 ans, en incluant les coûts souvent oubliés :

Différence sur 3 ans : le self-hosted revient à près du double du managé. C'est presque le salaire de 2 ingénieurs seniors pendant 3 ans.

Le poste le plus sous-estimé est celui des incidents non-planifiés. En self-hosted, une mise à jour Kubernetes qui tourne mal peut coûter 3-5 jours d'engineering par incident. Sur 3 ans avec 2 mises à jour par an, ces incidents s'accumulent. En managé, le provider absorbe ce risque.

Autre coût invisible : le turnover. Si votre unique expert Kubernetes part, vous perdez 3-6 mois de productivité le temps de recruter et former quelqu'un. En managé, cette dépendance est réduite car le provider assure la continuité opérationnelle.

Les vrais coûts du managé qu'on oublie parfois

C'est vrai, il y a quelques coûts du managé qu'on oublie souvent :

1. Dépendance au fournisseur. Si vous êtes sur AWS EKS, vos données sont sur AWS. Ce n'est pas grave si vous avez confiance. C'est grave si votre contrat change et que vous voulez partir.

2. Moins de contrôle. Avec le managé, vous avez moins de leviers à actionner. C'est un avantage (moins de risques de mauvaise configuration) et un désavantage (si vous avez un besoin spécifique, vous êtes bloqué).

3. Certaines fonctionnalités manquent. Si vous avez besoin d'une chose très spécifique (plugin réseau custom, stockage particulier), le managé peut ne pas le supporter.

Pour les entreprises suisses, Hikube.cloud règle plusieurs de ces préoccupations :

• Infrastructure en Suisse (pas de dépendance envers un cloud US)
• Support local (Hidora parle français, connaît les réglementations suisses)
• Plus de transparence sur ce qui se passe sous le capot

Quand le self-hosted a du sens

Il y a des cas où le self-hosted est justifié :

Cas 1 : Très grande échelle (> 1 000 pods)

À très grande échelle, les coûts unitaires d'un service managé deviennent significatifs. Si vous avez 5 000 pods, le surcoût du provider devient à lui seul un poste conséquent.

À ce stade, le self-hosted peut être plus avantageux. Mais vous avez aussi 5+ personnes à temps plein sur Kubernetes, donc c'est une organisation plus grande.

Cas 2 : Besoin spécifique de personnalisation

Vous avez besoin d'un CNI custom (container network interface), d'un système de stockage très spécifique, ou d'une architecture très inhabituelle. Le managé peut ne pas le supporter.

Mais ce cas est rare. Très rare.

Cas 3 : Infrastructure air-gapped (aucun accès internet)

Vous ne pouvez pas utiliser AWS/GCP (la politique réseau interdit tout accès internet). Vous devez héberger vous-même en on-premise.

C'est un cas d'usage légitime dans certains contextes.

En bref : matrice de décision

En résumé

Le Kubernetes self-hosted coûte plus cher que le managé une fois le coût humain inclus, et l'écart se creuse d'année en année. Sur trois ans, le self-hosted revient à près du double.

Mais c'est en supposant que le self-hosted tourne sans accroc. Un incident majeur et la facture self-hosted grimpe encore.

Pour 95 % des entreprises de 500+ employés : le managé est la réponse correcte. Vous économisez de l'argent, vous dormez mieux la nuit, et votre équipe peut se concentrer sur ce qui compte (les applications) au lieu de l'infrastructure.

Si vous êtes en Suisse ? Hikube.cloud est votre réponse. Kubernetes managé, infrastructure suisse, support local. Le meilleur des deux mondes.

À lire aussi :

• Choisir un MSP DevOps : critères de sélection
• Cloud cost optimization : ce que votre CFO veut entendre

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert