Pourquoi les développeurs parlent-ils toujours à DevOps ? !

DevOps a pris un départ prometteur. En 2006, le directeur technique d’Amazon, Werner Vogel, a prophétisé une relation sans tracas entre le développement et les opérations : « Le modèle traditionnel consiste à amener votre logiciel au mur qui sépare le développement et les opérations, à le jeter par-dessus bord, puis à l’oublier. Pas chez Amazon. Vous le construisez, vous l’exécutez. Cela met les développeurs en contact avec le fonctionnement quotidien de leur logiciel. »

Ce mouvement « vous le construisez vous l’exécutez », connu sous le nom de DevOps, nous a tous enthousiasmés par la promesse qu’il détruirait les silos et permettrait aux équipes de travailler ensemble plus efficacement que jamais.

Mais c’était il y a longtemps. Et dernièrement, les choses n’ont pas été aussi ensoleillées au pays DevOps.

Quels sont les signes indiquant que la lune de miel est terminée ?

Eh bien, d’une part, les développeurs se plaignent de ne pas vouloir gérer les opérations (raisonnablement, puisque ce n’est pas leur cœur de métier).

Et pendant ce temps, les équipes d’exploitation se plaignent d’être submergées par les demandes quotidiennes infimes du développement. Comme l’écrit Mat Duggan, ingénieur DevOps, les opérations « avaient toujours toutes les responsabilités que nous avions auparavant, s’assurer que l’application était disponible, surveillée, sécurisée et conforme ». pour permettre au développement de sortir le code rapidement et en toute sécurité sans que nous soyons impliqués.

Aujourd’hui, toutes les entreprises disent qu’elles font du DevOps, mais trop peu en récoltent les bénéfices. Pendant ce temps, DevOps ne signale plus un état d’esprit d’innovation comme il le faisait auparavant ; aujourd’hui, c’est juste un autre mot à la mode que chaque entreprise doit utiliser.

Est-il trop tard pour sauver DevOps ? Ou avons-nous encore une chance de ramener nos équipes à la promesse fondamentale, l’excitation d’une véritable collaboration, que Vogel et d’autres avaient autrefois prévue ?

Défis croissants

Nous avons vu comment DevOps promettait d’apporter une bouffée d’air frais au monde du développement logiciel lors de sa première apparition. Alors, qu’est-ce-qu’il s’est passé? Pourquoi les choses ne se sont-elles pas déroulées comme nous l’espérions ? Cela est principalement dû à des défis nouveaux et imprévus qui sont apparus à la fois dans le développement et les opérations.

Les défis pour les équipes de développement incluent :

• Cycles d’intégration et de livraison plus rapides

• Perte de QA dédié pour tester minutieusement les versions (il a été sacrifié à la vitesse)

• La pile de technologies de développement s’est développée et est devenue plus variée

• Applications plus complexes et distribuées avec des architectures de microservices complexes

• Problèmes de sécurité et vulnérabilités de la chaîne d’approvisionnement logicielle

• Manque de temps/incitations pour en savoir plus sur le côté opérationnel des choses

Les défis pour les équipes opérationnelles incluent :

• Manque de propriété claire dans le SDLC (avec des pointages fréquents vers les opérations, car les applications fonctionnent souvent en test mais échouent en production en raison de la complexité du monde réel)

• Le développeur demande de l’aide lorsque le test de l’application échoue

• Gestion de la surveillance continue et de l’observabilité, de la sécurité et de la conformité

• Adaptation des flux de travail pour intégrer les solutions IAC avec des garde-corps pour plus de sécurité et de cohérence

• Dépannage des systèmes abstraits (comme Kubernetes) – lorsque les applications échouent, les développeurs n’ont aucune idée de ce que pourrait être le problème

• Exige d’apprendre des aspects importants de la pile de développement et des outils pour résoudre les problèmes

Et puis, bien sûr, il y a des défis que DevOps et Ops ont en commun, comme…

• Des cycles de publication plus rapides obligent les deux équipes à être en état d’alerte à tout moment

