Quand les développeurs passent DevOps

La mouvance DevOps a pris tellement d’ampleur que c’est rare de tomber sur une boite qui n’y adhère pas. On m’a jeté dans ce parc-aventure sans que je m’en rende compte. Mais le DevOps, c’est quoi au juste ? Et pourquoi tout le monde en parle autant ?

DevOps, c’est pas un métier OK!?

C’est la réponse que tu auras DIRECT si tu poses la question “tu es devops ?” à n’importe qui dans la mouvance DevOps. Ha oui attention, ça rigole zéro, ils prennent cette affaire très au sérieux. Beaucoup d’entre eux ont cliqué sur cet article juste pour venir commenter que DevOps c’est pas un métier. DevOps c’est pas un métier et ils vont te le rappeler toutes les 30 secondes. C’est d’autant plus drôle que presque tout le monde fait un abus de langage et se définit comme DevOps par facilité. Et parce que les recruteurs recherchent le metier DevOps aussi. On des mauvaises personnes. Mais bon, quelque part, on s’en carre le cul. 

Mais si DevOps c’est pas un métier, c’est quoi alors ? Pour vraiment comprendre de quoi je te parle, il faut déjà que tu saches d’où ça vient. On est en juin 2009 et une présentation traitant de coopération entre développeurs et sysadmins en Californie fait beaucoup de bruit. Elle fait du bruit car elle montre la réalité de deux mondes qui se pointent du doigt en permanence.

Les sysadmins hurlent aux développeurs que si c’est codé avec le cul, le serveur pourra pas faire fonctionner l’appli. Les développeurs hurlent aux sysadmins que si le serveur est en mousse, c’est sûr que l’appli va pas fonctionner.

Au même moment, en Belgique, Patrick Debois regarde cette conférence via les Internets. Il kiffe tout ce qu’il peut kiffer. Il est inspiré par tout ça et à force de se faire chauffer par plein de monde sur ces réseaux, il décide de créer une conférence. Les fameuses DevOpsDays étaient nées. Par la même occasion, le terme DevOps devenait la norme.

C’est quoi le DevOps ?

Le DevOps est une mouvance, un mindset, qui a pour objectif de rendre facile et transparent le travail entre les différentes équipes du cycle de production et de déploiement d’un produit. On va faire VRAIMENT coopérer différents métiers pour mettre en place des outils d’automatisation. Et ça, du développement à la livraison, en passant par les tests et le monitoring. À tel point qu’on arrive à des déploiements en production réguliers et seamless. Finies les guéguerres entre les équipes, tout le monde embarque dans la même aventure.

Pour arriver à ça, les équipes de développeurs et de sysadmins ne sont plus isolées, elles travaillent ensemble, elles sont même parfois fusionnées. Elles ont toutes un seul objectif commun : que les cycles de production et de déploiement du produit soient optimisés au maximum. Voilà une vidéo parfaite de deux minutes qui montre l’avant et l’après DevOps. Cette vraiment une bonne analogie de ce qu’on veut du DevOps.

C’est pas magique cette affaire, il faut former et faire pratiquer tout le monde. Les conditions de ces formations ne sont pas toutes les mêmes. Et la mienne a été un peu spéciale.

Je suis un dev

Il y a bien longtemps dans une galaxie lointaine, très lointaine, je ne faisais que du code. Et c’était cool, j’avais aucun problème avec ça. On avait une équipe de SysAdmins dédiée qu’on insultait, et qui nous insultait. C’était parfait. Dans mon équipe on faisait toute la partie dev, on foutait tout ça dans un docker et DÉMERDEZ-VOUS avec vos serveurs à la con !

Et un beau jour, cette équipe a décidé qu’elle ne voulait plus gérer nos merdes. Beaucoup de boulot leur est tombé dessus. Trop de boulot. Du boulot plus urgent. Plus intéressant que gérer nos affaires. Le problème c’est que sans eux, on avait pas de solution pour nos déploiements. Et non seulement ils allaient se barrer, mais en plus ils allaient le faire vite.

Puis la nouvelle est tombée : on passe en mode DevOps ! On allait devoir gérer toute l’infra nous-mêmes avec l’accompagnement des SysAdmins. Pire, on allait complètement la transformer avec des nouveaux outils d’automatisation à toutes les étapes. On aller tout gérer en mode 360. C’était un changement radical ! Je me rappelle, j’étais tranquille entrain de bouffer du NodeJS au moment ou on m’a dit ça. Et l’idée d’être responsable de toute l’infrastructure du jour au lendemain m’a terrifié.

À ce moment-là, j’avais aucune idée de la quantité d’information qu’on allait me faire bouffer pour être opérationnel. J’avais surtout aucune idée du temps et de l’argent que ça allait prendre pour transformer mon équipe.

