Qu'est-ce que DevOps ?

Une brève histoire du temps

Pour comprendre DevOps, nous devons voyager dans le temps jusqu'à l'époque où il n'y avait que des programmeurs.

Comme le Tao nous l'enseigne :

Les programmeurs d'autrefois étaient mystérieux et profonds. Nous ne pouvons pas sonder leurs pensées, donc tout ce que nous faisons est de décrire leur apparence :

• Conscient, comme un renard traversant l'eau
• Alerte, comme un général sur le champ de bataille
• Gentil, comme une hôtesse qui accueille ses invités
• Simple, comme des blocs de bois non sculptés
• Opaque, comme des piscines noires dans des grottes sombres

Le programmeur a donné naissance au langage machine. Le langage machine a donné naissance à l'assembleur. L'assembleur a donné naissance au compilateur. Il existe maintenant des milliers de langues. Chaque langue a son but, aussi humble soit-il. Chaque langue exprime le Yin et le Yang du logiciel. Chaque langue a sa place au sein du logiciel.

À l'époque, les bureaux de développement de logiciels étaient principalement appelés laboratoires et les programmeurs étaient des scientifiques. Afin de créer une bonne application, les programmeurs devaient bien comprendre le problème que l'application résolvait. Ils devaient savoir où l'application sera utilisée et quel type de système l'exécutera. Essentiellement, les programmeurs savaient tout sur leur application, de la spécification au développement, en passant par le déploiement et le support.

Et puis la nature humaine est intervenue et nous avons commencé à en demander plus. Plus de vitesse, plus de fonctionnalités, plus d'utilisateurs, plus de tout.

Étant des créatures modestes, humbles et pacifiques, les programmeurs avaient très peu de chance de survivre à une telle explosion d'utilisateurs nécessiteux qui en demandaient toujours plus. La meilleure chance de l'emporter était de commencer à évoluer dans des directions différentes et de créer des castes. Bientôt, les programmeurs ont disparu en tant qu'ancêtres de nouvelles races appelées développeurs, ingénieurs logiciels, administrateurs réseau, développeurs de bases de données, développeurs Web, architectes système, ingénieurs QA et bien d'autres. Évoluer rapidement et s'adapter aux défis du monde extérieur sont devenus partie intégrante de leur ADN. Une nouvelle caste pourrait évoluer en quelques semaines. Les développeurs Web sont devenus des développeurs back-end, des développeurs front-end, des développeurs PHP, des développeurs Ruby, des développeurs Angular… tout allait en enfer.

Bientôt, ils ont tous oublié qu'ils venaient du même père, un programmeur. Un scientifique simple et pacifique qui voulait juste rendre le monde meilleur. Ils ont commencé à se battre, affirmant que chacun d'eux est un véritable descendant de "The Programmer" et que leur sang est plus pur que les autres.

Au fil du temps, ils ont réduit leur interaction au minimum et ne se parlaient que lorsque cela était vraiment nécessaire. Ils ont cessé de célébrer le succès des membres de leur famille éloignée et ont même cessé d'envoyer une carte postale de temps en temps.

S'ils ne cherchaient que leurs sentiments, ils découvriraient que l'étincelle du Programmeur était dans leur cœur, attendant de briller et d'apporter la paix dans la galaxie.

Dans leur course égoïste et égocentrique à la conquête du monde, les descendants de programmeurs ont oublié le but même de leur travail : résoudre les problèmes de leurs clients. Les clients ont commencé à ressentir la douleur d'un tel comportement alors que les projets étaient retardés, trop chers ou même échouaient.

De temps en temps, une étoile brillante brillait et quelqu'un trouvait l'inspiration pour essayer de faire la paix entre les Descendants. Ils ont inventé Waterfall. C'était une idée brillante, car elle utilisait le fait que différents groupes de développeurs ne communiquaient que lorsque cela était nécessaire. Lorsqu'un groupe a terminé sa partie du travail, il a communiqué avec le groupe suivant pour envoyer le travail tout au long du processus et n'a jamais regardé en arrière.

