Les Patterns des Grands du Web - DevOps

le 05/06/2012 par Olivier Mallassi, Rudy Krol
Tags: Software Engineering

Description

Le mouvement  « DevOps » nous invite à repenser la frontière classique de nos organisations qui séparent d’un côté les études, i.e. ceux qui écrivent le code des applications (les « Dev ») et de l’autre côté la production, i.e. ceux qui déploient et exploitent ces applications (les « Ops »).

Ces réflexions sont certainement aussi anciennes que les DSIs mais elles trouvent un peu de fraîcheur grâce notamment à deux groupes. D’un côté les agilistes qui ont levé la « contrainte » côté développement, et sont maintenant capables de « livrer » beaucoup plus souvent du logiciel valorisé par le client… de l’autre, des experts ou des managers de la « prod » des grands du web (Amazon, Facebook, LinkedIn…) partageant leurs retours d’expérience et la façon qu’ils ont d’aborder la frontière « dev » et « ops ».

Au-delà de la beauté intellectuelle de l’exercice, DevOps travaille surtout (oserais-je dire uniquement) sur la réduction du TTM (Time To Market). Il y a certes d’autres effets positifs ou de nécessaires améliorations autour de la culture, de la communication, de l’accélération des déploiements ou des approvisionnements mais l’enjeu d’ordre un, au final, reste bien ce fameux « Time To Market » (pas très étonnant dans l’industrie du web).

Dev & Ops : des préoccupations locales distinctes mais un objectif commun

Au-delà des fractures organisationnelles, les préoccupations des études et de la production sont bien distinctes et respectivement louables :

DevOps-Fig-01Figure 1.

Les études recherchent plus de réactivité (sous la pression du métier et du marché notamment) : il faut aller vite, ajouter de nouvelles fonctionnalités, réadapter les directions, refactorer, upgrader les frameworks, déployer rapidement sur de nouveaux environnements pour tester… C’est la nature même du code (« Soft ») : malléable, adaptable.

A l’inverse, la production a besoin de stabilité et de standardisation.

Stabilité car il est souvent difficile d’anticiper quels impacts auront telles modifications de code, d’architecture ou d’infrastructure : un disque local qui devient un disque réseau mais impacte les temps de réponses, ou bien un changement de code qui impacte fortement la consommation CPU et par là même le « capacity planning ».

Standardisation enfin car la production veut s’assurer que certaines règles (configuration des machines, versions logicielles, sécurité réseau, configuration des fichiers de logs, …) sont uniformément respectées pour assurer la qualité de service de l’infrastructure.

Reste que ces deux groupes, « dev » et « ops » ont pourtant bien un objectif commun : faire fonctionner le système vu du client final.

DevOps, dans la continuité de l’agile

L’agile est apparu en France il y a maintenant plus de 6 ans avec comme principal objectif de lever la contrainte autour du processus de développement.

Cette méthodologie introduisait les notions de cycles courts, de feedback terrain et client, la notion de Product Owner, une personne du métier responsable de la roadmap, des priorisations…

L’agile a également mis à mal l’organisation traditionnelle (dans les DSI Françaises tout du moins) en introduisant des équipes pluri-disciplinaires (du métier aux développeurs) et challengeant du même coup les découpages organisationnels.

Aujourd’hui, ces contraintes ont été levées, les développements suivent le plus fréquemment des itérations de 1 à 2 semaines. Les métiers voient le logiciel évoluer durant la phase de construction.

