N’utilisez pas encore Kubernetes
(matt-rickard.com)Les startups en phase early stage ne devraient pas adopter Kubernetes trop hâtivement.
Dans la plupart des cas, c’est prématuré.
Pour les petites équipes (1 à 10 personnes), il vaut mieux utiliser un service de conteneurs serverless.
(AWS ECS - Fargate, Google Cloud Run de GCP)
13 commentaires
Le sujet de k8s n’est déjà plus une question de préférences, mais plutôt de survie, non ?
Je pense qu’on en est arrivé à une situation où, même sans connaître AWS, il faut au moins connaître k8s.
Je ne suis pas d’accord avec cet avis.
Je pense que le seul véritable inconvénient de k8s, c’est sa courbe d’apprentissage.
Même avec une équipe d’environ cinq personnes, les débuts sont certes difficiles, mais une fois qu’on atteint un certain niveau de maîtrise de k8s, il est impossible de revenir en arrière. Le gain de productivité qui en découle est incomparable.
Le CI/CD, le GitOps, les déploiements canary, etc., peuvent se faire sans k8s, mais les mettre en place sur k8s est plus simple à comprendre et plus facile à administrer.
Pour avoir moi-même vécu cette transition, dire que c’est encore prématuré
me rappelle un peu l’époque de l’on-premise, quand on hésitait à adopter AWS cloud simplement parce que cela paraissait peu familier.
« Concentrez-vous sur le business » : ce n’est pas à ce niveau très général que se situe la discussion ; j’ai surtout du mal à approuver une décision qui vous enferme dans une technologie particulière.
Si l’article avait été un plaidoyer pour utiliser activement des PaaS comme beanstalk/app engine/heroku, j’aurais été tout à fait d’accord, mais aujourd’hui les avantages qu’une petite équipe peut tirer du choix d’ECS/cloud run/docker swarm sont presque inexistants. Peut-être que ça aurait été différent il y a 4 ou 5 ans.
En termes de coûts, le serverless est de loin plus avantageux.
Je suis d’accord aussi. Dans la plupart des cas,
docker-swarmoudocker-composesont largement suffisants, et même plus que suffisants.C’est aussi un avis qui revient très souvent dans les commentaires sur Hacker News..... [1]
Je trouve l’article un peu déroutant, parce qu’il part du principe que « Kubernetes est difficile ».
Ces derniers temps, l’écosystème Kubernetes a beaucoup mûri, donc à moins d’installer directement Kubernetes on-premise, ce n’est pas quelque chose d’aussi difficile.
De plus, avec l’exploitation de Kubernetes, on peut dans une certaine mesure choisir soi-même le niveau de complexité, et mettre en place une configuration de base n’est pas si compliqué. Bien sûr, dès qu’on commence à y ajouter toutes sortes d’add-ons plus tard, cela devient plus difficile.
Il y a aussi de plus en plus de personnes comme moi qui ont découvert les environnements de déploiement en commençant directement par EKS.
Pour le dire très clairement, je ne comprends pas en quoi mettre en place un Deployment k8s de base et un Ingress (avec, bien sûr, la base de données sur un service managé séparé) serait particulièrement plus difficile que configurer directement l’AWS ECS Fargate dont parle cet article.
Dans les deux cas, il faut de toute façon configurer un VPC, un cluster, un CDN et un load balancer... Il y a même beaucoup de commentaires qui disent au contraire qu’ECS était plus inconfortable à utiliser.
[1] https://news.ycombinator.com/item?id=31795160
Je suis d’accord. Je ne pense pas que la configuration de base soit si difficile, ni que la maintenance soit particulièrement complexe. Dans le cloud, qu’on transfère une configuration complexe telle quelle ou qu’on la remplace par une configuration YAML Kubernetes, je ne peux pas vraiment dire ce qu’il y a de mieux.
Dans notre entreprise, comme nous avons dépassé les 100 développeurs, nous avons ressenti le besoin de passer de ECS à EKS, mais il nous arrive de le regretter un peu.
Vous dites que « pour l’exploitation de Kubernetes, on peut en quelque sorte choisir soi-même le niveau de complexité », mais quand on ne connaît pas bien le sujet, on a tendance à penser que tout ce dont on parle dans l’écosystème Kubernetes est forcément nécessaire, et à tout ajouter.
Vous dites aussi qu’il faut de toute façon configurer un load balancer, mais je pense qu’il y a une différence entre devoir seulement connaître l’ALB et devoir comprendre à la fois l’ALB et l’Ingress.
Comme on n’a pas besoin de MSA à petite échelle, Kubernetes demande plus de connaissances qu’on ne l’imagine, donc je pense qu’à une échelle où il faut se concentrer sur l’application, c’est bien un surdimensionnement.
Cela dit, si quelqu’un a déjà très bien mis en place l’environnement Kubernetes, déployer des applications dessus m’a semblé avoir moins d’effet de lock-in, puisque c’est défini dans une expression plus indépendante du cloud.
À vous entendre, il semble clair qu’il y a effectivement ce genre d’aspects à prendre en compte. J’ai sans doute considéré comme trop évidentes les choses que j’ai apprises en utilisant Kubernetes.
Et je reconnais aussi qu’avec le très grand nombre d’add-ons qui sortent en ce moment autour de Kubernetes, il est difficile de faire des choix.
Comme je n’ai pas d’expérience de migration du type ECS -> EKS... je me demande s’il y a eu des améliorations après la transition, en dehors d’un éventuel effet de lock-in.
Ah, pour info, mon expérience se base sur EKS. C’est très différent d’installer soi-même k8s on-prem et d’exploiter directement etcd et le Control Plane, haha.
Du point de vue de quelqu’un qui a commencé directement avec k8s, en lisant l’article je me suis plutôt dit à l’inverse : est-ce vraiment nécessaire de prendre le temps d’étudier ECS... ?
Quoi qu’il en soit, je pense qu’il n’est pas forcément nécessaire de l’imposer officiellement comme ça ; au départ, le mieux n’est-il pas simplement d’utiliser la méthode que l’équipe trouve la plus confortable ?
Je suis d'accord avec l'idée de départ sur k8s.
Je suis tout à fait d’accord.
Je suis également plutôt opposé à l’adoption de k8s, non seulement dans des équipes de 10 personnes, mais aussi dans des entreprises d’une taille raisonnable.
À mon avis, cela n’a vraiment de sens que lorsque la dépendance à un fournisseur cloud devient critique, ou lorsqu’on en arrive à un niveau où des infrastructures comme l’on-prem sont utilisées en parallèle.
J’ai toujours pensé qu’on avait tendance à suivre par inertie les stacks techniques des entreprises de niveau enterprise.
Justement, comme un texte qui le résume bien est apparu sur Hacker News, je le partage.