• Dette technique créée en prenant des raccourcis pour respecter les délais mais qui doit être payée pour demain

• Aucune des deux parties n’est en mesure de se concentrer sur son expertise de base

Enfin, un problème auquel toute la communauté est confrontée est la « taxe sur les outils ». Également connu sous le nom de « prolifération d’outils », ou comme l’écrit Sharon Gaudin de GitLab, un « méli-mélo d’outils qui obligent les membres de l’équipe à faire des allers-retours continus entre plusieurs interfaces, mots de passe et méthodes de travail ».

Il existe tellement d’excellents outils DevOps, mais vous savez que les choses deviennent incontrôlables lorsque nos équipes utilisent, en moyenne, entre 20 et 50 outils DevOps différents.

Le libre-service est-il la solution ?

Comme nous l’avons vu, de nombreux problèmes entravent un développement rapide et efficace. Alors que pouvons-nous faire pour aider nos équipes à franchir tous ces barrages ?

Certaines entreprises ont adopté la promesse d’approches « DevOps en libre-service ». Et en théorie, cela ressemble à un rêve devenu réalité. DevOps en libre-service promet de supprimer les demandes de routine des équipes d’exploitation tout en offrant aux développeurs les outils, l’infrastructure et les services dont ils ont besoin avec des demandes simples et efficaces.

Cela élimine les goulots d’étranglement et rationalise le flux de travail de développement, leur permettant de reprendre le codage sans attendre l’implication des opérations. Et, bien sûr, cela allège la charge de travail manuelle des équipes opérationnelles.

Il existe plusieurs façons de mettre en œuvre le DevOps en libre-service, au moins partiellement, aujourd’hui :

Malheureusement, aucune de ces approches n’est idéale. Ils ajoutent généralement une couche supplémentaire de complexité, ce qui aggrave le problème avec un autre nouveau système brillant pour les développeurs et les opérations à apprendre et plus de changement de contexte pour les distraire des tâches principales.

De plus, si vous jetez un coup d’œil sous le capot, bon nombre de ces solutions reposent en fait fortement sur l’implication de « l’humain au milieu », ce qui signifie que les opérations reçoivent toujours ces appels au milieu de la journée – ou de la nuit – qui rendent leur travail si nerveux. -détruisant.

Il est temps d’aller sans tête ?

Contrairement aux approches DevOps « libre-service » existantes – qui, comme nous l’avons vu, ajoutent généralement simplement plus de complexité ingérable – une approche sans tête offre quelque chose de vraiment nouveau et différent.

Le terme « headless » est issu du monde des sites web (CMS) et du e-commerce. Dans un modèle sans tête, le back-end est « découplé » du front-end. Cela signifie que les informations (contenu, entrées de catalogue, prix, etc.) sont « indépendantes de la présentation ». Votre contenu ne se soucie pas de la façon dont il est affiché – via une application Web, une application mobile, un ordinateur de bureau, etc. Cela permet aux entreprises de dissocier le contenu de la façon dont ce contenu est utilisé ou affiché, créant une approche agile et (en théorie) intuitive qui fonctionne sur tous les appareils d’aujourd’hui.

Pour les sites Web et les applications, le headless peut rationaliser le développement ou les tests :

• Pour le commerce électronique, le développement back-end peut être effectué sans se soucier de la compatibilité/utilisabilité des différentes interfaces utilisateur, par exemple mobile, web, applications, etc.

• Pour les navigateurs, les tests peuvent être effectués plus rapidement sans les temps de chargement réels de l’interface utilisateur, etc.

Une approche sans tête peut également nous aider à penser différemment DevOps. Le développement et les opérations sont aujourd’hui submergés d’outils, comme nous l’avons vu. Mais que se passerait-il s’ils pouvaient tous les deux faire leur travail de manière intuitive sans avoir besoin de plusieurs outils et interfaces utilisateur juste pour accomplir une tâche ?

Découplage des flux de travail DevOps et des pipelines

