Lee Briggs, ingénieur logiciel chez Pulumi, une société d'infrastructure en tant que code (infrastructure-as-code - IaC), a récemment publié un avis personnel selon lequel l'approche DevOps est un échec. L'approche DevOps vise à supprimer les frictions entre les développeurs et les opérations dans toutes les étapes de la création d'un logiciel, depuis le développement, l'intégration, les tests, la livraison jusqu'au déploiement, l'exploitation et la maintenance des infrastructures. Mais Briggs pense que DevOps n'a pas réussi cette mission et ajoute que la plupart des outils commercialisés sous le nom de "DevOps tooling" sont axés sur les opérations.DevOps est un ensemble de pratiques qui met l’accent sur la collaboration et la communication entre les développeurs de logiciels et les professionnels des opérations informatiques, en automatisant le processus de livraison de logiciels et les changements d’infrastructure. L'objectif est de créer une culture et un environnement dans lesquels la conception, les tests et la diffusion de logiciels peuvent être réalisés rapidement, fréquemment et efficacement. Selon ses partisans, DevOps n’est pas seulement une méthodologie, c’est une véritable philosophie de travail. Cependant, d'autres pensent que DevOps n'a pas su tenir ses promesses.
Lee Briggs est de ceux qui pensent que DevOps a échoué. « En fin de compte, mon évaluation de DevOps en 2022 est la suivante : DevOps, ce sont des gens du côté des opérations qui essaient de convaincre les développeurs de faire les choses à leur manière. La quasi-totalité de l'outillage commercialisé sous le nom de "DevOps tooling" est axée sur les opérations. Si vous parcourez /r/devops, vous verrez des messages successifs de personnes parlant d'opérations et d'outils opérationnels. Si vous regardez la description de poste d'un ingénieur DevOps, elle ressemble beaucoup au rôle d'un administrateur système de 2013 », déclare Briggs.
Selon lui, si DevOps était censé changer la culture générale, il ne peut pas être considéré comme un mouvement réussi. L'ingénieur va plus loin en comparant DevOps à une course de dupes et appelle à un changement. « Les personnes du côté des opérations diront volontiers "Eh bien, nous essayons !", mais ce qu'ils veulent dire par là, c'est qu'ils essaient d'être un joueur de flûte pour les considérations opérationnelles. Ce n'est pas une voie à double sens. Il est bon de rappeler qu'en tant que personne chargée des opérations, nous sommes généralement en minorité d'au moins 5/1 dans toute organisation d'ingénierie donnée », a-t-il déclaré.
« Essayer de convaincre le moindre développeur de faire les choses "à la manière des opérations" et "d'utiliser les outils des opérations" est en fin de compte une course de dupes. Nous avons besoin d'un changement. En fin de compte, je pense qu'il est trop tard pour sauver le terme "DevOps". Si les gens vous vendent du DevOps, il est probablement trop tard. Ce que j'aimerais voir voir se produire à partir de maintenant, c'est un changement fondamental dans la façon dont les gens de DevOps pensent dans leur rôle quotidien », a-t-il ajouté. Briggs poursuit en disant que les opérations en arrivent parfois à oublier leur rôle principal.
« Il est parfois difficile de s'en souvenir, mais, en tant que personnes axées sur les opérations, notre rôle est de permettre et d'aider les développeurs à mettre les fonctionnalités dans les mains des clients (ou tout autre objectif commercial qu'ils pourraient avoir). La création d'un chemin de moindre résistance est une partie essentielle de la création et du maintien de la vitesse des développeurs qui livrent des produits et des fonctionnalités, et le fait que les développeurs apprennent et maintiennent toutes les pratiques d'exploitation n'est tout simplement pas réalisable », rappelle-t-il.
Eu égard à tout ce qui précède, Briggs propose de changer d'approche et de passer à ce qu'il appelle : SoftOps (Operations for Software Developers). « SoftOps est l'idée que nous allons construire des pratiques opérationnelles centrées sur l'amélioration de la vie des développeurs. Nous n'allons pas leur dire ce qu'ils doivent faire, nous allons leur demander ce qu'ils veulent faire, d'un point de vue opérationnel, puis nous allons leur faciliter la tâche autant que possible », a-t-il déclaré. Selon lui, l'époque où on lisait des pages de manuel de 48 pages et où l'on disait à son chef de projet que l'on ne respectait pas les délais des sprints est révolue.
Briggs explique que SoftOps est l'idée que vous allez mettre les développeurs en premier, en tant que client principal. Pour lui, l'élaboration de pratiques opérationnelles qui s'adressent à un monde de développeurs devrait (en théorie) amener les développeurs à la table des négociations afin de travailler en collaboration. « Peut-être que si nous nous concentrons uniquement sur cet objectif, nous finirons par résoudre les problèmes que DevOps a essayé de résoudre depuis 2009 », a-t-il déclaré. Briggs n'est pas allé plus loin dans les explications sur la nouvelle méthodologie qu'il met en avant, mais les avis sur sa proposition sont mitigés.
En outre, certains mettent en avant une autre approche appelée NoOps, et qui est présentée comme une amélioration du DevOps. NoOps est une évolution de la méthode DevOps visant à éliminer la nécessité d'une équipe d'exploitation distincte en automatisant entièrement l'infrastructure informatique. Dans cette approche, toutes les tâches d'approvisionnement, de maintenance et autres sont automatisées à un niveau tel qu'aucune intervention manuelle n'est nécessaire. NoOps et DevOps sont similaires dans un sens, car ils reposent tous deux sur l'automatisation pour rationaliser le développement et le déploiement de logiciels.
Cependant, DevOps vise à créer un environnement plus collaboratif tout en utilisant l'automatisation pour simplifier le processus de développement. D'autre part, NoOps vise à éliminer toute préoccupation opérationnelle du processus de développement. Dans un environnement entièrement automatisé, les développeurs peuvent utiliser directement ces outils et processus, même sans connaître leurs mécanismes sous-jacents. Par ailleurs, une autre proposition est l'ITOps. Dans ce cas, toute tâche informatique peut relever de l'ITOps, quel que soit le domaine d'activité. ITOps peut s'appliquer à pratiquement tous les domaines.
ITOps (ou TecOps) est l'abréviation de IT Operations. Dans sa forme la plus fondamentale, l'ITOps est le processus de fourniture et de maintenance de tous les services, applications, technologies et infrastructures nécessaires au fonctionnement d'un produit ou d'un service basé sur les technologies de l'information. Par conséquent, ITOps considère le développement de logiciels et la gestion de l'infrastructure informatique comme une entité unifiée faisant partie du même processus. La principale différence d'ITOps est la façon dont il gère la livraison et la maintenance.
Les ITOps sont davantage axées sur la stabilité et la fiabilité à long terme, avec un soutien limité aux flux de travail agiles et rapides. En général, l'agilité et la rapidité ne sont pas du tout les préoccupations principales des ITOps. Ainsi, les ITOps sembleront inflexibles avec des flux de travail rigides. Cette approche est également orientée vers la gestion de l'infrastructure physique avec des produits logiciels hautement testés et basés sur des versions, où la fiabilité et la stabilité sont des facteurs clés. Selon les critiques, ce manque de souplesse est également le principal inconvénient des ITOps.
Cependant, les analystes estiment qu'il peut constituer un excellent choix pour les développements de logiciels monolithiques et à évolution lente, comme dans le secteur des services financiers. En revanche, ils ajoutent que l'approche ITOps devient obsolète dans les développements logiciels qui évoluent rapidement. Et comme les développements logiciels modernes entrent dans cette catégorie, ITOps n'est pas un candidat approprié pour de tels environnements.
Source : Billet de blogue
Et vous ?
Quel est votre avis sur le sujet ? Que pensez-vous de l'avis de Lee Briggs sur l'approche DevOps ? Selon vous, la méthodologie DevOps est-elle une réussite ou un échec ? Pourquoi ? Que pensez-vous de l'approche SoftOps proposée par Briggs ? En quoi est-elle meilleure que DevOps ? Que pensez-vous des autres alternatives au DevOps, telles que l'approche ITOps ou NoOps ?Voir aussi
Les conteneurs du DevOps présentent-ils des risques pour la sécurité de vos données ? Oui, selon une étude Plus de 60 % des équipes DevOps sacrifient la sécurité des conteneurs au profit de la vitesse, selon un rapport de NeuVector France : le poste administrateur système DevOps officiellement créé, et classé au niveau 6 du cadre national des certifications professionnelles 
Envoyé par grunk
pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine 
) et qu'en plus ça demande des compétences CI/CD et Cloud dans les offres d'emploi, ce n'est pas étonnant que la production soit mal configurée. Certe, on a des connaissances et des compétences sur la partie DevOps mais on deviendra rarement un expert DevOps si on n'est pas à plein temps dessus.