Une décennie DevOps, quels enseignements tirer ?

Un mur qui peine à tomber

Le mur de la confusion est la plus célèbre métaphore du mouvement DevOps. Il faut déconstruire le mur qui sépare les devs (qui veulent du changement) et les ops qui sont garants de la stabilité). Après des années à vivre en silo avec des objectifs non alignés, nous sommes forcés de constater que la déconstruction du mur prend du temps même si tout le monde en est conscient. L’arrivée des solutions de cloud public a fait bouger les lignes : les dev pensent pouvoir se passer des ops, ce qui est faux dans la plupart des cas car ils sont souvent loin des réalités de la production. Les ops doivent réagir à cette offre publique en proposant une alternative interne : pour faire simple, supprimer les tickets et proposer des services à la demande par API ou portail. La peur des start-ups qui uberisent de nombreux marchés a poussé les entreprises historiques à se challenger. Malgré une résistance forte, la culture des entreprises évolue et les organisations entreprennent de déconstruire le mur. D’un coté en alignant les dev sur les réalités de la production avec la fusion du support et de l’intégration dans les feature teams. De l’autre en alignant les ops sur les enjeux métiers : ce qui passe par l’arrivée d’un product owner infra qui se rapproche des dev. Cet alignement devient nécessaire avec l’évolution des métier des ops qui sont de plus en plus développeurs.

a crack in the wall by Tai, flickr

DevOps n’est pas un concept IT

C’est sans doute son problème le plus important, le mouvement DevOps n’est pas aidé par son nom. L’agilité est un terme général adapté à des méthodes de développement logiciel technique. Dans le cas de DevOps, le choix fut inverse : un terme empreint de jargon pour désigner un modèle d’organisation de l’entreprise… 10 ans plus tard, nous sommes forcés de reconnaître que le terme n’aide pas. L’entreprise ne l’assume pas et le business y voit une solution quand les initiateurs du mouvement y voyaient une nouvelle culture avec une façon de s’organiser et un nouveau management.

Just wrote this for a non-IT boss:

Agile is the approach of working with complex systems anywhere.

Lean is the approach of optimising the flow of work anywhere.

DevOps is the application of Agile and Lean to the acceleration of value work through IT.

— Rob England (@theitskeptic) 6 juin 2018

Une obédience technique qui complique l’appropriation

Le terme DevOps fait peur, les métiers et les managers réagissent de deux manières quand ils l’emploient : soit ils le minimisent, soit ils le considèrent comme un mouvement pour les dev et les ops. Certes le mouvement DevOps est à l’origine initié par des personnes comme Patrick Debois qui sont issues des infrastructures mais ils avaient conscience de l’importance de l’agilité et de l’alignement de l’entreprise. Le mouvement DevOps propose une façon d’organiser et de manager l’entreprise dans son ensemble. Nombre d’entreprises ont du mal aujourd’hui à se retrouver derrière cet étendard par méconnaissance. Des méthodes comme le lean startup qui partagent des valeurs communes (à commencer par la culture de la mesure) ont aujourd’hui un écho plus important coté métier et il semble que le nom et l’origine en soient en partie la cause.

Des raccourcis pris par les technophiles

Automatiser n’est pas DevOps. On ne peut que constater dans les DSI que l’amalgame persiste. Certes il existe deux types d’automatisation indissociables de DevOps : le pipeline CI/CD qui va permettre de mettre en production rapidement de manière sécurisée. Et le provisionning des infras qui permet de construire rapidement des environnements reproductibles et maîtrisés. Sans ces deux automatisations, il n’y a pas de développements agiles mais un bon niveau d’automatisation n’implique absolument pas d’être DevOps. L’obnubilation pour l’automatisation peut vite faire oublier les principes de DevOps : la collaboration, l’importance de mesurer les actions, le lean et bien sûr l’amélioration continue. On parle souvent du modèle CALMS qui se veut une alternative a ITSM dans le monde ITIL.

Le marketing des éditeurs est un miroir aux alouettes

DevOps est un buzzword et l’homme aime ce qui est magique. Il est tentant de croire qu’un logiciel va nous rendre DevOps. C’est globalement le travers des organisations quant à l’outillage. Acheter un outil semble souvent la solution. Quand bien même l’outil est de qualité, on oublie de s’assurer que les collaborateurs l’utilisent correctement, formation et accompagnement sont souvent bâclés. Derrière chaque outil étiqueté DevOps il y a des concepts implémentés mais on ne peut décemment croire qu’un outil pourra tous les abstraire. Le développement est un métier complexe, le mouvement DevOps fait travailler avant tout l’état d’esprit des équipes. On n’installe pas un état d’esprit.

DevOps est l’organisation moderne pour une entreprise

Si vous n’en êtes pas convaincus, il reste un argument massue : même SAFe en parle ! On peut être DevOps sans être SAFe mais l’inverse n’est pas envisageable. A l’instar des frameworks d’agilité à l’échelle, DevOps propose une organisation et une culture adaptées aux enjeux de l’entreprise d’aujourd’hui : centrées sur l’utilisateur du produit, permettant d’expérimenter rapidement et de pivoter si besoin. Le monde dans lequel nous vivons est complexe, il est impossible de créer le produit parfait au bon prix et dans les temps pour de nombreuses raisons. Il faut donc repenser l’entreprise pour qu’elle devienne anti-fragile, par opposition à fragile. Comme le dit Nassim Nicholas Taleb dans son livre : « L’anti-fragilité est une propriété des systèmes qui se renforcent lorsqu’ils sont exposés à des facteurs de stress, des chocs, de la volatilité, du bruit, des erreurs, des fautes, des attaques ou des échecs. » Les entreprises doivent s’organiser pour tendre vers cet idéal.

Faire le deuil de la cohérence logique.

La cohérence logique est ce qui nous pousse à ranger les choses dans des boites. Il y a une indéniable logique à mettre tous les développeurs front ensemble, tous les DBA ensemble, etc. Ce modèle a certains avantages : économie d’échelle, contrat de type centre de service, gestion de la compétence. C’est inévitable, ce mode d’organisation en silo oblige à dépenser une énergie folle en coordination et en stratégie pour satisfaire des objectifs orthogonaux. Localement, on a l’impression de faire des économies mais dans la réalité, la gestion d’un SI est trop complexe pour que ce fonctionnement en silo soit efficient et surtout rapide. L’organisation en feature team, mais plus généralement en équipe pluridisciplinaire, est aujourd’hui la seule qui semble permettre un time to market concurrentiel pour beaucoup de produits.