Pour en finir avec le grand n’importe quoi qu’est devenu le DevOps

Ndr : Vous l’aurez compris, nous sommes de très fervents défenseurs du mouvement DevOps. Ce billet contiendra donc, de temps à autre, quelques petites doses de sel. Rien de grave, mais vous êtes prévenus.    

Depuis notre création en 2005, nous avons eu l’occasion d’assister à l’ascension et à la déchéance du mouvement DevOps. Sa mise en œuvre donnait (et donne toujours) lieu à des dynamiques positives en matière de gestion et de livraison de projets informatiques. Mais entre un marketing ou des consultants qui ont usé le terme jusqu’à la moelle, et des développeurs qui revendiquent injustement cette compétence sans réelles connaissances en infrastructures, le DevOps est devenu un grand n’importe quoi. Une surexploitation du terme qui a inévitablement abouti à la création d’une insupportable novlangue consistant à rassembler le plus de contractions possibles pour former des mots tiroirs et fourre-tout sans substance (nous nous risquons même à prédire un avenir similaire à l’Intelligence Artificielle, au Big Data et à la Blockchain). Mais qu’est-ce qui a bien pu se passer ? 

L’agilité, jusqu’au bout des infrastructures

Petit point historique rapide, car ce n’est pas le sujet. Créé en 2007 et popularisé en 2009 avec les premiers Devopsdays, on attribue la paternité du terme DevOps à Patrick Debois. Le concept a notamment émergé avec la popularisation de la méthode Agile. Cette dernière avait permis de s’écarter des cycles de développement en “V” pour adapter le travail des développeurs aux nouvelles exigences du web et accélérer le time to market. 

La méthode a eu beau faire des miracles pour les cycles de développement, les mises en production restaient quant à elles, toujours très laborieuses. C’est précisément pour ne pas ruiner ces avancées effectuées côté développeurs qu’il est apparu nécessaire de faire dialoguer les deux mondes : le développement et les infrastructures. 

DevOps, bullshit & désuétude 

Si l’idée a fait son chemin dans la plupart des entreprises qui se sont emparées du concept de façon à aligner le build avec le run, la philosophie DevOps a pris un peu de plomb dans l’aile au début des années 2010. En cause, une surexploitation du terme qui a fini par le galvauder et l’émergence d’une culture startup soucieuse de se détacher progressivement de tout modèle ou métiers jugés archaïques. 

DevOps : marketing du vent et foire aux contractions

Pour ce qui est de l’exploitation marketing, on peut dire que le mouvement DevOps a été victime de son succès. Qu’il s’agisse de simples outils collaboratifs rebaptisés “DevOps” pour surfer sur la tendance ou de consultants qui se sont engouffrés dans la brèche pour jouer les médiateurs entre les développeurs et les responsables infrastructures, le terme s’est rapidement transformé en un joyeux fourre-tout boursouflé. Mais les choses ont réellement pris une tournure dramatique avec la foire aux contractions.

Qu’est-ce que la foire aux contractions ? L’apparition des savoureux DevSecOps, FinOps et tous les TrucOps au monde. Blague à part, c’est à partir de l’émergence de ces concepts nébuleux que nous nous sommes résignés à faire le constat suivant : Le DevOps, c’est ceux qui en parlent le plus qui le comprennent le moins. Notamment parce que parler de DevSecOps ou de FinOps, c’est assumer d’ignorer que le mouvement DevOps intègre nativement l’aspect sécurité et l’anticipation financière dans sa mise en application. C’est comme préciser “beurre salé” aux bretons. 

Autant de tendances qui ont entaché durablement le terme comme le mouvement lui-même et qui ont également précipité sa tombée en désuétude pour beaucoup de jeunes entreprises. 

La “starification” du statut de développeur

Il serait néanmoins réducteur d’attribuer le désamour progressif du mouvement DevOps à ces seuls abus marketing. Une autre tendance, arrivée en parallèle sur le marché, a aussi joué un rôle : celle de l’explosion du modèle startup. Au début des années 2000, les startups étaient assez largement imprégnées d’une culture technique un peu geek, souvent matérialisées par une connaissance (presque) encyclopédique des infrastructures et plus largement du hardware.

Mais l’engouement nouveau pour les startups a créé une nouvelle culture, centrée sur la posture de l’entrepreneur touche-à-tout et du développeur de génie (quand les deux personnes ne sont pas réunies en une). En parallèle, les offres de Cloud Computing ont commencé à se démocratiser permettant ainsi aux néo-entrepreneurs de se débarrasser d’infrastructures coûteuses et encombrantes. 

Ajoutez à cela les moyens financiers limités de début d’activité, c’est en toute logique que les arbitrages techniques se sont faits en faveur des développeurs. Non seulement ils créent une valeur immédiate pour la startup (nous en convenons), mais ils ont aussi des outils à disposition pour pallier les manques de compétences en matière d’infrastructures. 

L’iconisation trompeuse du développeur omnipotent

Cela a eu plusieurs conséquences :

• L’illusion du statut de développeur omnipotent, capable d’avoir une vision des infrastructures aussi pertinente que pour le code
• Une réinterprétation du mouvement DevOps limitée aux développeurs qui ont quelques notions de système 
• Une mise à l’écart progressive des profils et compétences liés aux infrastructures, souvent associés à des cultures informatiques d’entreprises un peu ringardes et perçus comme des pertes de temps

