Salut les amis ! J’espère que vous avez passé de bonnes fêtes et que le Père Noël du Cloud vous a filé des crédits !

Un article un peu moins tech que les autres, j’ai envie de parler d’une méthode de travail que je nomme l’éclatops.

Je vais énerver certains, peut-être que je vais recevoir des lettres de menace, mais bon, c’est le jeu.

Alors de quoi on parle exactement ? De DevOps éclaté au sol ? On fait n’importe quoi ? On migre sans stratégie ? Cryptoanarchie ? Les femmes et les enfants d’abord ?

Pas tout à fait. Ce que j’essaie de vous amener, c’est que de manière temporaire, contrôlée et réfléchie, on peut relaxer nos pratiques et réduire nos standards dans le but de faire des itérations rapides. L’idée étant de commencer à dégager de la valeur et de la stabilité et progressivement améliorer les standards.

Dégrader ses standards pour s’adapter à l’organisation, pour ensuite pousser l’organisation à augmenter ses standards

Vous arrivez dans une organisation qui construit des machines en dur avec des gens qui tapent des commandes à la main ? Vous voulez passer en organisation full cloud avec de l’infra as code et du Kubernetes ?

Ne donnez pas une torche plasma à un singe qui a peur du feu !

Ok, allons-y ! Payons des prestas expérimentés pour faire ça, la migration est faite à un coût exorbitant, mettons que ça fonctionne.

Il n’y a plus de budgets pour former les équipes, plus personne ne contrôle la prod, on a besoin d’évolution et les prestas s’en vont. Qu’est-ce qui se passe du coup ?

Bah c’est la merde. Les équipes internes ont été mises de côté, sont démotivées et probablement s’en iront sans accompagnement et sans considération.

Je vous propose une autre solution, avancer plus lentement mais en intégrant les équipes et en faisant des étapes itératives, sur le code, sur l’infra, sur l’organisation.

Itérer en mode dégradé pour évacuer les actions chronophages

Le code qui bouge est déployé en compute à la main ? C’est pénible et ça ne marche pas tout le temps ? Une première étape serait de faire un script qui automatise les étapes manuelle.

On galère, on ne sait pas trop automatiser ? On prend un peu de temps pour se faire accompagner pour apprendre à faire du Ansible, voire co-construire avec quelqu’un d’expérimenté.

On sait déployer en staging toujours de la même façon avec Ansible ? Pourquoi ne pas mettre ça en CI/CD pour permettre aux développeurs d’être autonomes en staging ? Qu’est-ce qui manque pour faire la même chose en prod ?

En itérant, sans changements trop brutaux et en accompagnant les équipes, on a quelques personnes qui sont investies dans les déploiements et la bonne réussite des mises en prod.

On peut maintenant penser à faire un basculement tech vers du conteneur.

Est-ce que mon application est éligible pour faire un conteneur Docker ? Je regarde ce qui pourrait manquer en recoupant avec mon développeur. Je balance un Docker Compose, le développeur sait builder et tester sur sa machine, pourquoi ne ferai-je pas un Compose pour livrer mon staging aussi ? Ah, tiens, on s’organise et les développeurs veulent faire des microservices, on adapte le code de nos containers et on continue à progresser.

On veut faire du Kubernetes, mais c’est peut-être un peu trop compliqué et overkill pour nos besoins ? Pourquoi ne pas rentrer dans du Cloud Run pour commencer et voir si le nombre de microservices commence à augmenter drastiquement au point de ne plus pouvoir le gérer ? Après, on peut bouger vers du Kubernetes, pourquoi pas ?

On s’est planté, on veut revenir en arrière ? Baby step en arrière, baby step en avant, réduction des risques et prise en compte de la montée en compétences des équipes.

Entre temps, on a enforcé un standard dans la livraison des applications et on peut songer à renforcer des aspects de sécurité et d’optimisation.

Si l’infra et la tech s’adaptent au changement, votre organisation doit revoir et adapter ses contraintes pour autoriser cette prise de risque et permettre aux équipes de pouvoir expérimenter, se tromper et revenir en arrière.

Cramer de l’argent pour faire un setup parfait qui n’arrive jamais vs rendre de la valeur avec un produit imparfait ?

