DevOps

ORGANISATION / DEVOPS

Description
Le mouvement DevOps nous invite repenser la frontire classique
de nos organisations qui sparent dun ct les tudes, i.e. ceux qui
crivent le code des applications (les devs ) et de lautre ct la pro-
duction, i.e. ceux qui dploient et exploitent ces applications (les ops ).

Ces rflexions sont certainement aussi anciennes que les DSIs mais
elles trouvent un peu de fracheur grce notamment deux groupes.
Dun ct les agilistes qui ont lev la contrainte ct dveloppement,
et sont maintenant capables de livrer beaucoup plus souvent du logiciel
valoris par le client de lautre, des experts ou des managers de la
prod des gants du Web (Amazon, Facebook, LinkedIn) partageant
leurs retours dexprience et la faon quils ont daborder la frontire
dev et ops .

Au-del de la beaut intellectuelle de lexercice, DevOps travaille surtout

(oserais-je dire uniquement) sur la rduction du TTM (Time To Market). Il
y a certes dautres effets positifs mais lenjeu dordre un, au final, reste
bien ce fameux Time To Market (pas trs tonnant dans lindustrie
du Web).

Dev & Ops : des proccupations locales distinctes mais

un objectif commun
Au-del des fractures organisationnelles, les proccupations des tudes
et de la production sont bien distinctes et respectivement louables :

DevOps
mur de la confusion

Livrer de nouvelles Garantir le run des

Objectifs locaux
fonctionnalits (de qualit) applications (stabilit)

Cultures Culture de Service (archivage,

Culture du Produit (logiciel)
diffrentes supervision, etc.)

Cherche innover Cherche rationaliser

Figure 1.

> retour table des matires

65
LES GANTS DU WEB

Les tudes recherchent plus de ractivit (sous la pression du mtier et du

march notamment) : il faut aller vite, ajouter de nouvelles fonctionnalits,
rorienter les directions, refactorer, upgrader les frameworks, dployer
rapidement sur de nouveaux environnements pour tester Cest la nature
mme du code ( software ) : mallable, adaptable.

A linverse, la production a besoin de stabilit et de standardisation.

Stabilit, car il est souvent difficile danticiper quels impacts aura telle
modification de code, darchitecture ou dinfrastructure : un disque local
qui devient un disque rseau mais impacte les temps de rponse, ou bien
un changement de code qui impacte fortement la consommation CPU et
par l mme le capacity planning.

Standardisation enfin, car la production veut sassurer que certaines

rgles (configuration des machines, versions logicielles, scurit rseau,
configuration des fichiers de logs) sont uniformment respectes pour
assurer la qualit de service de linfrastructure.

Reste que ces deux groupes, devs et ops ont pourtant bien un
objectif commun : faire fonctionner le systme vu du client final.

DevOps, dans la continuit de lAgile

LAgile est apparu en France il y a maintenant plus de dix ans avec

comme principal objectif de lever la contrainte autour du processus de
dveloppement.

Cette mthodologie introduisait les notions de cycles courts, de feedback

terrain et client, la notion de Product Owner, une personne du mtier
responsable de la roadmap, des priorisations

LAgile a galement mis mal lorganisation traditionnelle (dans les DSI

franaises tout du moins) en introduisant des quipes pluri-disciplinaires
(du mtier aux dveloppeurs) et challengeant du mme coup les
dcoupages organisationnels.

Aujourdhui, lorsque ces contraintes sont leves, les dveloppements

suivent le plus frquemment des itrations de une deux semaines. Les
mtiers voient le logiciel voluer durant la phase de construction.
Il est dornavant temps dimpliquer les personnes de la production sur les
phases suivantes :

> retour table des matires

66
 ORGANISATION / DEVOPS

Approvisionnement / mise en place des environnements : dans

la plupart des entreprises, lapprovisionnement dun environnement
peut demander de une quatre mois (pourtant aujourdhui en
environnement virtualis). Cest tonnamment long, surtout face
des challengers comme Amazon ou Google

Dploiement : cette phase est certainement celle qui cristallise le

plus le problme et cre le plus dinstabilit ; les quipes agiles
se limitent parfois un dploiement par trimestre pour limiter les
impacts en production et garantir la stabilit du systme, dautant
plus que ces dploiements sont souvent manuels (donc longs,
sources derreur), bref, risqus.

