Après 11 semaines de migration vers Kubernetes, l’entreprise oublie pourquoi elle existe (2020)

Après 11 semaines de migration vers Kubernetes, l’entreprise oublie pourquoi elle existe

• La jeune startup de la Silicon Valley Xenobroom Inc. a lancé en mai 2020 un processus de mise à niveau de son infrastructure serveur.

• Face à une forte hausse de l’usage quotidien dans un contexte de pandémie mondiale, elle a décidé de migrer son infrastructure existante vers Kubernetes.

• Repenser et redéfinir de simples scripts Bash et des machines VPS a pris plus de temps que prévu.

• L’entreprise y a vu une bonne occasion de mettre à niveau ses dépendances logicielles et ses bibliothèques.

• Une grande partie de la base de données PostgreSQL, qui fonctionnait sur une seule machine, a été transformée en stockage KV distribué en tirant parti de la flexibilité d’AWS.

• Le serveur de staging habituel, qui effectuait des déploiements quotidiens depuis la branche develop, a été remplacé par un workflow réservé à la production, compatible avec la CI.

• Une fois la migration terminée, plus personne dans l’entreprise ne se souvenait de l’objectif du produit.

• Ni les utilisateurs ni les investisseurs ne comprenaient le produit d’origine, et après plusieurs semaines d’indisponibilité, il était pratiquement impossible d’en restaurer le sens.

• Le CEO a sollicité l’aide de l’expert médiumnique Phutar Afrayughum, connu pour avoir contribué à l’augmentation de la part de marché des applications de messagerie de Google.

L’avis de GN⁺

• Cet article traite de manière satirique de l’impact qu’un processus de migration vers Kubernetes peut avoir sur une entreprise. Dans la réalité aussi, une migration technique peut profondément transformer le fonctionnement d’une organisation et lui faire parfois perdre de vue son objectif initial.
• Lorsqu’on envisage une migration technique, il faut une compréhension claire non seulement des aspects techniques, mais aussi de la vision et des objectifs de l’organisation. Cela souligne le principe selon lequel la technologie doit soutenir la raison d’être de l’organisation.
• Kubernetes est une plateforme d’orchestration de conteneurs privilégiée par de nombreuses entreprises, mais son adoption exige une préparation suffisante et une expertise adéquate. Sinon, la complexité et la charge opérationnelle peuvent augmenter.
• Cet article rappelle que l’adoption d’une technologie n’apporte pas toujours uniquement des résultats positifs. Il avertit que la technologie peut parfois brouiller les valeurs et les objectifs essentiels d’une organisation.
• Parmi les autres plateformes offrant des fonctionnalités similaires à Kubernetes figurent Docker Swarm et Apache Mesos, qui peuvent constituer des alternatives selon le contexte.

[GN⁺]

Avis sur Hacker News

• Productivité de développement multipliée par 3 après le licenciement de 20 % des cadres intermédiaires

  Il existe un cas où une entreprise a accidentellement triplé sa productivité de développement en licenciant 20 % de ses managers intermédiaires.

• Partage d’expérience sur une migration vers Kubernetes

  Il est souligné que la migration vers Kubernetes actuellement en cours dure depuis deux ans sans être achevée à 30 %, et que ceux qui poussaient fortement Kubernetes au départ s’intéressent maintenant aux LLMs. Cela suggère qu’il existe des personnes attirées par les nouveautés brillantes, et que ce type de rôle peut en soi avoir une certaine utilité.

• Les articles amusants du blog Theolognion

  Le blog Theolognion contient plusieurs billets amusants, en particulier celui sur « le développeur qui a conçu le système parfait de consolidation de notes » et celui où « une IA ayant analysé les commentaires de Hacker News résout tous les problèmes politiques, économiques et médicaux ».

• Une plaisanterie sur la cause de l’échec

  Dans le post-mortem analysant les causes de l’échec, on suppose que l’entreprise y a vu une bonne occasion de mettre à niveau ses dépendances logicielles et ses bibliothèques, et qu’elle aurait pu convertir une grande partie d’une base de données PostgreSQL tournant sur une seule machine en stockage KV distribué afin de profiter de la flexibilité d’AWS.

• Un véritable cas de succès d’une migration vers Kubernetes en 11 semaines

  En réalité, réussir une migration vers Kubernetes en 11 semaines serait déjà considéré comme un grand succès.

• Conseils pour migrer des services vers Kubernetes

  Il faut d’abord apprendre la technologie complexe, puis essayer sur de petits services non critiques. Il faut faire une chose à la fois et commencer simplement. L’auteur n’a pas eu de problème pour migrer des services vers Kubernetes, mais cela est le résultat de deux ans d’apprentissage et d’essais, ainsi que de multiples approches testées avant de trouver la plus adaptée, introuvable telle quelle sur Internet. L’auteur utilise gitops sans automatisation et applique ce qui est nécessaire avec kubectl apply -k. Maintenant qu’il gère des dizaines de services et dispose d’une compréhension suffisante, il envisage d’adopter flux.

• La facilité et le faible coût de l’exploitation des systèmes

  Exploiter des systèmes n’a jamais été aussi simple ni aussi peu coûteux, mais les ingénieurs ont souvent tendance à choisir des méthodes complexes et inefficaces pour accomplir des tâches simples.

• Les problèmes du secteur liés aux choix technologiques

  À propos de la migration d’applications parfaitement fonctionnelles vers des technologies comme GraphQL/React/Next, quelqu’un qui travaille dans le secteur depuis longtemps dit avoir l’impression que beaucoup de gens ne savent pas vraiment ce qu’ils font.

• Expérience d’une migration vers du stockage cloud

  Quelqu’un raconte s’être battu jour et nuit pendant quatre mois pour déplacer 500 000 blobs depuis un MinIO auto-hébergé vers un stockage de blobs managé, alors que le travail réellement productif, sans lien avec la politique ou la bureaucratie, a représenté moins d’une semaine. Dans ce contexte, une migration vers Kubernetes en 11 semaines semble être un grand succès.

• Témoignage sur l’introduction de l’informatique dans un cabinet d’avocats dans les années 1970

  La personne raconte qu’en 1977, alors jeune avocat facturant à l’heure, elle a ensuite acheté en 1979 un ordinateur Tandy I et utilisé des programmes de base de données comme Foxbase. En 1981, elle a ouvert son propre cabinet et, à l’époque, les fax et les machines à écrire électriques représentaient la technologie de pointe pour améliorer la productivité du bureau, mais les ordinateurs personnels n’étaient pas utilisés. L’auteur a acheté des ordinateurs Compaq pour toutes les secrétaires, a consacré beaucoup de temps à écrire un programme de suivi du temps et de facturation pour remplacer le système manuel, et a aussi installé un réseau. Mais à force de se concentrer sur cette technologie, il a négligé son travail d’avocat et l’entretien des relations avec les clients professionnels, et a finalement fermé son cabinet en 1994. À l’époque, tous les cabinets utilisaient des ordinateurs pour le traitement de texte, mais il n’existait pas de programme commercial de facturation. D’autres avocats voulaient utiliser son programme, mais il raconte avoir ruiné son activité en se concentrant sur le plaisir de programmer.