Dans quels cas la méthode DevOps est-elle pertinente ?

DevOps serait l’apanage des géants du Web ou de grands groupes d’autres secteurs qui ont à disposition de très grandes réserves de code informatique ? Pas vraiment mais ce n’est pas étonnant que cette idée fausse perdure.

Pour une société d’informatique classique, Netflix a sûrement tout de l’extraterrestre ou de la licorne. Les nouvelles approches du développement comme les microservices ou la production quasi-continue de nouvelles versions ne vont surement pas devenir la norme, encore moins pour la partie dite classique de l’infrastructure IT (le Mode 1, pour reprendre la terminologie de Gartner). Mais ça ne signifie pas que les principes DevOps ne peuvent pas s’appliquer du tout aux environnements IT classiques dans des sociétés classiques.

Tout est une question de logiciel
La raison numéro un qui fait que les pratiques DevOps ne sont pas exclusivement réservées aux « cloud-natives » (le Mode 2 selon Gartner) est que les règles sont en train de changer. Le fameux adaje « software is eating the world » de l’investisseur Marc Andreesen a beau être devenu un cliché, la citation n’en est pas moins vraie. Comme James Labocki de Red Hat l’a déclaré récemment : « Bank of America n’est pas qu’une banque, c’est une société qui traite des transactions. Exxon Mobil n’est pas qu’un grand groupe pétrolier et gazier, c’est le fournisseur d’une solution SIG. Chaque jour, les pharmacies Walgreens dépendent davantage de l’utilisation des dossiers médicaux électroniques. »
Ces évolutions de la technologie et des pratiques business font que de nouveaux concurrents surgissent là où on ne les attendait pas. Les barrières de l’accès aux capitaux, des coûts des transactions ou même de l’image de marque sont moins infranchissables dans la mesure où une app sur smartphone peut changer la donne en un tour de main. (Pensez à toutes les offres de livraison sous 24h ou le jour-même qui pourraient venir concurrencer les opérateurs historiques du transport et de la logistique.)

Même si les priorités de l’IT classique et des environnements Cloud-native peuvent être différentes, le statu quo n’est pas envisageable. Les entreprises vont devoir évoluer et s’adapter. Même le fait de désigner l’IT traditionnel comme étant hérité (“legacy”) et statique est trompeur car l’expression peut amener à penser qu’il faille tout remplacer intégralement.

Cette approche IT « à vitesse lente », qui privilégie peut-être la stabilité au changement rapide, doit s’inscrire avec plus de pertinence dans les nouvelles initiatives d’organisation des entreprises et réduire la complexité. Pour être plus pertinente, elle doit pouvoir mettre à disposition des environnements pour les développeurs en quelques minutes et non en plusieurs jours ou semaines. Pour réduire la complexité, elle doit adopter l’automatisation à base de règles qui limite le recours aux tâches manuelles (sources d’erreur humaine).
Cette démarche suppose de combiner les approches DevOps et de gestion de Cloud hybride « policy based » (à base de règles).

La méthode DevOps a fait ses preuves dans les secteurs traditionnels de l’industrieLe concept DevOps tel que nous en parlons le plus souvent est assez nouveau. C’est le fruit de technologies modernes récentes, d’intégration continue Open Source, PaaS (platform-as-a-service) ou encore des infrastructures logicielles (software-defined). Mais dans les grandes lignes, l’approche DevOps s’inspire d’autres préceptes plus anciens que l’on retrouve, dans la fabrication industrielle et d’autres secteurs.Prenez la terminologie associée à DevOps. Les expressions « automatisation des processus » et « culture de la collaboration »  décrivent la transformation de l’industrie automobile jusqu’à l’âge moderne. Les concepts comme celui de kaizen (d’amélioration continue en douceur), de gestion des stocks juste à temps, de  fabrication sur demande (build-to-order) et la plupart des axes de réflexion systémique de la méthode « Toyota » sont autant d’invitations à établir des parallèles avec DevOps.Les pièces standardisées et réutilisables, comparables aux petits services réutilisables associés à DevOps, datent du Système Gribeauval pour les canons de 1765. Les processus et les machines que Brunel et Maudslay ont appliqués à la fabrication en série de poulies au début du 19ème siècle s’apparentent aux workflows automatisables et répétables associés à DevOps.Mais la similarité la plus importante tient peut-être du changement culturel en faveur de la flexibilité, de la coopération et de la transparence. Quand Jeffrey Liker a écrit « La méthode Toyota a été inculquée si profondément dans l’esprit des salariés que d’une stratégie c’est devenu un pilier important de la culture de l’entreprise », c’est d’un constructeur automobile qu’il parlait. De même, DevOps exige la mise en place de motivations et de récompenses, une structure et une organisation pour réunir les conditions de la culture voulue.Où appliquer les principes DevOps ?

Ce qu’il faut retenir, c’est que DevOps a de nombreuses applications. Dans le détail, les conditions d’application des principes DevOps seront différentes selon les organisations et au sein même d’une organisation, exactement comme la rigueur de certains processus de fabrication va dépendre de ce que l’on fabrique. La méthode « fail fast » est un concept général acceptable mais la nature et le nombre de tentatives qui se soldent par un échec doivent être inscrits dans le processus global.

Toutefois, il existe des principes universels, à tel point d’ailleurs que si DevOps s’appuie en grande partie sur des chaînes d’outils Open Source innovantes, c’est au moins autant une approche et une culture qu’une boîte à outils. Une volonté d’amélioration continue. Une philosophie du partage d’information et de l’expérimentation. La création aussi souvent que possible de processus automatisés et répétables. Ceci se vérifie que l’organisation donne la priorité à la stabilité ou à la rapidité. De nombreux analystes et observateurs de l’industrie s’attendent donc à ce que DevOps se généralise dans les années qui viennent, y compris dans les environnements IT plus traditionnels.