De nos jours, nous avons beaucoup de mal à définir le DevOps car le problème qu’il résout initialement a disparu depuis longtemps.  Pour certaines entreprises récentes, le problème n’a jamais réellement existé ! Ils font tout correctement, mais au lieu de cela, le paysage du génie logiciel a évolué si rapidement que le vide a été comblé par l'ingénierie des outils et du cloud.  Nous sommes loin de l’époque originelle du DevOps et de son changement de culture visant à briser les silos entre Dev et Ops.  Les silos de développement et d’opérations  En 2008, lorsque  En pensant pour la première fois au DevOps, il s'intéressait à la collaboration inefficace entre le développement et les opérations dans un contexte où la gestion de projet venait de passer de la cascade à l'Agile.   Patrick Dubois  Les équipes opérationnelles de l’époque géraient tout, depuis les mises à jour du réseau, des serveurs, des machines virtuelles, du système d’exploitation et des logiciels. Cela masquait effectivement de nombreuses opérations manuelles. Tout n'était pas manuel, mais c'était avant que Puppet, Chef et Ansible – ou même Terraform n'existent.  La gestion des versions de serveurs et de logiciels n'était pas simple et nécessitait beaucoup d'expertise. Quelque chose qui empêcherait une livraison rapide et fiable des nouvelles versions logicielles.   Le cloud, premier signe de la disparition des silos  AWS, né en 2006, a été le premier grand fournisseur de cloud. DevOps a été inventé en 2008 et n'était pas destiné à résoudre un problème de gestion du cloud, mais les véritables silos entre le fonctionnement de l'infrastructure sur site. C’est la racine de la confusion sur ce qu’est le DevOps. Deux changements majeurs dans le paysage du génie logiciel ont commencé à peu près au même moment.  En matière de cloud computing, nous utilisons trois modèles principaux : Software as a Service (SaaS), Platform as a Service (PaaS) et Infrastructure as a Service (IaaS). Parce que nous utilisons ces constructions de haut niveau, l’OPS (administration système) a presque disparu. C'est comme si le problème culturel initial identifié par les pères du DevOps n'existait plus.  Chaque modèle offre différents niveaux de contrôle, de flexibilité et de gestion de l'infrastructure sous-jacente, et très peu d'entreprises maintiendraient une infrastructure sur site.  Ainsi, alors que le mouvement DevOps tentait de   , l'infrastructure cloud atténuait déjà une partie du problème en   .  résoudre les problèmes de « silot » entre Dev et Ops rendant Ops obsolète  Pas d'opérations, pas de silos  Les mots clés du DevOps sont « décaler vers la gauche » et « vous le construisez, vous l'exécutez », ce qui ne peut que conduire au transfert de ce qui était une ou plusieurs tâches Ops vers les développeurs. Le cloud a réduit le besoin d'administrateurs système (Ops) en proposant le modèle IaaS, réduisant ainsi les efforts des développeurs pour gérer et déployer eux-mêmes les applications.  Nous pouvons le reformuler pour que ça sonne mieux ! Les opérations responsabilisaient les développeurs en proposant des outils pour simplifier l'intégration et le déploiement de logiciels, réduisant ainsi le travail lourd requis par les équipes opérationnelles pour maintenir l'infrastructure. En conséquence, nous nous sommes retrouvés dans une situation où nous n'avions pas besoin d'administration système (Ops).   Cependant, nous avons besoin de quelqu’un pour maintenir ces « outils permettant de simplifier l’intégration et le déploiement de logiciels ».  Ce nouveau rôle émergent n'a pas encore de nom puisqu'il vous a été présenté par les anciens Ops, qui l'ont rebaptisé « DevOps Guys ». Appelons-le ingénieur DevOps. Quelqu’un l’a probablement dit à un moment donné, et c’est resté.   DevOps s'est redéfini  DevOps n’a jamais été une question d’outils ; c'était une question de culture. L’idée est que l’ingénierie logicielle peut elle aussi devenir plus « Lean » et que la livraison de logiciels peut se faire juste à temps. Le problème initial du DevOps a peut-être disparu depuis longtemps, mais il a donné naissance à l'idée la plus importante de l'ingénierie logicielle : la livraison continue.  Je soutiens depuis longtemps ceux qui prétendent que DevOps n'est pas un rôle ou une équipe, et si vous l'appelez ainsi, vous vous trompez. Plus tard, j’ai réalisé que les choses étaient plus complexes. Nous avons créé de manière incongrue un rôle, « le(s) gars qui maintiennent les outils pour simplifier l'intégration et le déploiement des logiciels », mais nous n'avions pas de nom pour cela.  Quand on y réfléchit, avez-vous vraiment besoin « du ou des gars qui maintiennent les outils pour simplifier l'intégration et le déploiement des logiciels » si tout était une offre cloud ? Entièrement géré ? Fonctionne d'un simple clic ?  C’est le rêve de la plupart des fournisseurs de Cloud et des nombreux produits DevOps SaaS (pensez à GitLab, par exemple). La vérité n'est pas si simple. Alors qu’en théorie, les choses auraient pu être simples, et les tâches Ops auraient pu être automatisées, le service entièrement géré, etc. En réalité, nous avons créé un monstre.   En conséquence, le défi pour la plupart des équipes d'exploitation/infrastructure (alias Ops) consiste à naviguer dans la carte d'innombrables outils et services, à comprendre, déployer et connecter ces outils dans une infrastructure et des outils cohérents que les développeurs peuvent utiliser.  DevOps bloqué est ce mot clé à la mode, facile à dériver : DevSecOps, FinOps, GitOps, MlOps, etc.  Mais si vous le remarquez, le parfum qui reste est toujours Ops. Le plus drôle, c'est que chaque approche vise à supprimer les Ops des équations. The Ops, alias « le(s) gars qui se connectent au système et font des choses pour le faire fonctionner ».  TL;DR  Le problème initial que DevOps cherchait à résoudre n’existe peut-être plus en raison de l’essor de l’infrastructure cloud. Cependant, DevOps a donné naissance à l’idée importante de livraison continue et a entraîné un changement de culture dans le génie logiciel.  Même si le terme « DevOps » est peut-être resté un mot à la mode, il a conduit au développement de nouvelles approches telles que DevSecOps, FinOps et GitOps, qui visent toutes à supprimer le besoin de tâches opérationnelles traditionnelles.  En fin de compte, le paysage du DevOps et de l’infrastructure cloud évolue constamment, et il est difficile de rester à jour et de sélectionner les bons outils. Ironiquement, DevOps signifiait initialement une collaboration entre Dev et Ops, mais cela a évolué vers l'exclusion des Ops de l'équation.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This piece was written for humor or satire and may include nonfactual statements, stories, or anecdotes.

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Le paradoxe DevOps : s'éloigner des opérations

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps