Résoudre la dissonance DevOps

Par Benjamin Lallement, conseiller DevOps

 

Très peu d’histoire

 

Traditionnellement, le développement et l’exploitation d’une application étaient des activités aussi lointaines l’une de l’autre que Beethoven et Van Halen.

Le modèle “Waterfall” a longtemps dominé le cycle de vie de développement logiciel malgré le fait que son auteur, Winston W. Royce, l’avait originalement documenté comme étant défectueux et inutilisable. Cette “subtilité” n’a pas été retenue par le Département de la Défense américaine qui en a fait, son modèle de référence pour le développement logiciel. Le modèle séparait non seulement le développement et les opérations, mais attribuait séquentiellement les activités en amont et en aval du développement à des équipes distinctes. Résultat, beaucoup d’erreurs d’interprétation, de changements d’exigences non captés, d’abandons, d’attentes non satisfaites, de dépassements de coûts et de délais de livraison.

Le modèle de développement  “Agile” fit son apparition dans les années 90. Ce modèle itératif ajoute graduellement au projet logiciel, un ou plusieurs incréments fonctionnels, complets, déployables et utilisables. En général, les méthodes Agiles recommandent de petites équipes multidisciplinaires ainsi que des itérations de courte durée et d’une portée limitée. Chaque itération est suivie d’interactions avec les utilisateurs ce qui produit une rétroaction rapide, permettant d’apporter correctifs et améliorations.

Note: Une description exhaustive de ce modèle est hors de la portée de cet article. Néamoins, plusieurs ressources documentaires sont offertes sur le Web (liens pertinents en bas de page).

Cependant, le modèle Agile n’adresse que la phase de développement du cycle de vie d’un logiciel et ne fait aucune place pour la mise en service des incréments et évolutions produits. Ainsi, malgré la livraison rapide et successive d’incréments fonctionnels, les équipes opérationnelles, appliquant des méthodes non adaptées à ce modèle de développement, n’arrivaient pas à maintenir un rythme de mise en production équivalent. Ce goulot d’étranglement annulait systématiquement tous les bénéfices apportés par la transformation Agile.

Il fallait donc identifier les moyens pour synchroniser les mises en service au rythme de développement. Ce n’était pas une mince tâche à une époque où il fallait commander, configurer et mettre en ligne les serveurs nécessaires, le tout manuellement bien évidemment. Sans compter l’avènement des microservices qui requiert une indépendance de livraison (release) et de mise en service de chaque service composant une application globale. Éventuellement, la virtualisation des infrastructures ainsi que l’adaptation de l’outillage ont jeté les bases nécessaires à cette évolution.

Ces moyens techniques ont inspiré les instigateurs du mouvement DevOps à expérimenter et définir une approche et des méthodes permettant aux opérations de supporter le rythme de livraison des équipes Agiles. L’abandon des méthodes de déploiement manuelles pour les remplacer par des pipelines de déploiements automatisés, composés de blocs de microprogrammes effectuant, séquentiellement ou parallèlement, les tâches nécessaires au déploiement des services constitue le fondement incontournable d’une transformation DevOps.

Rapidement, certaines organisations ont réussi, grâce à l’automatisation de la mise en service, à déployer une dizaine de mises en production quotidienne puis une centaine et aujourd’hui, certaines grandes entreprises déploient régulièrement plus de mille mises en production quotidiennement.

Cela devait régler tous les problèmes… hélas! non.

 

Le périple DevOps

 

La plupart de nos lecteurs ne croient probablement plus au père Noël et savent déjà qu’un modèle organisationnel permettant d’augmenter une cadence dans les proportions mentionnées ne tombe pas du ciel… ni d’un traîneau.

Même en assumant qu’un modèle de développement Agile est déjà en place, la transformation vers le DevOps est une initiative importante. Le DevOps n’est pas une recette ou un processus rigide où les acteurs ne sont que des exécutants robotisés ayant suivi une ou deux formations rapides. Bien au contraire, le DevOps requiert un changement d’attitude face à certaines doctrines et doit donner beaucoup de soutien et de liberté aux praticiens pour acquérir de nouvelles connaissances et compétences en regard aux défis qui étaient traditionnellement résolus par “les autres”.

La culture du DevOps est essentiellement basée sur la collaboration, voire l’unification de l’équipe de développement et l’équipe d’opération, formant ainsi une seule équipe composée de deux groupes. Et comme le DevOps est souvent perçu comme un prolongement du modèle Agile, il est facile de penser que leurs approches et méthodes s’intègrent harmonieusement.

Désolé de vous décevoir encore une fois, mais la réalité est très différente.

Pour bien saisir l’ampleur du défi du DevOps, il faut comprendre la dissonance entre les objectifs respectifs des groupes de développement et d’opérations :

  • La responsabilité principale du développement est l’évolution rapide du logiciel par l’ajout ou l’amélioration de fonctionnalités, créant ainsi une instabilité opérationnelle.
  • En revanche, l’objectif principal des opérations est de maintenir la stabilité opérationnelle du logiciel afin d’assurer la continuité des services aux utilisateurs.