Rsolution dincidents et prise en compte des besoins non

fonctionnels : les acteurs de la production sont les autres utilisateurs
de lapplication. La facilit diagnostiquer, expliquer les problmes,
les enjeux de rsilience, robustesse doivent tre pris en compte.

DevOps sorganise autour de 3 piliers : Infrastructure as

Code (IaC), Continuous Delivery et culture de la coopration
1. Infrastructure as Code ou comment acclrer les phases
dapprovisionnement et de mise disposition des environnements.

Lun des points de friction les plus visibles dans le manque de collabo-
ration entre dev et ops se situe au niveau des phases de dploiement.
Cest dailleurs lactivit qui se montre tre la plus consommatrice en
ressources : la moiti du temps de la production est ainsi consomme
par le dploiement ou des problmes lis au dploiement.

Figure 2.
Source : Etude de Deepak Patil (Microsoft Global Foundation Services) de 2006,
via une prsentation de James Hamilton (Amazon Web Services), modifi
http://mvdirona.com/jrh/TalksAndPapers/JamesHamilton_POA20090226.pdf

> retour table des matires

67
LES GANTS DU WEB

Et mme sil est difficile de donner des rgles gnrales, il y a fort

parier quune partie de ce cot (le segment 31 %) peut diminuer via
lautomatisation de ce processus de dploiement.

Beaucoup doutils fiables existent aujourdhui pour automatiser les phases

dapprovisionnement et de mise disposition des environnements, allant
de linstanciation de Virtual Machines au dploiement applicatif, en
passant par la configuration systme.

Figure 3. Classement des principaux outils (octobre 2012).

Ces outils permettent le codage (dans des langages qui leur sont propres)
des infrastructures : installation et dmarrage dun service HTTP, du
serveur dapplication, cration des rpertoires pour les fichiers de logs
Les objectifs et les gains associs sont multiples :

Garantir un processus rptable et fiable (pas dintervention

humaine, qui est un facteur derreur) avec notamment la capacit
grer des mcanismes de retour arrire (rollback).

Productivit. One-click deployment (dploiement en un clic)

plutt quun ensemble de tches manuelles, ce qui permet daller
plus vite.

Traabilit permettant dexpliquer, de comprendre, de faciliter les

analyses (lors de post-mortem)

> retour table des matires

68
 ORGANISATION / DEVOPS

Diminuer le Time To Recovery : dans le pire des cas, il est

possible de remonter une infrastructure from scratch. Cest
intressant si lon commence penser recovery. A linstar de ce
quindiquent les ides autour du Recovery Oriented Architecture, la
rsilience peut sadresser soit en cherchant faire des systmes ne
tombant jamais en panne (on travaille alors sur le MTBF Mean
Time Between Failure), soit en acclrant le temps de rparation
(on travaille alors sur le MTTR Mean Time To Recovery). Bien que
souvent la seconde approche, mme si elle nest pas possible dans
tous les cas, est conomiquement avantageuse. Cest galement
intressant dans des organisations o sont ncessaires de
nombreux environnements. Dans ces organisations, cette multitude
denvironnements est maintenue disponible et faiblement utilise
essentiellement car les temps de mise disposition sont prohibitifs.

Cest galement au travers de lautomatisation que pourra samorcer un

changement de culture dans la collaboration entre dev et ops. Lautomati-
sation permet doffrir plus de self-service aux quipes de devs a minima
sur les environnements ante-prod.

2. Continuous Delivery

Classiquement et dans nos organisations, la frontire entre les populations

dev et ops se concrtise par la phase de dploiement o les tudes livrent
ou parfois se dbarrassent 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 Mary et Tom Poppendieck[1] rsume merveille lenjeu

qui est soulev :

How long would it take your organization

to deploy a changethat involves just one single line of code?

Les rponses sont, bien entendu, moins videntes et cest finalement

l que se cristallise la divergence dobjectifs. Les tudes voudraient la
main sur une partie de linfrastructure, pouvoir dployer rapidement, la
demande sur tous les environnements. linverse, la production a le souci
des environnements, de la rationalisation des cots, de lutilisation des
ressources (bande passante, CPU).

