Oraison funèbre pour le DevOps

Concept et histoire du DevOps

• Le DevOps est un concept introduit vers 2007, avec pour objectif d’effacer la séparation entre les personnes qui gèrent le matériel et celles qui écrivent les logiciels
• À ses débuts, il s’agissait d’une tentative d’imiter les procédures et les idées de la NASA pour renforcer la sécurité des déploiements de code
• À l’époque, le processus de déploiement logiciel se déroulait ainsi :
  • L’équipe de développement préparait une release du logiciel serveur, l’équipe QA la testait, puis elle était déployée chez le client
  • L’équipe d’exploitation recevait un playbook incluant les changements apportés au logiciel et la manière de réagir en cas de problème
  • Les mises à jour étaient progressivement déployées dans le data center tout en étant surveillées
  • Une date de déploiement était fixée, puis un suivi était assuré après le déploiement

Les problèmes du DevOps

• Le DevOps demandait énormément de travail manuel
• Il nécessitait une collaboration entre l’équipe de développement, l’équipe QA, les rédacteurs techniques et l’équipe d’exploitation
• Le déploiement des fonctionnalités était lent, et les mises à jour importantes étaient prioritaires
• De nombreuses organisations ont adopté le DevOps pour les raisons suivantes :
  • Il était difficile de remplacer facilement les profils techniques
  • Le recrutement était compliqué et coûteux
  • Les éditeurs SaaS réduisaient la complexité
  • Ils mettaient en avant les avantages des plateformes cloud
  • Les développeurs se plaignaient du temps nécessaire avant qu’un petit changement ne soit effectivement déployé

À quoi ressemblait réellement le DevOps

• Le DevOps visait à fusionner l’équipe de développement et l’équipe d’exploitation en une seule équipe
• L’équipe QA a été supprimée, et la période de test interne a été réduite grâce à des déploiements rapides et à des boucles de feedback
• Le DevOps est parfois confondu avec le SRE de Google, mais le SRE suit une approche plus structurée et plus rigoureuse
• Le processus réel du DevOps était le suivant :
  • Le développeur créait une branche dans git et ajoutait une fonctionnalité
  • Il ouvrait une PR, un coéquipier la relisait, puis elle était fusionnée dans main
  • Le système de CI/CD lançait le build et poussait le conteneur vers le registre
  • Le système de CD notifiait les serveurs de la nouvelle release et surveillait si le déploiement réussissait
  • Des métriques de prise en compte de la release permettaient de suivre les changements après le déploiement

Les causes de l’échec du DevOps

• Les développeurs testaient en local puis déployaient sur des serveurs Linux, ce qui introduisait de petites différences
• Comme l’équipe d’exploitation ne surveillait pas le déploiement, il était difficile de résoudre les problèmes
• Les développeurs manquaient de connaissances sur l’exploitation des systèmes
• L’introduction des conteneurs a résolu une partie de ces problèmes, mais la complexité opérationnelle restait présente

L’arrivée des conteneurs et leurs limites

• Les conteneurs ont résolu le problème du « ça marchait pourtant sur ma machine »
• Ils ont simplifié les composants de configuration des serveurs Linux
• Il restait néanmoins des problèmes
  • Exploitation (Operate) : maintenance de l’infrastructure, mises à niveau, etc., nécessitant une expertise spécialisée
  • Observation (Observe) : difficulté à mettre en place et à gérer des systèmes de monitoring complexes
  • Feedback continu : gestion insuffisante du feedback interne
  • Découverte (Discover) : manque de partage des connaissances entre les équipes
  • Planification (Plan) : difficulté à établir une planification centralisée

L’émergence du Platform Engineering

• Le Platform Engineering est apparu comme le concept succédant au DevOps : au lieu de demander aux équipes de développement de comprendre l’exploitation de la plateforme et de résoudre elles-mêmes les problèmes, cette responsabilité revient à l’équipe plateforme
• Cette approche sépare plus clairement les responsabilités entre l’équipe de développement et l’exploitation de la plateforme, ce qui clarifie la répartition des rôles, mais elle exige encore beaucoup de compétences techniques
• Les développeurs comme les équipes d’exploitation ont davantage de travail à accomplir

Conclusion

• On observe une tendance croissante à rechercher, dans le domaine de l’infrastructure, des outils simples et non dépendants d’une plateforme
• De nombreuses organisations abandonnent des technologies complexes comme Kubernetes pour revenir à des workflows plus simples
• Le Platform Engineering n’est pas une solution miracle, et les organisations doivent distinguer ce dont elles ont réellement besoin de ce qui est superflu
• Il faut conserver les avantages de l’approche DevOps tout en se recentrant sur la simplicité et la stabilité

L’avis de GN⁺