Je comprends l’argument parfaitement valable que migrer salement entraîne un coût important et une dette technique qu’il faudra forcément payer ensuite.

Cependant, le facteur argent est déterminant dans l’effort que vous devez mettre dans vos applications et processus.

Inutile de mettre une somme folle dans une cathédrale si vous la construisez sur une île de 10 habitants.

Ne mettez pas un temps fou et des sommes folles pour produire une application qui vous coûte plus que ce qu’elle vous rapporte.

N’essayez pas de résoudre les problèmes de demain aujourd’hui en produisant une infrastructure complexe et hyperscalable si vous avez 3 développeurs qui se battent en duel sur votre application.

Partez modeste et pragmatique en étant intransigeant sur les décisions structurantes dès le départ et en autorisant de la souplesse et des changements d’infrastructure qui s’adaptent à vos contraintes actuelles.

Construire modestement, ce n’est pas autoriser le provisionnement de ressources en mode far west et les failles de sécurité grossières. Il faut adapter les ambitions et les technologies en fonction des objectifs et des contraintes humaines et financières.

Organisation full auto rigide versus human failure tolérant ?

Pourquoi creuser dans une montagne de granit quand on peut faire une route qui la contourne ?

Parfois l’effort d’automatisation ne vaut pas forcément le coup pour des produits non prévus pour, et la rigidité de l’automatisation est un frein aux opérations et à l’innovation.

Cramer deux semaines de setup pour automatiser un truc qui n’a jamais été prévu pour, qui ne bougera peut-être plus jamais, c’est probablement une erreur économique.

À partir du moment où on peut garantir l’intégrité des données avec un backup automatisé et repartir sur un snapshot de disque en quelques minutes,

ne gaspillez pas des ressources pour un idéal d’automatisation qui n’a pas de sens.

Il est ok de parfois faire des actions manuelles d’urgence et des opérations rapides, à condition ensuite de maîtriser les risques et de répercuter les changements avec intelligence dans le code de l’infrastructure as code.

Ne vous battez pas contre Terraform, mais ajustez vos processus humains pour permettre des actions d’urgence et faire de la remédiation ensuite.

Taguez vos ressources faites avec Terraform, tagguez les ressources touchées à la main et répercutez les changements manuels dans le code.

Mes recommandations pour migrer vers un système et une organisation un peu plus automatisés

Lister les parties les plus susceptibles de changer rapidement. Lister les parties les moins fiables ou les plus fragiles. Lister les parties complexes à déplacer, les technologies legacy ou problématiques. Vous livrez du code régulièrement ? Le rythme est trop soutenu pour être tenable ? Mettez de l’effort pour automatiser ces livraisons.

Vous avez une application avec des problèmes récurrents, ou vous avez besoin d’un shift technologique inexistant dans votre organisation ?

Migrer vers le cloud en replatformant votre infrastructure pour tirer parti de ces services cloud.

Est-ce que votre machine legacy sculptée à la main dans un bloc de granit va bénéficier d’un boost de performance si on la met dans un compute GCE ? Probablement pas, et l’investissement de la migration ne sera probablement pas amorti par cette opération. Gardez-la au chaud chez vous et faites de l’hybride. Bougez-la seulement si ça coûte moins cher que de changer de produit. Tuez-la si elle n’est pas tellement indispensable.

Si vous voyez des piles d’équipements devant ou derrière vos applications, challengez l’idée d’en dégager quelques-unes !

Peut-être que les 3 reverses proxy devant votre application avaient du sens à un moment, mais peut-être aussi que vous pouvez rassembler leurs fonctions dans un seul proxy et vous réduirez la latence de chaques requêtes et sûrement la complexité de gestion de votre application.

Le mot de la fin

On revient à une de mes plus grandes obsessions : seul le service rendu et la disponibilité du service comptent. La rigidité peut apporter de la rigueur et de la structure, mais elle peut aussi aliéner et ralentir les opérations et l’innovation. Beaucoup de souplesse apporte de la liberté, mais elle permet aussi plus de déviance et de désorganisation.

Le niveau de flexibilité et d’automatisation joue sur la capacité à livrer plus vite et mieux, mais si l’organisation n’est pas mature dans son industrialisation et dans sa conduite du changement, vous balancez des coups d’épée dans l’eau.