Cela a fonctionné pendant un certain temps, mais comme d'habitude, les humains (clients) en voulaient encore plus. Ils voulaient participer plus activement à l'ensemble du processus de création d'un logiciel, donner leur avis plus souvent et demander des modifications même lorsqu'il était trop tard.

Les projets logiciels sont devenus si sujets à l'échec qu'ils ont été acceptés comme une norme de l'industrie. Les statistiques ont montré que plus de 50 % des projets échouaient, et il semble qu'il n'y avait rien à faire à ce sujet (ZDNet, CNet)

Chaque génération comptait quelques individus ouverts d'esprit qui savaient que tous ces groupes de développeurs devaient trouver un moyen de travailler ensemble, de communiquer et d'être flexibles pour s'assurer que leurs clients recevraient la meilleure solution possible. On trouve des traces de ces tentatives dès 1957, par des collègues du grand John Von Neumann. Cependant, nous avons dû attendre le début de 2001 pour commencer la révolution, quand une sale douzaine a créé un Manifeste Agile.

Le Manifeste Agile repose sur douze principes :

1. Satisfaction du client grâce à la livraison rapide et continue de logiciels de valeur
2. Accueillir les exigences changeantes, même en fin de développement
3. Le logiciel de travail est livré fréquemment (semaines plutôt que mois)
4. Coopération étroite et quotidienne entre les hommes d'affaires et les développeurs
5. Les projets sont construits autour d'individus motivés, à qui il faut faire confiance
6. La conversation en face à face est la meilleure forme de communication (colocation)
7. Le logiciel de travail est la principale mesure de progrès
8. Un développement durable, capable de maintenir un rythme constant
9. Une attention continue à l'excellence technique et à la bonne conception
10. La simplicité - l'art de maximiser la quantité de travail non fait - est essentielle
11. Des équipes auto-organisées
12. Adaptation régulière aux circonstances changeantes

Le manifeste Agile a été la première grande étape pour ramener la paix dans la Galaxie et rétablir l'équilibre dans la Force. Pour la première fois depuis très longtemps, la mise en relation de tous les acteurs du processus de développement logiciel s'est faite de manière culturelle et « humaine », autant que procédurale et mécanisée. Les gens ont commencé à se parler, à se rencontrer régulièrement et à échanger des idées et des commentaires tout le temps. Ils ont réalisé qu'ils avaient beaucoup plus en commun qu'ils ne le pensaient, et les clients sont devenus une partie de l'équipe, pas seulement un facteur externe censé envoyer de l'argent et ne poser aucune question.

Il restait encore quelques obstacles à surmonter, mais l'avenir semblait plus brillant que jamais. Être agile signifie être ouvert et prêt à s'adapter aux changements constants. Cependant, avec trop de changements, il est difficile de rester concentré sur l'objectif ultime et la livraison. Et c'est ainsi que le développement logiciel Lean est né.

Accros au LSD (jeu de mots) et risquant d'être exilés et exclus, certains des descendants ont cherché des solutions en dehors de leur caste et de l'industrie du logiciel. Ils ont trouvé le salut dans les travaux d'un grand constructeur automobile. Toyota Production System était étonnant dans sa simplicité et il était si évident que sa fabrication au plus juste peut être facilement appliquée au développement de logiciels.

Il existe 7 principes de Lean :

