Trois facteurs vous empêchent d'adopter DevOps

Non, pas toi. Toi. Les dirigeants ne sont pas aussi enthousiastes à propos de DevOps que ceux qui sont sur le terrain, et la réponse se trouve peut-être dans l’une de ces trois préoccupations clés.

Les organisations performantes n’ont pas seulement adopté, mais adopté DevOps. Le rapport phare de Puppet Labs sur l’état de DevOps nous l’a montré au cours des deux dernières années, et j’imagine qu’il renforcera à nouveau cette relation au cours de l’année à venir. Selon un certain nombre d’enquêtes et d’études sectorielles, les organisations adoptent DevOps. Mais tout comme ils ont adopté des méthodologies de développement d’applications agiles et allégée dans le passé, l’adoption ne signifie pas toujours ce que nous pensons que cela signifie. Il s’est avéré que ce que les organisations entendent réellement par « adopter Agile » pour le développement d’applications, c’est qu’un pourcentage relativement faible de leurs projets utilisaient Agile. Cela ne signifie pas qu'ils ont foncé tête baissée et ont sauté le pas en adoptant cette approche pour chaque projet.

Il semble que le même constat soit vrai pour DevOps, où les répondants l’adoptent avec enthousiasme – et obtiennent des résultats – mais les dirigeants dans leur ensemble semblent encore tièdes à l’égard de l’approche, avec une augmentation de seulement deux points de pourcentage de « l’impact stratégique » d’une année sur l’autre – de 15 % en 2016 à 17 % en 2017 selon notre enquête sur l’état de la distribution d’applications . Même si les architectes cloud et les rôles autoproclamés « DevOps » sont peut-être pleinement engagés dans leur initiative DevOps, et même au-delà du mur de production, les dirigeants tardent encore à adopter cette approche. Ce qui signifie en réalité que les « organisations » ne sont pas nécessairement toutes tournées vers DevOps.

Il existe trois préoccupations majeures qui empêchent probablement les dirigeants informatiques et commerciaux d’accorder à DevOps l’accueil vraiment chaleureux qu’il mérite.

1. Temps . Les projets informatiques internes de toute nature qui nécessitent une mentalité de migration – qu’ils soient traditionnels vers le cloud, monolithiques vers les microservices, manuels vers automatisés – sont parfois considérés comme une simple perte de temps. Ils ne contribuent pas directement à la croissance de l’entreprise et le temps consacré à de tels projets peut donc être difficile à supporter pour les parties prenantes de l’entreprise. Il incombe à ceux qui soutiennent DevOps d’illustrer aux chefs d’entreprise un ensemble clair d’objectifs et d’avantages attendus qui découleront de la mise en œuvre de tels projets. Qu'il s'agisse d'économies de coûts ou d'une informatique plus réactive, il est important pour les entreprises de comprendre le retour sur investissement attendu pour les inciter à adhérer et à soutenir l'effort. Un centime économisé peut être un centime gagné, mais un centime investi est souvent une pièce de dix cents gagnée. En investissant dans DevOps maintenant, les organisations en récolteront les fruits plus tard.
    
2. Perturbation.  Aucun responsable informatique ne souhaite être à l’origine de perturbations dans l’activité de son entreprise. Investir dans une initiative DevOps maintenant peut être perturbateur, en particulier si cela entraîne un ralentissement du pipeline de production alors que tout le monde sait que vous devez l’accélérer. Parce que permettre l’automatisation et l’orchestration de la production implique souvent de modifier les systèmes responsables des activités quotidiennes, toute initiative qui l’exige peut entraîner une perturbation indésirable. La réalité est que s’appuyer sur des méthodes manuelles et obsolètes pour provisionner, faire évoluer et gérer les systèmes pourrait être la véritable disruption – si ce n’est pas aujourd’hui, alors demain. L’une des caractéristiques d’un environnement de production sans friction est la capacité à répondre à la demande aux besoins de capacité et de services. C’est quelque chose qui devient de plus en plus difficile à réaliser à mesure que l’informatique plie sous le poids de la demande croissante causée par les efforts de transformation numérique. Pas de risque, pas de récompense. Prendre le risque maintenant comporte probablement moins de risques que lorsque votre portefeuille d’applications aura doublé ou plus.
    
3. Verrouiller . L’une des craintes les plus courantes des dirigeants informatiques est d’être « enfermés » dans des choix. La bonne nouvelle est que la prépondérance des périphériques et systèmes réseau prenant en charge l’automatisation et l’orchestration sont basés sur des protocoles et des concepts standards ouverts tels que HTTP, REST et JSON. C’est là que le temps passé en amont à concevoir et à architecturer un système qui tire le meilleur parti des API et des modèles sera rentable plus tard. L'intégration avec des appareils ou des systèmes qui nécessitent une recréation étape par étape des commandes émises par CLI via une API conduira presque certainement à un verrouillage. C’est l’un des principaux avantages des modèles : ils réduisent la dépendance aux API spécifiques aux appareils et aux systèmes et limitent ainsi votre exposition à quelques commandes seulement qui sont facilement migrées vers un nouveau système ou une nouvelle application à l’avenir.  Assurez-vous que l’infrastructure prend en charge une API basée sur REST et, dans la mesure du possible, utilisez des modèles pour permettre une extraction facile des systèmes et des environnements ultérieurement.

Il existe bien sûr d’autres préoccupations, mais ces trois principales préoccupations résonnent principalement dans tous les centres de données et à travers le temps lorsqu’il s’agit d’adoption de technologies et de méthodologies. Cela prend du temps, cela peut être perturbant et il y a de fortes chances que cela se transforme. Une diligence raisonnable et une approche réfléchie de la mise en œuvre, ainsi qu’une attitude d’investissement immédiat et de bénéfices ultérieurs peuvent apaiser ces inquiétudes et engendrer de meilleures chances de réussir à établir une base solide mais flexible qui non seulement permet mais accélère la transformation numérique nécessaire à la croissance des entreprises aujourd’hui et à l’avenir.