Avec un seul moyen clair, rationalisé et intuitif d’accéder à l’ensemble du flux de travail DevOps, les développeurs et DevOps ne seront pas obligés de maîtriser et d’accéder en permanence au large éventail de systèmes disparates tels que l’infrastructure cloud, CI/CD et les fournisseurs d’identité. . Pas de nouveaux systèmes à apprendre. Pas de changement de contexte.

Une seule interface simple pour les gouverner tous.

Au cas où vous pensez que je suis sur le point de suggérer d’ajouter un autre outil pour faciliter la vie de DevOps, n’ayez crainte. Je suggère en fait l’approche exactement opposée, à savoir « découpler » DevOps :

• Tout d’abord… détachez ces fonctions critiques de la myriade de systèmes et d’interfaces utilisateur que nos développeurs et DevOps utilisent actuellement.

• Ensuite… donnez-leur un moyen de tout faire en un seul endroit.

Et pas n’importe où. Quelque part les devs et DevOps travaillent déjà : leur outil de collaboration et de gestion de projet de prédilection. Cela pourrait être Slack, qui est utilisé par 40 % des entreprises du Fortune 100, ou MS Teams, qui compte 270 millions d’utilisateurs à ce jour.

Headless DevOps a lieu partout où vos équipes communiquent toute la journée, tous les jours. Car ce n’est qu’alors qu’ils pourront réaliser la véritable promesse du libre-service avec un accès simple et sécurisé à l’infrastructure cloud, aux pipelines CI/CD, aux informations, etc.

Imaginer la nouvelle réalité sans tête

Vous espérez rendre vos équipes DevOps plus productives ? Où qu’ils se trouvent, que ce soit Slack ou Teams (ou même CLI), vous devez transformer cela en leur interface utilisateur DevOps universelle.

Cela crée un gagnant-gagnant :

• Les développeurs gagnent car ils peuvent accéder à l’infrastructure cloud nécessaire, déclencher des pipelines, etc. sans avoir besoin d’expertise dans ces domaines. De plus, ils peuvent le faire en toute sécurité grâce au contrôle d’accès intégré.

• Les opérations gagnent parce qu’elles peuvent être autonomes pour les fonctions quotidiennes les plus courantes, ce qui leur permet de se concentrer sur des problèmes plus vastes.

En utilisant l’IA conversationnelle intégrée dans Slack, MS Teams ou CLI, vous pouvez fournir un contrôle d’accès granulaire, en automatisant tous vos flux de travail avec des conversations simples.

Les avantages de cette approche sont sans aucun doute évidents pour quiconque a déjà traité des arriérés et des goulots d’étranglement dans le SDLC, mais pour n’en citer que quelques-uns spécifiquement…

• Éliminer le changement de contexte et les tâches répétitives – plus besoin de jongler avec les demandes Slack, les tickets Jira et une gamme d’autres outils et plates-formes

• Rendre les automatisations hautement accessibles – le développement n’a pas besoin de s’appuyer sur les opérations pour trouver et déclencher les flux de travail appropriés, éliminant ainsi l’intervention humaine et les retards dans la mesure du possible

• Garantir la responsabilisation – plus besoin de se refiler la responsabilité, avec chaque fonction DevOps sous un même toit et une ligne d’autorité claire

• Amélioration de la sécurité – les opérations intègrent des garde-corps pour donner aux développeurs un accès sûr et sécurisé avec un accès granulaire et juste à temps aux ressources auxquelles ils ne peuvent normalement pas accéder

• Mettre fin aux conflits – mettre fin aux tensions entre les départements en donnant simplement (et en toute sécurité) aux développeurs ce qu’ils veulent, quand ils le veulent

Bref, vous remettrez vos équipes au travail comme jamais auparavant.

Et le meilleur de tous, vous ferez tout cela non pas en ajoutant un autre nouvel outil brillant dont vos équipes se plaindront, mais en transformant un outil que vous utilisez déjà en une centrale DevOps. Maintenant, cela utilise vraiment votre tête.