DevOps connaît-il une crise d’identité? [Interview]

La définition de DevOps est un sujet très controversé parmi les praticiens amateurs et les ingénieurs expérimentés. Ironiquement, DevOps était en fait censé mettre de l’ordre dans l’environnement désordonné et chaotique du développement de logiciels informatiques.

Dans Paradoxe DevOps, L’expert DevOps Viktor Farcic s’entretient avec d’autres personnalités du secteur qui révèlent leur point de vue sur la tendance et ce que cela signifie pour eux. Dans cet article, nous allons voir ce que certaines personnes éminentes de la communauté DevOps ont à dire sur DevOps. Les citations de cet article sont tirées directement du livre.

Alors, comment sommes-nous censés intégrer DevOps dans nos organisations si nous ne savons même pas ce que c’est? Écoutons les réflexions de Viktor sur ce qu’est le DevOps, quelles sont ses tendances et ses aspects futurs:

Qu’est-ce que DevOps et pourquoi en avons-nous besoin?

Qu’est-ce que DevOps et pourquoi en avons-nous besoin? Quelle est la chose la plus importante que DevOps nous aide à réaliser? Quels sont les facteurs qui motivent le développement de DevOps?

Viktor Farcic: Presque tout le monde donne une réponse différente à la question «Qu’est-ce que DevOps?» – il y a un énorme écart entre l’idée et la mise en œuvre. Je pense que l’objectif principal de DevOps est de permettre à des équipes orientées produits autosuffisantes, capables d’avoir un contrôle total de leurs produits. Cela contraste fortement avec la façon dont de nombreuses entreprises fonctionnent aujourd’hui.

Normalement, le cycle de vie d’une application est divisé entre plusieurs équipes. Les analystes métier définissent les exigences, les architectes travaillent sur les directives à suivre et les frameworks à utiliser, les développeurs écrivent le code, les testeurs sont en charge des validations, les opérateurs déploient les nouvelles versions, etc. Le problème est que chacun de ces groupes appartient à des départements différents et a des objectifs différents et souvent opposés. Au lieu de favoriser la collaboration vers un objectif commun, différentes équipes (départements) recherchent leurs propres intérêts à courte vue. DevOps essaie de supprimer l’organisation en fonction du type de tâches effectuées et d’unir toute l’expertise requise pour tout le cycle de vie d’une application en une seule équipe relevant d’une seule personne. Cela nous oblige à travailler ensemble et cela renforce l’empathie.

DevOps est-il un processus? Ou un ensemble de technologies? Quel est votre point de vue sur ce domaine de débat?

Viktor: DevOps n’est ni l’un ni l’autre. Contrairement à certains frameworks agiles (par exemple Scrum), il n’y a pas de processus prescrit à suivre. De même, il n’y a pas de technologie que nous pouvons adapter qui nous convertira en équipes «DevOps». Ce n’est qu’une idée dont les développeurs, les opérateurs et tout le monde ont besoin de travailler ensemble au lieu d’être isolés dans des silos différents. Cela ne veut pas dire que la technologie n’est pas importante; c’est le cas, mais souvent pour des raisons autres qu’évidentes.

Chaque nouvelle technologie est créée par un groupe de personnes qui ont travaillé ensemble pour la créer. En tant que tel, il reflète toujours les processus de ceux qui sont impliqués dans sa création. Ces processus, en revanche, sont le résultat de la culture des gens qui les suivent. En d’autres termes, chaque technologie est le résultat de certains processus créés en raison de la culture de l’équipe qui a travaillé dessus. Ainsi, même si nous utilisons un résultat final, c’est le produit d’un processus créé dans une culture spécifique. Si nous adoptons une technologie qui ne correspond pas à nos propres processus et culture, elle produira au mieux des résultats sous-optimaux. Nous devons donc soit adopter une technologie qui correspond à nos processus et à notre culture, soit l’utiliser pour les changer. L’un ne peut pas fonctionner sans l’autre.

Dans l’ensemble, DevOps est une idée, pas beaucoup plus que cela. C’est à nous de déterminer quels processus et quelle technologie nous aideront à en faire une réalité.

Que fait un ingénieur DevOps? Est-ce même un vrai rôle professionnel?

Quels sont les rôles clés des ingénieurs DevOps en termes de développement et d’infrastructure?

Viktor: Je ne pense pas qu’il existe un «ingénieur DevOps». Le terme a été inventé par des personnes qui n’étaient pas prêtes à appliquer les changements apportés par DevOps. La plupart du temps, un «ingénieur DevOps» est juste un nom différent pour quelqu’un travaillant dans les services partagés, les opérations, l’infrastructure ou le service qui a été renommé en premier en DevOps.