Il est dorénavant temps d’impliquer les personnes de la production sur les phases suivantes :

  • approvisionnement / mise en place des environnements : dans la plupart des entreprises, l’approvisionnement d’un environnement peut demander de 1 mois à 4 mois (pourtant en environnement virtualisé). C’est admirablement long surtout face à des challengers comme Amazon ou Google…
  • déploiement : cette phase est certainement celle qui cristallise le plus le problème et créée le plus d’instabilité ; les équipes agiles se limitent parfois à un déploiement par trimestre pour limiter les impacts en production et garantir la stabilité du système, d’autant plus que ces déploiements sont souvent manuels (donc longs, sources d’erreurs, …), bref, risqués.
  • résolution d’incidents et la prise en compte des besoins non fonctionnels : les acteurs de la production sont les autres utilisateurs de l’application. La facilité à diagnostiquer, expliquer les problèmes, les enjeux de résilience, robustesse doivent être pris en compte.

Devops s’organise autour de 3 piliers : « Infrastructure as code », « Continuous Delivery » et Organisation

1. « Infrastructure as Code » ou comment accélérer les phases d’approvisionnement et de mise à disposition des environnements.

Un des points de friction les plus visibles dans le manque de collaboration entre dev et ops se trouve au niveau des phases de déploiement. C’est d’ailleurs l’activité qui se montre être la plus consommatrice en ressources : la moitié du temps de la production est ainsi consommée par le déploiement ou des problèmes liés au déploiement.

Figure 2. Source : Etude de Deepak Patil (Microsoft Global Foundation Services) de 2006, via une présentation de James Hamilton (Amazon Web Services)

http://mvdirona.com/jrh/TalksAndPapers/JamesHamilton_POA20090226.pdf

Et même s’il est difficile de donner des règles générales, il y a fort à parier qu’une partie de ce coût (le segment à 31%) peut diminuer via l’automatisation de ce processus de déploiement.

Beaucoup d’outils fiables existent aujourd’hui pour automatiser les phases d’approvisionnement et de mise à disposition des environnements, allant de l’instanciation de VM au déploiement applicatif, en passant par la configuration système.

Figure 3. Classement des principaux outils

Ces outils visent à permettre le codage (dans des langages qui leur sont propres) des infrastructures : installation et démarrage d’un service http, du serveur tomcat, création des répertoires pour les fichiers de logs…

Les objectifs et les gains sont multiples :

  • Garantir un processus répétable et fiable (pas d’intervention humaine facteur d’erreur) avec notamment la capacité à gérer des mécanismes de retour arrière (rollback).
  • Productivité. « One click deployment » (déploiement en un clic) plutôt qu’un ensemble de tâches manuelles qui permettront d’aller plus vite.
  • Traçabilité permettant d’expliquer, de comprendre, de faciliter les analyses (lors de post mortem…)
  • Faciliter les « Time To Recovery » : dans le pire des cas, il est possible de remonter une infrastructure « from scratch ». C’est intéressant si l’on commence à penser « recovery ». A l’instar de ce qu’indiquent les idées autour du « Recovery Oriented Architecture », la résilience peut s’adresser soit en cherchant à faire des systèmes ne tombant jamais en panne (on travaille alors sur le MTBF – Mean Time Between Failure), soit en accélérant le temps de réparation (on travaille alors sur le MTTR – Mean Time To Recovery). Il y a fort à parier que la seconde approche, même si elle n’est pas possible dans tous les cas, soit économiquement avantageuse. C’est également intéressant dans des organisations où sont nécessaires de nombreux environnements. Dans ces organisations, ces nombreux environnements sont maintenus disponibles et faiblement utilisés essentiellement car les temps de mise à disposition sont prohibitifs.

C’est également au travers de l’automatisation qui pourra s’amorcer un changement de culture dans la collaboration entre dev et ops. L’automatisation permet d’offrir plus de self-service aux équipes de « devs » – a minima sur les environnements ante-prod : un accès en lecture sur des machines ou uniquement aux logs, la possibilité de monter eux-mêmes les environnements d’intégration avec les données de la production à J-1….autant de gains de souplesse pour les « dev », autant de choses que les « ops » n’ont plus à faire.

2. « Continuous delivery »