J’ai dépensé sans compter

Avant de continuer, je suis obligé de te préciser des trucs importants. Même si je le fais penser jusqu’ici, DevOps c’est pas deux métiers en un. C’est même pas un métier comme je te disais au début. On le savait pas encore, mais on allait se faire former sur des outils comme Terraform, Kubernetes et plein d’autres. Ces outils aident les développeurs et les SysAdmins à travailler ensemble pour le déploiement d’un produit. Ils brouillent la limite entre les deux métiers. Mais ça s’arrête là. J’ai pas les connaissances pour faire le boulot d’un vrai SysAdmin.

Ensuite une transformation DevOps, c’est un investissement de ouf pour une boite. Les entreprises qui font ça ont un plan moyen / long terme juste là-dessus. Le temps nécessaire est long, les formations coûteuses. Une étude faite sur 200 entreprises ayant fait un virage DevOps aux États-Unis rapporte des chiffres intéressants. La majorité d’entre elles ont dépensées entre 100K et 500K USD sur une année de transformation. C’est de la thune en masse.

Et en effet, un an, c’est très proche du temps que ça a pris à mon équipe pour faire le virage. Et quand je dis faire le virage, je veux dire devenir totalement opérationnel. Avant d’arriver à ce résultat, c’était vraiment été les montagnes russes en termes d’expérience.

La belle aventure

Au début, c’était vraiment cool. On apprenait plein de nouveaux concepts tous les jours. On nous laissait jouer avec juste pour apprendre. C’est le paradis pour un dev. Tout était nouveau et on avait pour le moment aucun enjeu. On avait juste à expérimenter et décider ce qu’on voulait utiliser. De la R&D le bordel !

D’abord, on a réappris Docker. Finies les images docker à l’arrache, on a vraiment appris à faire de belles images respectables. Après on est parti sur docker swarm pour nous familiariser avec un premier orchestrateur de container. Ensuite on a commencé à nous parler de CI/CD, reverse proxy, load balancer, infra-as-code, cloud computing et de plein d’autres concepts. Concepts qu’on connaissait de loin, mais qu’on n’avait jamais approchés d’aussi près. Mes collègues et moi on était comme des gamins dans un parc aventure. 

Et puis on a décidé. Notre futur s’appellera Kubernetes. C’était une bonne décision. Mais le problème, c’était pas la technologie. Le problème c’était que le DevOps, ce n’est pas qu’utiliser des outils et de l’automatisation. On allait vite découvrir cette réalité.

Vous n’avez pas dit le mot magique

Le problème c’est qu’on utilisait des outils dits DevOps dans notre coin. On bossait comme avant en fait. Comme un dev dans son coin. Gros casque sur la tête, musique à fond, à essayer d’automatiser un cluster à la con avec toute l’automatisation qui va bien. Évidemment, aucune collaboration ou discussion avec l’équipe de SysAdmins qui était pourtant dispo. Et ça, c’est pas DevOps. On se tapait de plus en plus de problèmes et d’erreurs de l’enfer, mais rien ne changeait la situation.

La première fois qu’on m’a jeté devant Kubernetes dans ce contexte, j’ai pleuré du sang. Je bouffais la doc, puis du YAML, puis la doc et y’a rien qui semblait fonctionner. Fallait vite faire fonctionner ma partie de l’architecture dans mon coin. D’autant plus que l’ambiance générale commençait à se tendre.

Le temps commençait à jouer contre nous. La direction nous a posé une deadline sur la table. Ça chauffait sévère. Fini le temps des papillons et de la découverte. Une folle course contre la montre était lancée. Et les délais étaient vraiment agressifs.

Ça c’est DevOps

Brutalement, les choses ont changé. Des meetings de collaboration ont été forcés dans les agendas de tout le monde. Des workshops de groupe avec l’équipe sysadmins ont été organisés. On a commencé à passer des journées entières de pair programming avec eux.

On apprenait ce qu’eux faisaient et surtout pourquoi ils le faisaient de cette façon. Du coup on leur expliquait les plans impossibles qu’on essayait de mettre en place. Des solutions simples sont immédiatement apparues sur la table.

En quelques heures de collaboration, on allait plus vite que plusieurs jours de galère entre nous. Et c’est ça le DevOps, la rencontre de plusieurs compétences pour un but commun. C’est juste qu’on n’avait pas encore adopté ce mindset. Et sans cette transformation de notre façon de travailler, on pouvait pas faire une vraie transformation.