[1] Mary et Tom Poppendieck, Implementing Lean Software Development: From Concept to
Cash, Addison-Wesley, 2006.

> retour table des matires

69
LES GANTS DU WEB

Lautre ironie est que moins on dploie, plus les TTR (Time To Repair)
augmentent et donc rduisent la qualit de service rendu au client final.

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

Autrement dit, plus les modifications apportes entre deux mises en

production sont grandes (i.e. le volume de code modifi est important),
plus la capacit corriger rapidement un problme survenu suite au
dploiement donc la phase dinstabilit tant redoute par les ops
diminue, et donc plus le TTR augmente.

L encore, travailler sur ce gchis permet de diminuer la part lie

lIncident Management de la figure 2.

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

> retour table des matires

70
 ORGANISATION / DEVOPS

Pour finir, la figure 5, issue dune tude de Flickr, montre la corrlation

entre les TTR (et donc la svrit des incidents) en fonction du volume de
code dploy (et donc de la quantit de changement introduit).

Nanmoins, mettre en production en continu nest pas ais et requiert :

Lautomatisation des processus de dploiement et dapprovision-

nement : Infrastructure as Code .

Lautomatisation de la chane de construction logicielle et de d-

ploiement. Lusine de dveloppement devient la chane de fabrica-
tion qui emmne le logiciel de la gestion des sources jusquaux
diffrents environnements sur lesquels le logiciel sera dploy.
Une nouvelle gnration dusine de dveloppement est donc
ncessaire, incluant la gestion des environnements, la gestion
des workflows pour faciliter lavance des binaires dans le couloir
de MEP, des fonctionnalits daudit et de reporting pour com-
prendre et analyser ce qui sest pass, la capacit distribuer les
tests pour rduire leur dure dexcution et toujours garantir des
temps de cycle courts

La prise en compte de ces problmatiques dans les architectures et

notamment le respect dun principe : dcorrler le dploiement des
fonctionnalits du dploiement du code avec des patterns comme
Feature flipping (cf. Feature flipping p. 107), dark launch
Une complexit certes nouvelle mais qui offre le niveau de souplesse
ncessaire ce type de dploiements frquents.

Une culture de la mesure avec des mtriques orientes usage. Car

il ne sagit pas uniquement de mesurer la consommation CPU mais
de mettre en corrlation des mtriques mtiers et applicatives pour
comprendre et anticiper les comportements du systme.

3. Une culture de la collaboration voire un modle organisationnel

Ces deux pratiques que sont Infrastructure as Code et Continuous

Delivery peuvent tre mises en uvre dans lorganisation telle quelle
existe traditionnellement ( Infrastructure as Code chez les op s ,
Cont inuous Delivery chez les devs). Cependant, une fois que
les tudes et la production auront atteint leur optimum local et un bon
niveau de maturit, ces dernires se retrouveront toujours contraintes par
cette frontire organisationnelle.

> retour table des matires

71
LES GANTS DU WEB

Cest l que le troisime pilier prend tout son sens ; une culture de la
collaboration, voire de la coopration, permettant dautonomiser les
quipes et ne plus les rendre interdpendantes/bloquantes dun point
de vue oprationnel. Par exemple, pour les devs, un accs aux logs
en lecture sur des machines, la possibilit de monter eux-mmes les
environnements dintgration avec les donnes de la production J-1,
louverture aux mtriques et aux outils de supervision (voire laffichage
de ces mtriques dans les open spaces) Autant de gain de souplesse
pour les devs, autant de responsabilisation et de partage de ce quil se
passe en prod , autant de tches peu de valeur ajoute que les ops
nont plus faire.

Les principaux lments de culture autour de DevOps peuvent se rsumer

ainsi :

Le partage des mtriques aussi bien techniques (augmentation des

temps de rponse, du nombre denregistrements), que business
(volution du CA gnr)

Les ops sont galement des clients de lapplication. Cela peut

ncessiter des volutions des architectures applicatives et
des dveloppements pour faciliter lintgration aux outils de
supervision, pour avoir des logs pertinents et utilisables, qui aident
aux diagnostics (et diminue le TTD, Time To Diagnose). Pour aller
plus loin, certains besoins des ops devraient tre exprims en tant
que user stories dans le backlog.

