- Figma a déplacé ses services cœur déjà conteneurisés d’ECS vers Kubernetes basé sur EKS, avec pour objectif une migration sans interruption afin de réduire les limites de long terme de sa plateforme
- Sur ECS, l’absence de StatefulSets, la difficulté à exploiter des solutions open source basées sur des Helm charts et les contraintes d’isolation des nœuds posaient de gros problèmes ; Kubernetes ouvrait l’accès à l’écosystème CNCF et à des options comme Keda, Karpenter et Istio
- La migration a été cadrée de façon étroite : conserver les abstractions d’exécution, de déploiement et d’outillage des services, et ne remplacer que l’orchestration ; les définitions de services basées sur Bazel et la configuration de 3 clusters EKS faisaient partie du périmètre initial
- Pendant la transition, Figma a assuré la possibilité de rollback grâce aux tests de charge, à une bascule progressive du trafic via du DNS pondéré, à la migration précoce de vrais services, au masquage du YAML brut et à la collaboration avec les propriétaires de services
- En janvier 2024, la plupart des services les plus prioritaires avaient migré vers EKS ; après avoir réduit les coûts de surprovisionnement, amélioré la fiabilité et l’expérience développeur, Figma poursuit les travaux sur le logging, l’autoscaling et la transition vers Graviton
Pourquoi passer d’ECS à Kubernetes
- Début 2023, Figma exécutait déjà tous ses services sous forme de conteneurs et utilisait AWS Elastic Container Service (ECS) comme plateforme d’orchestration
- En évaluant sa plateforme de calcul de nouvelle génération, l’équipe a estimé que continuer à construire par-dessus ECS rendrait difficile, à long terme, la création des fonctionnalités souhaitées
- Figma n’étant pas une entreprise exploitant des milliers de microservices, le périmètre d’une migration vers Kubernetes restait réalistement maîtrisable
- De nouveaux services peuvent être nécessaires pour des raisons d’isolation ou de performance, mais les services cœur fournissent déjà une modularisation de base et une isolation du trafic
- Même les nouveaux produits sont souvent pris en charge en ajoutant de la logique dans les services cœur existants plutôt qu’en créant de nouveaux services
Les fonctionnalités qui manquaient dans ECS
- ECS ne prend pas en charge les StatefulSets de Kubernetes, ce qui compliquait l’exploitation de stockages de données de consensus à forte cohérence comme etcd
- Figma contournait ce problème avec du code personnalisé qui mettait dynamiquement à jour l’appartenance au cluster au démarrage des conteneurs etcd
- Cette approche était fragile et difficile à maintenir ; avec Kubernetes, l’usage des affectations réseau avec état des StatefulSets est courant
- Sur ECS, il était difficile d’exécuter des ensembles de services définis avec des Helm charts
- Avec ECS on EC2, arrêter proprement une machine EC2 individuelle problématique était également fastidieux
- Sur EKS, lorsqu’un mauvais nœud est marqué comme cordon, le serveur d’API respecte la procédure d’arrêt et peut déplacer les Pods vers d’autres machines
L’écosystème CNCF et le choix de plateforme
- Continuer avec ECS aurait rendu plus difficile l’exploitation des technologies open source de l’écosystème Cloud Native Computing Foundation (CNCF)
- L’autoscaling était un sujet important pour la plateforme de calcul de nouvelle génération
- À l’époque, Figma n’appliquait pas l’autoscaling à ses services conteneurisés
- Les services étaient provisionnés pour absorber les pics de charge même pendant les périodes de faible trafic, comme les nuits et les week-ends, ce qui entraînait des coûts inutiles
- Dans l’écosystème Kubernetes, Keda permet de scaler non seulement sur l’utilisation CPU, mais aussi sur la longueur des files AWS SQS et sur des métriques personnalisées Datadog
- Un service mesh pourrait aussi devenir nécessaire à long terme
- Le trafic entre services existants était routé via des AWS Application Load Balancers (ALB) et Network Load Balancers (NLB)
- Les NLB prennent plusieurs minutes pour enregistrer de nouvelles cibles et retirer les anciennes, ce qui ralentit les déploiements d’urgence et augmente le temps moyen de résolution des incidents
- Envoy offre davantage de personnalisation et la possibilité d’exécuter des filtres personnalisés
- Figma disposait déjà, devant ses principaux services, d’un cluster indépendant de machines Envoy faisant office de proxy, et avait déjà utilisé des filtres personnalisés pour réduire la charge pendant des incidents
- Sur EKS, il existe de nombreuses options open source comme Istio ; sur ECS, il aurait fallu reconstruire soi-même des fonctionnalités similaires
Les avantages opérationnels d’une plateforme populaire
- Figma cherche à éviter d’être le plus grand utilisateur d’un service ou d’un logiciel
- Les plus grands utilisateurs sont souvent les premiers à rencontrer les aspérités et les limites de passage à l’échelle
- Kubernetes étant utilisé par de nombreuses grandes entreprises pour d’immenses plateformes de calcul, Figma en est un utilisateur beaucoup plus petit
- Kubernetes aide à réduire le verrouillage fournisseur
- EKS apporte les avantages d’un control plane pris en charge par le fournisseur
- Les services étant écrits pour s’exécuter sur un Kubernetes standard, le coût d’un déplacement vers une autre plateforme Kubernetes prise en charge par un fournisseur, ou vers une plateforme auto-hébergée, n’est pas très élevé
- Il est plus facile de recruter des ingénieurs ayant de l’expérience Kubernetes
- Les ingénieurs ayant déjà cette expérience peuvent monter rapidement en compétence et apporter du contexte sur des domaines susceptibles d’être nouveaux pour Figma
Principes de cadrage de la migration
- Dans une grande migration, il est plus sûr de ne remplacer que le système cœur que l’on souhaite changer, tout en conservant autant que possible les abstractions visibles par les utilisateurs de la plateforme
- Figma a donc réduit le périmètre à l’exécution sur EKS plutôt que sur ECS, sans changer la façon d’exécuter les services, de les déployer ni les outils d’interaction entre services
- Même des travaux qui ne semblent pas être des changements fonctionnels peuvent produire des effets de second ordre, ce qui peut facilement faire gonfler le calendrier d’une migration à grande échelle
- Il y avait deux exceptions
- Lorsque faire en sorte que le nouveau système se comporte comme l’ancien demandait trop de travail supplémentaire, il pouvait être préférable d’accepter les effets de second ordre et d’adopter la nouvelle approche
- Les décisions de type one-way door, difficiles ou coûteuses à modifier plus tard, pouvaient être prises dès le départ selon la nouvelle approche
Améliorations incluses dans le périmètre
-
Expérience développeur
- Les définitions de services ECS existantes étaient principalement créées et modifiées avec Terraform
- L’application de Terraform créait un modèle d’ECS task set avec 0 instance ; ensuite, lors du déploiement, ce modèle était dupliqué, le hash d’image remplacé, puis un task set avec un nombre d’instances non nul était déployé sur ECS
- Même pour ajouter une seule variable d’environnement, il fallait écrire et appliquer du Terraform puis lancer le déploiement ; si l’ordre n’était pas respecté, le code ne pouvait pas utiliser la variable d’environnement en toute sécurité, ce qui provoquait des bugs
- Sur EKS, Figma a déplacé les définitions de services au même endroit et fait en sorte que les changements soient déployés en une seule étape
- Figma a créé une approche interne simple définissant les services via des fichiers de configuration Bazel, et générant automatiquement le YAML de définition de service ainsi que des YAML de configuration comme les Ingress
- Le YAML est généré par les outils de CI lors des commits de code, puis appliqué via le système de déploiement interne
-
Fiabilité
- Pour chaque service, 3 clusters EKS ont été configurés afin d’exécuter les Pods et de recevoir le trafic
- Lorsque toutes les opérations ont lieu au niveau du cluster, l’impact d’une panne complète peut être réduit à un tiers du service
- Pour les services pouvant réessayer les requêtes ou traiter de façon asynchrone, l’interruption côté utilisateur est souvent minimale
- Cette configuration a fortement accru la complexité opérationnelle, notamment dans les pipelines de déploiement, mais l’équipe a estimé qu’il valait mieux l’appliquer dès la migration plutôt que de l’ajouter plus tard
-
Efficacité des coûts
- Peu de travaux complexes d’optimisation des coûts ont été inclus dans le périmètre de la migration, mais l’autoscaling des nœuds a été pris en charge dès le départ
- Les services ECS on EC2 surprovisionnaient des machines pour absorber les pics pendant les déploiements
- Sur EKS, Karpenter est utilisé pour augmenter et réduire dynamiquement le nombre de nœuds selon la demande
Travaux exclus du périmètre
- Le pipeline de logging existant était complexe
- Tous les logs étaient d’abord écrits dans CloudWatch
- Une Lambda lisait les logs et effectuait des transformations comme la suppression de certains motifs et l’ajout de tags
- Les logs étaient ensuite écrits dans Datadog et Snowflake
- Le coût de CloudWatch, utilisé comme stockage intermédiaire, augmentait fortement
- Figma prévoyait d’adopter Vector, un projet CNCF capable de traiter et de transmettre les logs sous forme de sidecar dans la stack EKS
- Mais l’équipe a estimé que porter la logique du forwarder de logs vers une configuration Vector ne valait pas les effets de second ordre, et l’a exclu du périmètre de migration
- L’autoscaling au niveau des Pods n’a pas non plus été inclus dans la migration
- La complexité était jugée trop élevée
- L’équipe considérait que ce travail pourrait facilement être ajouté plus tard
- Ces travaux exclus sont ensuite devenus des chantiers de suivi, permettant d’apporter des améliorations en parallèle de la migration d’autres services vers EKS
Une méthode d’exécution sûre
- Comme la stack ECS existante était relativement stable, la nouvelle stack EKS et le processus de migration devaient être au moins aussi fiables
-
Tests de charge
- Figma a créé un service “Hello, World” et l’a fait scaler jusqu’à exécuter le même nombre de Pods que le plus grand service de Figma
- Ce test a révélé qu’il fallait ajuster la taille et le passage à l’échelle des services de calcul cœur soutenant toute la plateforme
- Kyverno est un outil de validation de sécurité des clusters ; s’il n’est pas dimensionné suffisamment grand, il peut ralentir le démarrage de nouveaux Pods
-
Déploiement progressif
- Des enregistrements DNS pondérés ont été utilisés pour déplacer petit à petit le trafic des services ECS existants vers leurs équivalents EKS
- Un contrôle fin du transfert de trafic et du retour arrière était essentiel à une migration sûre
- Les effets inattendus pouvant apparaître à des points d’inflexion inconnus, il fallait réduire le périmètre d’impact et pouvoir revenir rapidement en arrière
-
Exécuter tôt de vrais services
- Mettre de vraies charges de travail sur le système permet d’apprendre beaucoup de choses que le staging seul ne révèle pas
- Figma a migré un service avant même d’avoir terminé la mise en place de l’environnement de staging
- Cette migration précoce a aidé à valider de bout en bout la capacité à exécuter les charges de travail, et à trouver des goulots d’étranglement et des bugs
-
Abstraction du YAML
- Demander aux utilisateurs de définir eux-mêmes leurs services en YAML Kubernetes brut pouvait être source de confusion
- Figma a fourni aux utilisateurs un golden path, avec possibilité de personnalisation seulement dans les cas particuliers
- En clarifiant ce que les utilisateurs peuvent et doivent personnaliser, tout en imposant une cohérence par défaut, cette approche simplifie la maintenance et les changements futurs
-
Collaboration avec les propriétaires de services et allocation des équipes
- La nouvelle configuration des services était prise en charge par l’équipe plateforme, tandis que la mise à jour du monitoring et des alertes se faisait en étroite collaboration avec les propriétaires de services, qui connaissent le mieux leur état
- Avant même le début de la migration, les options et compromis ont été largement discutés avec les propriétaires de services
- Une migration de grande ampleur peut faire apparaître des problèmes inattendus, des interactions complexes et des bugs ordinaires ; elle nécessite donc une équipe disposant d’une expertise technique approfondie et de solides capacités de debugging
Calendrier réel de la migration et résultats
- Au 1er trimestre 2023, Figma a établi le plan et obtenu l’accord pour lancer la migration
- Au 2e trimestre 2023, l’équipe a créé l’environnement de staging et migré un service unique
- Au 3e trimestre 2023, elle s’est concentrée sur la mise en production, les tests de charge et la préparation de la migration d’autres services
- Du 4e trimestre 2023 à la première semaine de janvier 2024, le trafic des services a été basculé lentement
- En janvier 2024, la plupart des services les plus prioritaires avaient été migrés vers les nouveaux clusters EKS
- Le monolithe contenant la logique métier cœur
- Un service complexe qui gère l’aspect multijoueur de l’édition de fichiers Figma
- Les services composant Livegraph 100x, qui poussent des mises à jour en temps réel vers tous les clients
- Au final, Figma a réduit les coûts de surprovisionnement pour les déploiements, amélioré la fiabilité grâce à l’exécution sur 3 clusters et amélioré l’ergonomie pour les développeurs
- L’ensemble du chantier s’est déroulé avec de petits incidents et un faible impact client
- Un incident s’est produit lorsqu’un opérateur a supprimé et recréé par erreur CoreDNS dans l’un des clusters de production
- Avec l’ancienne configuration, la situation aurait entraîné une panne complète
- Avec la configuration à 3 clusters, l’impact a été limité à un tiers des requêtes
- La plupart des services en aval ont réessayé les requêtes, qui ont fini par réussir
Améliorations des outils après le lancement
- Figma a créé des outils pour permettre aux propriétaires de services de déboguer ce qui se passe dans les clusters
- Vérifier le nombre d’instances en cours d’exécution
- Ouvrir un shell dans un conteneur
- Effectuer des opérations comme un scaling d’urgence
- Juste après le lancement, l’équipe a reçu des retours indiquant que ces outils d’accès n’étaient pas assez conviviaux
- La complexité venait de deux facteurs
- L’introduction de 3 clusters obligeait les utilisateurs à exécuter des commandes sur plusieurs clusters et à ajouter le nom du cluster à chaque commande
- En utilisant les rôles Kubernetes RBAC pour fournir des permissions plus fines, les utilisateurs devaient comprendre quels rôles ils possédaient et quels rôles étaient nécessaires pour une action donnée
- Figma a immédiatement interrompu les autres travaux pour modifier les outils afin qu’ils déduisent automatiquement le cluster et le rôle appropriés
- Les utilisateurs n’ont ainsi plus à perdre du temps à chercher un rôle, en particulier lors d’urgences au milieu de la nuit
Prochaines étapes
- Figma continue de migrer les services restants tout en améliorant en parallèle la nouvelle plateforme de calcul
- Les axes actuels sont les suivants
- Simplifier la conception du pipeline de logging
- Prendre en charge l’autoscaling horizontal des Pods via Keda
- Migrer vers les processeurs Graviton les services les plus coûteux de Figma afin de réduire les coûts, et préparer un chemin permettant à d’autres services de s’exécuter aussi sur Graviton
- L’équipe prévoit également d’explorer des domaines dans lesquels elle n’a pas encore beaucoup investi
- Étudier une offre de service mesh afin d’améliorer la fiabilité et l’observabilité de la stack réseau
- Gérer davantage de ressources avec AWS Controllers for Kubernetes (ACKs) afin de réduire la dépendance à Terraform et de simplifier et unifier la stack
- Collaborer avec l’équipe expérience développeur pour unifier la façon dont les services s’exécutent dans l’environnement de développement et dans les autres environnements
1 commentaires
Avis de Hacker News
Personnellement, j’aime Kubernetes. Je gère plusieurs petites boutiques e-commerce sur mesure mais complexes, tout en m’occupant aussi du marketing, des finances et du support client.
Avant, tout tournait sur des serveurs dédiés, mais la stack était assez complexe, les déploiements étaient un cauchemar, et au final la charge liée aux déploiements ralentissait la petite entreprise.
Il m’a fallu un mois pour apprendre Kubernetes et migrer, et nous exploitons environ 25 services : frontend, gestionnaire de produits, tableau de bord logistique, optimisation des itinéraires de livraison, OSRM, ERP, moteur de recommandation, recherche, etc.
En centralisant la configuration du cluster, nous avons pu l’organiser dans une structure reproductible, et savoir précisément l’état de chaque service ainsi que la version en cours d’exécution. Les déploiements rolling sans interruption sont aussi devenus possibles et, même si c’est complexe, les programmeurs traitent par nature des choses complexes. Les fichiers de configuration Nginx sont complexes eux aussi.
Plus on creuse, plus on comprend pourquoi l’architecture de Kubernetes a du sens, et elle force à respecter strictement le 12-factor. Si vos revenus sont directement liés à la disponibilité et à la stabilité de votre stack, la haute disponibilité est plus qu’un simple « plus ». Les coûts d’hébergement tournent aussi autour de 400 dollars par mois, donc ce n’est pas si cher.
J’ai plutôt confiance en Kubernetes, mais c’est vraiment complexe. C’est un outil qui résout des problèmes difficiles. Si vous êtes en multi-cloud, il n’y a pas à hésiter, et si vous voulez une infrastructure complexe qui corresponde en 1:1 au local, c’est adapté.
Mais si vous avez moins de 100 développeurs et que vous ne déployez que des conteneurs sur AWS, utiliser EKS plutôt que ECS + Fargate en 2024 relève, à mon avis, de la folie.
La migration elle-même, pour améliorer les fondations de l’infra, est une bonne chose. En revanche, j’ai été surpris que l’une des motivations soit de faire utiliser aux équipes des charts Helm plutôt que de les convertir en Terraform.
En pratique, j’ai rarement vu des charts Helm quelconques utilisés de manière stable sans modification, et encourager leur usage finit par pousser les équipes à forker et modifier les charts. Helm est un outil tellement horrible que je n’ai pas envie de maintenir mes propres charts Helm personnalisés.
Je pense qu’il est plutôt plus simple de les réécrire en Terraform pour maintenir une version locale. Je serais curieux d’entendre des contre-exemples. Peut-être qu’aujourd’hui la folie du
indent 4de Helm et les problèmes de templates de chaînes à plusieurs niveaux ont disparu.On peut gérer des workloads Kubernetes avec Terraform, mais je ne le recommande pas. Kubernetes a déjà son propre état ; si Terraform a lui aussi un état, la combinaison Terraform + Kubernetes devient pénible. Helm est fait pour Kubernetes, Terraform ne l’est pas.
Cela ne veut pas dire que j’aime Helm. Le YAML templatisé n’est pas terrible, et la folie du
indent 4existe toujours. Kustomize est bien quand c’est simple, mais quand l’application devient complexe, je le trouve pire que Helm. Par exemple, pour déployer une application avec Ingress, certificats TLS et external-dns sur plusieurs environnements, au lieu d’utiliser une variable à trois endroits, il faut patcher trois ressources.Helm comme Terraform sont très populaires, donc on en parle beaucoup, mais je pense qu’au final un outil qui les remplacera tous les deux, pas encore largement adopté, finira par émerger.
Le problème de Terraform, c’est qu’il faut concevoir les workspaces de façon à ne pas dépasser le nombre recommandé de ressources par workspace, environ 100 à 200. Sinon, le plan devient très lent parce qu’il vérifie aussi des bases de données ou des réseaux auxquels vous n’avez pas touché et que vous n’avez pas l’intention de toucher, ce qui allonge les temps de déploiement.
En pratique, on finit par créer une grille de workspaces Terraform qui se déclenchent les uns les autres, et il n’existe actuellement pas de bon outil open source qui prenne correctement cela en charge.
À l’heure actuelle, la meilleure approche me semble être que Terraform installe, dans le cadre de l’infrastructure, un outil de déploiement continu comme ArgoCD, puis que les déploiements quotidiens soient pris en charge par l’outil de CD. Et la plupart des outils de CD demandent de packager les déploiements avec quelque chose comme Helm.
Mais il y a tellement de pièges que je passe du temps à refaire et déboguer le travail d’autres ingénieurs.
J’espère qu’un nouvel outil appelé
timoniva prendre de l’élan. Il résout presque tous les griefs que j’ai contre Helm. Si vous cherchez une meilleure solution, timoni mérite d’être regardé.Nous avons choisi de conserver les charts Helm publics tels quels, et de gérer les personnalisations avec
kustomize —enable-helm.Dans notre cas, nous avons un chart Helm de base pour une application/un service unique, avec des valeurs par défaut raisonnables, et tous les déploiements l’étendent. Côté utilisateur, les valeurs Helm à configurer sont minimales, et nous avons rarement eu besoin d’ajouter nos propres templates, car le chart de base expose suffisamment de points de réglage.
Nous avons pu déployer tels quels un bon nombre de charts tiers, et avons parfois ajouté les fonctionnalités nécessaires upstream via des PR. Il nous est arrivé rarement de devoir les wrapper ou les forker, mais les charts tiers déployés tels quels sont bien plus nombreux.
Pour maintenir des charts personnalisés, helm unittest (https://github.com/helm-unittest/helm-unittest) aide beaucoup à éviter les régressions.
Même si nous gérons quelques ressources Kubernetes avec Terraform, y compris ArgoCD, en général, déployer des charts Helm via ArgoCD s’est avéré bien plus facile à gérer et plus productif.
Je suis surpris qu’il y ait autant de sentiment anti-Kubernetes sur HN. Je me demande si c’est parce que la plupart des commentateurs sont des développeurs habitués à des services comme Heroku, fly.io ou render.com, ou bien parce qu’ils font tourner leurs applis sur des VM.
Ce n’est pas un problème propre à un cas particulier, mais plutôt le résultat d’incitations très mal alignées dans l’ensemble du secteur, et en partie de la ruée vers l’or de l’ère des taux bas.
Franchement, dans son état actuel, cela ressemblerait dans d’autres domaines à un artisan assez inutile. Une obsession malsaine pour les outils et le méta-travail, tout en continuant à jeter par la fenêtre une utilisation raisonnable des ressources pour pouvoir utiliser tel ou tel outil. C’est une sorte de situation d’« ingénieur FAANG temporairement dans l’embarras ».
Il est difficile d’expliquer combien de temps en plus il faut, combien d’expertise supplémentaire c’est nécessaire, à quel point cela rend les choses plus fragiles et combien cela coûte en plus de construire sur Kubernetes plutôt que d’utiliser les modèles de déploiement disponibles sur AWS, comme les images VM sur EC2, Elastic Beanstalk, ECS/Fargate ou Lambda.
Je n’ai pas envie d’installer et de maintenir moi-même une stack ELK ou Prometheus. Je n’ai pas non plus envie de me battre avec des plugins CNI, Kafka, Postgres en haute disponibilité, Argo, Helm et les mises à niveau du control plane. Avec les services équivalents d’AWS, on peut démarrer presque immédiatement, la maintenance est quasi nulle et les coûts partent généralement d’un point proche de zéro puis augmentent linéairement.
On peut résoudre les problèmes métier beaucoup plus vite et plus efficacement. C’est la différence entre une situation où l’on peut largement dépasser les attentes et une autre où toute l’équipe prend plusieurs trimestres de retard.
Cela dit, s’il y a de vrais besoins de multi-cloud ou d’on-premise, je ne voudrais rien utiliser d’autre que Kubernetes. Dans une grande entreprise avec beaucoup d’ingénieurs expérimentés qui comprennent Kubernetes, ce n’est peut-être pas si mauvais. En tout cas, les endroits où j’ai travaillé n’étaient pas comme ça.
C’est une bonne chose de voir les entreprises migrer principalement vers de l’infrastructure open source. Une bonne partie vient de la CNCF (https://landscape.cncf.io), de l’ASF et de nombreux projets sur GitHub.
kata-containers pourrait peut-être lever cette inquiétude et me faire apprécier Kubernetes.
Globalement, il n’y a rien dans Kubernetes qui me paraisse personnellement cool. Les conteneurs, les load balancers, les mégaoctets de YAML, j’ai déjà vu tout ça, et ça ne me semble pas assez intéressant pour avoir envie d’essayer.
À cette échelle d’entreprise, c’est peut-être normal, mais j’ai du mal à suivre la logique de décision derrière d’aussi grosses migrations ou projets techniques. Les décisions ne semblent pas venir des besoins des utilisateurs ou de l’entreprise.
J’avais eu la même impression avec un article similaire de Figma sur les bases de données.
Par exemple, si la raison de vouloir passer à Kubernetes est qu’on ne peut pas utiliser etcd/Helm avec ECS, il faut d’abord se demander pourquoi on veut utiliser etcd/Helm. Est-ce vraiment si important ? La manière d’atteindre les objectifs de l’entreprise passe-t-elle vraiment exactement par là ?
Quand une décision est fondée sur les besoins des utilisateurs, il est facile de vérifier si les décisions de niveau inférieur sont pertinentes. Mais quand elle est fondée sur des envies techniques, les décisions de niveau inférieur peuvent sembler plausibles dans le contexte de ces envies techniques tout en restant incertaines dans le contexte utilisateur.
Soit je ne comprends pas les organisations de cette taille, soit il est fondamentalement difficile, pour des organisations de cette taille, d’identifier ce qui a de la valeur et de raisonner à ce sujet.
Nous sommes essentiellement une équipe plateforme, et nous créons souvent des outils pour d’autres équipes plateforme qui créent elles-mêmes des outils destinés à soutenir les développeurs Figma qui construisent l’expérience produit réelle. Plus on s’éloigne de l’utilisateur final, plus il devient difficile de raisonner sur les bonnes décisions, mais en même temps, l’effet de levier devient important.
Si l’on construit bien la plateforme, ses effets touchent la capacité de tous les autres ingénieurs à travailler efficacement et utilement. Une grande partie de ces effets est indirecte.
Il y avait clairement aussi l’option consistant à dire que, puisque nous ne pouvions pas prendre en charge etcd et Helm, il fallait trouver d’autres contournements. Mais ces deux éléments étaient des points de données supplémentaires qui nous ont poussés à conclure que nous faisions tourner notre plateforme Compute sur de mauvais blocs de base.
Même si le raisonnement est difficile, cela vaut largement la peine d’essayer de bien le faire. En tant qu’équipe plateforme, c’est ainsi que nous vérifions que nous faisons les bonnes choses pour arriver à la meilleure plateforme possible. C’est pourquoi nous avons passé beaucoup de temps à prendre cette décision, et j’ai pensé que c’était un sujet intéressant à raconter par écrit.
Une bonne partie des migrations Kubernetes dans les grandes entreprises est probablement motivée par le désir de multi-cloud ou d’hybride on-premise, ainsi que par la réduction des risques de coût, de disponibilité et de lock-in.
Il faut harmoniser les mises à niveau des VM, l’authentification, les sauvegardes, la rotation des logs, etc.
Avec Kubernetes, on donne à chacun un namespace, des policies, des volumes, et grâce aux DaemonSets et à la stack Kubernetes/cloud native, l’agrégation automatique des logs devient aussi possible.
Il y a aussi l’auto-réparation, et il est difficile d’expliquer à quel point ça améliore les choses.
Par exemple, il existe peu de stockages de données hautement disponibles et cohérents qu’on puisse utiliser comme l’équivalent d’un fichier
.piddans un environnement distribué. Ce qui me vient à l’esprit, c’est Zookeeper, mais c’est vraiment pénible à exploiter, ça exige de vieilles versions de la JVM et, malgré tout, l’ensemble reste instable.Lorsque le code Terraform est appliqué, il crée un task set ECS avec 0 instance pour lancer un modèle de service, puis, quand un développeur déploie un service, il doit cloner ce task set modèle et effectuer plusieurs opérations manuelles : cette partie ressemble moins à un problème d’ECS qu’à une méthode de gestion des déploiements Terraform + ECS rendue excessivement complexe
Je comprends l’idée de créer un modèle pour valider avant le déploiement réel. Mais là, c’est un peu ambigu
C’est pourquoi j’ai volontairement classé ce point comme un travail que nous avons décidé d’inclure dans le processus de migration, et non comme l’une des raisons fondamentales qui nous ont poussés à lancer la migration
Cela dit, j’imagine quelques scénarios où cette approche devient nécessaire. Par exemple, si beaucoup de services sont déployés sur ECS et que la taille de l’état Terraform augmente. Dans ce cas, plan et apply deviennent nettement plus lents, et il peut être beaucoup plus sûr de sharder l’état Terraform en dupliquant la configuration telle quelle à partir de modèles
Il suffisait grosso modo d’ajouter les variables d’environnement au fichier Terraform, de merger, puis de laisser la CI déployer. La plupart de nos changements de configuration passaient par ce processus
« Migrer vers Kubernetes peut prendre des années » : je me demande bien ce que je suis en train de lire
Pour qui est-ce le cas ? Je ne comprends pas vraiment non plus pourquoi les entreprises s’imposent ce genre de migration. Où est la valeur business, et quel bénéfice pour les clients ? Est-ce un projet « l’art pour l’art », parce que Figma peut se le permettre ?
Dans une entreprise très établie, vieille d’environ 30 ans et avec tout le bagage que cela implique, nous avons migré vers Kubernetes en beaucoup moins de temps. Cela dit, nous n’avons pas essayé de tout mettre sur Kubernetes : seulement ce qui pouvait en tirer bénéfice
Notre proposition ressemblait à ceci : si vous migrez vers Kubernetes, lors du déménagement de datacenter prévu en fin d’année, vous n’aurez rien à faire à part vérifier que tout va bien. Sinon, il faudra redéployer l’application sur de nouvelles machines ou VM et gérer tous les problèmes que cela entraîne. Si ce n’est pas déjà conteneurisé, conteneurisez maintenant et nous nous occuperons du reste
La majorité a migré et a été très satisfaite du résultat. En revanche, pour les services sensibles à la latence ou relevant du calcul haute performance, il n’y avait aucune raison de les forcer à migrer, et nous n’avons pas essayé de les faire rentrer au chausse-pied
Combien de temps faudra-t-il pour en sortir ?
Si l’application est déjà découpée en microservices, revenir en arrière n’est pas simple non plus
Quand je lis un billet de blog qui mentionne nonchalamment six projets CNCF aux noms cool que je n’avais jamais entendus, apparemment pour obtenir une fonctionnalité simple, j’ai l’impression d’être dépassé
Je me demande sérieusement s’il est temps pour moi de vieillir hors du développement logiciel professionnel
Cela signifie simplement que tu n’es pas habitué à une certaine approche de la montée à l’échelle des organisations, où une équipe plateforme abstrait le matériel, les logs, les tentatives de reprise, etc.
Ce n’est pas la seule approche ; tu peux donc être plus familier avec d’autres manières de faire
J’aime cet article parce qu’il explique clairement et de façon structurée les bénéfices et les raisons de passer à Kubernetes
Beaucoup d’équipes se lancent sans savoir ce qu’elles vont y gagner, ni même si elles en ont besoin au départ ; les raisons présentées ici me semblent solides
D’autres commentaires ont déjà soulevé ce point : https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
Par pure curiosité, quels autres systèmes ou services modernes une personne sensée pourrait-elle se vanter d’avoir migrés en un an ?
Un système comme Kubernetes est généralement au cœur de l’infrastructure, donc il affecte tout ce qui tourne. Ajoutez à cela les contraintes d’équipe mentionnées dans l’article, et un an ne paraît pas si mauvais
L’exemple qui me vient immédiatement à l’esprit est l’époque où Amazon est complètement passé d’Oracle à des bases de données relationnelles Amazon/open source. Mais il me semble que cela avait pris plusieurs années. S’ils l’avaient fait en moins d’un an, ils s’en seraient certainement vantés
C’est souvent davantage une question de dette technique, de complexité d’intégration et de personnes mobilisées que de technologie elle-même