Le mouvement DevOps se présente comme une culture impliquant les process, l’outillage et l’organisation. Si les deux premiers axes semblent couverts par des démarches méthodologiques et techniques éprouvées (lean, agilité, automatisation, craft …etc), l’axe organisationnel manque – quant à lui – d’abaques fiables.
De ce fait il devient primordial avant d’entamer une transition inspirée par la culture DevOps, d’identifier le modèle organisationnel en place et ainsi cibler le pattern le plus adapté au mode de fonctionnement de notre structure de sorte à réduire la résistance au changement et d’effectuer une migration fluide et pragmatique.
Dans ce qui suit, nous allons exposer quelques modèles usuellement rencontrés, les évaluer et tenter de donner une appréciation de leur adaptabilité dans une démarche de transformation DevOps
Dedicated DevOps Team
Integration Team
Modèle historique où une équipe dédiée - généralement connue comme l’équipe d’intégration - représente une entité de liaison entre les développeurs et les opérationnels. Son rôle consiste à connaitre et maitriser les offres mises à disposition par les opérationnels en matière d’infrastructure et d’outillage, et sont la garants du bon déroulement des livraisons des projets, et doivent - par conséquent - se maintenir à jour par rapport aux nouvelles fonctionnalités développées.
L’intégrateur a ainsi un rôle de release manager, qu’il soit dédié à un projet ou mutualisé pour un domaine fonctionnel ou un ensemble de projets.
- Avantages
- Décharge les développeurs et les opérationnels du la mise en œuvre et suivi des livraisons.
- Inconvénients
- Avec l’accroissement des fonctionnalités / projets de développement et infrastructure, il devient compliqué de maintenir l’équipe d’intégration à jour
- Ce modèle favorise le cloisonnement des équipes OPS et DEV, et contribuer à maintenir des silos d’activité bien distincts.
Classification : DevOps Anti Pattern
Pilot DevOps Team
Dans cette approche, une équipe DevOps transverse est mise en place afin de répondre aux besoins des projets sur des problématiques de provisionning ou de delivery. L’objectif stratégique consiste à réaliser l’apport de valeur DevOps sans pour autant perturber l’organisation en place ou effectuer des changements de fond
- Avantages
- Mise en place rapide des fondations de la transformation DevOps
- Pilotage par l’exemple et la pratique
- Gestion du changement de manière progressive et adaptée au rythme et à la maturité des équipes
- Inconvénients
- On se laisse rapidement tenter par la pérennisation de cette organisation, ce qui nous conduit à l’anti pattern de l’équipe d’intégration.
Classification : DevOps Compatible
Recommandation : Ce modèle est un bon déclencheur qui permet de tester l’organisation et fournir des abaques pour un processus de transformation a plus grande échelle
Operational Developers
Ce pattern est assimilé à une organisation où les développeurs prennent à leur charge partie voire l’ensemble des tâches de provisionning, configuration et gestion des environnements techniques, ainsi que d’autres tâches habituellement prises en charge par des opérationnels
Il est également question de ce type de modèles lorsque les opérationnels sont complétement intégrés dans l’équipe de développement
Ce modèle peut être observé aussi bien dans des petites structures (type startups) que chez de grands acteurs IT comme Facebook ou encore Netflix. Le point commun étant le focus sur un (ou peu) de produits / services
- Avantages
- L’architecture et l’outillage de production s’adapte aux besoins des projets
- Bon niveau de maitrise du produit et de la chaine de production logicielle
- Inconvénients
- Les tâches opérationnelles sont souvent dépriorisées par rapport aux tâches de développement qui sont assimilées à la valeur ajoutée du business, ce qui conduit à des dispositifs dont la qualité tends à se détériorer avec le temps
- Quand cette approche est issue d’une mauvaise appréciation de l’importance de l’expertise des SysOps, la contrainte de maintient d’un haut niveau de polyvalence des développeurs risque d’être mal anticipée
Classification : Pattern ou Anti Pattern en fonction du contexte
Recommandation : Dans une approche orientée produit, ce pattern fait ressortir la symbiose entre développeurs ou opérationnels qui partagent les mêmes problématiques. Cependant il vaut mieux éviter ce pattern si on est dans un modèle d’équipes gérant plusieurs produits
Operationals 2.0
Survient lorsqu'une équipe OPS traditionnelle souhaite surfer sur la vague DevOps en espérant en tirer bénéfice en termes d’amélioration de l’automatisation et réduction du TTM
Cette équipe – rebaptisée DevOps pour le coup – reste néanmoins dans un silos organisationnel qui ne respecte pas l’esprit de collaboration transversale et de partage des responsabilités inhérents à la culture DevOps
- Avantages
- La mise à jour des méthodes ou outils de travail côté OPS conduisent vraisemblablement à une amélioration des process de provisionning, delivery …etc.
- Inconvénients
- Pas de changement significatif. Les silos sont maintenus et les gains obtenus ne sont pas au niveau attendu.
- Adopter ce modèle risque de générer un mauvais feedback qui pourrait contraindre voir bloquer de futures stratégies de transformation
Classification : DevOps Anti Pattern
Devops Champions
Ce modèle présente une communauté de personnes motivées qui prennent à leur charge la tâche d’évangélisation et de promotion de la démarche DevOps et des outils techniques et méthodologiques qui l’accompagnent.
De manière générale, cela peut être issu d’une émulation collective (communauté spontanée) ou d’une décision stratégique qui conduit à identifier les évangélistes et les positionner dans les différentes équipes concernées.
- Avantages
- Modèle issu d’une réelle prise de conscience et d’une forte motivation
- Transformation "en douceur" par l’exemple et la pratique
- Inconvénients
- Le processus peut être plus lent que d’autres modèles, et requiert un fort investissement des DevOps champions ainsi que l’implication stratégique des décideurs afin de faciliter leur tâches et pérenniser la démarche sur le long terme
Classification : DevOps Compatible
Ops As A Service
Certaines organisations font le choix d’externaliser leurs tâches opérationnelles, soit par le biais d’un prestataire de service, ou bien en exploitant des offres de cloud public (Amazon EC2, Azure …etc.)
Une variante de ce modèle consiste à s’appuyer sur une équipe OPS interne, transverse à la structure et qui propose ses service sous forme d’infrastructure as a service
L’ensemble ou partie des équipes de DEV doit, dans ce cas de figure, acquérir la maîtrise des offres IAAS afin de pouvoir piloter son delivery. Les tâches de support et de maintenance étant prises en charge de manière transparente par le fournisseur de l’offre IAAS
- Avantages
- Les équipes de DEV sont impliquées concrètement dans les tâches
- Ce modèle requiert un bon niveau de maîtrise des équipes OPS de leurs infrastructure et process ce qui améliore la qualité et la réactivité du service fourni aux équipes de développement
Classification : DevOps Compatible
Halfway DevOps (Dev + Middleware, Dev + DBA, DBA + Ops)
Il est possible de se trouver dans une organisation où une démarche de rapprochement des équipes opérant dans un même objectif fonctionnel a déjà eu lieu sans pour autant s’inscrire dans une stratégie de transformation stratégique.
Il est donc commun de voir des rapprochements entre Développeurs applicatifs et les équipes de support et d’optimisation des middlewares ou des DBA.
Ces équipes peuvent être partie ou totalement identifiées dans l’organisation comme des équipes OPS, même si au final, ils sont souvent sollicités pendant le cycle de développement.
Classification : DevOps Compatible
Recommandation : Cette démarche peut être une entrée en matière pour diffuser une culture DevOps au sein de l’organisation. Il s’agit néanmoins à ne pas tomber dans le piège des silos d’activité