Autant de tendances qui ont inévitablement conduit à la glorification des compétences liées au développement, au détriment des expertises en matière d’infrastructures. Or le DevOps, quand il est pratiqué intégralement par des développeurs, c’est juste du Dev. 

Quel est l’intérêt du DevOps aujourd’hui ? 

Loin de nous l’envie de renvoyer dos à dos les développeurs et les responsables infrastructures, cela desservirait notre propos. En revanche, réduire l’Ops à des casse-pieds qui font perdre du temps dans la gestion de projet, c’est une vision passéiste en plus d’être erronée. Y consacrer du temps dès la conception, c’est éviter d’en perdre plus tard. 

Faciliter le maintien des applications, ou éviter l’effet déodorant sur les infrastructures  

Sans une connaissance fine et précise des infrastructures, il est très facile de tomber dans le piège d’architectures inutilement complexes et contre-performantes. La principale erreur avec les infrastructures, c’est de les aborder comme un célèbre déodorant : “Plus t’en mets, plus t’en as”. C’est-à-dire considérer le sujet uniquement par le prisme de la quantité. Et c’est principalement le premier rôle des “Ops” dans les organisations DevOps : éviter de créer des usines à gaz pour concevoir des logiciels facilement maintenables.

C’est même sur cet aspect que repose en partie le modèle économique de certains acteurs, très cyniques, du cloud computing. Un drame composé de deux actes : 

1. Offrir beaucoup de ressources aux développeurs pendant quelques temps pour créer de la dépendance et rendre indispensable le paiement desdites ressources.
2. Capitaliser assez largement sur le manque de connaissances en infrastructures de leurs clients développeurs et les incitent à consommer toujours plus d’instances et de ressources pour des projets qui n’en ont pas toujours besoin. 

Ces pratiques nous révoltent surtout quand nous constatons que certaines startups allouent une part importante de leur levée de fonds pour des dépenses cloud, au détriment d’autres postes de dépenses à plus grande valeur ajoutée comme la R&D, les compétences humaines… Ou les développeurs justement.

Éviter les handicaps techniques

Quand il s’agit de code, nous sommes d’accord pour dire que la dette technique n’existe pas. Supprimer du code crado pour le réécrire proprement, c’est un investissement rentable. En revanche, la dette technique est un vrai sujet quand on parle d’architectures et d’infrastructures, car elles peuvent rapidement devenir un boulet pour les entreprises si elles sont mal pensées. Non seulement elles conditionnent l’évolutivité des sites et applications, mais en plus, la moindre modification entraînera fatalement un travail sur le code. Un manque de flexibilité qui peut se transformer en véritable handicap technique. 

Exemple assez connu, celui de Twitter. Si vous avez utilisé l’outil à son lancement, vous vous souvenez peut-être des nombreuses coupures de service. En cause, un très mauvais ratio de scalabilité qui a forcé les équipes à réécrire complètement le code et repenser l’architecture. Pour un service comme Twitter, c’était un vrai souci. 

Il est pourtant possible de penser et bâtir des architectures qui permettent de toucher aux infrastructures sans toucher au code et inversement, qui permettent d’adapter rapidement un service web à de nouvelles contraintes du marché. Mais cela requiert de solides compétences et un savoir quasi-encyclopédique en matière d’infrastructures. Et c’est là tout le paradoxe auquel nous nous confrontons régulièrement avec certaines startups. C’est de la bonne intégration et compréhension d’une compétence jugée archaïque et chronophage, que dépend en partie la bonne exécution de la manœuvre qui demande le plus de flexibilité aux startups : le pivot. En d’autres termes, le DevOps facilite grandement l’exercice du pivot. 

Réconcilier (à nouveau) les deux mondes

Il ne s’agit pas ici d’un pamphlet ou d’une demande d’inverser la tendance pour redonner de l’importance aux infrastructures au détriment du développement. Au contraire, nous plaidons en faveur d’une complémentarité des expertises. C’est le statut du développeur omnipotent qui nous gêne. Ce sont deux métiers très différents et aussi vrai que les développeurs ne peuvent pas tout faire seuls, les responsables des infrastructures ne peuvent pas non plus gérer le code eux-mêmes.

Estimer pouvoir se passer de compétences en infrastructures parce que le cloud computing existe, c’est comme vouloir se passer de développeurs parce qu’il existe des outils en ligne permettant de développer soi-même des sites ou des applications. Ça fera le travail au début mais ça deviendra vite pas très propre. 

Néanmoins, nous ne réfutons pas les arbitrages économiques que cela peut représenter pour les entreprises et les startups. Nous nous risquons même à penser que ce serait une erreur d’internaliser cette compétence. Premièrement pour un aspect purement financier. Et deuxièmement, parce que l’expertise et la sagacité en matière d’infrastructures naissent de la diversification des projets ou sujets traités, ainsi que d’un apprentissage continu. S’entourer de compétences “Ops” ne veut pas dire en recruter pour autant. 

Nous comprenons également le besoin de sortir rapidement des produits web (sites ou applications) et que pour y arriver, il faut parfois prendre des raccourcis intelligents. C’est là que la philosophie DevOps reste pertinente car, pour prendre des raccourcis intelligents, encore faut-il avoir une vision globale des différents composants d’un projet informatique.