En d’autres termes, c’est comme le groupe ingénierie qui développe un satellite et le groupe opération qui supervise son lancement et son fonctionnement tant qu’il est en orbite. Imaginez maintenant qu’on remplace le satellite par un nouveau tous les jours.

 

Quelques défis de terrain

 

Traditionnellement, les équipes Dev et Ops déterminaient indépendamment leurs méthodes, processus et outillages pour réaliser leur objectif primaire respectif. Par exemple, les développeurs avaient un processus de déploiement en environnement test différent de celui utilisé par les opérateurs pour la production. La cause principale étant que le premier est très différent du second. Conséquemment, à chaque nouvelle livraison, les opérateurs devaient reconfigurer la procédure et les paramètres en plus de tester et corriger le déploiement de bout en bout. Travail long, ardu, périlleux et surtout, très coûteux.

Il en allait de même pour les logs, l’instrumentalisation de surveillance, la sécurité et plusieurs autres préoccupations globales essentielles, mais généralement attribuées aux Ops. Cette dissonance entre Dev et Ops, couplée à l’attitude du “pas mon problème” était, et demeure toujours dans plusieurs cas, la cause de nombreux retards et défaillances en production ainsi que du semi-succès, voire de l’échec d’une initiatives DevOps.

Au vu de ces défis difficiles à résoudre, il est normal de se poser la question suivante : “Le DevOps est-il réellement Agile”? On pourrait argumenter ad nauseam, mais si l’on considère que l’Agilité consiste à diviser le travail (sprint) pour une réalisation par étape de l’ensemble (application), il faut admettre que la mise en service des incréments et des évolutions doit ultimement se produire dans un “big bang” afin d’éviter toute interruption de production.

À notre avis, la réponse est que Dev et Ops sont comme des services indépendants, mais complémentaires, hautement interconnectés par un API humain et déployés dans un même conteneur (équipe DevOps). Les préoccupations sont globales, mais leurs résolutions sont partagées.

Quelques exemples :

  • La sécurité de l’information est autant du domaine de Dev que d’Ops.
    • Application (authentification, autorisation, confidentialité) et infrastructure (SSL/TLS, intrusion, etc.)
  • Le backlog est partagé afin que le travail à faire soit connu de tous.
    • Commentaires de l’un ou l’autre groupe améliore la conception (performance, sécurité, etc.).
  • Une urgence de production devient le problème de tous.
    • La priorité de service aux usagers est la préoccupation principale de toute l’équipe et souvent, la solution vient de Dev.

Conséquemment, toute approche sensible pour une transformation DevOps réussie passe obligatoirement par un rapprochement de ces groupes. Ce rapprochement débute par une connaissance et une compréhension mutuelle des problèmes et défis de l’autre. Ainsi, l’intégration de Dev et d’Ops se traduit d’abord pas une association de Dev et d’Ops.

 

Gologic

 

Ainsi donc, Beethoven et Van Halen doivent apprendre à jouer ensemble, chacun selon sa méthode et son style afin de produire une œuvre éternelle (enfin presque) et iconique pour le plus grand plaisir de leurs admirateurs respectifs et communs (gestionnaires, utilisateurs). Tout un défi* et, de plus, il reste à déterminer lequel jouera la partition Beethoven ou Van Halen.

C’est bien beau tout cela, mais comment on procède? C’est là que notre expertise et expérience interviennent pour accompagner gestionnaires et équipes de Dev et d’Ops dans leur apprentissage des œuvres de BeetHalen.

D’où ce blogue dont l’objectif principal des articles est d’exposer les défis et les approches de solution d’une transformation vers un modèle de livraison continue DevOps. Régulièrement, nous produirons des articles destinés aux chefs d’orchestre qui apporteront des réponses aux défis organisationnels que nous avons déjà identifiés ainsi qu’à plusieurs autres. Particulièrement aux cas complexes liés à l’impact sur la culture d’une organisation.

Nous adresserons aussi les champs d’intérêt des musiciens avec des articles proposant des techniques d’avant-garde ainsi que des analyses de cadriciels et d’outillage spécialisé. Finalement, nous analyserons quelquefois des cas et situations intéressantes, rencontrées par nos conseillers, en préservant bien sûr, l’anonymat des parties en cause.

Alors, restez à l’écoute sur les réseaux sociaux où nous annoncerons les nouvelles publications.

À bientôt donc.

Benjamin Lallement, conseiller DevOps et associé Gologic

* Solution au défi.

Liens relatifs à l’approche Agile

Avec la collaboration de Jacques Ledoux, jcq@ledx.com

Suivez-nous et partagez

Laisser un commentaire