1. Éliminer les déchets
2. Construire la qualité dans
3. Créer des connaissances (Amplifier l'apprentissage)
4. Différer l'engagement (décider le plus tard possible)
5. Livrez aussi vite que possible
6. Respecter les gens (responsabiliser l'équipe)
7. Optimiser l'ensemble

Ajoutés à Agile, les principes Lean ont soutenu la mentalité et l'accent mis sur les bonnes choses, tout en étant flexible tout au long du processus.

Une fois Agile et Lean adoptés par les équipes de développement de logiciels, il n'a fallu qu'une étape de plus pour appliquer l'ensemble des principes à l'informatique dans son ensemble - ce qui nous a finalement amenés au DevOps !

Entrez DevOps - Autoroute à trois voies

La vision à l'ancienne des équipes de développement de logiciels comprenait des analystes commerciaux, des architectes système, des développeurs front-end, des développeurs back-end, des testeurs, etc. L'optimisation du processus de développement logiciel, y compris les principes agiles et lean, était principalement axée sur ces derniers. Une fois que l'application était « prête pour la production », elle était envoyée aux « Opérations », y compris les ingénieurs système, les ingénieurs de publication, les DBA, les ingénieurs réseau, les professionnels de la sécurité, etc. La suppression du grand mur entre Dev et Ops est le principal moteur de DevOps .

DevOps est le résultat de la mise en œuvre des principes Lean sur l'ensemble du flux de valeur informatique. Le flux de valeur informatique étend le développement à la production, combinant tous les "parents éloignés" qui descendent du programmeur d'origine.

La meilleure explication des solutions DevOps est donnée par Gene Kim, et si vous n'avez pas lu The Phoenix Project, je vous suggère de prendre un peu de temps et de le faire.

Vous ne devez pas embaucher un ingénieur DevOps et DevOps ne doit pas être un nouveau département de votre informatique. DevOps est une culture, un état d'esprit et fait partie de l'informatique dans son ensemble. Aucun outil ne fera de votre informatique une organisation DevOps , et aucun niveau d'automatisation ne permettra à vos équipes d'offrir une valeur maximale à vos clients.

DevOps est généralement appelé méthode à trois voies, mais je les vois comme trois voies de la même autoroute. Vous commencez dans la première voie, puis vous accélérez et passez à la voie deux, et finalement vous accélérez dans la troisième voie.

• Voie 1 - La performance du système dans son ensemble est le point focal principal et elle est mise en avant par rapport à la performance de tout élément individuel du système

• Voie deux - Assurez-vous qu'il y a une boucle de rétroaction constante envoyée en amont, et non ignorée

• Voie 3 - Nourrir les expériences, l'amélioration constante et échouer rapidement

Lane 1 - Se mettre à niveau

Comprendre l'importance de l'ensemble du système et hiérarchiser correctement les éléments de travail est la première chose qu'une organisation informatique doit apprendre lors de l'adoption des principes DevOps. Personne dans le flux de valeur informatique n'est autorisé à créer un goulot d'étranglement et à réduire le flux de travail.

Assurer un flux de travail ininterrompu est l'objectif ultime pour toutes les personnes impliquées dans le processus. Quel que soit le rôle d'une personne ou d'une équipe, il est impératif qu'elle cherche à acquérir une compréhension approfondie du système. Adopter cette façon de penser a un impact direct sur la qualité, car les défauts ne sont jamais renvoyés dans le flux car ils provoqueraient des goulots d'étranglement.

S'assurer que le travail ne stagne pas n'est pas suffisant. Une organisation productive doit toujours chercher à augmenter le flux. Il existe de nombreuses méthodologies pour augmenter le débit. Vous pouvez trouver une solution dans la Théorie des Contraintes, Six Sigma, Lean ou Toyota Production System. N'hésitez pas à choisir l'un d'entre eux, à créer le vôtre ou à les combiner.

Les principes DevOps ne se soucient pas de l'équipe à laquelle vous appartenez, si vous êtes un architecte système, un DBA, un QA ou un administrateur réseau. Les mêmes règles s'appliquent à tout le monde, et chacun doit suivre deux principes simples :

• Gardez le flux du système ininterrompu
• Augmentez et optimisez le flux de travail à tout moment

Voie 2 - Équipez-vous

Le flux système ininterrompu est unidirectionnel et devrait aller du développement aux opérations. Dans un monde idéal, cela signifie que les logiciels sont créés rapidement avec une haute qualité, déployés en production et offrent de la valeur aux clients.

Cependant, DevOps n'est pas une utopie, et si la livraison unidirectionnelle était possible, la méthode en cascade serait suffisante. L'évaluation des livrables et la communication en amont sont très importantes pour assurer la qualité. Le premier canal de communication "en amont" qui doit être mis en œuvre est Ops to Dev.

Se donner un high-five est facile, mais demander des commentaires et donner des commentaires est le moyen de voir la vraie image. Il est impératif que chaque petit pas en aval soit suivi d'une confirmation instantanée en amont.

Peu importe comment vous établissez la boucle de rétroaction. Vous pouvez inviter des développeurs à rejoindre les réunions de l'équipe d'assistance ou faire participer l'administrateur réseau à la planification hebdomadaire des sprints. Tant que vos commentaires sont en place et que les commentaires sont récupérés et traités, votre organisation accélère sur l'autoroute DevOps.

Voie trois - Warp 10

La voie rapide DevOps n'est pas pour les faibles d'esprit. Pour accéder à la voie rapide DevOps, votre organisation doit être suffisamment mature. Il s'agit de prendre des risques et d'apprendre de l'échec, d'expérimenter continuellement et d'accepter que la répétition et la pratique sont les conditions préalables à la maîtrise. Très souvent, vous entendrez le terme Kata, et c'est pour une raison. L'entraînement continu et la répétition mènent à la maîtrise car cela transforme les mouvements complexes en une routine.

Mais avant de commencer à combiner des mouvements, il est impératif que vous maîtrisiez d'abord chaque étape individuelle.

« Ce qui convient au maître ne convient pas au novice. Vous devez comprendre Tao avant de transcender la structure.

DevOps Third Way/Fast Lane comprend l'allocation quotidienne de temps pour l'expérimentation continue, la récompense constante de l'équipe pour la prise de risques et l'introduction de défauts dans le système pour augmenter la résilience.

Afin de vous assurer que votre organisation n'implosera pas lors de la mise en œuvre de ce type de mesures, vous devez créer des boucles de rétroaction fréquentes entre toutes les équipes, tout en vous assurant que tous les goulots d'étranglement sont clairs et que le flux du système est ininterrompu.

La mise en œuvre de ces mesures rend votre organisation alerte en tout temps et capable de répondre aux défis rapidement et efficacement.

Résumé - Liste de contrôle de l'organisation DevOps

Voici une liste de contrôle que vous pouvez utiliser pour valider la façon dont DevOps a activé votre organisation informatique. N'hésitez pas à commenter l'article et à ajouter vos propres points.

• Il n'y a pas de mur entre l'équipe de développement et l'équipe d'exploitation. Les deux font partie du même processus
• Le travail qui est envoyé d'une équipe à une autre est toujours vérifié et de qualité supérieure
• Il n'y a pas d'"empilement" de travail et tous les goulots d'étranglement sont traités
• L'équipe de développement n'utilise pas le temps des opérations pour ses activités, car le déploiement et la maintenance font partie de la même boîte de temps
• L'équipe de développement ne livre pas le code pour le déploiement à 17h le vendredi, laissant les opérations nettoyer leur travail pendant le week-end
• Les environnements de développement sont standardisés et les opérations peuvent facilement les reproduire et les mettre à l'échelle en production
• L'équipe de développement peut fournir de nouvelles versions lorsqu'elle le juge approprié et les opérations peuvent facilement les déployer en production
• Il existe des lignes de communication claires entre toutes les équipes
• Tous les membres de l'équipe ont le temps d'expérimenter et de travailler à l'amélioration du système
• Les défauts sont introduits (ou simulés) et traités régulièrement dans le système. Les leçons tirées de chaque expérience sont documentées et partagées avec toutes les personnes concernées. La gestion des incidents est une routine et est généralement gérée de manière connue

Conclusion

L'utilisation d' outils DevOps modernes tels que Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS, etc. ne signifie pas que vous appliquez les principes DevOps. DevOps est une façon de penser. Nous faisons tous partie du même processus, nous partageons le même temps et apportons de la valeur ensemble. Chaque personne qui participe au processus de livraison du logiciel peut accélérer ou ralentir l'ensemble du système. Un bogue créé pendant le développement peut faire tomber le système, ainsi qu'une mauvaise configuration du pare-feu.

Toutes les personnes font partie de DevOps, et une fois que votre organisation comprend cela, les outils et la pile technologique qui vous aideront à la gérer apparaîtront comme par magie.