Classiquement et dans nos organisations, la frontière entre les populations « dev » et « ops » se concrétise par la phase de déploiement où les études « livrent » ou parfois se « débarrassent » de leur code et où ce dernier va suivre un long chemin au travers des couloirs de la MEP (Mise En Production).

Cette citation de Poppendieck (« From Concept To Cash ») résume à merveille l’enjeu qui est soulevé :

« How long would it take your organization to deploy a change that involves just one single line of code? »

Les réponses sont bien entendues moins évidentes et c’est finalement là que se cristallise la divergence d’objectifs. Les études voudraient la main sur une partie de l’infrastructure, pouvoir déployer rapidement, à la demande sur tous les environnements. A l’inverse, la production a le souci des environnements, de la rationalisation des coûts, de l’utilisation des ressources (bande passante, CPU…).

L’autre ironie est que moins on déploie, plus les TTR (Time To Repair) augmentent et donc diminuent la qualité de service rendu au client final.

Figure 4. Source : http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108

Autrement dit, plus les modifications apportées entre deux mises en production sont grandes (ie. le volume de code modifiée est important), plus la capacité à corriger rapidement un problème survenu suite au déploiement (donc la phase d’instabilité tant redoutée par les « Ops ») diminue (et donc le TTR augmente).

Là encore travailler sur ce gâchis permet de diminuer la part liée au « Incident Management » de la figure 2.

Figure 5. Source : http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108

Pour finir, la figure 5, issue d’une étude de Flickr, montre la corrélation entre les TTR (et donc la sévérité des incidents) en fonction du volume de code déployé (et donc de la quantité de changement introduit).

Néanmoins, mettre en production en continu n’est pas aisé et requiert :

  • L’automatisation des processus de déploiement  et d’approvisionnement : « Infrastructure As Code »
  • L’automatisation de la chaîne de construction logicielle et de déploiement. L’usine de développement  devient la chaîne de fabrication qui emmène le logiciel de la gestion des sources aux différents environnements sur lesquels le logiciel est déployé. Une nouvelle génération d’usine de développement est nécessaire incluant la gestion des environnements, la gestion des workflows pour faciliter l’avancée des binaires dans le couloir de MEP, des fonctionnalités d’audit et de reporting pour comprendre et analyser ce qui s’est passé, la capacité à distribuer les tests pour toujours garantir des temps de cycle court…
  • La prise en compte de ces problématiques dans les architectures et notamment le respect d’un principe : décorréler le déploiement des fonctionnalités du déploiement du code avec des patterns comme « feature flipping », « dark launch »… Une complexité certes nouvelle mais qui offre le niveau de souplesse nécessaire à ce type de déploiements fréquents
  • Une culture de la mesure qui redonnera des lettres de noblesse à des développements souvent négligés : les métriques. Car il ne s’agit pas que de mesurer la consommation CPU mais de mettre en corrélation des métriques métiers et applicatives pour comprendre et anticiper les comportements du système.

3. Une culture de la collaboration voire un modèle organisationnel

Ces deux pratiques que sont « Infrastructure as Code » et « Continuous Delivery » peuvent être mises en œuvre dans l’organisation telle qu’elle existe traditionnellement (« Infrastructure as Code » chez les ops, « Continuous Delivery » chez les dev). Cependant, une fois que les études et la production auront atteint leur optimum local et un bon niveau de maturité, ces dernières se retrouveront toujours contraintes par cette frontière organisationnelle.

C’est là que le troisième pilier prend tout son sens ; une culture de la collaboration, voire de la coopération, permettant d’autonomiser les équipes et ne plus les rendre interdépendantes/bloquantes d’un point de vue opérationnel. Par exemple pour les « dev », un accès aux logs en lecture sur des machines, la possibilité de monter eux-mêmes les environnements d’intégration avec les données de la production à J-1, l’ouverture aux métriques et aux outils de supervision (voire l’affichage de ces métriques dans les open space)… Autant de gain de souplesse pour les « dev », autant de responsabilisation et de partage de « ce qu’il se passe en prod », autant de tâches à peu de valeur ajoutée  que les « ops » n’ont plus à faire.