Des approches lean [http://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 modle, les zones de responsabilits (principalement

le dveloppement, la supervision applicative, le support et lexploitation
des datacenters) existantes sont quelque peu remises en cause.

Les organisations classiques privilgient lquipe projet. Dans ce modle,

les processus de dploiement, de supervision applicative et de gestion
des datacenters sont rpartis sur plusieurs organisations.

> retour table des matires

72
 ORGANISATION / DEVOPS

Figure 6 : Lquipe projet.

linverse, certains acteurs (notamment Amazon) ont pouss ce modle

organisationnel trs loin en proposant des quipes multi-disciplinaires
qui sont responsables du bon fonctionnement du service vu du client
(cf. Feature Teams p. 57).
You build it, you run it . Autrement dit, chaque quipe est responsable
du mtier, du dev et des ops.

Figure 7 : Lquipe produit You build it, you run it .

> retour table des matires

73
LES GANTS DU WEB

Cest par ailleurs dans ce type dorganisations que les notions de self-
service prennent un sens diffrent et fondamental. On observe alors des
quipes responsables de lapplication et de son fonctionnement, et
une quipe responsable des datacenters. La frontire est place plus
en aval que ce que lon fait traditionnellement, ce qui permet le pas-
sage lchelle et assure lquilibre entre agilit et rationalisation des
cots (notamment li aux infrastructures datacenters). Le Cloud AWS est
trs certainement n de l Cest une autre histoire mais imaginez une
organisation en quipes produits et des quipes de production qui pro-
posent une offre de service (au sens ITIL) comme AWS ou Google App
Engine

Conclusion
DevOps nest donc rien dautre quun ensemble de pratiques qui visent
trouver des leviers damlioration autour :

De loutillage qui permet dindustrialiser linfrastructure et de

rassurer la production sur la faon dont cette infrastructure est
utilise par les tudes. Cest lun des gnes 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 forcment aller
ces niveaux de maturit, on peut imaginer lutilisation doutils type
Puppet, Chef ou CFEngine

De larchitecture qui permet de dcorrler les cycles de

dploiements, de dployer du code sans pour autant dployer
la fonctionnalit (cf. Feature flipping p. 107 et Continuous
Deployment p.99).

De lorganisationnel qui amne implmenter les patterns dAmazon

Pizza teams (cf. Pizza Teams p. 51) et You build it, you run it .

Des processus et mthodologies qui permettent de fluidifier tous

ces changes. Comment dployer plus souvent ? Comment limiter
ces risques en dployant progressivement ? Comment appliquer
la production les leons de flux issues de Kanban ? Comment
repenser les mcanismes de communication et de coordination
luvre sur la frontire tudes/production ?

> retour table des matires

74
 ORGANISATION / DEVOPS

En dfinitive ces 4 axes permettent datteindre les objectifs de DevOps :

amliorer la collaboration, la confiance et lalignement dobjectifs entre les
tudes et la production et travailler en priorit sur les douleurs adresser,
synthtises sur la figure 8.

Figure 8.

> retour table des matires

75
LES GANTS DU WEB

Sources
White paper DevOps Revolution :
> http://www.cutter.com/offers/devopsrevolution.html

Article Wikipedia :
> http://en.wikipedia.org/wiki/DevOps

Prsentation Flickr la confrence Velocity 2009 :

> http://velocityconference.blip.tv/file/2284377/

Dfinition DevOps par Damon Edwards :

> http://dev2ops.org/blog/2010/2/22/what-is-devops.html

Article de John Allspaw sur DevOps :

> http://www.kitchensoap.com/2009/12/12/devops-cooperation-doesnt-
just-happen-with-deployment/

Article sur la part de lactivit de dploiement dans les tches des Ops :
> http://dev2ops.org/blog/2010/4/7/why-so-many-devopsconversations-
focus-on-deployment.html

USI 2009 :
> http://www.usievents.com/fr/conferences/4-usi-2009/sessions/797-
quelques-idees-issues-des-grands-du-web-pour-remettre-en-cause-vos-
reflexes-d-architectes#webcast_autoplay

> retour table des matires

76