Pensez-vous que DevOps traverse une crise d’identité?

Viktor: DevOps n’a jamais été défini comme un processus. Agile, par exemple, a un certain nombre d’implémentations qui indiquent aux gens quoi faire. Entre autres, nous avons Scrum qui définit clairement ce qu’il faut faire. Nous pourrions même affirmer que Scrum, en tant qu’ensemble de pratiques à suivre, est contraire à l’esprit Agile, mais c’est une conversation pour une autre fois.

Ce qui compte, c’est que personne n’a défini le processus derrière DevOps. Il n’existe pas de série d’étapes à suivre quotidiennement ou hebdomadairement. C’est juste une idée que nous devrions travailler ensemble et ne pas jeter les choses par-dessus les murs du département. En tant que tel, la manière d’accomplir cela est ouverte à l’interprétation. Ainsi, DevOps n’a jamais eu une identité claire, il ne peut donc pas non plus avoir de crise d’identité. C’est juste une idée, et c’est à chacun d’entre nous d’essayer de comprendre comment en faire une réalité.

Les plus grands défis du DevOps aujourd’hui

Quels sont les plus grands défis du DevOps en ce moment?

Viktor: Actuellement, DevOps est généralement mal compris. Le plus souvent, les entreprises renomment simplement un département. Dans certaines entreprises, les services partagés deviennent des équipes DevOps; dans d’autres, il s’agit de l’infrastructure, des opérations ou de tout autre service. C’est comme s’il s’agissait d’une course et que le premier département à changer son nom en «DevOps» était un gagnant. Logiquement, changer le nom ne signifie rien et n’entraîne aucune amélioration tangible.

Les principaux défis sont liés aux personnes et à la culture. DevOps n’est pas facile car il remet en question la structure organisationnelle actuelle, il restructure le pouvoir au sein d’une organisation et remet en question la nécessité de l’existence de nombreux départements. À ce titre, les cadres intermédiaires y sont souvent opposés car ils sont perçus comme un risque pour leur position. Dans le même temps, les personnes qui ont passé de nombreuses années à faire la même chose à maintes reprises ont le sentiment que leur crédibilité est menacée si la structure qui leur permettait de gravir les échelons de l’entreprise est supprimée.

Félicitations pour la sortie de Paradoxe DevOps. Pourriez-vous parler un peu de l’idée derrière et de ce que vous espérez réaliser?

Viktor: Je vais à beaucoup de conférences et je me suis rendu compte que les discussions programmées ne sont pas la principale chose à retenir. Certes, j’ai appris des choses en les écoutant, mais la principale raison pour laquelle je continue à participer sont les «causeries de couloir». Les conférences sont une excellente occasion pour moi de trouver des personnes intéressantes et d’avoir des discussions incroyables. Contrairement aux discussions programmées, ces conversations ne sont pas structurées. Je ne prépare pas de liste de questions pour la prochaine personne que je rencontrerai entre les pourparlers ou lors d’une fête. Au lieu de cela, nous commencerons simplement à parler d’une chose aléatoire qui se trouve être intéressante.

Je voulais amener ces types de conversations à des gens qui ne peuvent pas voyager dans le monde et être chaque papillon de nuit dans une conférence différente dans un pays différent. Donc, je n’avais pas d’objectifs réels pour ce livre, à part parler avec les gens sur n’importe quel sujet, du moment qu’il est lié au DevOps. Étant donné que DevOps peut être tout ce qui concerne le développement de logiciels, vous pouvez dire que la portée du livre est aussi large que possible. Mon véritable objectif était de profiter des conversations avec les gens. Je n’ai pas préparé de questions à l’avance. Au lieu de cela, j’ai simplement rassemblé des personnes avec lesquelles j’aimerais parler si je les rencontrais dans une conférence et disais: «Prenons un café et voyons ce que vous faisiez depuis la dernière fois que nous nous sommes rencontrés». Certains de ceux que j’ai interviewés sont mes amis, tandis que d’autres que j’ai rencontrés pour la première fois. Certains travaillent pour de grandes entreprises, tandis que d’autres travaillent dans des startups. Certains ont travaillé dans l’industrie du logiciel pendant de nombreuses années, tandis que d’autres sont de jeunes experts en devenir. Je voulais m’assurer que le livre donne autant d’opinions différentes que possible.

Trouvez Viktor Farcic DevOps Paradox sur la boutique Packt.

Lisez le premier chapitre gratuitement sur la plateforme d’abonnement Packt.