IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

DevOps est-il un échec ? Un ingénieur logiciel de Pulumi pense que c'est le cas et propose de passer à une nouvelle approche appelée SoftOps,
Pour résoudre les problèmes que DevOps n'a pu résoudre

Le , par Bill Fassinou

52PARTAGES

21  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de micka132
Expert confirmé https://www.developpez.com
Le 05/07/2022 à 9:19
Citation Envoyé par grunk Voir le message
Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
Avec cette phrase tu résumes le phénomène. Les "ops" ne sont que les "sys admin" de la décennie précédente.
Et comme dans la décennie précédente, tu as les gars dans les petites boites qui font tout (dev/exploitation/support/qualité) et au plus tu vas dans de grosse boite au plus les activités sont dissociées. Cette mouvance "devops" est initiée par des gars de grosse structure qui voulait ressentir le coté touche à tout de la petite boite.
Mais le réel c'est que passer le fun d'apprendre des trucs avec des tutos, ça reste bien plus efficace d'avoir des "spécialistes".

Moralité: si vous voulez faire du vrai devops il faut aller dans une petite structure.
10  0 
Avatar de Eric80
Membre confirmé https://www.developpez.com
Le 02/07/2022 à 0:15
le job d un ingénieur moderne est d automatiser des tâches, cad de faire travailler des machines plutôt que des humains.
Avec DevOps, il s agit donc de supprimer les équipes opérationnelles et de demander aux développeurs de les remplacer par des outils automatisés. Sauf que ces outils sont souvent frustrants à utiliser pour les développeurs car comme dit l auteur, les outils sont d abord penser pour la partie opérationnelle et sont pas aussi mature que les IDE pour la partie développement des scripts.
Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour déployer automatiquement les composants logiciels écrits par les équipes de développeurs. Mais on demande à ces mêmes développeurs d'écrire aussi les scripts de ces pipelines, qui peuvent vite devenir très complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "coûteuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas débugger notre code si facilement.
(bais cognitif du moment: cela fait des semaines que je me prends la tête sur les "rules" dans des pipelines imbriquées sur Gitlab)
6  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 04/07/2022 à 16:45
C'est Devops qui est un échec, ou alors les baltringues qui sont censés faire appliquer cette méthode ?

T'es nul en programmation ? T'es nul en informatique ? T'es nul en management de projet ? Hop devient "Devops" après quelques semaines de formation merdique dans une école privée pourrie avec des profs nuls voir absents, ou alors lis un "tuto" sur Youtube, et devient grassement payé à ne rien foudre en travaillant seulement en vrai 1 h par jour pour pondre des rapports à la con qui servent à rien

La théorie sur ce que ça devrait être :



Le résultat sur le terrain en pratique dans les faits :



6  4 
Avatar de grunk
Modérateur https://www.developpez.com
Le 04/07/2022 à 21:36
Citation Envoyé par Eric80 Voir le message
le job d un ingénieur moderne est d automatiser des tâches, cad de faire travailler des machines plutôt que des humains.
Avec DevOps, il s agit donc de supprimer les équipes opérationnelles et de demander aux développeurs de les remplacer par des outils automatisés. Sauf que ces outils sont souvent frustrants à utiliser pour les développeurs car comme dit l auteur, les outils sont d abord penser pour la partie opérationnelle et sont pas aussi mature que les IDE pour la partie développement des scripts.
Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour déployer automatiquement les composants logiciels écrits par les équipes de développeurs. Mais on demande à ces mêmes développeurs d'écrire aussi les scripts de ces pipelines, qui peuvent vite devenir très complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "coûteuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas débugger notre code si facilement.
(bais cognitif du moment: cela fait des semaines que je me prends la tête sur les "rules" dans des pipelines imbriquées sur Gitlab)
Rien ne t'empêche d'écrire un yaml ultra minimal qui va ensuite aller exécuter des scripts écrits dans le langage que tu veux.

Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
3  1 
Avatar de smarties
Membre chevronné https://www.developpez.com
Le 14/07/2022 à 10:56
Citation Envoyé par TJ1985 Voir le message
Problèmes de riches. "De mon temps", même dans des structures importantes, un développeur était responsable de son produit de a..z. Accessoirement, c'étaient les développeurs internes qui développaient l'environnement d'exploitation et l'environnement de développement, afin d'offrir une gestion de sources et de versions homogènes, une gestion multi-plateformes des mises en production, etc.
Ça, c'était dès 1990. Ensuite, on a voulu des spécialistes, car un spécialiste, c'est spécialisé et le "chef de projet consultant" aura toujours beau jeu de le renvoyer à sa spécialité lorsque lui-même sera menacé d'avoir démontré son inutilité.
La situation a commencé à sérieusement se dégrader lorsque les méthodes dites agiles sont apparues. L'aspect sectaire et messianique des séances était frappant, leur inefficacité aussi. Mais comme on avait payé très cher le super consultant venu mettre tout ça en place, il n'était pas question de revenir en arrière. Alors on a engagé, car c'est bien connu : Quand un projet prend du retard, doublez les effectifs, ça ira mieux (je plaisante).
Bref. J'ai l'impression qu'aujourd'hui beaucoup de gens dépensent une énergie folle à faire une informatique qui ne soit plus de l'informatique mais de la gestion administrative, tout en s'affublant de titres inflationnistes.
Mais dans le fond, si vous voulez livrer quelque chose qui facilite la vie de votre client, un compilateur (multi-plateformes), un SGBDR, de bonnes librairies, du temps, un peu de talent valent beaucoup mieux qu'une équipe de fashionistas déversant leur glose récemment apprise en prenant l'air d'avoir inventé la poudre qui pète deux fois.
Dans les années 90 il n'y avait pas autant d'outils qu'aujourd'hui et d'environnements cloud. De plus on voit ce que ça donne le code legacy :
- souvent peu de documentation
- les personnes qui les ont développés sont parties
- chacun programmait à sa façon
- parfois obliger de coder des fonctionnalités qui sont devenues standards dans les autres langages/frameworks
- peu de tests