1. L’évolution du DevOps et sa situation actuelle illustrent bien les changements de tendance dans l’industrie technologique. Il est intéressant de voir comment le secteur prend conscience de l’écart entre les objectifs idéaux du départ et la réalité, puis cherche des approches plus pragmatiques

2. Le passage au Platform Engineering semble être une tentative de reconnaître les limites du DevOps et de chercher de nouvelles solutions. Mais ce n’est pas non plus une réponse parfaite, et il faudra probablement une approche sur mesure adaptée à la taille et aux caractéristiques de chaque organisation

3. Avec l’augmentation de la complexité des technologies cloud native et des architectures en microservices, on assiste à une réévaluation de la simplicité et de la stabilité. Cela suggère qu’il faut accorder encore plus d’importance à la valeur métier et à l’efficacité opérationnelle dans les choix technologiques

4. Les transformations du DevOps et du Platform Engineering soulignent l’importance de l’apprentissage continu et de l’adaptation dans le développement logiciel et l’exploitation. Les techniciens devront non seulement apprendre de nouveaux outils et de nouvelles méthodologies, mais aussi développer leur capacité à équilibrer les besoins métier et la complexité technique

5. À l’avenir, les méthodes de développement et d’exploitation logicielle devraient adopter des approches plus flexibles et contextuelles. Plutôt que de voir grandes organisations et petites startups suivre la même méthode, la tendance devrait se renforcer vers le choix de processus et d’outils optimaux selon la situation de chacun

[kaydash]

Assez souvent
les managers
pensent à tort qu’il suffit d’adopter le concept de DevOps
pour qu’une grande innovation apparaisse sans effort
— une attente erronée des vieilles entreprises
qu’elles soient grandes ou petites

[GN⁺]

Avis Hacker News

• Le point clé est de se concentrer sur build, test, deploy dans le diagramme du « devops cycle »

  • L’accent a été mis sur la vitesse, sans prendre en compte l’excellence de l’ingénierie
  • Les équipes Ops ont été licenciées et la QA a été réorganisée
  • Toutes les équipes se sont retrouvées avec une rotation d’astreinte
  • Des changements désordonnés ont été apportés au système pour des gains à court terme
  • Quelques mois plus tard, chaque modification causait des problèmes
  • Les outils DevOps étaient utiles, mais coûteux et source de frustration
  • Les nouveaux développeurs ne connaissent pas le DevOps, mais connaissent les conteneurs

• Avis fondé sur les problèmes rencontrés par les équipes DevOps

  • Il faut pouvoir ajouter de nouveaux services et gérer l’infrastructure en toute sécurité
  • Le DevOps est devenu la norme, et les tâches manuelles d’administration système ne sont plus nécessaires

• Les critiques envers Kubernetes sont mal fondées

  • Kubernetes est un excellent exemple de génie logiciel, bien maintenu et exécutable partout
  • Mieux vaut apprendre Kubernetes que d’utiliser au hasard des scripts bash

• Le DevOps consiste à supprimer les barrières pour faciliter le déploiement des logiciels

  • Les déploiements quotidiens aident à livrer un code de meilleure qualité
  • Il est important d’avoir la possibilité de ne déployer le code que lorsqu’il est prêt
  • Les releases mensuelles mettent la pression et peuvent conduire à des choix inefficaces

• Le DevOps est une philosophie, pas une méthodologie

  • Le but est d’intégrer les opérations au SDLC
  • Le cloud a rendu cela plus facile
  • L’apparition d’équipes « DevOps » a déformé la philosophie d’origine

• Le fait, pour le leadership, de « briser les silos » est presque purement formel

  • L’autorité sans responsabilité n’est pas efficace
  • Les meilleurs talents DevOps aiment se remplacer eux-mêmes par du code
  • Les outils DevOps sont matures et bien documentés
  • Un développeur qui n’apprend pas Kubernetes, c’est comme un développeur qui ne connaît pas les commandes Linux

• Si les utilisateurs peuvent servir de testeurs, il faut le faire

  • Il n’y a qu’une question économique
  • S’il y a beaucoup de clients, on les laisse tester ; s’il y en a peu, il faut tester soi-même

• Les équipes plateforme ne sont viables que dans les grandes entreprises

  • Les PME manquent de personnel DevOps et doivent absorber du stress et des risques
  • L’absence d’équipe plateforme provoque de nombreux problèmes

• Le DevOps est une philosophie, pas une méthodologie

  • L’expérience des équipes en silos prouve la nécessité du DevOps
  • Le DevOps permet aux équipes de comprendre complètement un projet et de le déployer

• Le DevOps part de bonnes intentions

  • Des boucles de feedback rapides sont essentielles à la vitesse de développement
  • Il faut trouver la solution optimale adaptée à l’organisation et au produit