DevOps : le mouvement qui tend à “Agilifier” votre DSI

La communauté "DevOps" nous invite à repenser la frontière classique de nos organisation, séparant d'un côté les études, i.e. ceux qui écrivent le code (le “Build”) et de l'autre côté la production, i.e. ceux qui déploient et exploitent ces applications (le “Run”).

2 groupes se retrouvent dans le mouvement DevOps et apportent un peu de fraicheur dans ces réflexions aussi anciennes que les DSIs :

• les agilistes qui ont levé la "contrainte" côté développement, et sont maintenant capable de "livrer" beaucoup plus souvent du logiciel valorisé par le client...mais regrettent que "la prod ne suive pas"
• des experts ou des managers de la "prod" des grands du web (Amazon, Facebook, LinkedIn...) partageant leurs retours d'expérience sur leur façon d'envisager cette frontière

Au delà des fractures organisationnelles, les préoccupations des études et de la production sont bien distinctes et respectivement louables. 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 pour tester...La nature même du code (“Soft”) est celle ci : malé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 l’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 la même le “capacity planning”. Standardisation enfin car la production veut s’assurer que certaines règles (sécurité réseaux, configuration des fichiers de logs...) sont uniformément respectées.

Très souvent, la frontière entre ces deux populations 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 Mise En Production. Et ce point précis cristallise la divergence d’objectifs. Les études voudraient la main sur une partie de l’infrastructure, pouvoir déployer rapidement, à demande et simplement sur les environnements (a minima ceux de “tests” au sens large). A l’inverse, la production a le souci des environnements, de l’utilisation des ressources, de la consommation de bande passante et de la fiabilité en général. Ce que veut la production : des fichiers de log standards, une configuration du serveur HTTP identique...

**Sauf que ces deux groupes ont un objectif commun : faire fonctionner le système...**et finalement le déploiement n’est pas le plus important dans cette problématique même si c’est certainement une des activités les plus consommatrices en ressource : la moitié du temps de la production est ainsi consommée par le déploiement ou des problèmes liés au déploiement.

C’est donc certainement le premier levier d’amélioration mais non l’unique. Damon Edwards et John Allspaw nous rappellent :

• qu’il s’agit de partager des métriques et d’être capable de transformer des variables techniques (augmentation des temps de réponse...) en variables business (baisse du CA généré...). Et qu’une des clés du succès d’interprétation de ces métriques est la collaboration entre les études (la compréhension du code) et la production (la compréhension des serveurs, du réseau...)
• “qu’agilifier” le processus de développement c’est bien mais que le véritable enjeu c'est l'agilité "business" qui passe par la réduction du délai global “from concept to cash”, de l’idée à la mise au production. Cela passera entre autres par des déploiements plus “agiles”, sur l'exemple de Flickr, qui réalise 10 déploiements quotidiens

Atteindre cet objectif ne se fera pas sans douleur et trouve des leviers d’amélioration dans 4 axes :

• de l’outillage qui permettra 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 vous amènera peut-être à vous aussi implémenter les patterns d’Amazon “two pizzas team” et “you build it, you run it”
• du processus qui permettra de fluidifier tous ces échanges. Comment déployer plus souvent ? Comment limiter ses 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'oeuvre sur la frontière études/production ?

En définitive ces 4 axes nous permettront d'atteindre les objectifs supérieurs de DevOps : améliorer la collaboration, la confiance et l'alignement d'objectifs entre les études et la production.