- La startup de la Silicon Valley Xenobroom Inc. décide en mai 2020 de migrer son infrastructure serveur existante vers Kubernetes après une forte hausse de l’usage quotidien pendant la pandémie
- La migration dépasse la simple amélioration du déploiement et devient un chantier de longue haleine consistant à réexaminer et reconcevoir les scripts bash et l’architecture basée sur des VPS
- La portée continue de s’élargir avec les mises à niveau des dépendances et bibliothèques, la conversion d’une partie de PostgreSQL en stockage KV distribué, et l’exploitation de la flexibilité d’AWS
- L’ancien serveur de staging et les déploiements quotidiens basés sur la branche develop sont remplacés par un workflow de CI production-only, du routage dynamique, des tests A/B et la prise en charge des dépendances régionales
- Au moment où la migration semble terminée, plus personne dans l’entreprise ne se souvient de la finalité du produit, et les utilisateurs comme les investisseurs admettent qu’ils n’avaient jamais vraiment compris le produit d’origine, rendant toute restauration pratiquement impossible
Un périmètre de travail gonflé par la migration Kubernetes
- Xenobroom Inc. lance en mai 2020 une mise à niveau de son infrastructure serveur
- Selon des extraits du journal du CEO et les notes d’ingénierie du CTO, l’usage quotidien augmente brutalement pendant la pandémie
- L’entreprise décide ensuite de migrer son infrastructure existante vers Kubernetes
- Le chantier s’avère plus long que prévu
- Il faut recréer, réévaluer et réingénierer de simples scripts bash et des machines VPS
- En interne, on estime que c’est aussi l’occasion de mettre à niveau les dépendances logicielles et les bibliothèques
- Le changement d’infrastructure débouche sur une refonte structurelle plus vaste
- L’entreprise juge possible de remplacer une grande partie de la base de données PostgreSQL, qui tournait sur une seule machine, par un stockage KV distribué
- L’argument avancé est aussi de tirer parti de la flexibilité d’AWS
- Le simple serveur de staging avec déploiement quotidien depuis la branche develop disparaît
- À sa place arrive un workflow de CI production-only avec routage dynamique, conçu pour prendre en charge de manière fluide les tests A/B et les dépendances régionales
Perte de l’objectif du produit et aide extérieure
- Quand la procédure de migration semble achevée, plus personne dans l’entreprise ne se souvient de la finalité du produit
- Les utilisateurs et les investisseurs ne parviennent pas non plus à résoudre la situation
- Les deux groupes admettent publiquement n’avoir en réalité jamais bien compris le produit au départ
- Après plusieurs semaines d’interruption, restaurer le sens du produit devient pratiquement impossible
- Le CEO demande l’aide de Phutar Afrayughum, présenté comme médium et spécialiste de la perception extrasensorielle
- Il est décrit comme quelqu’un ayant aidé Google à accroître sa part de marché dans les applications de messagerie et ayant participé au développement du framework Material Design
- Cette aide reste toutefois présentée comme « allegedly », sans pouvoir être affirmée comme un fait
1 commentaires
Avis sur Hacker News
Cet article est encore plus drôle : après avoir licencié 20 % des cadres intermédiaires, la productivité des développeurs a accidentellement triplé
https://www.theolognion.com/p/company-accidentally-increased...
À mon $dayjob, on est aussi en train de faire ce genre de migration : elle a commencé il y a deux ans, mais on n’en est même pas à 30 %
Les gens qui criaient le plus fort autrefois qu’« il faut passer à Kubernetes, il faut tuer le monolithe » ont maintenant oublié Kubernetes parce qu’ils bricolent avec des LLM
Certaines personnes adorent vraiment les preuves de concept et les nouveautés qui brillent, et ce rôle a sans doute aussi son utilité
C’est pour ça que des gens intelligents semblent travailler avec pas mal de satisfaction dans de grandes entreprises tech peu éthiques, des sociétés de publicité ou de surveillance
La raison d’être de l’entreprise, ou ce qu’elle fait réellement en dehors de leur ordinateur, n’a pas beaucoup d’importance ; ce qui compte, c’est la technologie et la liberté de poursuivre la nouveauté
L’entreprise aime la productivité et l’enthousiasme que ces personnes produisent, et les paie bien
En général, ces développeurs ont aussi une conscience, mais cette conscience est souvent absorbée et mise en vitrine sous la forme d’un militantisme social bienveillant compatible avec l’entreprise
Quelqu’un coche des cases une par une pour pouvoir dire « j’ai fait X »
Dans une petite équipe, cette approche peut très vite bloquer la productivité, et elle est souvent emballée comme une envie de résoudre tous les problèmes
Mais au final, aucun problème n’est résolu ; au contraire, on en crée beaucoup de nouveaux
Une promotion nécessite un dossier de promotion, et un dossier de promotion nécessite un gros projet bien lourd
Au bout du compte, le problème central à résoudre n’est plus un besoin business mais la promotion, et l’on voit apparaître d’énormes projets à la recherche d’un problème
Ce qui est décrit ne ressemble même pas à une preuve de concept. La condition de base d’une preuve de concept, c’est d’abord que ça fonctionne ; là, on est plutôt dans la fabrication d’une configuration pour suivre le troupeau et avoir l’air occupé
Du point de vue des employés non plus, ça ne semble pas être un environnement où il fait bon rester longtemps
Il y a plein d’autres articles encore plus drôles sur ce blog. J’ai particulièrement aimé celui-ci :
https://www.theolognion.com/p/dev-builds-perfect-note-taking...
Et il y a aussi celui-là :
https://www.theolognion.com/p/ai-solves-all-political-econom...
Ça évitera deux clics aux autres
Je sais que c’est une blague, mais si on faisait une analyse post-mortem, la cause de l’échec serait probablement : « beaucoup de gens dans l’entreprise ont pensé qu’il fallait profiter de l’occasion pour aussi mettre à niveau les dépendances logicielles et les bibliothèques. Ils ont aussi estimé qu’une grande partie de la base PostgreSQL qui tournait sur une seule machine pouvait être remplacée par un magasin clé-valeur distribué pour tirer parti de l’immense flexibilité d’AWS »
Il faut tenir le périmètre
Il y a beaucoup de gens dans le monde qui se concentrent davantage sur les technologies qu’ils utilisent que sur le produit qu’ils fabriquent
Se concentrer sur le produit, c’est connaître le périmètre et ne pas surconcevoir trop tôt
La blague se concentre sur Kubernetes, mais on pourrait faire exactement la même avec le rendu côté serveur, l’IA, $modernFrontendLib ou $modernLanguage
Si votre activité n’est pas de vendre de l’infrastructure cloud, utilisez un fournisseur cloud prêt à l’emploi
Et si vous payez déjà un fournisseur cloud, mieux vaut surtout ne pas utiliser Kubernetes
Dans la vraie vie, une migration Kubernetes de 11 semaines aurait été considérée comme un énorme succès
Bien sûr, l’exploitation de la base de données aurait été un peu pénible. Comme ils auraient oublié de configurer correctement le stockage Kubernetes, les données auraient disparu après le déplacement soudain d’un pod
Si vous n’utilisiez même pas Docker, alors dans une migration similaire, le problème n’est probablement pas Kubernetes lui-même
Il n’a jamais été aussi facile ni aussi peu coûteux d’exploiter des systèmes qu’aujourd’hui
Mais les ingénieurs préfèrent monter une expédition pour livrer une pizza, gravir l’Everest, prendre une photo de la pizza au sommet, la ramener ensuite en avion, louer une Lamborghini pour faire le Mongol Rally, puis seulement 18 mois plus tard livrer cette pizza
Pendant ce temps, il suffit de prendre un scooter bon marché et de descendre la rue pour gagner
Si c’est une technologie complexe, il faut d’abord l’apprendre. Il faut l’essayer d’abord sur de petits services peu importants
Faire une seule chose à la fois, et commencer simplement
J’ai migré nos services vers Kubernetes sans problème, mais il m’a fallu 2 ans pour apprendre et expérimenter en déplaçant de petits services
Après avoir essayé plusieurs approches, je suis arrivé à celle qui convenait le mieux, et ce n’était pas une méthode qu’on trouve directement sur Internet
On utilise GitOps, mais sans automatisation : on lance simplement
kubectl apply -kpour ce dont on a besoin. À l’époque, j’avais jugé que flux était inutilement complexe pour démarrerMaintenant qu’on a des dizaines de services et une meilleure compréhension, j’envisage d’adopter flux
En 1977, je travaillais comme jeune avocat plaidant dans un cabinet qui facturait à l’heure.
Pour chaque dossier, on notait sur papier le travail effectué, et le personnel administratif découpait des bandes détachables sur les feuilles terminées pour les coller sur le carton à l’intérieur du dossier papier de chaque affaire.
En 1979, j’ai acheté un RadioShack Tandy I, et je me suis vite plongé chez moi dans Foxbase, un programme de base de données sous DOS. Il est ensuite devenu FoxPro, puis Microsoft l’a racheté au début des années 1990.
En 1981, j’ai ouvert mon propre cabinet ; à l’époque, les dernières innovations en productivité bureautique étaient le fax et les machines à écrire électriques dotées d’un écran d’une ligne, de mémoire et de petits disques pour stocker des formulaires. Les entreprises n’utilisaient pas encore d’ordinateurs personnels.
Mon cabinet a rapidement atteint une dizaine d’avocats et douze personnes en support, et j’ai acheté des ordinateurs Compaq pour toutes les secrétaires.
J’ai passé beaucoup de temps à écrire un programme de suivi du temps et de facturation pour remplacer le collage manuel de bandes, et j’ai aussi appris à installer un réseau, que j’ai mis en place moi-même.
Les autres cabinets que je connaissais n’avaient pas le moindre ordinateur, mais nous en avions plus de dix pour le personnel de support, ainsi que quatre ou cinq Compaq « portables » pour les avocats, afin qu’ils relisent les factures avant de les envoyer aux clients.
Dans le même temps, j’étais en train de ruiner mon activité. À une époque où les autres n’avaient pas un seul ordinateur, nous disposions d’une technologie de tout premier plan, mais au lieu de me concentrer sur le travail d’avocat ou le développement de clients entreprises, je m’enfermais pour programmer.
J’ai fini par fermer le cabinet en 1994.
Cela reste une période enthousiasmante. Bientôt, tous les cabinets se sont équipés d’ordinateurs pour le traitement de texte, mais il n’existait pas encore de logiciel de facturation commercial.
Pendant environ 24 mois, tous les avocats d’autres cabinets avec lesquels j’ai travaillé ont voulu mon programme de facturation.
Mais même débordé par les dossiers, je ne me consacrais qu’à ce qui m’amusait, la programmation, et mon activité juridique était le laboratoire parfait pour le programme. Malheureusement, cette programmation a ruiné mon entreprise.
S’il en reste des photos, j’aimerais beaucoup les voir.
Dans mon domaine, on peut remplacer « Kubernetes » par GraphQL/React/Next et ça reste exactement vrai.
Tout ça, bien sûr, pour migrer une application qui fonctionne parfaitement bien, et qui est en plus essentiellement du CRUD.
On le fait alors même qu’on n’a aucun besoin des compromis apportés par GraphQL ou par un frontend interactif.
Plus je passe de temps dans ce secteur, plus je constate que les personnes en position de responsabilité ne savent souvent pas ce qu’elles font.
Ils sont récompensés pour le changement, du moment qu’on peut au moins faire semblant que ce changement produit des résultats, ou en produira un jour.
Cela fait quatre mois que je me bats jour et nuit pour migrer 500 000 blobs depuis un MinIO auto-hébergé vers un stockage de blobs managé, et le travail réellement productif — hors politique et bureaucratie — représente moins d’une semaine.
Du coup, une migration Kubernetes en 11 semaines me paraît être un énorme succès.