Maintenant que vous connaissez ce qu'est le DevOps, et que vous savez quels sont ses avantages et ses principaux piliers, vous vous demandez sûrement comment l'implémenter au sein de votre entreprise ? De nombreuses tentatives d'implémentation du DevOps ont déjà été effectuées dans plusieurs entreprises, plusieurs de ces tentatives avec succès, d'autres avec beaucoup moins de succès...
Dans ce chapitre, je vous propose de parcourir plusieurs de ces patterns et anti-patterns, afin que vous puissiez les connaître avant d'implémenter DevOps dans votre entreprise, mais aussi savoir identifier les pièges courants dans lesquels ne pas tomber.
Dans les chapitres précédents, nous avons vu ensemble ce qu'est le DevOps, d'où il vient et quels sont ses fondamentaux.
Dans ce chapitre, nous allons voir, grâce à des cas concrets, comment s'implémente le DevOps en entreprise. Pour cela, nous allons voir des exemples (patterns) récurrents de manières efficaces et bénéfiques pour l'entreprise d'implémenter ces méthodes. Mais nous verrons également des contre-exemples (anti-patterns) vous permettant de voir ce qu'il ne faut pas faire. Ceci vous permettra de connaître les bonnes pratiques pour les implémenter dans votre entreprise, mais aussi de savoir éviter les pièges.
Comme vous le verrez, j'ai agrémenté ce chapitre de mon expérience personnelle d'implémentation du DevOps. Vous trouverez donc des exemples pour la plupart des types d'implémentation ! Notamment, je parlerai d'un grand groupe français que j'ai accompagné dans sa transformation en DevOps, et que j'appelle ici Contoso.
Le principal but du DevOps dans une entreprise est d'abord d'améliorer la livraison de valeur ajoutée pour le métier et l'utilisateur final. Ce n'est pas nécessaire, ou pas forcément prioritaire de réduire les coûts, d'augmenter l'automatisation des livraisons, ou de tout faire depuis de la gestion de configuration.
Cela veut donc dire que plusieurs organisations auront potentiellement des besoins différents pour structurer les équipes de développeurs et les équipes de production, afin de permettre une collaboration efficace entre ces deux métiers.
La structure d'une organisation DevOps va donc dépendre de plusieurs facteurs, comme :
l'ensemble des produits de l'organisation. Une entreprise travaillant sur moins de produits aura plus de facilités à la collaboration, car il y aura moins de silos naturels, comme le prévoit la loi de Conway ;
la portée, la force et l'efficacité du leadership technique, et si les développeurs et la production ont un objectif commun, comme vu dans le chapitre précédent ;
l'alignement des pratiques de l'équipe Opérations informatiques avec la chaîne de valeur. Si le département des opérations informatiques est organisé autour de la configuration de serveurs et de hardware et non autour des fonctionnalités opérationnelles, un gros travail d'évolution sera à faire sur ce point-là. Or, toutes les entreprises n'ont pas la capacité ou la volonté d'évoluer sur ce point ;
l'envie ou la capacité d'une organisation à changer son département des opérations informatiques, de "racking hardware" et de "configuration de serveurs" à un alignement réel avec la chaîne de valeur, et à ce que les fonctionnalités opérationnelles soient prises au sérieux par les équipes logicielles ;
la capacité ou les compétences présentes dans l'organisation qui sont nécessaires pour prendre l'initiative sur les questions opérationnelles.
Ne tombez pas dans le piège ! ❌
Commençons par les anti-patterns, car ils découlent généralement d'une bonne idée au départ, qui se transforme au fur et à mesure en une idée contre-productive allant à l'encontre de ce qu'elle est censée améliorer.
Silo Dev et silo Ops
Le premier anti-pattern que l'on retrouve souvent en entreprise, et que le DevOps cherche à éliminer, est la séparation entre les équipes de développement et les équipes d'ops. Ces équipes sont séparées par le fameux "mur de la confusion".
D'un côté, nous avons des développeurs dont le métier est de développer des user stories, de faire évoluer l'application, d'implémenter de nouvelles features et de corriger les bugs. Et de l'autre, nous avons des ops dont le métier est de maintenir en condition opérationnelle l'application, de réparer les serveurs qui ne fonctionnent pas, d'appliquer des patchs de sécurité et de faire évoluer les produits.
Ces deux équipes ont donc deux vitesses différentes : une équipe voulant aller vite et avoir le maximum de changements, et une autre équipe voulant garantir la stabilité de l'application. De plus, généralement, ces équipes sont motivées par le nombre de bugs corrigés ou de nouvelles features produites, pour les développeurs ; et par le nombre de bugs critiques en production, pour les ops.
Ces deux mondes ne se comprennent pas et finissent par ralentir la cadence de livraison des applications en production. Le DevOps est une approche visant à casser ces silos et fluidifier les communications entre personnes d'une part, et mettre en place des outils d'automatisation de livraison de l'autre. C'est pourquoi le DevOps explose littéralement dans les entreprises françaises depuis quelques années.
J'ai eu l'occasion d'accompagner l'entreprise Contoso dans la transformation des équipes Dev et Ops, en mettant notamment en place une culture partagée, mais aussi des outils de livraison et de déploiement continus. Nous verrons dans la suite de ce cours comment nous pouvons résoudre le problème de ces silos Dev et Ops, en mettant en place des patterns de collaboration par exemple, ou d'équipe d'évangélistes.
Silo DevOps
Une des bonnes idées qu'une entreprise peut avoir, afin de pallier la problématique citée précédemment, est de mettre en place une équipe DevOps en charge de l'implémentation des processus de livraison et de déploiement continus. Cette équipe est généralement transverse à l'entreprise et est sollicitée par toutes les applications, afin de pouvoir mettre en place des outils d'automatisation.
Généralement, cette idée vient d'une personne du top management, car elle a assisté à une conférence sur un retour d'expérience de la mise en place d'une telle équipe au sein d'une autre entreprise.
Malheureusement, la création de cette équipe transverse génère un troisième silo, car elle va être confrontée à :
des développeurs la sollicitant, mais ne comprenant pas les fondamentaux du DevOps ;
des ops qui veulent garder la main sur la mise en production, garder leurs outils, et ne voient généralement pas d'un bon œil la création de cette équipe.
Dans l'entreprise Contoso que j'ai eu la chance d'accompagner, une telle équipe était présente en transverse dans l'entreprise. Cette équipe était en charge de la mise en place des outils de déploiement sur toutes les applications de l'entreprise. La création de cette équipe partait d'un bon sentiment, mais l'équipe s'est vite retrouvée surchargée de travail, car toutes les applications voulaient alors mettre en place les outils de livraison et de déploiement continus, ce qui a conduit l'équipe à ne plus pouvoir innover et à maintenir une liste d'outils de plus en plus grande, selon les besoins des applications.
De plus, les développeurs et les ops consommateurs de cette équipe ne comprenaient pas les fondamentaux du DevOps, et se reposaient alors quasiment exclusivement sur cette équipe transverse. Nous avions alors créé un troisième silo, alors que le DevOps est censé les casser et fluidifier la communication.
Nous avons partiellement résolu cette problématique chez Contoso, en redonnant du pouvoir aux développeurs, notamment, pour qu'ils puissent installer et configurer seuls certains outils de la livraison continue.
NoOps
Avec l'arrivée du cloud computing, et plus récemment du serverless, de plus en plus d'articles de blogs et de conférences parlent du mouvement NoOps, ou la non-nécessité des ops dans un schéma traditionnel. Effectivement, ce mouvement part du principe que la plateforme Cloud, et donc le cloud provider, prend en charge toutes les opérations pour le maintien en condition opérationnelle de l'application (sauvegarde, plan de reprise d'activité, scalabilité, résilience, etc.).
Même les cloud providers font la promotion du fait que seul un développeur est nécessaire pour le déploiement et la gestion de l'application. Malheureusement, même si le DevOps nous permet de casser les silos et de fluidifier les communications entre personnes, le métier de développeur et le métier d'ops sont bien deux métiers totalement différents. Les développeurs ne mesurent pas la complexité d'une application, et savent rarement comment rétablir une infrastructure qui ne fonctionne pas.
Une équipe constituée uniquement de développeurs finira souvent par avoir besoin d'un ops, au fur et à mesure de la montée en complexité de l'application. Dans ce cas-là, même si les développeurs gardent la main sur ce qu'ils ont mis en place, ils feront alors appel à une équipe DevOps transverse, ou à l'équipe Cloud d'une entreprise.
J'ai eu l'occasion de discuter de ce pattern avec beaucoup d'équipes. Ce pattern est généralement utilisé soit dans des startups où la priorité numéro 1 est de sortir un produit correspondant aux besoins des utilisateurs, remettant à plus tard les questions ops, mais ne les occultant pas ; soit dans des équipes créant un nouveau produit sans existant, et où les questions d'ops se posent alors plus tard.
Équipe transverse Outils
La création d'une équipe transverse uniquement basée sur les outils est aussi une mauvaise idée lors de l'implémentation du DevOps. Comme nous avons pu le voir plus haut dans le cours, cette équipe va créer un troisième silo, là où le DevOps cherche à les faire disparaître.
De plus, cette équipe est uniquement axée sur l'implémentation des outils afin de pouvoir mettre en place des pipelines de déploiement de livraison continue, de la gestion de configuration, de la gestion d'environnement, etc. Cette équipe n'a pas pour vocation de changer la culture de l'entreprise, et les deux équipes Dev et Ops continuent à travailler sans changer leur process, et en se reposant en grande partie sur cette équipe Outils transverse, pour livrer l'application.
Certes, cette équipe sera bénéfique à très court terme, car elle permet aux autres équipes de ne plus avoir à penser à tout ce qui ne touche pas à l'application, mais son impact est limité car elle ne changera pas les process, qui parfois peuvent être très lourds.
Lors de l'implémentation d'une telle équipe chez Contoso, elle s'est vite retrouvée surchargée de travail, car elle ne servait qu'à déployer et maintenir des outils de livraison continue comme Jenkins, Nexus, XLDeploy, Git, etc. Son importance était capitale car toutes les équipes d'applications ne reposaient plus que sur elle. Afin de contrer cela, une idée fut de redonner du pouvoir aux équipes Dev et Ops, en leur permettant d'installer leurs propres plugins et leurs propres outils.
Ops dans l'équipe de dev
L'organisation ne veut pas conserver une équipe d'exploitation distincte, de sorte que les équipes de développement assument la responsabilité de l'infrastructure, de la gestion des environnements, de la surveillance, etc. Toutefois, le fait de le faire en fonction du projet ou du produit signifie que ces éléments sont soumis à des contraintes de ressources et à des redéfinitions des priorités, qui conduisent à des approches partielles et à des solutions à demi perçues.
Dans cet anti-pattern, l'organisation montre un manque d'appréciation de l'importance et des compétences requises pour des opérations informatiques efficaces. En particulier, la valeur des opérations est diminuée parce qu'elle est traitée comme une gêne pour les développeurs (car les opérations sont gérées par un seul responsable d'équipe avec d'autres priorités).
Assurez une bonne mise en place du DevOps ✅
Collaboration entre dev et ops
Pour favoriser la communication de ces deux équipes chez Contoso, j'ai notamment demandé aux ops de participer au Daily meeting des développeurs, afin que les ops soient au courant des nouvelles features qui étaient implémentées lors du sprint courant.
Les ops pouvaient aussi, lors de ces daily meetings, faire des remontées d'infos aux équipes de développeurs sur, par exemple, l'opérabilité de l'application. Ils pouvaient faire inscrire sur les user stories des évolutions de l'application, afin que celle-ci soit plus facile à exploiter. Par exemple, les ops avaient demandé que tous les logs soient implémentés sous forme de Json, afin de pouvoir mieux les importer dans la stack ELK.
De plus, afin que les développeurs soient aussi plus impliqués sur le métier d'ops, j'avais demandé à ce que des tableaux de bord correspondant à l'état de l'application en production, mais aussi sur tous les autres environnements, soit mis en place sur le plateau des développeurs. Les développeurs étaient alors sensibilisés à l'impact de l'état de l'application lorsqu'ils committaient du code et déclenchaient une release.
Enfin, les ops étaient sensibilisés à la qualité du code, grâce notamment aux techniques de TDD et BDD qui produisaient des rapports sur la non-régression de bugs en production, et qui, par conséquent, rassuraient l'équipe d'ops sur la qualité du produit qu'ils allaient mettre en production.
Tout ceci doit évidemment passer par un changement culturel de l'entreprise important et soutenu par un sponsor fort, comme le DSI ou le directeur de production, par exemple.
Dev et équipe Cloud
Pour les organisations disposant d'un département IT assez traditionnel qui ne peut pas ou ne veut pas changer (assez) rapidement, et pour les organisations qui exécutent toutes leurs applications dans le cloud public (Amazon EC2, Azure, etc.), il est probablement utile de traiter les opérations comme une équipe qui fournit simplement l'infrastructure sur laquelle les applications sont déployées et fonctionnent.
Une équipe (peut-être une équipe virtuelle) au sein des développeurs agit alors comme une source d'expertise sur les fonctionnalités opérationnelles, les métriques, la surveillance, le provisionnement des serveurs, etc., et assure probablement la majeure partie de la communication avec l'équipe Cloud. Cette équipe est toujours une équipe de développement ; cependant, elle suit alors des pratiques standard comme le TDD, le CI, le développement itératif, le coaching, etc.
La topologie Cloud offre une certaine efficacité potentielle (perdant de la collaboration directe avec les équipes d'exploitation) pour une mise en œuvre plus facile, peut-être en tirant de la valeur plus rapidement qu'en essayant le premier pattern Collaboration entre dev et ops, qui pourrait être tenté à une date ultérieure.
Service externe DevOps
Certaines organisations, en particulier les plus petites, peuvent ne pas avoir les finances, l'expérience ou le personnel nécessaires pour prendre la direction des aspects opérationnels de l'application qu'elles produisent. L'équipe de développement peut alors faire appel à un fournisseur de services comme Google, Amazon ou Azure, pour les aider à créer des environnements de test, et à automatiser leur infrastructure et leur surveillance. Ce fournisseur externe pourra également les conseiller sur les types de fonctionnalités opérationnelles à mettre en œuvre pendant les cycles de développement logiciel.
Ce que l'on pourrait appeler DevOps-as-a-Service pourrait être un moyen utile et pragmatique pour une petite organisation ou une petite équipe d'en apprendre davantage sur l'automatisation, la surveillance et la gestion de la configuration, puis peut-être de passer à un modèle de type "Dev et équipe Cloud" ou même de type "Collaboration entre dev et ops", à mesure que le personnel s'accroît et se concentre sur les opérations.
Équipe DevOps temporaire
L'équipe DevOps temporaire ressemble beaucoup à l'anti-pattern Silo DevOps, mais son intention et sa longévité sont très différentes. Cette équipe temporaire a pour mission de rapprocher les développeurs et les opérations, idéalement vers un modèle de type Collaboration entre dev et ops, et éventuellement de se rendre obsolète.
Les membres de l'équipe temporaire parleront de problématiques propres à chaque équipe :
en introduisant des idées comme les stand-up meetings et le Kanban pour les équipes Ops ;
en pensant aux détails comme les load-balancers, la gestion des cartes réseaux, et le SSL pour les équipes Dev.
Si suffisamment de personnes commencent à voir l'intérêt de réunir dev et ops, alors l'équipe temporaire a une réelle chance d'atteindre son objectif. La responsabilité à long terme des déploiements et des diagnostics de production ne devrait donc pas être confiée à l'équipe temporaire, sinon elle risque de devenir un silo DevOps.
Équipe d'évangélistes DevOps
Un des patterns qui pour moi fonctionne le mieux en entreprise, car je l'ai expérimenté et implémenté chez Contoso, est une équipe d'évangélistes DevOps ou coachs DevOps. Mon rôle chez Contoso était un rôle de coach DevOps. J'aidais les équipes Devs et Ops des applications à implémenter le DevOps, mais aussi l'intégration et la livraison continues.
Je travaillais conjointement avec l'équipe transverse DevOps, afin d'utiliser les outils qu'elle avait déployés pour implémenter des pipelines d'intégration et livraison continues. Mon rôle était d'aller voir les équipes Devs et Ops de chaque application, afin de les sensibiliser sur l'intérêt commun du DevOps, et le partage des bonnes pratiques.
J'avais comme outil les daily meetings où j'amenais les ops, comme vous avez pu le voir plus haut dans le cours. Mais aussi des jeux comme le DevOps game, où chacun se mettait dans la peau de l'autre, afin que tout le monde comprenne le métier de l'autre et l'intérêt de se parler. J'avais aussi d'autres outils à ma disposition, comme les tableaux de bord sur les équipes projet.
Mon rôle était d'accompagner ces équipes pendant 3 à 6 mois, afin que qu'elles puissent se passer de moi et puissent implémenter le DevOps sans mon intervention.
Collaboration axée sur les conteneurs
Une des promesses des conteneurs (notamment avec Docker) est de pouvoir s'exécuter de la même manière sur n'importe quel environnement exécutant un démon pouvant exécuter ce conteneur. Effectivement, l'application est encapsulée dans un conteneur avec tout ce qui est nécessaire pour la faire tourner (librairies, framework, middleware, etc.).
D'un coté, les développeurs ne se chargent que de créer l'image, afin que l'application puisse tourner correctement.
De l'autre, les ops opèrent cette image avec toutes les contraintes liées au maintien en condition opérationnelle.
De fait, le conteneur devient alors le livrable universel servant de passerelle entre les développeurs et les ops. Avec une forte automatisation et beaucoup d'outillage, ce pattern permet une fluidification de livraison d'applications, les exigences de déploiement et de fonctionnement étant encapsulées dans le conteneur.
Malheureusement, si les développeurs commencent à ignorer les recommandations des ops pour le maintien en condition opérationnelle de l'application (par exemple le format d'envoi des logs), ce pattern devient alors un anti-pattern similaire aux silo Dev et silo Ops.
Dans la pratique, et ayant eu l'occasion de le voir maintes fois implémenté dans les entreprises, beaucoup d'équipes pensent que le conteneur est la solution ultime pour délivrer des applications rapidement, et donc faire sauter les contraintes opérationnelles (problème de livraison d'environnement, problème d'installation de la bonne version du framework, évolution des middlewares, etc.). Mais dans les faits, il faut mettre en place un modèle d'opération de ces conteneurs, car ils doivent être patchés, les conteneurs doivent changer de serveur si celui-ci doit être mis à jour, etc.
En résumé
Et voilà, j'espère que cette présentation des bonnes et mauvaises pratiques vous aura aidé à y voir plus clair sur la manière d'implémenter le DevOps en entreprise. Résumons ensemble les bonnes et mauvaises pratiques :
les mauvaises pratiques ❌ :
silo Dev et silo Ops. Aucune méthodologie DevOps ici, modèle classique ;
silo DevOps. LE piège, créer un troisième silo en essayant de briser les deux autres ;
NoOps. Eh non ! Le rôle des ops est encore utile, même s'il évolue ;
équipe transverse outil. Vous passez à côté de plein d'autres aspects du DevOps et... vous créez un troisième silo !
ops dans l'équipe de dev. C'est montrer un manque d'appréciation du travail des ops !
les bonnes pratiques ✅ :
collaboration entre dev et ops. La collaboration est la clé pour un bon fonctionnement de l'équipe de production en mode DevOps ;
dev et équipe Cloud. Une équipe qui s'occupe simplement de fournir l'infrastructure de déploiement. Ceci peut être une étape intermédiaire vers une implémentation plus complète du DevOps ;
service externe. Souvent une solution adaptée aux petites équipes, faire appel à un fournisseur externe d'expertise DevOps peut s'avérer une bonne idée ;
équipe DevOps temporaire. Une équipe DevOps qui n'est présente que le temps de mettre en place les démarches DevOps et former les équipes Dev et Ops aux bonnes pratiques ;
évangélistes DevOps. Proche du pattern précédent, c'est une équipe qui s'occupera uniquement de former les équipes au DevOps ;
collaboration axée sur les conteneurs : les conteneurs permettent de fluidifier le travail entre le développement et la mise en production.
Dans le dernier chapitre, je vous propose de creuser une dernière bonne pratique : la mise en place d'un poste de SRE (Site Reliability Engineer).
