DevOps style !

Ce que beaucoup qualifiaient de mode s’installe de plus en plus durablement dans l’entreprise, 2020 n’échappe pas à la règle. Le nombre d’entreprises qui souhaite adopter le DevOps augmente de manière constante.

Mais déjà, mettons-nous d’accord sur le DevOps: un métier ? Une organisation ? Une culture ? Je soutiens que le DevOps est une culture de la collaboration afin de réduire les frictions entre les équipes par divers moyens (en particulier les Dev et les Ops) afin de réduire le time to market.

On parle d’ailleurs souvent des 5 piliers C.A.L.M.S pour Culture, Automatisation, Learn, Mesure et Solidarity, qui à mon sens couvrent assez bien les principes du DevOps. Cela ne doit néanmoins pas permettre de simplifier le DevOps à l’automatisation, comme je le voie trop souvent. On automatise depuis bien plus longtemps que celui-ci n’existe ! Si vous voulez plus d’informations, je parlais du DevOps l’année dernière par ici.

DevOps, DevSecOps, DataOps, DevQAOps, qui est le prochain ?

Ces derniers mois, voir années nous avons vu fleurir les différentes déclinaisons de l’abréviation DevOps, plus ou moins farfelues. Mais ces abréviations sont-elles que des mots en l’air ?

Alors oui et non, souvent ils sont utilisés pour créer un effet de “buzz words”, une technique de plus en plus présente dans nos métiers malheureusement. Il suffit de naviguer quelques minutes sur Linkedin pour s’en rendre compte. Mais passons au-delà de cela, le DevOps a bien évolué. D’ailleurs, j’aime voir la culture DevOps étant elle même itérative. En effet, pour moi c’est avant tout se retrouver autour d’une table, qu’on pourrait matérialiser par la chaine de déploiement continue, et au fur et à mesure des années, nous avons ajouté toutes les équipes nécessaires à cette table, la Quality assurance (les testeurs), la sécurité, la Data, etc.

Donc au final c’est une évolution logique, mais pour autant le terme doit-il évoluer ? Personnellement, je ne pense pas que ça soit pertinent de sortir de nouvelles abréviations chaque fois que l’on invite une nouvelle personne à sa table. De plus cela doit rester agile, chaque projet ne nécessite pas d’impliquer pleinement un ingénieur donné, il faut rester pragmatique. Il serait ridicule à mon avis de mettre tout dans une abréviation.

Néanmoins il y a deux termes qui me semblent plus pertinents dans cette liste. DevSecOps tout d’abord qui à mon sens doit plus traduire une vraie compréhension des nouveaux paradigmes et une implication dans le DevOps de la part des équipes sécurités ce qui est encore trop rare. Il y a aussi GitOps, qui est très à la mode est de ce que j’en voie se définit simplement par le fait d’avoir son dépôt Git en unique source de vérité. Rien de transcendant là encore des années maintenant que l’on centralise un maximum de chose dans le versionning y compris côté infrastructure.

Niveau technologie, Kubernetes gagne par K.O

Le nombre de technologies augmente constamment comme on peut le voir sur cette cartographie de la Cloud Native Foundation Landscape.

Malgré cela j’ai l’impression que globalement le marché se polarise autour de solutions qui deviennent des standards. On peut voir des technologies comme Terraform, Packer, Vault et bien sûr Kubernetes être devenues des standards dans la grande majorité des projets. Cela traduit à mon sens une certaine maturité de ses technologies.

Ces différents outils ne sont pas pour autant parfaits et sont souvent utilisés dans des situations où d’autres feraient surement mieux. Nous sommes donc en droit de se demander pourquoi un tel succès. La raison est plutôt simple la maintenance et le suivi, il sera toujours bien plus difficile de trouver de la compétence sur une technologie pointue de niche que pour une solution générique comme Kubernetes. Ajoutez à cela la loi du marché et les difficultés à trouver des modèles rentables, beaucoup de concurrents ont simplement disparu. Et ne nous mentons pas même si ces outils ne demeurent pas parfaits, ils comportent tout de même pas mal de qualités non négligeables.

Le DevOps enfin mature ?

La maturité est avant tout un état de stabilité et je pense que nous avons atteint une certaine maturité. Le DevOps est bien implanté aujourd’hui dans nos métiers et les paradigmes qui l’accompagnent aussi (Pet vs Cattle, Infra As Code…). Néanmoins, il faut avoir conscience qu’une grande partie des entreprises en est encore très loin et n’y passera peut-être jamais.

On pourrai être tenté de définir la maturité du DevOps par son taux d’adoption. Sur ce point j’émets énormément de réserve. Une grande partie des entreprises n’aura jamais le besoin de passer au DevOps. Et surtout parce que le DevOps n’est pas une magie, pour que la démarche soit efficace il faut investir et se remettre en question. Ce n’est pas donné à toutes les organisations.

Cette maturité ne signifie pas que le DevOps ne va pas changer et évoluer, mais cela va se faire moins brutalement et restera une évolution naturelle.