Quand les outils de gestions de version sont arrivés cela a apporté un confort et de nouvelles règles.
Je trouve que ça s'est complexifié quand les solutions cloud sont arrivée : avant on installait un serveur de A à Z mais maintenant on doit apprendre un nouvel environnement à chaque fois que l'on change d’hébergeur cloud.
Avant on avait des petits scripts pour la compilation et le déploiement (ou ce dernier point était fait manuellement) mais maintenant on a intégrer des outils d'analyse de code, des automatisation de tests, des règles pour les pull requests donc de nouveaux outils à connaître.
Enfin, on a des délais courts pour le développement donc il est plus facile de déléguer à des spécialistes plutôt que de passer plusieurs jours pour automatiser le déploiement ou autre.
2  0 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 08/07/2022 à 8:25
Citation Envoyé par redcurve Voir le message
Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace à Powershell core https://github.com/powershell/powershell .
Je suis heureux de pas être le seul pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine
1  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 08/07/2022 à 9:24
Citation Envoyé par Astraya Voir le message
Je suis heureux de pas être le seul pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine
Franchemen je n'ai pas touché Bash depuis 3 ans et je dois dire que ça ne me manque pas
1  0 
Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 13/07/2022 à 12:16
Mon point de vue sur DEVOPS c'était surtout de "professionnaliser" ce qui tourne autour du dev sans être du dev pur. En effet, le focus étant souvent mis sur le dev pur que le reste, le reste est mal maîtrisé au sens gestion, mal budgété, et en plus mal maîtrisé techniquement par les développeur, résultant plus souvent dans des résultats relativement "amateur".

Car le fait est que la plupart des développeurs peuvent écrire quelques script d'auto déploiement qui marcherons a peu près. Mais pour avoir un truc nickel, surtout dans le cas d'un client lourd par exemple, il y a une marche qui distingue bien un truc plus "amateur" qu'un truc "pro" fait par les gens plus du système généralement.

Dans les exemples :
  • Mis à jour automatiques des applications, mais aussi upgrade des composant de serveur/bdd.
  • Regénération des certificats SSL nécessaires pour avoir une plateforme validation qu'on teste en HTTPS.
  • Gestion des comptes utilisateurs, de l'AD, des trucs SSO (kerberos, SAML, CAS, ,...),...
  • Pipelines CI (bon j'ai pas chez moi ça )
  • ...


Quand on voit ça, j'ai aucun doute qu'une bonne partie peuvent ce dire "bon je vais galérer mais ça va globalement passer", ben oui, sauf que régulièrement y'a quand même un truc qui pète et le temps de trouvé tu prend deux jours.
1  0 
Avatar de smarties
Membre chevronné https://www.developpez.com
Le 05/07/2022 à 11:40
Citation Envoyé par grunk Voir le message
Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
C'est en effet ce qui arrive quand on embauche des développeurs sur du DevOps.
En tant que développeur, quand je vois la stack technique sur la partie dev (souvent back-end avec la connaissance du front ) 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.
Personnellement, je me contente au quotidien de :
- 1-2 langages de programmation avec 1-2 framework par langage
- docker pour la conteneurisation et effectuer des tests
- un serveur Linux et Ansible pour le déploiement de la solution en production
- nginx pour configurer le serveur web

La partie CI/CD je passerais du temps si je dois mettre ça en place
0  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 05/07/2022 à 13:12
Citation Envoyé par grunk Voir le message
Rien ne t'empêche d'écrire un yaml ultra minimal qui va ensuite aller exécuter des scripts écrits dans le langage que tu veux.

Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace à Powershell core https://github.com/powershell/powershell .
0  0