Les principaux éléments de culture autour de devops peuvent se résumer ainsi :

  • Le partage des métriques aussi bien techniques (augmentation des temps de réponse, du nombre d’enregistrements, …) que business (évolution du CA généré, …).
  • Les « ops » sont également des clients de l’application. Cela peut nécessiter des évolutions des architectures applicatives et des développements pour faciliter l’intégration aux outils de supervision, pour avoir des logs pertinents et utilisables ; qui aident aux diagnostics (et diminue les TTD (Time To Diagnose). Pour aller plus loin, certains besoins des « ops » devraient être exprimés en tant que user story dans le backlog.
  • Des approches lean [https://blog.octo.com/tag/lean/] et des post mortems qui se concentrent sur les causes profondes (5 pourquoi…) et la mise en place de contre mesures.

Reste que dans ce modèle les zones de responsabilités (principalement le développement, la supervision applicative, le support et l’exploitation des data centers) existantes sont quelque peu remises en cause.

Les organisations classiques privilégient l’équipe projet. Dans ce modèle, les processus de déploiement, de supervision applicative et de gestion des datacenters sont répartis sur plusieurs organisations.

Figure 6 : L’équipe projet

A l’inverse, certains acteurs (notamment Amazon) ont poussé ce modèle organisationnel très loin en proposant des équipes multi-disciplinaires qui sont responsables du bon fonctionnement du service (vu du client).

« You build it, you run it ». Autrement dit, chaque équipe est responsable du métier, du « dev » et des « ops » c’est-à-dire de l’exploitation (déploiement, supervision) de l’application en production.

Figure 7 : L’équipe produit : « You build it, you run it »

C’est par ailleurs dans ce type d’organisation que les notions de « self-service » prennent un sens différent et fondamental. Une équipe responsable de l’application et de son fonctionnement, une équipe responsable des datacenters. Une frontière placée plus « en aval » que ce que l’on fait traditionnellement qui permet le passage à l’échelle et assure l’équilibre entre agilité et rationalisation des coûts (notamment lié aux infrastructures datacenters). Le Cloud AWS est très certainement né de là…C’est une autre histoire mais imaginez une organisation en équipe produit et des équipes de production qui proposent une offre de service (au sens ITIL) comme AWS ou Google App Engine…

Conclusion

DevOps n’est donc rien d’autre qu’un ensemble de pratiques qui visent à trouver des leviers d’amélioration autour :

  • de l’outillage qui permet d’industrialiser l’infrastructure et de rassurer la production sur la façon dont cette infrastructure est utilisée par les études. C’est un des gènes du cloud : le « self-service ». Les offres de cloud public sont matures sur le sujet mais certaines offres (VMWare par exemple) visent à reproduire ces modes de fonctionnement en interne. Mais sans forcément aller à ces niveaux de maturité, on peut imaginer l’utilisation d’outils type Puppet, Chef ou CFEngine…
  • de l’architecture qui peut permettre de décorréler les cycles de déploiements, de déployer du code sans pour autant déployer la fonctionnalité…
  • de l’organisationnel qui amène à implémenter les patterns d’Amazon “two pizzas team” et “you build it, you run it”
  • des processus et méthodologies qui permettent de fluidifier tous ces échanges. Comment déployer plus souvent ? Comment limiter ces risques en déployant progressivement ? Comment appliquer les leçons de « flux » tirées de Kanban à la production ? Comment repenser les mécanismes de communication et de coordination à l’œuvre sur la frontière études/production ?

En définitive ces 4 axes permettent d’atteindre les objectifs de DevOps : améliorer la collaboration, la confiance et l’alignement d’objectifs entre les études et la production et travailler en priorité sur les douleurs à adresser, synthétisées sur la figure ci-dessous.

Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"

Références