Et je me répète, mais c’est important, même avec les outils d’automatisations maîtrisés pour nos déploiements, l’accompagnement des sysadmins est toujours fondamentale. Il y a une vision et un recul sur les problématiques d’administration systèmes que les développeurs n’ont pas. Difficile d’automatiser quelque chose qu’on ne comprends pas parfaitement. La collaboration entre équipe permet justement de n’avoir aucun trou dans la compréhension avant d’automatiser. Et même avec tout ça, c’est pas suffisant.

Fail fast, iterate faster

Régler les problèmes d’architecture et de communication, c’était que le début. Une des idées principales du mouvement DevOps c’est l’itération rapide sur son produit. Concrètement au lieu de faire tout immédiatement, on fait une petite partie, on vérifie que ça marche bien, et on itère dessus rapidement. C’est exactement ce qu’on a fait avec notre infra. Et les résultats étaient spectaculaires.

Je me souviens très bien de la première fois qu’on a fait tourner notre produit sur Google Cloud. On le voyait scaler sous le poids de nos tests de charges. On avait un contrôl total sur la production, le déploiement, le monitoring et l’évolution de notre produit. C’était fou. On avait plus de doute sur ce qui se passait, c’était devenu la maison.

Je ne pense plus mon code sans son futur déploiement. Quand j’écris du code, je dois savoir dans quel contexte il va être utilisé. Car même s’il finit par être conteneurisé et exposé sur un port, il y’a toujours moyen de l’optimiser pour son utilisation finale.

Depuis ce jour, je suis officiellement entré dans la secte des adorateurs DevOps. Et c’est autant pour tout ce que j’ai appris que pour la manière de travailler. À tel point que j’ai vraiment du mal à voir les mauvais côtés.

Le revers de la médaille

Ce virage, je l’ai fait y’a pas si longtemps que ça. J’ai pas assez de recul avec tout ça pour exposer les vrais défauts de cette mouvance. Du coup, je me suis dit que j’allais demander à quelqu’un qui est là depuis plus longtemps.

Et aujourd’hui petite surprise ! Je me suis carrément incrusté dans la vidéo de mon invité. Ouais, le connard qui parle de bash au début de la vidéo, c’est moi (c’est une blague les sysadmins, faut pas s’énerver) !

Salut Cocadmin ! D’après toi, c’est quoi les inconvénients à bosser avec le mindset DevOps ?

Cocadmin

Cocadmin est un « devops » avec une chaîne YouTube et même un compte Twitter. Si tu veux en savoir plus sur le DevOps et les outils DevOps en général, son contenu est une mine d’or ! En plus on rigole, je conseille très fortement. Merci Cocadmin d’avoir répondu à ma question dans cette super vidéo !

Quoiqu’il en soit le DevOps c’est pas nouveau. Ça fait plus de dix ans que ça existe. Du coup, il faut qu’on se pose la question du futur du mouvement.

DevOps : présent et futur

Ça fait plus de 10 ans que la mouvance DevOps a commencé à se propager de partout. Après autant de temps, ça serait un peu logique que ça se calme, comme un effet de mode qui retombe. Bah non, pas du tout. 2020 marquerait même le début d’une nouvelle ère DevOps. Comme un bon vin, le mouvement DevOps a mûri et s’est bonifié avec le temps. Et tout le monde semble bien confortable dans cette façon de travailler.

Le mindset DevOps a réussi à détruire le travail en silo, en partie responsable de l’enfer dans ton projet. Aujourd’hui, on est dans une phase d’optimisation. Dans le futur, le nombre et surtout la qualité des outils continueront d’augmenter en même temps que l’efficacité des équipes à les utiliser. Ça veut dire une seule chose : la réduction du time-to-market. Ou, autrement dit, mettre le produit dans les mains du client toujours plus rapidement. Et ça, ça donne beaucoup de plaisir aux entreprises.

Et y’a pas que les entreprises qui prennent du plaisir. Les premiers concernés sont en pleine lune de miel aussi. Le fait d’avoir le contrôle et la compréhension sur toutes les étapes de vie de son travail est super satisfaisant.

Je pourrais plus revenir en arrière. En arrière pour bosser dans une boîte qui refuse une organisation DevOps ? Non. Je suis beaucoup trop fier de moi quand je déploie en prod quand bon me semble, avec un simple commit.

Épilogue

Bref, le DevOps c’est pas simple au début, mais très vite ça devient la vie. C’était mon histoire personnelle avec cette mouvance. Si tu en veux plus sur le sujet, je te conseille fortement ce bouquin que j’ai adoré. Et si tu es dans une entreprise qui n’est toujours pas convertie, je te conseille d’en faire le prêche. C’est vraiment un mindset qui va faire évoluer, d’une part ton entreprise, mais surtout toi et ta vision de l’IT en général.