Les Geants Du Web

Les Gants
du Web
Culture Pratiques Architecture
Les Gants
du Web
Table des Matires
Prface................................................................................................................ 6 Introduction..................................................................................................... 8 Culture............................................................................................................. 11 Lobsession de la mesure............................................................13 Build vs Buy.........................................................................................19 Fluidit de lexprience utilisateur........................................27 Les artisans codeurs.......................................................................33 Contribution au logiciel libre....................................................41 Organisation................................................................................................ 49 Pizza Teams.........................................................................................51 Feature Teams...................................................................................57 DevOps.................................................................................................63 Pratiques........................................................................................................ 79 Lean Startup.......................................................................................81 Minimum Viable Product.............................................................89 Continuous Deployment.............................................................99 Feature Flipping............................................................................ 107 Test A/B.............................................................................................. 117 Device Agnostic............................................................................ 123 La bta perptuelle..................................................................... 131 Architecture............................................................................................... 139 Cloud First........................................................................................ 141 Commodity Hardware............................................................... 151 Sharding............................................................................................. 163 TP vs BI : la nouvelle approche NoSQL.......................... 179 Design for Failure......................................................................... 189 Open API ou cosystme ouvert................................. 195 propos dOCTO Technology..................................................... 202 Auteurs......................................................................................................... 203
LES GANTS DU WEB
Prface
Les entreprises traditionnelles voient encore parfois linformatique comme un moyen : un moyen pour baisser les cots, un moyen pour produire plus, un moyen pour vendre diffremment, mais toujours un moyen, un outil la marge. Pour les entreprises du Web, les technologies de linformation sont au cur mme du produit, elles sont le produit. Cest la comprhension de cette simple diffrence, qui induit invitablement des carts voire des fosss dans les mentalits et les pratiques. Louvrage dOCTO dtaille avec prcision certaines caractristiques qui participent de cette prise de conscience et qui font la force des Gants du Web, dans lesquels jose inclure Viadeo. Jaimerais insister sur trois perspectives fondamentales, qui seront approfondies tout au long de ce recueil. La premire et la plus fondamentale est la dimension humaine. Il ny a de bonnes organisations que celles qui placent lhomme au cur de leur dispositif. Les artisans qui crent, inventent, et ralisent le produit sont autant de personnes responsables, professionnelles, cratives et qui ne pourront pleinement sexprimer et se raliser que dans une certaine autonomie de la ralisation de leur art. Chez Viadeo, nous visons par exemple appliquer le Principe de Subsidiarit notre organisation de dveloppement produit, qui consiste pousser la prise de dcision au plus prs des personnes et des quipes directement en charge de leur ralisation ; le management est leur service pour suppler lorsque la dcision ncessite dautres moyens ou implique dautres acteurs. Il sagit dun renversement de paradigme qui implique dabandonner la vision top-down o le management dcide, contrle et dlgue tout en grant son territoire , au profit dune grande responsabilisation de chacun des acteurs, leur mise en synergie, et leur amlioration continue par des changes au sein de communauts de pratiques. Le deuxime axe est li au produit lui-mme : la mesure. Nous avons en effet lopportunit et la chance de pouvoir tout mesurer, ou presque, dun produit informatique. Je tempre toutefois cette obsession de la mesure car selon moi, tout piloter par la donne et uniquement par la donne aboutit des amliorations locales mais non globales. Piloter par la donne, oui, mais au service dune vision stratgique et innovante, qui elle, mane de la crativit humaine.
> retour table des matires
PRFACE
Enfin, le troisime enjeu est le rythme. Pour les entreprises du Web, lenjeu est bien souvent dinventer de nouveaux usages et de nouveaux marchs. Ceci inclut de dcouvrir ses utilisateurs, trouver lusage qui leur rend la vie plus simple ou leur cre de la valeur. Ces dcouvertes se font essentiellement par ttonnement, il est donc impratif dentretenir des cycles courts et de mettre en place des pratiques comme le test A/B , le Minimum Viable Product , le dploiement continu, et toujours valider nos inspirations au principe de ralit, fourni par la donne. Vous laurez compris, les pratiques qui suivent font cho de faon surprenante celles que lon retrouve dans une entreprise comme Viadeo : nous implmentons beaucoup de ce qui va suivre, et le reste est dj en cours. Que vous montiez votre start-up web ou que vous soyez DSI dun grand groupe, vous trouverez dans ces pages un matriel prcieux pour vous hisser sur les paules des Gants. Jean-Marc Potdevin, Chief Operations Officer, Viadeo
LES GANTS DU WEB
Introduction
Il se passe, en ce moment mme, quelque chose dextraordinaire, presque une rvolution. De lautre ct de lAtlantique, mais aussi dautres endroits du monde comme en France, des gens sont en train de rinventer la faon de faire de linformatique. Ils sappellent Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus. Cette nouvelle gnration dacteurs a su se librer des dogmes du pass et aborder les sujets avec fracheur pour apporter des solutions nouvelles, radicales, efficaces de vieux problmes de linformatique. Nous autres, informaticiens, nous savons tous que lorsque lon introduit loutil informatique dans un mtier, on ne tire les bnfices de cette informatisation qu la condition de repenser les processus mtier la lumire des potentialits offertes par la technologie. Il restait pourtant un mtier qui avait chapp cette remise plat complte des faons de travailler : celui de linformatique. Nous continuions, et nous continuons encore souvent, construire des systmes dinformation comme lon construit des ponts ou des autoroutes. Nous avions oubli que la matire que nous manipulons quotidiennement est lune des plus instables qui soit. A force dentendre parler de la loi de Moore [1], nous en avions oubli le sens : ce qui tait infaisable lanne dernire est possible aujourdhui, et ce que nous ne pouvons pas faire aujourdhui sera possible demain. Nous sommes dans un cosystme o les croyances et les habitudes sont challenger intervalles rguliers. Cest la fois terrible et fantastique. Maintenant que les pionniers ont montr la voie, nous ne pouvons continuer travailler comme avant. Car ces nouvelles approches offrent une puissance de feu, une efficacit, une ractivit et une capacit dinnovation que des concurrents sapproprieront si nous ne le faisons pas avant eux. Lexcellente nouvelle est que ces gants du Web qui tracent la voie partagent la vision dune informatique communautaire. Ils sinvestissent dans lOpen-Source, communiquent sur leurs pratiques pour sduire les recrues potentielles, travaillent en troite collaboration avec les milieux de la recherche. Si bien que linformation publique sur leurs faons de travailler est trs largement disponible qui prend le temps de sy plonger.
[1] loi empirique qui stipule que toute ressource informatique double de capacit prix constant tous les 18 mois.
INTRODUCTION
Lobjectif de cet ouvrage est de proposer une synthse sur les pratiques, les solutions technologiques et les traits culturels les plus saillants. En esprant que cela puisse inspirer nos lecteurs pour contribuer une informatique qui transforme nos socits.
Cet ouvrage est conu la fois pour une lecture linaire et une lecture par thme. Le lecteur qui choisira la premire option pourra donc y trouver quelques redites.
Culture
LES GANTS DU WEB
Lobsession de la mesure.................................................................. 13 Build vs Buy..................................................................................... 19 Fluidit de lexprience utilisateur..................................................... 27 Les artisans codeurs......................................................................... 33 Contribution au logiciel libre............................................................. 41
12
Lobsession de la mesure
LES GANTS DU WEB
CULTURE / LOBSESSION DE LA MESURE
14
Description
En informatique, nous connaissons tous des citations qui rappellent limportance de la mesure :
Ce qui ne se mesure pas, ne se pilote pas, sans mesure, tout nest quopinion.
Les gants du Web ont pouss cette logique lextrme et ont, pour la plupart, dvelopp une culture pousse de la mesure. La structure mme de leurs activits les conduit trs naturellement ce tropisme. Elles ont en effet souvent 3 caractristiques : L informatique est loutil de production de ces entreprises. Leurs cots sont donc directement corrls lutilisation optimale des machines et du logiciel. Et toute amlioration du nombre dutilisateurs simultans ou de lutilisation des processeurs a un ROI rapide. Les revenus sont directement corrls lefficacit du service informatique rendu. Par consquent, lamlioration du taux de conversion a un ROI rapide. Ils ont des ordinateurs partout ! Or, ce sont de trs bons instruments de mesure. Autant essayer de sen servir !
Ainsi, les gants du Web ont pour la plupart pris lhabitude de tout mesurer : les temps de rponses, les pages les plus vues, les articles (de contenu ou de vente) qui fonctionnent le mieux, le temps pass sur chaque page Bref, du classique premire vue. Mais pas seulement ! Ils mesurent aussi la chaleur dgage par tel processeur, la consommation lectrique de tel transformateur, le temps moyen entre deux pannes de tel disque dur (le MTBF, Mean Time Between Failure)[1] et cest sur cette base quils construisent des infrastructures optimisant lefficacit nergtique de leurs installations (le PUE Power Usage Effectiveness suivi de trs prs par ces acteurs). Et ils ont surtout appris baser leurs plans dactions sur cette masse dinformations.
[1] > http://storagemojo.com/2007/02/19/googles-disk-failure-experience
15
LES GANTS DU WEB
Le test A/B (cf. Test A/B p. 117), qui consiste tester sur des groupes de clients diffrents des versions diffrentes dune application, participe de cette tendance. A fonctionne-t-elle mieux que B ? La meilleure faon de le savoir reste encore de le mesurer objectivement. Avec des rsultats qui dfient parfois le sens commun et qui illustrent les limites de la rflexion en chambre, comme le montre le site www.abtests.com, qui rfrence des rsultats de tests A/B. Lors dune interview, Yassine Hinnach, alors Senior Engineer Manager chez LinkedIn, nous confiait que les quipes de LinkedIn sont encourages tester rapidement toute technologie susceptible damliorer les performances du site. Les dcisions dapprofondissement se font alors sur la base des mtriques constates. Le site HighScalability.com a publi un article prsentant les recettes du succs dAmazon et bas sur des interviews de son CTO. Parmi les citations marquantes, celle-ci a retenu notre attention :
Everyone must be able to experiment, learn, and iterate. Position, obedience, and tradition should hold no power. For innovation to flourish, measurement must rule.[2]
Pour donner un autre exemple de cette approche, voici ce que dit Timothy B. Lee, journaliste Wired et au New York Times, de la culture de la mesure chez Google.
Plutt que davoir une connaissance intime de ce que leurs subordonns font, les cadres de Google se basent sur des mesures quantitatives pour valuer la performance de lentreprise. Lentreprise conserve des statistiques sur tout nombre de chargements de pages, taux de pannes, taux de clics, etc. et travaille avec lobsession damliorer ces chiffres. Lobsession du management par la mesure diffuse jusquaux snacks pour les petites faims, qui sont choisis sur une analyse dtaille des usages et des rsultats de sondages.[3]
[2] > http://highscalability.com/amazon-architecture [3] > http://arstechnica.com/apple/news/2011/06/fourth-times-a-charm-why-icloud-faceslong-odds.ars
16
La consquence de ce mode de fonctionnement est profonde. On a pu ainsi lire dans les bureaux de certains pure players In God we trust. Everything else, we test . Au del du clin dil Deming[4], cest une approche profondment pragmatique des problmes qui est ainsi vhicule. Une concrtisation extrme de cette tendance, qui frise la caricature, est linitiative Oxygen de Google : une quipe interne de statisticiens a dissqu le matriel RH disponible dans lentreprise (revues annuelles des collaborateurs, enqutes de satisfaction, nominations pour les prix de managers) pour en extraire les pratiques managriales les plus efficaces. Et a nonc cette suite les 8 rgles du bon manager. leur lecture, nimporte quel manager expriment pourrait considrer que Google a rinvent leau chaude du management. Mais la diffrence, cest quils lont statistiquement prouv par des mtriques[5] !
Et chez moi ?
La culture franaise apprcie les modles et nous conduit donc souvent tre moins pragmatiques que les anglo-saxons. Notre conviction est que cette boucle de feedback rapide hypothse a mesure a dcision devrait tre un rflexe quasi-systmatique dans le monde de la DSI, lequel peut tre mis en uvre ds demain Lauteur de ces lignes a le souvenir encore douloureux de 2 fois 4 heures de runion 10 personnes pour savoir si le passage en HTTP des appels la couche service allait avoir un impact significatif sur les performances. 10 jours de travail dun dveloppeur auraient largement suffi ltablir pour un cot moindre Autre exprience vcue plusieurs fois par des consultants OCTO lors daudits : les performances de lapplication taient amliores lorsque lon dbranchait le cache qui avait t mis en uvre pour amliorer les performances ! Le remde avait t ainsi pire que le mal et son efficacit prsume, non mesure. Le management court le risque de tomber dans lillusion que ce travail danalyse des faits durs est ralis. Il peut tre bon de vrifier rgulirement que cest bien le cas et surtout que les informations issues
[4] In God we trust; all others must bring data , W. Edward Deming. [5] Adam BRYANT, Googles Quest to Build a Better Boss, The New York Times Company, March 12, 2011 : > http://www.nytimes.com/2011/03/13/business/13hire.html
17
LES GANTS DU WEB
des mesures sont bien prises en compte dans les dcisions. Malgr tout, on ne le dira jamais assez : une partie des recettes du succs des gants du Web vient avec un cosystme qui favorise leur application. Deux autres pratiques viennent ainsi tayer la culture de la mesure : Des tests automatiss : cest vert ou rouge, pas de discussion possible. Et du coup, on est sr que lon mesure toujours la mme chose. Des cycles courts. Pour mesurer et surtout pour interprter ces mesures, il faut tre capable de comparer des options, toutes choses tant gales par ailleurs . Ce point est particulirement crucial. Dans un contexte rcent, nous avons diagnostiqu les actions mises en uvre pour amliorer la performance dune application. Mais environ une dizaine dautres optimisations avaient t intgres la release venir. Comment alors distinguer les optimisations efficaces de celles contre-productives ?
18
Build vs Buy
CULTURE / BUILD VS BUY
Description
Un cart marquant entre la stratgie des gants du Web et celle des DSI dans lesquelles nous intervenons porte sur le sujet du Build vs Buy. Ce dilemme est vieux comme le monde de linformatique : vaut-il mieux investir dans la fabrication dun logiciel taill au mieux pour ses besoins ou bien sappuyer sur un progiciel et des outils prpackags qui embarquent la capitalisation et la R&D dun diteur (ou dune communaut) qui a le temps de creuser les sujets technologiques et mtier ? La plupart des grandes DSI franaises ont tranch et ont inscrit la progicialisation maximale dans leurs principes directeurs, partant souvent du principe que linformatique nest pas une activit cur de mtier pour elles et quil vaut mieux la laisser des acteurs spcialiss. Les acteurs du Web tendent faire exactement linverse, avec une certaine logique puisque, prcisment, linformatique est leur cur de mtier et, par consquent, trop stratgique pour tre laisse des tiers. Il y a donc une cohrence dans ces carts constats. Il est nanmoins intressant de pousser un cran plus loin lanalyse. Car les gants du Web ont quelques motivations supplmentaires : dune part la juste adquation et la matrise des solutions quils retiennent, et dautre part, les cots quand on passe lchelle ! Et ces motivations se retrouvent parfois au sein des DSI, ce qui peut justifier de limiter le recours des progiciels.
La juste adquation des solutions

Sur le premier point, lun des dfauts intrinsques du progiciel rside dans le fait quil constitue le PPCM des besoins habituellement constats chez les clients de lditeur[1]. Vos besoins particuliers ne sont par consquent quun sous-ensemble limit de la couverture du progiciel. Ainsi, prendre le parti du progiciel, cest accepter par dfinition davoir une solution trop lourde, trop complexe et non optimise pour rpondre au besoin que lon a ;
[1] On ninsistera pas ici sur le fait quil ne faut pas trop scarter du standard out of the box du progiciel sous peine de le payer trs (vraiment trs) cher sur le long terme, notamment lors des montes de version.
21
LES GANTS DU WEB
et que lon paye donc en excution et en complexit ce que lon gagne en nayant pas investir sur le design et la fabrication dune application complte. Ceci est particulirement frappant dans les modles de donnes des progiciels. Une grande partie de la complexit du modle est induite par le fait que le progiciel doit tre configurable pour sadapter diffrents contextes (Modle Conceptuel de Donnes trs normalis, tables dextensions, faible expressivit du modle car il sagit dun mta-modle). Mais les abstractions et lhyper-gnricit que cela implique dans le design du progiciel ont un cot sur les performances lexcution[2]. Dautre part, les gants du Web ont des contraintes en termes de volumtrie, de dbit de transactions et de nombre dutilisateurs simultans qui font exploser les approches traditionnelles darchitecture et qui requirent par consquent des optimisations extrmement fines en fonction des patterns daccs constats. Telle transaction trs sollicite en lecture ne sera pas optimise de la mme faon que telle autre dont lenjeu sera plutt le temps de rponse en criture. Bref, pour arriver de tels rsultats, il faut pouvoir soulever le capot et mettre les mains dans le moteur, ce qui nest prcisment pas possible avec du progiciel (pour lequel la garantie saute si on ouvre le botier). Ainsi la performance tant lune des obsessions des gants du Web, loverhead et les faibles possibilits doptimisation induits par la progicialisation ne sont tout simplement pas acceptables pour eux.
Les cots
Le deuxime point particulirement critique est bien sr le volet cot quand on passe lchelle. Quand on multiplie les processeurs et les serveurs, la facture grimpe trs vite et pas toujours linairement, et les cots deviennent ds lors trs visibles. Quil sagisse ici de progiciel mtier ou de brique dinfrastructure. Cest prcisment lun des arguments qui a conduit LinkedIn remplacer progressivement leur BDD Oracle par une solution maison, Voldemort[3].
[2] Quand il ne sagit pas de la lourdeur de lergonomie. [3] Yassine Hinnach, volution de larchitecture de LinkedIn, enjeux techniques et organisationnels, USI 2011 : > http://www.usievents.com/fr/conferences/8-paris-usi-2011/sessions/1007
22
De la mme faon, nous avons ralis une tude en 2010 sur les principaux sites e-commerce en France : la date de ltude, huit des dix plus gros sites (en termes de CA annuel) fonctionnaient sur une plateforme dveloppe en interne et 2 sur des progiciels de e-commerce. Les gants du Web prfrent donc le Build au Buy. Mais pas seulement. Ils ont aussi massivement recours lOpen-Source (cf. Contribution au logiciel libre p. 41). Linux et MySQL rgnent en matres chez beaucoup. Les langages et les technologies de dveloppement viennent quasisystmatiquement du monde ouvert : trs peu de .NET par exemple, mais du Java, du Ruby, du PHP, du C(++), du Python, du Scala... Et ils nhsitent pas forker partir de projets existants : Google travaille partir dun noyau Linux largement modifi[4]. Cest aussi le cas dun grand acteur franais dans le domaine du voyage. La plupart des technologies qui font le buzz aujourdhui dans le monde des architectures hautes performances sont le rsultat de dveloppements raliss par les gants du Web qui ont t mises en Open-Source. Cassandra, dvelopp par Facebook, Hadoop et HBase inspirs par Google et dvelopps chez Yahoo!, Voldemort par LinkedIn Une faon, au final, de combiner les avantages : un logiciel taill aux petits oignons pour ses besoins tout en bnficiant des contributions de dveloppement de la communaut, avec, en prime, un march qui se forme aux technologies que vous utilisez chez vous. Si lon reprend lexemple de LinkedIn, beaucoup des technologies utilises sappuient sur des solutions open-source du march : Zoie, recherche en temps rel base sur Lucene. Bobo, recherche facettes base sur Lucene. Azkaban, framework permettant de planifier des tches Hadoop et des dpendances entre tches. GLU, un framework de dploiement.
[4] > http://lwn.net/Articles/357658
23
LES GANTS DU WEB
Et chez moi ?
Et dans ma DSI, dois-je renoncer aux progiciels ? Evidemment non, pas pour tout. Le progiciel reste souvent pertinent : par exemple, il ne viendrait aujourdhui lide de personne de redvelopper un systme de paie pour ses besoins propres. Mais le dveloppement spcifique est envisager dans certains cas : quand loutil informatique est lune cl de russite dterminante pour votre mtier. La figure 1 donne des orientations en termes de stratgie.
Figure 1.
Lautre contexte dans lequel le spcifique peut simposer est celui des hautes performances : avec louverture des entreprises vers du tout Web , trs peu de progiciels mtier sont architecturs pour supporter le niveau de sollicitation que lon peut rencontrer sur des sites web fort trafic. Pour ce qui est des solutions dinfrastructure, lOpen-Source est devenu la norme : OS et serveurs dapplications en premier lieu. Bien souvent aussi, bases de donnes et bus de messages. LOpen-Source sait faire tourner les solutions des gants du Web. Leurs qualits de performance et de stabilit ne peuvent plus aujourdhui tre remises en cause. Reste le frein psychologique de labsence de support qui bloque encore beaucoup de dcideurs informatiques. Mais lorque lon investigue, en cas de problme sur un socle technique commercial, cest rarement le support de lditeur, pay au prix fort, qui fournit la solution, mais
[5] Business Process Outsourcing.
24
plutt le rseau des experts et les forums dentraide sur la toile. Pour les socles applicatifs du type base de donnes ou bus de messages, la rponse est plus contraste car certaines solutions payantes offrent des fonctionnalits que lon ne retrouve pas encore dans les alternatives opensource. Mais avant de pousser un Oracle dans des zones o MySQL ne peut plus le suivre, il faut quand mme avoir des besoins un peu pointus ce qui nest pas le cas de 80 % des contextes que nous rencontrons !
25
Fluidit de lexprience utilisateur
LES GANTS DU WEB
CULTURE / FLUIDIT DE LEXPRIENCE LUTILISATEUR
Description
La performance, un enjeu incontournable
Il existe une conviction partage chez les gants du Web : la performance perue par lutilisateur est critique. Cette performance a en effet un impact direct sur ladoption du service et son utilisation dans la dure. Et le ressenti utilisateur est directement li la rapidit daffichage des interfaces graphiques (IHM). Le grand public se moque bien de larchitecture logicielle, de la puissance des serveurs, de la latence rseau provoque par lappel des web services... Tout ce qui lui importe, cest limpression de fluidit dans lusage.
lergonomie nest plus ngociable aujourdhui

Les gants du Web lont bien compris et parlent ainsi de mesure en battement de cils . Tout se joue donc lchelle du 1/10e de seconde. Leurs tudes, ralises notamment grce du test A/B (cf. Test A/B p. 117), le dmontrent clairement : Amazon : une augmentation de 100 ms de la latence signifie une baisse de 1 % de ventes. Google : plus de 500 ms au chargement signifie 20 % de trafic perdu (pages vues). Yahoo! : plus de 400 ms au chargement signifie + 5 9 % dabandons. Bing : plus dune 1 seconde au chargement signifie une perte de 2,8 % de revenu publicitaire.
Comment assurer cette performance ?

Suivant en cela le pattern Device Agnostic (cf. Device Agnostic p. 123), les gants du Web dveloppent selon les cas des interfaces natives, ou des interfaces Web, afin de toujours offrir la meilleure exprience utilisateur. Dans les deux cas, la performance perue par lutilisateur doit tre maximise.
29
LES GANTS DU WEB
Applications natives
Avec liPhone, Apple a rintroduit le dveloppement au plus prs du matriel (sans revenir lassembleur, tout de mme) pour maximiser les performances perues. Ainsi les technologies Java et Flash sont bannies de liPhone. La plateforme utilise aussi des artifices visuels : au lancement dune application, la vue du dernier tat de lapplication est charge par le systme pour maximiser limpression dinstantanit, la vritable application tant charge en tche de fond. Sur Android, les applications Java sont excutes sur une machine virtuelle optimise pour la plateforme. Elles peuvent aussi tre crites en C pour maximiser les performances. De manire gnrale, un consensus sest dessin autour du dveloppement natif, en particulier sur plateformes mobiles : il doit tre au plus prs du matriel. Et des technologies multi-plateformes comme Java ME, Flash ou Silverlight tendent tre cartes au profit de lexprience utilisateur.
Applications Web
Le chargement complet dun cran Web est souvent de lordre de 4 10 secondes tout compris (avec les images, le JavaScript, Le Flash, etc.). Or, il apparat que la lenteur daffichage perue est gnralement lie pour 5 % aux traitements sur les serveurs, et pour 95 % aux traitements sur le navigateur. Les gants du Web apportent donc un soin tout particulier loptimisation de laffichage des pages Web. titre dillustration, voici une liste des principales bonnes pratiques qui font consensus, pour optimiser le ressenti de lutilisarteur : Il est crucial de mettre en cache les ressources statiques (les images, les feuilles de style CSS, les scripts JavaScript, les animations Flash, etc.) lorsque cest possible. Il existe pour cela diverses technologies de cache HTTP. Loptimisation de la dure de vie des ressources dans le cache est ainsi une comptence acqurir. Il est recommand dutiliser un rseau de cache, ou Content Delivery Network (CDN), pour placer les ressources au plus prs des utilisateurs et limiter limpact de la latence rseau. Disposer de serveurs de cache dans les pays o rsident la majorit des utilisateurs est vivement recommand.
30
CULTURE / FLUIDIT DE LEXPRIENCE LUTILISATEUR
Le chargement en tche de fond permet de masquer la lenteur daffichage de certains lments de la page. Une pratique trs frquente consiste utiliser des sprites : il sagit dagrger des images dans un mme fichier pour limiter le nombre de ressources charger ; elles seront ensuite dcoupes la vole par le navigateur (voir lexemple Gmail ci-aprs). Le recours des noms de domaines multiples permet de maximiser la paralllisation dans le chargement simultan de ressources par le navigateur. En effet, les navigateurs sont soumis un nombre maximal de requtes simultanes sur un mme domaine. Ainsi Yahoo.fr charge ses images partir de l.yimg.com. Placer les ressources JavaScript en toute fin de page pour que le visuel apparaisse le plus vite possible. Minifier, laide doutils, cest dire supprimer du code (JavaScript, HTML, etc.) tous les caractres (retours chariot, commentaires) servant la relecture mais pas lexcution du code, et minimiser la longueur des noms des fonctions. Compacter les diffrents fichiers de code source tels que JavaScript dans un seul fichier, quand cest possible.
Chez qui a fonctionne ?

Les exemples de ces pratiques sont nombreux chez les gants du Web : on peut citer Google, Gmail, Viadeo, Amazon, Yahoo!...
Les rfrences chez les gants du Web

Google possde le rseau de cache distribu le plus maill des gants du Web : le gant de la recherche disposerait de machines dans toutes les grandes villes, et mme dun rseau priv mondial, selon des rumeurs difficiles vrifier. Google Search pousse lexprience utilisateur temps-rel trs loin avec Instant Search qui charge les rsultats de recherche au fur et mesure de la frappe clavier. Cette fonction est une prouesse technique : elle a soulev nombre de questions dans la communaut des architectes.
31
LES GANTS DU WEB
Les images de linterface Gmail sont rduites au strict ncessaire (deux sprites dicnes prsents sur la figure 1), et le site fait un usage intensif du cache et du chargement JavaScript en tche de fond.
NDLR : Les sprites tant par dfinition prvus pour un affichage cran, nous ne pouvons pas vous assurer une meilleure dfinition dimpression pour cet exemple. Merci de votre comprhension.
Figure 1 : Sprites dicnes de Gmail.
France
Sites utilisant ou ayant utilis le rseau de cache distribu (CDN) Akamai : cite-sciences.fr lemonde.fr allocine.com urbandive.com
Et chez moi ?
Leffet de la latence daffichage est le mme sur les applications internes, propres une DSI : exaspration des utilisateurs et abandon du recours lapplication. Le pattern sapplique donc parfaitement en interne.
Sources
Eric Daspet, Performance des applications Web, quoi faire et pourquoi ? USI 2011 : > http://www.usievents.com/fr/conferences/10-casablanca-usi-2011/ sessions/997-performance-des-applications-web-quoi-faire-et-pourquoi Articles sur Google Instant Search : > http://highscalability.com/blog/2010/9/9/how-did-google-instantbecome-faster-with-5-7x-more-results.html > http://googleblog.blogspot.com/2010/09/google-instant-behindscenes.html
32
Les artisans codeurs
CULTURE / LES ARTISANS CODEURS
Description
Aujourdhui, les gants du Web nous rappellent que la carrire de dveloppeur peut tre tout aussi prestigieuse que celle de manager ou de consultant. En effet, lorigine des succs les plus marquants de la Silicon Valley, il y a souvent un ou plusieurs geeks visionnaires, passionns et attachs du code de qualit. Et quand les produits de ces entreprises gagnent en visibilit, satisfaire un nombre croissant dutilisateurs ncessite de conserver un cercle vertueux sur la qualit des dveloppements, sans lequel le succs peut devenir aussi phmre que rapide. Do limportance dune culture du dveloppement logiciel chez les gants du Web, qui sappuie sur quelques principes cls : attirer et recruter les meilleurs dveloppeurs,
investir sur la formation des dveloppeurs et leur laisser de lautonomie, les fidliser par le cadre de travail et le niveau de rmunration, tre intransigeant sur la qualit des dveloppements logiciels car la qualit est non-ngociable.
Mise en uvre
Le premier enjeu des gants du Web est donc de recruter les meilleurs dveloppeurs. Ils sont ainsi passs matres dans cet exercice, qui est finalement plus dlicat qui ny parat. Une pratique gnralise chez ces acteurs est de faire coder les candidats. Un test utilis chez Facebook tait celui du FizzBuzz. Cet exercice, issu dun jeu boire que certains reconnatront peut-tre, consiste afficher les 1.000 premiers nombres entiers, sauf pour les multiples de 3 ou 5, o il faut alors afficher respectivement Fizz ou Buzz , et pour les multiples de 3 et 5 o il faut afficher FizzBuzz . Ce petit exercice de programmation permettrait ainsi de filtrer 99,5 % des personnes. De faon similaire, pour gagner sa place chez Google, entre quatre et neuf entretiens techniques sont ncessaires.
35
LES GANTS DU WEB
La question du salaire rentre bien videmment en compte. Pour avoir de trs bons dveloppeurs, il faut y mettre le prix ! Chez Facebook, les Senior Software Engineers comptent ainsi parmi les plus hauts salaires de lentreprise. Une fois que les dveloppeurs ont rejoint lentreprise, le second enjeu consiste favoriser leur dveloppement, leur panouissement et leur monte en comptence. Le dveloppeur nest pas vu dans ces entreprises comme un ouvrier du code surveill par son manager, mais comme un acteur cl de lentreprise. Le modle Google qui encourage les dveloppeurs consacrer 20 % de leur temps en projets R&D a souvent t cit en exemple. Cela peut notamment donner lieu des contributions des projets open-source, lorigine de nombreux bnfices pour lentreprise (cf. Contribution au logiciel libre , p. 41). Par exemple, Netflix cite sur son blog ses nombreuses initiatives opensource notamment sur Zookeeper et Cassandra. Double effet bnfique pour Netflix, qui permet ainsi ses dveloppeurs de se faire reconnatre lextrieur de lentreprise tout en faisant avancer sa plateforme. Autre lment cl de la fidlisation des dveloppeurs : proposer un cadre de travail convivial. Il suffit dun surf sur Internet pour avoir un aperu du soin apport lenvironnement de travail chez les gants du Web : le dcalage avec la plupart des plateaux de dveloppement de nos DSI[1] est frappant. Mais ce nest pas tout ! Netflix, encore elle, a construit une culture qui mise beaucoup sur lautonomie et la responsabilisation de ses employs. Plus rcemment, Valve, diteur de jeux vido, a fait bruisser la communaut des dveloppeurs en publiant son handbook, qui dcrit une culture de travail exigeante mais aussi trs libre et propice lpanouissement personnel. 37signals enfin, avec son ouvrage Getting Real, prsente un ensemble de pratiques trs ouvertes, souvent loppos du fonctionnement de nombreuses organisations. De pair avec ces efforts dploys dans le recrutement et la fidlisation des dveloppeurs, vient galement une trs forte culture du code et de la qualit logicielle. Cest cette culture qui cre le socle permettant daller vite et de sadapter rapidement, tout en matrisant de gigantesques plateformes technologiques o les performances et la robustesse sont cruciales. Les gants du Web sont ainsi trs proches du mouvement Software Craftsmanship[2], qui prne un ensemble de valeurs et de pratiques visant garantir des produits logiciels de grande qualit et apportant la plus grande valeur possible aux utilisateurs finaux. Dans
[1] Direction du Systme dInformation. [2] > http://manifesto.softwarecraftsmanship.org
36
cette mouvance, Google et GitHub nhsitent pas communiquer sur leurs guidelines de programmation[3].
Et chez moi ?
Recrutement : Il est important de mettre en place un processus de recrutement solide pour embaucher vos dveloppeurs. Aprs un premier entretien pour cerner la personne que vous souhaitez recruter, il est essentiel de la faire coder. Il est possible de proposer quelques exercices techniques pour sentir lexpertise du dveloppeur, mais il est encore plus intressant de le faire coder en binme avec lun de vos dveloppeurs, pour sentir si le feeling passera sur le projet. Vous pouvez aussi demander vos candidats de fournir du code, en particulier celui dont ils sont le plus fiers ou bien celui dont ils ont le plus honte aujourdhui. Plus que le code lui-mme, les discussions sur ce code seront riches en enseignements sur le candidat. Dailleurs, a-t-il mis son code sur GitHub ? Participe-til des projets open-source ? Si oui, vous aurez alors des chantillons reprsentatifs du code quil est capable de produire. Qualit : Proposez vos dveloppeurs un contexte qui leur permettra de garder un haut niveau de qualit logicielle (puisquelle est non-ngociable). Laissez-leur du temps pour crire des tests unitaires, pour mettre en place lusine de dveloppement ncessaire au Continuous Deployment (cf. Continuous Deployment , p. 99) , pour binmer, pour tenir des ateliers de design sur leur domaine mtier, pour prototyper. La pratique connue pour avoir le plus dimpact sur la qualit est la revue de code par les pairs. Cest malheureusement encore trop rare dans nos entreprises. R&D : Offrir loccasion aux dveloppeurs de participer des projets de R&D en parallle de leur projet est une pratique qui peut savrer trs profitable. Cela peut gnrer de linnovation, contribuer lamlioration des projets et, dans le cas de lOpen-Source, augmenter lattractivit de votre entreprise pour les dveloppeurs. Cest aussi tout simplement une source de motivation pour cette population souvent nglige. De plus en plus dentreprises reprennent le principe des hackathons, populariss par Facebook, et dont le principe consiste coder, en une ou deux journes, un produit logiciel utilisable.
[3] > http://code.google.com/p/google-styleguide/ et https://github.com/styleguide
37
LES GANTS DU WEB
Formation : La formation peut se faire auprs dorganismes externes, mais vous pouvez aussi profiter du partage des savoirs entre dveloppeurs en organisant par exemple des ateliers de programmation collectifs, plus communment appels Dojo[4]. Les dveloppeurs peuvent sy runir pendant une demi-journe, autour dun vidoprojecteur, pour apprendre et partager ensemble sur une problmatique technique. Cela leur permet aussi de partager des pratiques de dveloppement, et au sein dune quipe de saligner sur des standards de dveloppement. Enfin, le travail sur un projet open-source permet aussi de se former sur de nouvelles technologies. Convivialit : Le cadre et les conditions de travail sont importantes ! Permettre lautonomie, prner une certaine ouverture et transparence, clbrer les erreurs et garder un rythme soutenable sont autant de pratiques payantes sur le long terme.
Patterns connexes
Pattern Pizza Teams , p. 51. Pattern DevOps , p. 63. Pattern Continuous Deployment , p. 99.
Sources
Culture dentreprise chez Netflix : > http://www.slideshare.net/reed2001/culture-1798664 Quel doit tre lapprentissage dun bon dveloppeur : > http://www.slideshare.net/petegoodliffe/becoming-a-better-programmer Liste de tous les postes de dveloppeur que recherche actuellement Facebook : > http://www.facebook.com/careers/teams/engineering Le plus gros salaire chez Facebook ? Senior Software Engineer : > http://www.businessinsider.com/the-highest-paying-jobs-at-facebookranked-2012-5?op=1
[4] > http://codingdojo.org/cgi-bin/wiki.pl?WhatIsCodingDojo
38
Les guides de programmation de GitHub : > https://github.com/styleguide Comment GitHub crot : > http://zachholman.com/talk/scaling-github Les contributions open-source de Netflix : > http://techblog.netflix.com/2012/07/open-source-at-netflix-by-ruslan.html Le test du Fizzbuzz : > http://c2.com/cgi/wiki?FizzBuzzTest Getting Real : > http://gettingreal.37signals.com/GR_fra.php Manifeste du Software Craftsmanship : > http://manifesto.softwarecraftsmanship.org Le blog de Google sur les tests : > http://googletesting.blogspot.fr Le Happy Manifesto : > http://www.happy.co.uk/wp-content/uploads/Happy-Manifesto1.pdf
39
Contribution au logiciel libre
CULTURE / CONTRIBUTION AU LOGICIEL LIBRE
Description
Mais pourquoi les gants du Web comme Facebook, Google et autre Twitter contribuent-ils autant lOpen-Source ? Lavance technologique est un atout important dans la conqute du Web. Que ce soit pour se dmarquer de la concurrence en lanant de nouveaux services (pensez la sortie de Gmail et de son large espace de stockage lpoque de lhgmonie Hotmail), ou plus pragmatiquement pour faire face aux contraintes qui leur sont propres comme le dfi de croissance li la croissance de leurs bases utilisateurs, les gants du Web ont su plusieurs reprises inventer de nouvelles technologies. Alors que lon pourrait penser que cette matrise technologique, et cet actif que reprsente le code, devraient tous deux tre secrtement conservs, voil quun pattern largement rpandu nous interpelle : les gants du Web ne sont pas seulement de grands consommateurs de technologies open-source, ils en sont aussi les principaux contributeurs. Le pattern contribution au logiciel libre consiste ainsi rendre public un outil logiciel (librairie, framework) construit et utilis en interne. Le code est mis disposition sur un serveur public, comme GitHub, et une licence libre de type Apache, par exemple, autorise son utilisation et son adaptation par dautres socits. Ce code devient par la mme occasion potentiellement ouvert aux contributions des dveloppeurs du monde entier. Notons que ce passage lOpen-Source saccompagne traditionnellement dune large communication en ligne et lors de confrences ddies aux dveloppeurs.

Les exemples sont nombreux. Parmi les plus reprsentatifs, on pense Facebook et sa base de donne Cassandra, construite pour grer des quantits massives de donnes rparties sur plusieurs serveurs. Il est intressant de noter que dans les utilisateurs actuels de Cassandra on peut compter dautres gants du Web comme Twitter ou Digg. Alors que dans le mme temps, Facebook a abandonn Cassandra au profit dune autre solution de stockage galement Open-Source HBase initie quant elle par la socit Powerset. A limage de la mouvance NoSQL, les nouvelles fondations du Web daujourdhui sont massivement issues des technologies des gants du Web.
43
LES GANTS DU WEB
Facebook a galement ouvert la communaut plusieurs autres frameworks, comme le moteur HipHop permettant de compiler le PHP en C++, Thrift, le framework de dveloppement de services multilangages, ou encore Open Compute, une initiative dopen hardware visant optimiser le fonctionnement des datacenters. Mais Facebook ne fait pas exception. Google a fait de mme avec son framework dIHM[1] GWT utilis notamment dans Adword. Ou encore avec Tesseract OCR le moteur de reconnaissance de caractres initialement dvelopp par HP, rcupr par Google, qui louvrira la communaut quelques annes plus tard. Enfin, comment parler de Google sans citer videmment Android, le systme dexploitation open-source pour mobile ou encore leurs nombreuses publications scientifiques autour du stockage et du traitement de trs gros volumes de donnes. Nous faisons rfrence leurs papiers autour de Big Table et Map Reduce qui ont inspir la construction du projet Hadoop. La liste serait encore longue, et lon terminera en voquant Twitter et son framework CSS et responsive design trs tendance, nomm Bootstrap. Ou encore lexcellent Ruby On Rails extrait du logiciel de gestion de projet Basecamp et ouvert la communaut par 37signals.
Pourquoi a fonctionne ?
En laissant de ct les considrations idologiques, nous proposons dexplorer diffrents avantages que lon pourrait attribuer une telle dmarche de contribution au logiciel libre. Ouverture et gratuit ne sopposent pas forcment guerre conomique et rentabilit. Dune certaine faon cette ouverture pourrait mme apparatre comme un moyen dannihiler lmergence de la concurrence sur certains pans technologiques. Faire un don l Open-Source permet de redessiner les contours dun secteur technologique, tout en sassurant de rester influent sur la meilleure solution disponible. A ce jour, Google est toujours le principal sponsor de la fondation Mozilla et de son projet phare Firefox, plus de 80 %... Un moyen de diversifier la concurrence face Microsoft ? Mais revenons sur lanalyse de nos trois bnfices.
[1] Interface Homme Machine.
44
Amliorer limage de marque

En ouvrant la communaut une technologie de pointe, les gants du Web se forgent une image de leaders, de pionniers. Ils communiquent implicitement sur lesprit dinnovation qui rgne dans leurs murs, sur la recherche permanente. Ils font passer le message quils sont en mesure de rsoudre de grands problmes ; ils sont puissants technologiquement. Livrer un framework open-source qui trouve le succs, cest montrer que lon a su rsoudre avant tout le monde, ou mieux que les autres, un problme partag. Et que dune certaine faon ce problme est maintenant derrire eux. Ils lont mis en bote et continuent de btir. Ils gardent une longueur davance. Ouvrir un framework lOpen-Source, est en soi une action de communication forte, un renforcement de limage de marque. Un moyen de faire passer lutilisateur le message implicite et primaire : Nous sommes les meilleurs, sois rassur . Et puis, comme pour se prmunir dapparatre comme les nouveaux Big Brothers, on ne peut sempcher de lire entre les lignes de cette dmarche Nous sommes ouverts gentils naie pas peur [2].
Attirer et conserver les meilleurs

Voila un aspect essentiel pouvant tre induit par une dmarche OpenSource. Car afficher son code cest afficher une partie de son ADN, de son mode de pense, de sa faon de rsoudre les problmes Montre-moi ton code, et je te dirai qui tu es. Un moyen naturel de communiquer vers lextrieur sur ce quil se passe prcisment lintrieur de son entreprise : le niveau de ses dveloppeurs, ses standards de qualit, les sujets qui proccupent le quotidien des quipes Un bon moyen dattirer des dveloppeurs compatibles qui se seraient intresss deux-mmes aux projets soutenus par lentreprise. Grce ces contributions, il devient alors facile de dtecter les dveloppeurs les plus impliqus, les plus comptents, les plus motivs. Et de les embaucher alors avec la garantie de leur capacit sintgrer dans leur cosystme. Dune certaine faon, lOpen-Source est un peu comme une immense priode dessai ouverte tous.
[2] Devise de Google : Dont be evil.
45
LES GANTS DU WEB
Attirer les meilleurs geeks est une chose, les garder en est une autre. Sur ce second point, lOpen-Source peut savrer tre un formidable moyen doffrir aux meilleurs dveloppeurs de votre socit une vitrine sur le monde extrieur, une tribune. A partir de maintenant, ils pourront briller autant lintrieur qu lextrieur de lentreprise. Favoriser lOpen-Source cest permettre aux dveloppeurs de prendre soin de leur CV. Cest comprendre le besoin de Personal Branding[3] de vos quipes, tout en les conservant au sein de lentreprise. Tout dveloppeur recherche un environnement qui valorise les dveloppeurs, un environnement qui propose une carrire aux profils techniques. Parole de dveloppeur.
Amliorer la qualit
Penser Open-Source permet dj en soi de faire un bond en avant niveau qualit : ouvrir un morceau de code un framework la communaut, ncessite tout dabord den dfinir les contours, de le nommer, de dcrire ce framework et den dfinir le but. elle seule, cette dmarche est un considrable pas en avant dans la qualit de vos logiciels. Car elle induit invitablement la modularisation du code, sa structuration. Elle facilite galement la rutilisation de code au sein de lentreprise. Elle dfinit des responsabilits dans le code, et peut-tre mme au sein des quipes. Inutile de prciser quun dveloppeur qui sait que son code sera relu (a fortiori relu par des dveloppeurs de la terre entire), sy reprendra deux fois avant de commiter cette mthode non teste, ou ce bout de code fait la va-vite. Au-del de cet effet responsabilisant, rcolter du feedback de la part de dveloppeurs externes lentreprise sera srement salvateur.
Et chez moi ?
Bien utilis, lOpen-Source peut donc tre un moyen intelligent de structurer votre R&D tout en fournissant un cadre dvaluation vos dveloppeurs. Cet article avait pour objectif dexplorer diffrents bnfices offerts par louverture dune partie de votre actif technologique. Si, culturellement, vous ntes pas encore prt faire le grand saut, ou si votre SI ne sy
[3] Marketing personnel propre un individu.
46
prte pas encore, il peut nanmoins tre intressant de conserver le sens dune telle dmarche avec quelques premires actions faciles mettre en uvre. Selon la taille de votre entreprise, le lancement de votre tout nouveau projet Open-Source pourrait malheureusement se faire dans lindiffrence gnrale. Nous navons pas tous la puissance de communication dun Facebook. Commencer par contribuer des projets Open-Source existants peut tre dans un premier temps une bonne faon de tester cette culture auprs de vos quipes. A limage de Google ou GitHub, une autre action agissant sur les trois bnfices prsents ici pourrait-tre de matrialiser et dexposer sur le Web vos guidelines de programmation. Ou encore dinviter vos dveloppeurs ouvrir un blog technique sur lequel ils partageraient les problmatiques cls quils ont d aborder. Le Tumblr Instagram Engineering anim par Instagram est une bonne source dinspiration.
Sources
Portail dveloppeur de Facebook, projets Open-Source : > http://developers.facebook.com/opensource Open-Source Projects Released By Google : > http://code.google.com/opensource/projects.html Portail dveloppeur de Twitter, projets Open-Source : > http://dev.twitter.com/opensource/projects Instagram Engineering Blog : > http://instagram-engineering.tumblr.com Rgle dcriture du code de GitHub : > http://github.com/styleguide Question sur Quora : Open-Source: Why would a big company do open-source projects? : > http://www.quora.com/Open-Source/Why-would-a-big-company-doopen-source-projects
47
Organisation
LES GANTS DU WEB
Pizza Teams...................................................................................... 51 Feature Teams ................................................................................. 57 DevOps........................................................................................... 63
50
Pizza Teams
ORGANISATION / PIZZA TEAMS
Description
Quelle est la bonne taille dquipe pour fabriquer un produit logiciel remarquable ? La sociologie des organisations sest penche sur le sujet de la taille des quipes depuis plusieurs annes dj. Si la rponse nest pas uniforme et semble dpendre de diffrents critres comme la nature des tches effectuer, le niveau moyen et la diversit de lquipe, un consensus merge sur des tailles de 5 12[1][5].En de de 5, lquipe devient fragile aux vnements extrieurs et manque de crativit. Au-del de 12, la communication perd en efficacit, la cohsion diminue, on voit apparatre des comportements de parasitisme et des luttes de pouvoir, et la performance de lquipe dcrot trs rapidement avec le nombre de membres. Cela sapplique videmment aussi en informatique. Le cabinet Quantitative Software Management, qui sest fait une spcialit de la conservation et de lanalyse de mtriques sur les projets informatiques (si vous aimez les chiffres, visitez leur site Web, cest une mine dinformations!), a ainsi publi quelques statistiques intressantes. Sur un chantillon de 491 projets, le cabinet QSM a mesur une baisse de productivit et une augmentation de la variabilit lorsque la taille des quipes augmente, avec un dcrochage assez net partir de 7 personnes. De faon corrle, la dure moyenne des projets augmente et leffort de dveloppement explose surtout au-del de 15[6]. Bref, si vous voulez faire vite et bien, rduisez la taille de vos quipes! Pourquoi voquer de tels sujets dans cet ouvrage consacr aux gants du Web? Tout simplement car ceux-ci sont particulirement conscients de limportance de la taille des quipes sur la russite de leurs projets et adoptent au quotidien certaines pratiques pour la limiter.
[1] > http://knowledge.wharton.upenn.edu/article.cfm?articleid=1501 [2] > http://www.projectsatwork.com/article.cfm?ID=227526 [3] > http://www.teambuildingportal.com/articles/systems/teamperformance-teamsize [4] > http://math.arizona.edu/~lega/485-585/Group_Dynamics_RV.pdf [5] > http://www.articlesnatch.com/Article/What-Project-Team-Size-Is-Best-/589717 [6] > http://www.qsm.com/process_improvement_01.html
53
LES GANTS DU WEB
Le titre de cet article sinspire dailleurs du nom quAmazon a donn cette pratique[7] : la taille dune quipe ne dpasse pas le nombre de personnes que lon peut nourrir avec 2 pizzas (modle amricain, tout de mme), soit de lordre de 8 personnes. Et Werner Vogels (CTO et VP Amazon) denfoncer le clou avec cette citation, presque du Nietzsche :
Small teams are holy.

Mais Amazon, nest pas le seul, loin sen faut. Pour illustrer limportance que les gants du Web accordent la dynamique dquipe, Google a recrut Evan Wittenberg en tant que responsable Global Leadership Development ; cet ancien universitaire sest fait connatre (entre autre) par des travaux sur les tailles dquipe. Mme hygine chez Yahoo! qui limite la taille de ses quipes produit la premire anne 5 10 personnes. Viadeo, de son ct, pratique les pizza teams de taille franaise, avec des quipes composes de cinq six personnes. Dans le domaine des startups, Instagram, Dropbox, Evernote sont connues pour avoir maintenu le plus longtemps possible une quipe de dveloppement trs rduite.
Et chez moi ?
Une petite quipe agile sera toujours plus efficace quune grosse quipe paresseuse : telle est la conclusion que lon pourrait tirer des expriences accumules sur la taille des quipes. Finalement, il suffit de sen souvenir pour lappliquer Et de rsister la pression des raisonnements linaires : pour aller 2 fois plus vite, il suffit de mettre 2 fois plus de gens . Rien de plus faux ! Si une quipe dpasse 15 personnes, daprs les tudes, cela doit devenir votre signal dalerte[8][10].
[7] > http://www.fastcompany.com/magazine/85/bezos_4.html [8] > https://speakerdeck.com/u/searls/p/the-mythical-team-month [9] > http://www.3circlepartners.com/news/team-size-matters [10] > http://37signals.com/svn/posts/995-if-youre-working-in-a-big-group-youre-fightinghuman-nature
54
ORGANISATION / PIZZA TEAMS
Deux options se prsentent alors : Lutter bec et ongles contre la croissance de cette quipe et ne se rsoudre quen dernier recours la solution daprs. Dcouper en quipes plus petites. Et bien rflchir ce dcoupage en se souvenant quune quipe, cest un groupe de personnes motives sur un objectif commun. Cest ce que nous verrons dans le chapitre suivant, Feature Teams .
55
Feature Teams
ORGANISATION / FEATURE TEAMS
Description
Dans le chapitre prcdent, nous avons vu que les gants du Web prtaient beaucoup dattention la taille de leurs quipes. Mais ce nest pas le seul point de vigilance quils ont sur leurs quipes : ils veillent aussi frquemment avoir des quipes organises par fonctionnalit, autrement dit des feature teams . La petite quipe polyvalente est la cl pour aller vite, et la plupart des gants du Web tentent de rsister le plus longtemps possible la multiplication dquipes pour raliser un seul produit. Malgr tout, si le succs advient, arrive un moment o la dizaine de personnes ne suffit plus et o il faut pouvoir monter en charge. Mme dans ce cas, on ne droge pas la rgle des quipes taille humaine et il faut donc augmenter le nombre dquipes. Se pose alors la question de laxe selon lequel les dcoupages de primtres doivent se faire. Il existe deux grandes options[1] : Le dcoupage par couche technologique . Le dcoupage par pan fonctionnel .
Par pan fonctionnel , il faut comprendre le fait de livrer de bout en bout des fonctionnalits autonomes, qui rendent un service lutilisateur final. A linverse le dcoupage par couche technologique consiste ddier chaque quipe sur un type de technologie : typiquement, la couche prsentation, la couche mtier, les socles transverses, la base de donnes Cest dailleurs traditionnellement le mode dorganisation retenu dans nos DSI o les personnes sont souvent regroupes par spcialits. Mais partir du moment o le Time To Market devient un enjeu critique, le mode dorganisation par couche technologique, dit encore component team, commence montrer ses limites. En effet, qui dit Time To Market dit souvent mthode de type Agile ou Lean. Et donc de la spcification, du dveloppement, de la mise en production le plus possible selon des cycles courts, voire au fil de leau.
[1] En ralit, il existe dautres axes possibles, notamment par release, par zone gographique, par segment dutilisateurs ou par famille de produits. Mais cela nous emmnerait un peu loin de notre propos, sachant que certaines de ces options sont des impasses, et que dautres peuvent au final sapprhender comme des dcoupages par pans fonctionnels.
59
LES GANTS DU WEB
Or, avec des component teams, on se retrouve trs vite dans des situations de goulet dtranglement. Prenons lexemple dcrit sur la figure 1.
Fonctionnalit 1 Fonctionnalit 2 Fonctionnalit 4 Fonctionnalit 5
Equipe 1 - Front Equipe 1 - Back Equipe 1 - changes Equipe 1 - Socle
Figure 1.
Les flches rouges dcrivent le premier problme. Les fonctionnalits les plus importantes (fonctionnalit 1) sur-sollicitent lquipe Front. Les autres quipes doivent produire des choses marginales pour ces fonctionnalits. Malgr tout, on ne peut rien livrer tant que lquipe 1 na pas fini. Les autres quipes, ne pouvant pas vraiment aider lquipe 1 (car ntant pas de la mme spcialit), elles nont dautre choix que de ne pas produire ou alors de faire du stock de fonctionnalits moins importantes (et le stock, en Lean, cest mal). Il y a plus grave. La fonctionnalit 4 ncessite de faire collaborer les 4 quipes. Seulement voil, en mode Agile, cest au sein de chaque quipe que se fait lanalyse dtaille. Or, dans ce cas, il faut faire lanalyse dtaille des impacts sur les 4 quipes. Donc du coup, il faut faire une analyse dtaille en amont, ce que prcisment on essaie dviter en fonctionnement Agile. De la mme faon, en aval, il faut synchroniser le travail des 4 quipes pour pouvoir tester, et donc attendre lquipe la plus lente. Pour limiter les impacts, cela signifie quil faut dfinir des priorisations de tches de chaque quipe de faon centralise. Et on se retrouve petit
60
ORGANISATION / FEATURE TEAMS
petit dans des gros plannings qui cherchent synchroniser au mieux toutes les activits mais qui enlvent de lautonomie aux quipes. Bref, on se retrouve faire de la cascade en amont la fois pour lanalyse et la planification et de la cascade en aval pour du test et de la mise en production. Cette dynamique est trs bien dcrite dans louvrage de Craig Larman et Bas Vodde, Scaling Lean And Agile . Les feature teams permettent de corriger ces dfauts : chaque quipe travaillant sur un sous-ensemble fonctionnel cohrent et ce, indpendamment des technologies - elle est capable tout moment de livrer de la valeur au client final en dpendant faiblement des autres quipes. Cela implique que dans une mme quipe se retrouvent toutes les comptences ncessaires la production de fonctionnalits, et cela peut vouloir dire (entre autre) un architecte, un ergonome, un dveloppeur Web, un dveloppeur Java, un expert base de donnes, et, oui, mme un exploitant car quand on pousse la logique lextrme, on tombe sur le you build it, you run it de DevOps, dcrit dans le prochain chapitre, ddi ce sujet (cf. DevOps p. 63). Mais du coup, comment assure-t-on la cohrence technologique de ce qui est produit, si chaque expert Java de chaque feature team prend des dcisions sur son primtre ? Ce point est adress par le principe des communauts de pratiques. Les pairs de chaque type dexpertise se runissent intervalles rguliers pour changer sur leurs pratiques et saccorder sur des stratgies technologiques par rapport la fabrication du produit en cours. Les feature teams prsentent galement un intrt induit non ngligeable : les quipes progressent trs vite sur le mtier et cela favorise limplication des dveloppeurs dans la vision produit et dans la qualit du rsultat final. La pratique est videmment un peu moins rose que ce que nous dcrivons ici (la dfinition des primtres nest pas simple, il reste des adhrences entre quipes grer, il faut arriver faire vivre les communauts de pratiques). Malgr tout, ce mode dorganisation prsente de rels avantages par rapports aux organisations en couches et permet dtre beaucoup plus efficace et agile.
61
LES GANTS DU WEB
Et pour en revenir nos gants du Web, cest un mode dorganisation quils tendent privilgier. En particulier Facebook, qui communique beaucoup sur sa culture, met en avant le principe dquipes mixant toutes les comptences ncessaires pour construire une fonctionnalit[2]. Cest galement une organisation retenue par Viadeo,Yahoo! et Microsoft[3] pour le dveloppement de leurs produits.
Et chez moi
Les gants du Web ne sont pas les seuls appliquer le principe des feature teams. Cest souvent le mode dorganisation galement retenu chez les diteurs de logiciels. Par ailleurs, lAgile se diffuse de plus en plus largement dans nos DSI et commence tre appliqu des projets de plus en plus gros. A partir dune certaine taille de projet (3 4 quipes), les feature teams deviennent la rponse la plus efficace, si bien que certaines DSI sorientent naturellement vers ce type de pattern[4].
[2] > http://www.time.com/time/specials/packages article/0,28804,2036683_2037109_2037111,00.html [3] Michael A. Cusumano and Richard W. Selby. 1997. How Microsoft builds software. Commun. ACM 40, 6 (June 1997), 53-61 :> http://doi.acm.org/10.1145/255656.255698 [4] > http://blog.octo.com/compte-rendu-du-petit-dejeuner-organise-par-octo-et-stratorretour-dexperience-lagilite-a-grande-echelle
62
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 production, 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
Objectifs locaux
Livrer de nouvelles fonctionnalits (de qualit)
Garantir le run des applications (stabilit)
Cultures diffrentes
Culture du Produit (logiciel)
Culture de Service (archivage, supervision, etc.)
Cherche innover
Cherche rationaliser
Figure 1.
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 :
66
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 collaboration 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
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)
68
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. Lautomatisation 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.
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-forchange-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 l Incident Management de la figure 2.
Figure 5 (modifie). Source : http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-forchange-4608108

70
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 dapprovisionnement : Infrastructure as Code . Lautomatisation de la chane de construction logicielle et de dploiement. Lusine de dveloppement devient la chane de fabrication 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 comprendre 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.
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 postmortems 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.
72
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 .
73
LES GANTS DU WEB
Cest par ailleurs dans ce type dorganisations que les notions de selfservice 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 passage 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 proposent 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 selfservice . 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 ?
74
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.
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-doesntjust-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-devopsconversationsfocus-on-deployment.html USI 2009 : > http://www.usievents.com/fr/conferences/4-usi-2009/sessions/797quelques-idees-issues-des-grands-du-web-pour-remettre-en-cause-vosreflexes-d-architectes#webcast_autoplay
76
Pratiques
LES GANTS DU WEB
Lean Startup.................................................................................... 81 Minimum Viable Product.................................................................. 89 Continuous Deployment................................................................... 99 Feature Flipping............................................................................. 107 Test A/B......................................................................................... 117 Device Agnostic............................................................................. 123 La bta perptuelle ....................................................................... 131
80
Lean Startup
PRATIQUES / LEAN STARTUP
Description
La cration dun produit est trs souvent voue lchec. Ainsi, les chiffres montrent que 95 % des produits ou startups meurent par manque de clients. Le Lean Startup est une approche de cration produit qui se propose de rduire les risques et les impacts des checs en attaquant paralllement les aspects organisationnels, business et techniques et avec des itrations agressives. Formalise par Eric Ries, elle est fortement inspire du Customer Development de Steve Blank.
Build Mesure Learn

Tout produit ou fonctionnalit part dune hypothse. Cette hypothse peut tre issue de donnes rcoltes sur le terrain ou dune simple intuition. Toujours est-il que lapproche que prne le Lean Startup est : De considrer toute ide comme hypothse, quelle soit marketing ou fonctionnelle, de valider toute hypothse le plus vite possible sur le terrain.
Ce dernier point est lun des lments centraux du Lean Startup. Chaque hypothse business, organisationnelle ou technique doit tre valide qualitativement et vrifie quantitativement. Cette dmarche permet de mettre en place une boucle dapprentissage sur le produit et le client. Le Lean Startup combat donc lapproche qui consiste construire un produit pendant un an et se rendre compte tardivement que des choix (marketing, fonctionnel, commercial) mettent lorganisation en danger. Il faut tester au plus vite.
Figure 1.
83
LES GANTS DU WEB
Exprimenter pour Valider

Une partie de lapproche se base sur le Minimum Viable Product (cf. Minimum Viable Product p. 89). Quel est le minimum que je dois construire pour valider mes hypothses ? On ne parle pas ici ncessairement de code et de produit au sens technique du terme, mais de nimporte quel effort qui va permettre davancer sur ces hypothses. Cela peut tre un questionnaire Google Docs, une mailing list ou une fausse fonctionnalit pour tester lapptence du march. Lexprimentation et les leons associes sont un actif inestimable pour le pilotage du produit et justifient la mise en place de la boucle dapprentissage.
Lobsession de la mesure
On imagine donc bien que ces exprimentations doivent systmatiquement tre suivies par une mesure fiable et complte (cf. Lobsession de la mesure p. 13).
Une approche centre client Go out of the building

Vrifier qualitativement et valider quantitativement signifie bien souvent sortir de limmeuble , comme dirait Bob Dorf, co-auteur du fameux 4 Steps to the Epiphany . Go out of the building (GOOB) est au centre des proccupations des Product Managers pratiquant le Lean Startup. Tant que les hypothses ne sont pas confrontes la ralit, elles restent des suppositions. Et donc, des risques potentiels pour lorganisation. No plan survives first contact with customesr (Steve Blank) est ainsi lune des devises des quipes produit : Construire le minimum ncessaire valider une hypothse. GOOB (de linterview en face face au dploiement continu). Apprendre. Construire et ainsi de suite.
84
Cette approche permet ainsi de rester constamment au contact du client, et, donc, de valider les hypothses business (les euros). Zappos, gant US de la chaussure sur le Web, est un exemple de MVP mis entre les mains des utilisateurs rels trs tt. Pour se confronter la ralit et valider que les utilisateurs seraient prts acheter des chaussures en ligne, le futur CEO de Zappos photographia les chaussures des magasins locaux, crant linventaire dun site e-commerce de toute pice. Ce faisant, et sans construire une cathdrale, il valida trs tt que la demande existait et que la construction dun tel produit pouvait savrer gagnante.
Le pilotage par la donne

Evidemment, pour apprendre du comportement des utilisateurs lors de ces sessions de GOOB, les Product Managers rcoltent mticuleusement de la donne qui leur permet de prendre les dcisions adquates. Et mettent en place les outils et processus de collecte de cette donne. Les plus utilises sont bien connus de tous. Il sagit dinterviews et des solutions danalytics. Ce que le Lean Startup prne est une utilisation froce de ces indicateurs pour rellement piloter la stratgie produit. Sur ChooseYourBoss.com[1], nous avons fait comme hypothse que les utilisateurs choisiraient LinkedIn ou Viadeo pour se connecter, pour viter aux utilisateurs de se crer un compte et pour nous viter de dvelopper un systme dinscription. Nous avons donc construit le minimum pour invalider ou valider lhypothse : une page qui comportait les 3 options savoir linscription via Linkedin, celle par Viadeo et celle par un compte ChooseYourBoss. Les 2 premires marchaient rellement, tandis que la 3me, le compte ChooseYourBoss, indiquait que le compte ChooseYourBoss ntait pas encore disponible en production. Rsultats : les utilisateurs ne voulant pas utiliser ces rseaux pour se connecter reprsentent 11 % de nos visiteurs. Nous nimplmenterons donc pas dans limmdiat la cration de compte sans rseau. Nous sommes passs du informs par la donne au pilots par la donne .

IMVU, Dropbox, Heroku, Votizen ou Zappos sont quelques exemples de produits Web qui ont russi intgrer les feedbacks utilisateurs au plus tt
[1] Site de mise en contact entre candidats et recruteurs.
85
LES GANTS DU WEB
dans la cration de produit. Dropbox a par exemple chang compltement son fonctionnement en simplifiant drastiquement la gestion des dossiers synchroniss. Heroku est pass dune plateforme de dveloppement sur le Cloud une solution dhbergement sur le Cloud. Les exemples sont nombreux et plus ingnieux les uns que les autres !
Et chez moi ?
Le Lean Startup nest pas dogmatique. Cest avant tout prendre conscience que le march et le client ne sont pas dans les runions darchitecture, les plans marketing, les projections de ventes ou les fonctionnalits cls. Une fois ce constat fait, vous verrez des hypothses partout. Tout consiste mettre en place une discipline de validation des hypothses en gardant pour principe de valider le minimum de fonctionnalits un instant t. Avant de faire la moindre ligne de code, les principales questions se poser tournent autour du triplet Client / Problme / Solution : Ai-je rellement un problme qui vaut la peine dtre rsolu ? Ma solution est-elle la bonne pour mon client ? Est-il susceptible de lacheter ? A combien ?
Tous les moyens sont bons pour lever ces hypothses : interviews, tudes de march, maquettes La seconde tape consiste savoir si le modle que jai pu tester moindre chelle est rptable et extensible. Comment mettre entre les mains des clients un produit dont ils nont jamais entendu parler ? Vont-ils comprendre, utiliser et tirer des bnfices de mon produit ? Les troisime et quatrime tapes tournent autour de la croissance : comment faire venir des clients et comment construire une socit qui va pouvoir accueillir et faire grandir mon produit. Contrairement ce que lon pourrait penser la lecture de ce chapitre, le Lean Startup nest pas une approche rserver uniquement des sites Web grand public. Innover en validant le plus rapidement possible des hypothses et en limitant linvestissement financier est videmment
86
une logique transposable tout type de projet informatique, ft-il interne. Nous sommes convaincus que cette dmarche mriterait dtre plus largement utilise pour viter les projets Titanic qui peuvent engouffrer des sommes colossales avec une trs faible valeur perue par lutilisateur. Pour plus dinformation, vous pouvez aussi consulter les sessions sur le Lean Startup lors des USI 2011 et 2012 qui traitent des deux premires tapes (www.usievents.com).
Sources
Running Lean Ash Maurya 4 Steps to the Epiphany Steve Blank & Bob Dorf : > http://www.stevenblank.com/books.html Blog Startup Genome Project : > http://blog.startupcompass.co/ The Lean Startup: How Todays Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses Eric Ries : > http://www.amazon.com/The-Lean-Startup-Entrepreneurs-Continuous/ dp/0307887898 The Startup Owners Manual Steve Blank & Bob Dorf : > http://www.amazon.com/The-Startup-Owners-Manual-Step-By-Step/ dp/0984999302
87
Minimum Viable Product
PRATIQUES / MINIMUM VIABLE PRODUCT
Description
Un Minimum Viable Product (Produit Minimal Viable), abrg en MVP, est une stratgie de dveloppement de produit. Eric Ries, crateur de Lean Startup qui a fortement contribu dvelopper cette approche, nous en donne la dfinition suivante :
le MVP est la version dun nouveau produit qui permet une quipe de collecter sur les clients (early adopters) le maximum denseignements valids, et ce avec un minimum deffort[1]
En rsum, il sagit de raliser rapidement un prototype de produit minimal, afin de vrifier lexistence dun besoin, didentifier le march associ, et de valider les hypothses business telles que la rentabilit. Lintrt est vident : construire plus rapidement un produit qui rponde vraiment au besoin dun march, en limitant les cots de mise au point de deux manires : Par la rduction du TTM[2] : plus rapide, donc moins deffort humain, do moins cher toutes choses gales par ailleurs, et par la rduction du primtre fonctionnel : moins deffort de dveloppement dans des fonctionnalits inutiles, sans valeur dmontre ce stade, pour lutilisateur.
Dans le cadre dune startup, les ressources financires sont gnralement limites. Il est faut donc tester le plus rapidement possible les hypothses du business plan cest l que le MVP apporte toute sa valeur. Lavantage de lapproche MVP est bien rsume par lexprience de Eric Ries au sein de IMVU.com, site davatar 3D et chat en ligne : six mois leur ont suffit pour y crer leur premier MVP, alors que dans une exprience prcdente de startup, il lui avait fallu prs de cinq ans avant daboutir un premier produit pas forcment viable !
[1] the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. > http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html [2] Time To Market : dlai coul entre la conception dun produit et sa mise sur le march.
91
LES GANTS DU WEB
Aujourdhui, un dlai de six mois peut sembler dj relativement long, et il est bien souvent possible de dployer un MVP plus rapidement. En effet, laborer un MVP nimplique pas forcment de produire du code ou un site trs sophistiqu, bien au contraire il sagit de tter le terrain, trs tt dans le projet, pour valider la direction dans laquelle on envisage de dvelopper le produit ou service. Cest une approche de type Fail Fast . Le MVP permet ainsi de valider rapidement les hypothses sur les besoins du client, et par consquence offre la possibilit, tt en amont dans la conception du produit ou service, de rorienter celui-ci : cest ce que lon appelle un pivot , dans le vocabulaire du Lean Startup. Ou, si les hypothses sont valides au moyen des informations rcoltes via le MVP, il sagira de passer ltape suivante : implmenter la fonctionnalit qui avait t simule, crer un vrai site Web, et plus simplement une page de marketing. Le MVP ne sapplique pas quau lancement dun nouveau produit : le principe reste tout fait pertinent dans le cadre de nouvelles fonctionnalits envisages pour un produit dj existant. Lapproche peut tre aussi plus directe : collecter le feedback de lutilisateur en lui demandant ce quil souhaite comme fonctionnalits (cf. figure 1), et collecter aussi des informations concernant son comportement dans lutilisation du produit. Le MVP est particulirement bien adapt lorsque lon na pas ou peu de connaissance du march et des clients, ni de vision produit bien dfinie.
Mise en uvre
Le MVP peut vraiment tre trs dpouill. Par exemple, Nivi Babak nous dit que le MVP est souvent une publicit dans Google. Ou un slide Powerpoint. Ou une page daccueil. Vous pouvez souvent le construire en une journe ou une semaine [3]. L approche la plus minimaliste est qualifie de Smoke Test, appele ainsi par rfrence aux tests raliss sur les composants lectroniques, qui permettent de sassurer du bon fonctionnement dun composant avant de passer un degr suprieur
[3] The minimum viable product (MVP) is often an ad on Google. Or a PowerPoint slide. Or a dialog box. Or a landing page. You can often build it in a day or a week. > http://venturehacks.com/articles/minimum-viable-product
92
de test (stress tests, etc.) et notamment au travers du dgagement de fume qui accompagne gnralement un dfaut ! Dans la version pure du Smoke Test, il suffit dune bannire publicitaire dans un grand moteur de recherche par exemple, vantant les mrites du produit que lon cherche dvelopper. Le clic sur la bannire renverra sur une page, gnralement statique, rduite au minimum, mais pouvant offrir quelques liens, dont le seul but est de permettre la collection des informations de clic, indicateurs de lintrt port par le client au service, et de sa capacit passer lacte dachat. Pour autant, les fonctionnalits concernes par les liens nont absolument pas besoin dtre oprationnelles ce stade ! Le strict minimum est la bannire publicitaire, qui permet dj de collecter des informations. Le site theleanstartup.com, qui applique les principes quil dfend (Pattern EYODF [4]) propose par exemple, tout en bas de sa page daccueil (qui constitue le MVP de theleanstartup.com), un formulaire trs simple, pour collecter les demandes de lutilisateur, constitu de deux champs email et proposition de nouvelle fonctionnalit accompagn dune invitation : Que voulez-vous voir dans notre future version (du site) ?
Figure 1. Formulaire de collecte dinformation utilisateur sur le site theleanstartup.com, aprs soumission des informations.
En termes doutillage, les services du type Google Analytics, Xiti, etc., qui permettent de tracer toutes les actions et les parcours des utilisateurs sur un site Web, sont des allis indispensables. Par exemple, dans le cas dune nouvelle fonctionnalit implmenter sur un site Web, il est trs simple dajouter un nouveau bouton, une option dans un menu, un push publicitaire quelconque, et de tracer les actions de lutilisateur avec ce type doutil.
[4] Eat Your Own Dog Food : pratique qui consiste par exemple tre le propre consommateur dun service que lon offre.
93
LES GANTS DU WEB
Le risque
Lapproche MVP peut nanmoins engendrer un rsultat ambigu : le faux ngatif. En effet, si un MVP nest pas suffisamment bien pens, ou mal prsent, il peut entraner une rponse ngative de la part du groupe de clients cibls. Il tendrait ainsi faire penser que le produit envisag nest en fait pas viable, alors quil sagit plutt ditrer dessus pour le perfectionner afin de rpondre mieux au besoin. Il sagit prcisment de ne pas sarrter ce qui peut tre ressenti comme un chec : un pas de plus permettra peut tre de passer du non-viable au viable, soit au MVP proprement dit. Il peut tre judicieux de rappeler la phrase attribue Henri Ford : Si javais demand a mes clients ce quils voulaient, ils mauraient rpondu un cheval plus rapide . Avoir une vision produit, ce nest donc pas forcment quune option.

Il nous faut reparler de IMVU (cf. supra), lune des pionnires du Lean Startup, dans laquelle Eric Ries et consorts ont expriment le MVP, en particulier pour la conception davatars 3D. Le site imvu.com est un rseau social en ligne, proposant des avatars 3D, du chat, des jeux, et offrant le plus grand catalogue de biens virtuel au monde, la plupart tant crs par les utilisateurs. Citons encore Dropbox, service Web dhbergement de fichiers qui a connu une croissance trs rapide, et dont le MVP tait une vido dune dmonstration factice, le produit nexistant pas encore lpoque. Suite la publication de cette vido, lengouement des souscriptions la liste de bta test, passe de 5.000 75.000 personnes en une nuit, a confirm aux fondateurs de Dropbox que leur vision produit tait la bonne. Plus prs de chez nous, deux de nos collgues dOCTO, Vincent Coste et Benot Guillou, ont partag leur exprience en 2011 lors dune session sur le Lean Startup lUSI 2011. Ils nous donnent, dans cette prsentation, lexemple du dveloppement dune fonctionnalit de Bon plan dans le site hubluc.com, o lapproche MVP leur a permis dinvalider rapidement lintrt port par les utilisateurs ce service.
94
Et chez moi ?
Avec le dveloppement du e-commerce et des rseaux sociaux, le Web est maintenant au cur des stratgies de dveloppement conomique des entreprises. Lapproche MVP est ainsi activable telle quelle pour une large gamme de projets ports aussi bien par les DSI que par le Marketing sur ce canal, mais le MVP peut bien sr tre aussi mis en uvre en dehors du contexte Web. Il est mme possible dappliquer cette dmarche ses projets personnels. Par exemple, dans son ouvrage de rfrence, Running Lean, Ash Maurya donne lexemple de lapplication de MVP (et du Lean Startup) la publication de ce mme ouvrage. Laudit de S.I. reprsente une part importante de lactivit dOCTO, et nous sommes frquemment confronts des projets dinnovation (plateforme communautaires, e-service, boutiques e-commerce, ) dont les mises en production drapent, par exemple de six mois en six mois, et dont la mise en march, retarde dun ou deux ans, saccompagne souvent dun flop, car la valeur dlivre lutilisateur ne correspond pas en dfinitive aux attentes du march Dans lintervalle, des millions deuros auront t engloutis, pour un projet qui finira dans les oubliettes du Web. Une approche de type MVP permet de rduire ces risques et les cots associs sur le Web, des dlais dun ou deux ans pour sortir un produit ne sont pas viables, et la concurrence est non seulement froce, mais vloce ! Au sein du S.I. dentreprise, il parat difficile de raliser des Smoke Tests laide de bannires publicitaires. Pourtant, aussi, lon y rencontre frquemment des applications ou des fonctionnalits qui ont mis des mois tre dveloppes, sans pour autant remporter ladhsion des utilisateurs La vertu du Lean Startup et de lapproche MVP est bien de recentrer le discours sur la valeur apporte lutilisateur, et dapprendre sur son besoin rel. Le MVP peut, dans ce cas, servir prioriser par les utilisateurs finaux les fonctionnalits dvelopper dans la future version dune application.
95
LES GANTS DU WEB
Sources
Eric Ries, Minimum Viable Product: a guide, bLessons Learned, 3 aot 2009 > http://www.startuplessonslearned.com/2009/08/minimum-viableproduct-guide.html Eric Ries, Minimum Viable Product, StartupLessonLearned conference > http://www.slideshare.net/startuplessonslearned/minimum-viableproduct Eric Ries, Venture Hacks interview: What is the minimum viable product? > http://www.startuplessonslearned.com/2009/03/minimum-viableproduct.html Eric Ries, How DropBox Started As A Minimal Viable Product, 19 octobre 2011 > http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product Wikipedia, Minimum viable product > http://en.wikipedia.org/wiki/Minimum_viable_product Timothy Fitz, Continuous Deployment at IMVU: Doing the impossible fifty times a day, 10 fvrier 2009 > http://timothyfitz.wordpress.com/2009/02/10/continuous-deploymentat-imvu-doing-the-impossible-fifty-times-a-day Benot Guillou, Vincent Coste, Lean Start-up, 29 juin 2011, Universit du S.I. 2011, Paris > http://www.universite-du-si.com/fr/conferences/8-paris-usi-2011/ sessions/1012-lean-start-up Nivi Babak, What is the minimum viable product?, 23 mars 2009 > http://venturehacks.com/articles/minimum-viable-product Geoffrey A. Moore, Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, 1991 (revised 1996), HarperBusiness, ISBN 0066620022 Silicon Valley Product Group (SVPG), Minimum Viable Product, 24 aot 2011 > http://www.svpg.com/minimum-viable-product
96
Thomas Lissajoux, Mathieu Gandin, Fast and Furious Enough, Dfinissez et testez rapidement votre premier MVP en utilisant des pratiques issues de Lean Startup, Confrence Paris Web, 15 octobre 2011 > http://www.slideshare.net/Mgandin/lean-startup03-slideshare Ash Maurya, Running Lean > http://www.runningleanhq.com/
97
Continuous Deployment
PRATIQUES / CONTINUOUS DEPLOYMENT
Description
Dans le chapitre Bta perptuelle p. 131, nous verrons que les gants du Web amliorent leur produit de faon permanente. Mais comment arrivent-ils livrer frquemment ces amliorations alors que dans certaines DSI, la moindre modification peut prendre plusieurs semaines tre dploye en production ? La plupart du temps, ils ont instaur un processus de dploiement continu (continuous deployment), selon deux modalits possibles : Soit de faon totalement automatise une modification de code est automatiquement vrifie puis, le cas chant, dploye en production. Soit de faon semi-automatise : il est possible tout moment de mettre en production le dernier code stable en cliquant simplement sur un bouton. On parle alors de one-click-deployment .
Evidemment, la mise en place de ce pattern demande certains pr-requis
Pourquoi dployer en continu ?

La motivation premire du dploiement continu est damliorer le Time To Market, mais aussi de se donner autant doccasions de tester des hypothses, de les valider et au final damliorer son produit. Effectivement, imaginons une quipe qui met en production tous les 1er du mois (ce qui est dj une frquence leve pour beaucoup de DSI) : Jai une ide le 1er. Avec un peu de chance, les dveloppeurs peuvent limplmenter pendant les trente jours qui restent. On met en production comme prvu dans le plan de release mensuel le 1er du mois suivant. Pendant un mois, on collecte les donnes pour finalement sapercevoir que lon doit amliorer lide de base Il faut alors attendre un nouveau mois pour mettre en uvre cette future amlioration, soit trois mois au final, pour avoir la fonctionnalit stabilise.
101
LES GANTS DU WEB
Dans cet exemple, ce qui nous empche daller vite, ce nest pas le dveloppement, mais bien le processus de livraison, et le plan de release. Dployer en continu permet donc damliorer le Time To Market, mais aussi dacclrer les cycles damlioration du produit. On peut ainsi amliorer le cycle bien connu du Lean Startup (cf. Lean Startup p. 81) :
Figure 1.
Quelques dfinitions
On entend souvent parler indiffremment de Continuous Delivery et Continuous Deployment , pour viter les erreurs dinterprtation, voici notre dfinition : chaque commit (ou par intervalle de temps), le code est : Compil, test, dploy sur un environnement dintgration a Continuous Integration Compil, test, livr lquipe suivante (Tests, Qualification, Mise En Production, Ops). a Continuous Delivery Compil, test, dploy en production. a Continuous Deployment
102
Attention, il ne sagit pas ici de dire que le Continuous Delivery et la Continuous Integration ne servent rien. Bien au contraire, ce sont des tapes essentielles, et le Continuous Deployment nest que lextension naturelle du Continuous Delivery qui est lui-mme lextension naturelle de la Continuous Integration.
Et la qualit ?
Une des objections courantes lorsque lon parle de Continuous Deployment est le manque de qualit : ne risquons-nous pas de livrer quelque chose dincorrect, de livrer des bugs ? Tout comme avec la Continuous Integration, on ne bnficiera pleinement du Continuous Deployment que si lon est capable dtre sr du code tout moment. Ceci implique davoir une couverture de tests (unitaires, dintgration, de performances, etc.) trs complte. Outre les tests unitaires, invitables, on trouvera donc toute une srie de tests automatiss comme : Tests dintgration (Fitnesse, Greenpepper, etc.) Tests IHM (Selenium, etc.) Tests de performance (Gatling, OpenSTA, etc.)
Lautomatisation des tests peut sembler coteuse, mais quand lobjectif est de les excuter plusieurs fois par jour (IMVU lance 1 million de tests par jour), le retour sur investissement est trs rapidement positif. Certains, comme Etsy, nhsitent pas crer et partager des outils pour coller aux mieux leur besoin dautomatisation et de test[1]. De plus, lorsquon dploie tous les jours, la taille des dploiements est videmment plus petite que lorsquon dploie tous les mois. Et sur des petits dploiements, le TTR (Time To Repair ou temps de rparation) est plus petit, comme on peut le voir sur la figure 2.
[1] https://github.com/etsy/deployinator
103
LES GANTS DU WEB
Figure 2 (modifie). Source : http://www.slideshare.net/jallspaw/opsmetametrics-the-currency-you-pay-for-change-4608108
Etsy donne une bonne illustration de la confiance que lon peut avoir dans le code et dans la capacit de corriger rapidement. En effet, ils ne prvoient pas de mcanismes de rollbacks : We dont roll back code, we fix it ( on ne fait pas de retour arrire sur le code, on le corrige ). Selon un de leur employ la plus longue dure de rparation dun bug critique fut de quatre minutes. Les gros changements crent de gros problmes, des petits changements crent de petits problmes.

De nombreux gants du Web ont implment avec succs le Continuous Deployment, voici quelques chiffres des plus reprsentatifs Facebook, trs agressif sur lautomatisation des tests, effectue 2 dploiements par jour. Flickr utilise massivement le Feature Flipping (cf. Feature Flipping p. 107) afin de se passer de branches de dveloppement et dployer plus de 10 fois par jour. Une page affiche les dtails du dernier dploiement : http://code.flickr.com Etsy (site de commerce en ligne), a investi normment dans ses tests automatiss et ses outils de dploiement et effectue plus de 25 dploiements par jour.
104
IMVU (Site de jeux sociaux et avatars 3D), excute plus dun million de tests par jour et ralise environ 50 dploiements par jour.
Et chez moi ?
Tout dabord, estimez (ou mieux, mesurez!) le temps ncessaire vous et votre quipe pour livrer une simple ligne de code jusquen production, en respectant le processus standard videmment.
Mettre en place le Continuous Deployment

La mise en place dune Usine de Dveloppement est la premire tape du Continuous Deployment. Afin de pouvoir aller plus loin, il est essentiel de sassurer que lensemble des tests raliss couvrent une large part de lapplication. Si certains acteurs nhsitent pas coder leur propres frameworks de tests (Netflix a initi le projet Chaos Monkey qui teint des serveurs alatoirement), on peut se baser sur des frameworks existants allant de JUnit Gatling en passant par Selenium. Afin de rduire le temps dexcution des tests, IMVU rpartit ses tests sur pas moins de 30 machines. Dautres utilisent les services Cloud comme AWS afin dinstancier des environnements de test la vole et parallliser lexcution des tests. Une fois que lusine de dveloppement produit des artefacts suffisamment tests, celle-ci peut tre tendue afin de livrer ces artefacts lquipe qui va dployer lapplication sur les diffrents environnements. cette tape, on est dj dans le Continuous Delivery. Maintenant, cette dernire quipe peut enrichir lusine afin dy inclure les tches de dploiement. Ceci ncessite videmment que diffrentes tches soient automatises, comme la configuration des environnements, le dploiement des artefacts constituant lapplication, la migration des schmas de bases de donnes et bien dautres encore. Attention aux scripts de dploiement ! Il sagit de code, et comme tout code, il doit rpondre aux standards de qualit (utilisation dun SCM, tests, etc.).
Forcer le Continuous Deployment

Une solution plus radicale mais intressante est de forcer le rythme de livraison, par exemple toutes les semaines, afin de provoquer les changements.
105
LES GANTS DU WEB
Patterns connexes
Lorsque lon met en place le Continuous Deployment, plusieurs patterns sont invitablement tirs et notamment : Le Zero Downtime Deployment, car si une interruption de service dune heure nest pas problmatique lorsque lon livre tous les mois, elle peut le devenir quand on passe une livraison hebdomadaire ou quotidienne. Le Feature Flipping (cf. chapitre suivant Feature Flipping ), car une livraison rgulire entrane fatalement la livraison de fonctionnalits non termines ou avec des erreurs, il faut donc pouvoir dsactiver instantanment ou en avance les fonctionnalits posant problme. Devops videmment puisque le Continuous Deployment en est lun des piliers (cf. DevOps p. 63).
Sources
Chuck Rossi, Ship early and ship twice as often, 3 aot 2012 : > https://www.facebook.com/notes/facebook-engineering/ship-earlyand-ship-twice-as-often/10150985860363920 Ross Harmess, Flipping out, Flickr Developer Blog, 2 dcembre 2009 : > http://code.flickr.com/blog/2009/12/02/flipping-out Chad Dickerson, How does Etsy manage development and operations? 04 fvrier 2011 : > http://codeascraft.etsy.com/2011/02/04/how-does-etsy-managedevelopment-and-operations Timothy Fitz, Continuous Deployment at IMVU: Doing the impossible fifty times a day, 10 fvrier 2009 : > http://timothyfitz.wordpress.com/2009/02/10/continuous-deploymentat-imvu-doing-the-impossible-fifty-times-a-day Jez Humble, Four Principles of Low-Risk Software Releases, 16 fvrier 2012 : > http://www.informit.com/articles/article.aspx?p=1833567 Fred Wilson, Continuous Deployment, 12 fvrier 2011 : > http://www.avc.com/a_vc/2011/02/continuous-de
106
Feature Flipping
PRATIQUES / FEATURE FLIPPING
Description
Le pattern Feature Flipping permet dactiver et de dsactiver des fonctionnalits directement en production, sans re-livraison de code. Plusieurs termes sont utiliss par les gants du Web : Flickr et Etsy utilisent des feature flags , Facebook des gatekeepers , Forrst des feature buckets , des features bits chez Lyris inc., alors que Martin Fowler opte pour des feature toggles . Bref, chacun nomme et implmente le pattern sa manire mais dans lide toutes ces techniques rejoignent les mmes objectifs. Dans cet article, nous utiliserons le terme feature flipping . Mis en uvre avec succs sur notre solution de store priv Appaloosa[1], cette technique nous a apport de nombreux bnfices pour quelques inconvnients.
Mise en uvre
Le mcanisme est trs simple, il suffit de conditionner lexcution du code de la fonctionnalit de la manire suivante :
if Feature.is_enabled(new_feature) # do something new else # do same as before end

Limplmentation de la fonction is_enabled va par exemple interroger un fichier de configuration ou une base de donnes pour savoir si la fonctionnalit est active ou non. Une console dadministration est alors ncessaire pour configurer ltat des diffrents flags, chaud, sur les diffrents environnements.
Dployer en continu
L un des premiers avantages de pouvoir activer et dsactiver des fonctionnalits chaud est de livrer en continu lapplication en production. En effet, les organisations qui mettent en place un processus de livraison continue sont vite confrontes un problme : comment
[1] cf. appaloosa-store.com
109
LES GANTS DU WEB
commiter frquemment sur le rfrentiel de sources tout en garantissant la stabilit de lapplication, toujours prte pour la production ? Dans le cas de dveloppements de fonctionnalits qui ne peuvent tre termins en moins dune journe, commiter la fonctionnalit seulement lorsquelle est termine (au bout de quelques jours) est contraire aux bonnes pratiques de dveloppement en intgration continue. En effet, plus les commits sont espacs, plus les merges sont complexes et risqus, et les possibilits de refactoring transverse limites. Face cette contrainte, deux possibilits : feature branching ou feature flipping . En dautres termes, crer une branche via loutil de gestion de configuration ou dans le code. Le dbat entre ces deux approches est passionn, vous pouvez trouver quelques avis dans : http://jamesmckay. net/2011/07/why-does-martin-fowler-not-understand-feature-branches Le feature flipping permet au dveloppeur de coder lintrieur de son if , et ainsi de commiter un code non termin, non fonctionnel, tant que le code compile et que ses tests passent. Les autres dveloppeurs peuvent rcuprer les modifications sans problme tant quils nactivent pas la fonctionnalit en cours de dveloppement. Et le code peut alors tre dploy en production puisque, l encore, la fonctionnalit ne sera pas active. Cest l tout lintrt de la dmarche : ne pas conditionner le dploiement du code en production par la compltude de toutes les fonctionnalits en cours de dveloppement. Une fois la fonctionnalit termine, elle peut tre active simplement en changeant ltat du flag sur la console dadministration. Cela prsente un autre avantage ; on peut par exemple activer la fonctionnalit de manire synchronise avec une campagne marketing, on limite alors les risques derreurs suite une MEP (Mise En Production) non matrise le jour J.
Scuriser les dploiements

L un des gains les plus intressants du pattern est quil permet de scuriser les dploiements. En effet, de la mme manire que lon peut activer une fonctionnalit chaud en un clic, la dsactivation est tout aussi simple, permettant dviter un processus de rollback long et risqu pour revenir la version N-1 du systme. On peut donc trs rapidement annuler lactivation dune fonctionnalit si les tests en production ne sont pas concluants ou bien si les retours des premiers utilisateurs sont ngatifs. Tout nest pas si simple malheureusement : il faut faire attention aux
110
donnes et sassurer que le modle fonctionnera avec et sans la fonctionnalit active (voir le paragraphe Limites et contraintes > Modifications lourdes ).
Exprimenter pour amliorer le produit

Une volution naturelle du feature flipping est dtre capable dactiver ou dsactiver des fonctionnalits pour des sous-populations. Ceci permet alors de tester une fonctionnalit sur un groupe dutilisateurs et en fonction de leurs retours, de lactiver pour tous les utilisateurs ou bien de revenir en arrire. Le code ressemblera alors ceci :
if Feature.is_enabled_for(new_feature, current_user) # do something new else # do same as before end

On peut alors utiliser le mcanisme pour tester la performance dune fonctionnalit en modifiant une variable de son implmentation sur plusieurs sous-populations. La mesure des rsultats permettra de dterminer limplmentation la plus performante retenir. Autrement dit, le feature flipping reprsente un outil idal pour procder des tests A/B (cf. Test A/B , p. 117).
Offrir un produit customisable

Dans certains cas, il est intressant de permettre lutilisateur de choisir lui mme entre deux modes de fonctionnement. Par exemple, la gestion des pices jointes dans Gmail : par dfaut, linterface propose un certain nombre de fonctionnalits avances (drag and drop, uploads multiples), qui peuvent tre dsactivs dun simple clic par lutilisateur si celui-ci rencontre des dysfonctionnements. A linverse, on peut proposer un mode amlior pour lutilisateur, les labs (Gmail) sont des exemples parlants dimplmentation de feature flipping. Pour cela, il suffit de proposer une interface accessible lutilisateur luimme, lui permettant dtre matre sur lactivation ou la dsactivation de certaines fonctionnalits (self-service).
111
LES GANTS DU WEB
Grer les fonctionnalits payantes

Lactivation de fonctionnalits payantes selon diffrents plans peut tre complexe mettre en uvre et ajoute du code conditionnel du type suivant :
if current_user.current_plan == enterprise || current_user.current_plan == advanced

Que faire lorsque les exceptions arrivent : lentreprise amie paie le plan basic mais on veut lui ouvrir toutes les fonctionnalits, la fonctionnalit tait disponible sur le plan advanced il y a deux mois, mais aujourdhui, le marketing veut quelle soit accessible uniquement aux plans entreprise sauf pour ceux ayant souscrits il y a plus de deux mois.
On peut utiliser le feature flipping pour viter de grer ces exceptions dans le code. Il suffit de conditionner lactivation de features la souscription dun abonnement. Lorsque lutilisateur souscrit un abonnement entreprise, on active les fonctionnalits X,Y et Z. On peut alors grer les exceptions de faon simple dans linterface dadministration.
Graceful degradation
Certaines fonctionnalits sont plus cruciales pour le business que dautres. Lors de montes en charge importantes, il est judicieux de privilgier certaines fonctionnalits au dtriment dautres. Malheureusement, il est difficile de demander son application ou son serveur de traiter en priorit tout ce qui concerne les paiements au dtriment de laffichage des graphiques de synthse sauf si cette fonctionnalit daffichage des graphiques est feature flippe . Nous avons dj voqu limportance de la mesure (cf. Lobsession de la mesure p. 13). Une fois cette mesure en place, il est alors trivial de flipper une fonctionnalit en fonction de celle-ci. Par exemple : Si le temps de rponse moyen daffichage des graphiques dpasse 10 secondes, sur une priode de 3 minutes, alors dsactiver la fonctionnalit . Ceci permet de dgrader progressivement les fonctionnalits de site pour favoriser une exprience satisfaisante aux utilisateurs sur les fonctionnalits
112
cur de mtier. Cela rejoint le pattern de circuit breaker (dcrit dans le livre Release It! de Michel Nygard) permettant de court-circuiter le fonctionnement dune fonctionnalit en cas dindisponibilit dun service externe.
Limites et contraintes
Comme voqu prcdemment, limplmentation du feature flipping se fait simplement avec un if . Mais comme tout dveloppement, cela peut facilement devenir une nouvelle source de complexit si lon ne prend pas quelques prcautions. 1. 1 if = 2 tests 3. Aujourdhui, les tests automatiss restent la meilleure faon de vrifier le bon fonctionnement de son logiciel. Dans le cas dun feature flipping, il faudra au moins 2 tests : tester la fonctionnalit flippe OFF (active) et tester la fonctionnalit flippe ON (dsactive). Lors dun dveloppement, on a souvent tendance oublier de tester la fonctionnalit OFF , pourtant cest bien ce que verront tous vos utilisateurs avant que vous ne layez active. Donc, encore une fois, lapplication du TDD[2] est une bonne solution : les tests crits lors du dveloppement initial garantissent lexistence des tests sur des fonctionnalits OFF. 2. Faire le mnage ! Lusage intensif du feature flipping peut aboutir une accumulation de if rendant le code de plus en plus difficile maintenir. Or, pour certaines de ces fonctionnalits, lusage de flipping navait dintrt que pour garantir le dploiement continu. Pour toutes les fonctionnalits qui ne devront plus jamais tre dsactives (fonctionnalits non payantes/optionnelles, et qui ne feront pas lobjet de mode dgrad car critiques dun point de vue fonctionnel), il est important de supprimer les if pour allger le code et conserver un code maintenable. Il faut donc prvoir de consacrer un peu de temps aprs la mise en production pour faire le mnage . Comme toutes les tches de code refactoring , celles-ci sont dautant plus lgres quelles sont rgulires.
[2] Test Driven Development : dveloppement pilot par les tests.
113
LES GANTS DU WEB
3. Modifications lourdes (i.e. changement de schma relationnel) Certaines fonctionnalits entrainent des modifications lourdes de code et de modle de donnes. Prenons pour exemple une table Personne qui comprend un champ Adresse. Pour rpondre de nouveaux besoins, on dcide de sparer les tables comme suit :
Personne Id Nom Prnom Adresse Personne Id Nom Prnom Adresse Id Personne_id Rue Code_postal Ville Pays
Pour grer ce genre de cas, voici une stratgie que lon peut mettre en uvre : Ajouter la table Adresse (la base contient donc la colonne Adresse ET la table Adresse). Lapplicatif, inchang, utilise les anciennes colonnes. Modifier lapplicatif existant pour quil utilise les nouvelles tables. Migrer les donnes existantes et supprimer les colonnes non utilises. ce point, lapplicatif na souvent que peu volu du point de vue utilisateur, mais il utilise le nouveau modle de donnes. On peut alors commencer dvelopper les nouvelles fonctionnalits reposant sur le nouveau modle de donnes, en utilisant le feature flipping .
Cette stratgie est relativement simple et implique des temps darrt lors des diffrentes livraisons (tapes 2 et 4). Dautres techniques sont possibles pour grer plusieurs versions de schma en parallle, rejoignant les concepts du pattern zero-downtime deployment , permettant de mettre jour le schma relationnel sans impacter la disponibilit de lapplication qui lutilise, laide de diffrents
114
types de scripts (expansion et contraction scripts), de triggers pour synchroniser les donnes, ou encore de vues pour exposer les donnes lapplicatif travers une couche dabstraction. Beaucoup moins frquents que les modifications de code, les changements de schma relationnel sont complexes et doivent tre anticips et grs avec la plus grande attention. Les bases NoSQL (Not Only SQL) qui offrent beaucoup plus de souplesse sur le schma sont aussi des options qui peuvent tre pertinentes.

Cela fonctionne chez nous, bien que nous ne soyons pas (encore !) des gants du Web : Sur le projet Appaloosa, nous avons mis en place avec succs les diffrents patterns expliqus dans cet article. Chez les gants du Web, leur taille, les contraintes de dploiements sur plusieurs sites, les migrations de donnes trs volumineuses, les forcent mettre en place de tels mcanismes. Parmi les plus connus, on peut citer Facebook, Flickr ou Lyris inc. Plus prs de chez nous on trouve Meetic, la BnF ou encore Viadeo, ce dernier insistant particulirement sur le nettoyage de code et ne laissant ses flippers que quelques jours en production. Et tous ceux qui font du Continuous Deployment (cf. Continuous Deployment p. 99) appliquent, dune faon ou dune autre, le pattern feature flipping.
Et chez moi ?
Il existe diffrentes implmentations dans diffrents langages comme la gem rollout en Ruby ou feature-flipper en Grails, mais cest tellement simple que vous voudrez srement faire votre propre implmentation pour coller au plus prs de vos besoins. Les avantages et les utilisations sont multiples, donc si vous avez besoin de dployer progressivement des fonctionnalits ou de tester sur des groupes dutilisateurs ou de dployer en continu, il ne vous reste plus qu commencer.
115
LES GANTS DU WEB
Sources
Flickr Developer Blog : > http://code.flickr.com/blog/2009/12/02/flipping-out Compte-rendu session Flickr Velocity 2010 : > http://theagileadmin.com/2010/06/24/velocity-2010-always-ship-trunk Question Quora sur Facebook : > http://www.quora.com/Facebook-Engineering/How-does-FacebooksGatekeeper-service-work Forrst Engineering Blog : > http://blog.forrst.com/post/782356699/how-we-deploy-new-featureson-forrst Slideshare Lyrics inc. : > http://www.slideshare.net/eriksowa/feature-bits-at-devopsdays-2010-us Talk Lyrics inc. Devopsdays 2010 : > http://www.leanssc.org/files/201004/videos/20100421_ Sowa_EnabilingFlowWithinAndAcrossTeams/20100421_Sowa_ EnabilingFlowWithinAndAcrossTeams.html Whitepaper Lyrics inc. : > http://atlanta2010.leanssc.org/wp-content/uploads/2010/04/Lean_ SSC_2010_Proceedings.pdf Interview de Ryan King de Twitter : > http://nosql.mypopescu.com/post/407159447/cassandra-twitter-aninterview-with-ryan-king Article de Blog de Martin Fowler : > http://martinfowler.com/bliki/FeatureToggle.html Blog 99designs : > http://99designs.com/tech-blog/blog/2012/03/01/feature-flipping
116
Test A/B
PRATIQUES / TEST A/B
Description
Le test A/B est une mthode de dveloppement produit qui permet dexprimenter lefficacit dune fonctionnalit. On peut par exemple tester un courrier e-mail de campagne marketing, une page daccueil, une bannire publicitaire ou un parcours de paiement. Cette stratgie de test permet de valider les diffrentes versions dun objet en agissant sur une unique variable : le libell dun objet de courrier lectronique ou le contenu dune page par exemple. Comme toute stratgie de test mesurant une performance, le test A/B ne peut se faire que dans un environnement capable de mesurer le succs dune action. Pour prendre lexemple de lobjet du courrier lectronique, il faudra tre capable de mesurer son taux douverture afin de comprendre quel message est le plus percutant. Pour une page Web, on regardera le taux de clic, pour un parcours de paiement, le taux de conversion.
Mise en uvre
La mthode en elle-mme est relativement simple. Vous avez des variantes dun objet que vous voulez faire tester diffrentes souspopulations. Une fois la meilleure variante trouve, vous la soumettez au reste de la population. Simple comme bonjour ? Pas tout fait. La premire interrogation porte sur la nature de la variation : o placer le curseur entre la micro optimisation et le grand chambardement ? Tout dpend de la phase dapprentissage dans laquelle vous vous trouvez. Si vous tes dans une phase de dcouverte client (cf. Minimum Viable Product , p. 89, Lean Startup p. 81), les tests A/B peuvent faire compltement varier la version teste. Vous pouvez par exemple faire deux pages daccueil diffrentes, avec des messages marketing diffrents, une disposition diffrente, des images diffrentes pour tester le taux dinscription sur deux populations. Dans une phase plus avance du projet, o la variation dun objectif de conversion de 1 % fait la diffrence, les variations devront tre plus fines (taille, couleur, disposition dun bouton par exemple).
119
LES GANTS DU WEB
La seconde interrogation concerne votre segmentation. Comment allezvous dfinir vos diffrentes sous-populations ? Il ny a pas de formule miracle mais une rgle fondamentale : le critre de segmentation ne doit pas influer le rsultat de lexprience (test A/B = une seule variable). On peut prendre un critre basique : la date dinscription, lordre alphabtique, tant quil ne rentre pas en compte dans les rsultats. La troisime question est celle de la condition darrt. partir de quand a-ton assez de rponses pour gnraliser le rsultat de lexprimentation ? Cela dpend du trafic que vous arrivez gnrer, de la complexit de votre exprience et de la diffrence de performance entre vos diffrents chantillons. Autrement dit, peu de trafic, avec des rsultats trs proches les uns des autres ncessitera une dure de test plus longue. Les principaux outils du march (Google Website Optimizer, Omniture Test&Target, Optimizely) offrent la possibilit de savoir si le test que vous menez est significatif. Si vous grez votre test manuellement, vous devrez rviser quelques lois statistiques et dchantillonnage. Pour vous aider, des sites Web se proposent de calculer cette pertinence votre place[1]. Voyons maintenant deux piges viter lorsquon commence test A/B. En premier, ne regarder la performance dun test que vis vis dun seul objectif est trompeur. Dans la mesure o lon met en place un test qui change lexprience de lutilisateur, il est ncessaire de suivre les autres objectifs business. En changeant la page daccueil dun site par exemple, vous suivrez bien sur votre taux dinscription, tout en noubliant pas de regarder la performance du paiement. Lautre pige est doffrir une exprience diffrente une population dans le temps. La solution que vous mettez en place doit absolument tre consistante durant la dure de lexprience : un utilisateur qui revient doit tre expos la mme version de lexprimentation, tant pour la pertinence des rsultats de lexprimentation que pour lexprience utilisateur. Une fois la meilleure solution dtermine, il faudra bien sur la gnraliser.

On ne peut pas ne pas citer le pionnier des tests A/B : Amazon. Les acteurs Web dans leur ensemble sont enclins partager leurs exprimentations.
[1] > http://visualwebsiteoptimizer.com/ab-split-significance-calculator
120
PRATIQUES / TEST A/B
Vous trouverez facilement sur le Web des exemples de Google, Microsoft, Netflix, Zynga, Flickr, eBay et bien dautres avec des rsultats parfois surprenants. Le site www.abtests.com recense certaines exprimentations.
Et chez moi ?
Le test A/B est avant tout un droit lexprimentation. Se mettre dans une dmarche dapprentissage, avec ds le dpart des hypothses de rsultats et un modus operandi, est une source de motivation pour les quipes produit. Ce pilotage la performance permet de mettre en place un management produit pilot par la donne. La mise en place dune solution de test A/B est relativement simple (mais ncessite de lhygine dans les pratiques). Google Web Site Optimizer, pour ne citer que lui, permet de mettre en place un outil directement coupl aux indicateurs Google Analytics. Avec un investissement modr, vous donnez vos quipes le moyen dobjectiver leurs actions par rapport une finalit produit.
Sources
37signals, Test A/B sur la page de signup : > http://37signals.com/svn/posts/1525-writing-decisions-headline-testson-the-highrise-signup-page Tim Ferris : > http://www.fourhourworkweek.com/blog/2009/08/12/google-websiteoptimizer-case-study Wikipedia : > http://fr.wikipedia.org/wiki/Test_A/B
121
Device Agnostic
PRATIQUES / DEVICE AGNOSTIC
Description
Pour les gants du Web, lergonomie nest plus un dbat : elle nest pas ngociable. Dj en 2003, le manifeste du Web 2.0 plaidait pour une Rich User Experience , et aujourdhui la ncessit doffrir la meilleure interface utilisateur possible fait consensus dans le monde du Web. Elle est considre un facteur important de gain de parts de march. lexigence dune exprience utilisateur de grande qualit sajoute le besoin daccder aux applications anywhere/anytime , cest dire dans tous les contextes de la vie courante. On distingue en gnral les situations sdentaires (ex. : usage au bureau), nomades (ex. : usage en position assise dans un aroport) ou mobiles (ex. : usage en marchant dans la rue). Ces situations reposent aujourdhui sur diffrents types dappareils ou devices (terminal). En simplifiant, on peut distinguer : Les ordinateurs fixes pour lusage sdentaire. Les ordinateurs portables et tablettes pour lusage nomade. Les smartphones pour lusage mobile.
Le pattern Device Agnostic signifie la chose suivante : il est indispensable doffrir la meilleure ergonomie possible quelle que soit la situation dusage et le device. Lune des premires socits avoir dvelopp ce pattern est Apple avec lcosystme iTunes. En effet, Apple a rendu la musique accessible dabord sur PC/Mac et iPod, puis par la suite sur iPhone et iPad. Apple couvre donc les trois situations dusage. Par contre, Apple napplique pas compltement le pattern car la musique nest pas accessible sur Android ou Windows Phone. Pour mettre en uvre cette approche, il est parfois ncessaire doffrir autant dinterfaces quil existe de situations dusages. En effet, une interface gnrique de type one size fits all ne permet pas cette ergonomie optimale sur ordinateur, tablette, smartphone, etc.
125
LES GANTS DU WEB
Les gants du Web investissent donc dans le dveloppement de nombreuses interfaces, ce qui est rendu possible par lapplication du pattern API first (cf. Open API p. 195). Selon ce principe, larchitecture de lapplication doit reposer sur une API gnrique, les diffrentes interfaces seront ensuite dveloppes directement par lentreprise ou indirectement par lcosystme des dveloppeurs et partenaires sur la base de cette API. Pour tirer le meilleur parti de chacun des terminaux, il est aujourdhui encore difficile de se cantonner des interfaces Web. En effet, ces dernires ne grent pas les fonctionnalits propres des devices (push, capteur photo ou vido, acclromtre, etc.). Elles donnent aussi lutilisateur une impression de manque de ractivit, car elles ncessitent le tlchargement initial de tout le contenu[1], l o les applications natives peuvent fonctionner sans rien ou en tlchargeant ventuellement quelques ressources XML ou JSON.
Id love to build one version of our App that could work everywhere. Instead, we develop separate native versions for Windows, Mac, Desktop Web, iOS, Android, BlackBerry, HP WebOS and (coming soon) Windows Phone 7. We do it because the results are better and, frankly, thats all-important. We could probably save 70% of our development budget by switching to a single, cross-platform client, but we would probably lose 80% of our users.
Phil Libin, CEO Evernote (janvier 2011)
Cependant, les choses voluent avec HTML5 qui gre le mode dconnect et rpond aux besoins des nombreuses applications qui nutilisent pas de GPS ou dacclromtre. Et de fait, si certains acteurs du Web, comme Evernote, recourent des applications compltement natives, dautres sorientent vers une approche hybride : des contenus HTML5 embarqus dans une application native qui devient une simple coquille, capable de recevoir des notifications en push. Cest en particulier le cas de Gmail, Google+ ou Facebook sur iPhone. Un avantage de cette approche est dassurer une prsence sur les AppStores, auxquels les utilisateurs ont lhabitude de recourir pour installer leurs applications. Le pattern Hybride est ainsi un bon compromis : il permet une rutilisation du code HTML5 sur divers terminaux, tout en bnficiant de linstallation de lapplication via les AppStores Apple, Android, Windows Phone, et bientt Mac et Windows
[1] Ce tlchargement peut tre optimis (cf. Fluidit de lexprience lutilisateur , p. 27) mais on ne fait jamais de miracle
126

Les exemples dusage du pattern Device Agnostic sont nombreux chez les gants du Web. On peut citer : Dans la catgorie des applications totalement natives : Evernote, Twitter, Dropbox, Skype, Amazon, Facebook. Dans la catgorie des applications hybrides : Gmail, Google+.

Facebook propose : Une interface Web pour PC/Mac : www.facebook.com. Une interface Web mobile pour Smartphones : m.facebook.com. Des interfaces mobiles embarques pour iPad, iPhone, Android, Windows Phone, Blackberry, PalmOS. Une interface par SMS pour mettre jour son status et tre notifi des mises jour de status de ses amis. Une interface par email pour mettre jour son status. Par ailleurs, plusieurs interfaces embarques pour Mac et PC sont proposes par des tiers comme Seesmic ou Twhirl. Twitter se distingue des autres gants du Web par le fait quil a laiss son cosystme implmenter le pattern pour lui (cf. Open API p. 195). En effet, de nombreuses interfaces graphiques Twitter ont t cres par les tiers comme TweetDeck, Tweetie pour Mac et PC, Twitterrific, Twidroid pour mobile... tel point que, pendant un temps, linterface Web de Twitter tait rpute comme peu ergonomique et de nombreux utilisateurs lui prfraient celles issues de lcosystme. Twitter est aujourdhui en train de reprendre la main sur ses interfaces utilisateurs.
127
LES GANTS DU WEB
En France
On trouve des exemples du pattern Device Agnostic chez les grands mdias. Par exemple le Monde propose : une interface Web pour PC/Mac : www.lemonde.fr, une interface Web mobile pour smartphone : mobile.lemonde.fr, des interfaces mobiles hybrides pour iPhone, Android, Windows Phone, Blackberry, PalmOS, Nokia OVI, Bada, une interface pour iPad.
On le trouve aussi dans des services grand public ncessitant une consultation frquente, comme la banque. A titre dexemple, le Crdit Mutuel propose : une interface Web pour PC/Mac : www.creditmutuel.fr, un portail de redirection pour tous les types de devices : m.cmut.fr, une interface Web mobile pour Smartphones : mobi.cmut.fr, une interface Web mobile pour tablettes : mini.cmut.fr, une interface Wap : wap.cmut.fr, une interface Java simplifie pour les tlphones basiques, des interfaces mobiles embarques pour iPhone, Android, Windows Phone, Blackberry, une interface pour iPad.
128
Et chez moi ?
Le pattern peut tre envisag pour tout service B2C dont laccessibilit anywhere/anytime a du sens. En cas de budget limit, il est frquent dimplmenter une application mobile pour le device le plus utilis par la population cible, et de proposer une API ouverte en esprant que dautres implmenteront les interfaces pour les autres devices.
Patterns connexes
Pattern Open API ou cosystme ouvert, p. 195. Pattern Fluidit de lexprience utilisateur, p. 27.
Exceptions !
Comme prcis prcedemment, la limite de cette approche est le budget ncessaire son implmentation !
Sources
Rich User Experiences, manifeste du Web2.0, Tim Oreilly : > http://oreilly.com/Web2/archive/what-is-Web-20.html Four Lessons From Evernotes First Week On The Mac App Store, Phil Libin : > http://techcrunch.com/2011/01/19/evernote-mac-app-store
129
La bta perptuelle
PRATIQUES / LA BTA PERPTUELLE
Description
Avant dintroduire la bta perptuelle, il est ncessaire de revenir sur un pattern classique du monde du logiciel libre :
Release early, release often.

Le principe de ce pattern consiste mettre rgulirement le code la disposition de la communaut afin de permettre aux dveloppeurs, testeurs et utilisateurs de donner un feedback en continu sur le produit. Cette pratique a t dcrite dans La cathdrale et le bazar dEric Steven Raymond en 1999. Elle rejoint le principe ditrations courtes des mthodes agiles. Le principe de la bta perptuelle a t introduit dans le manifeste du Web 2.0, crit par Tim OReilly, et o il nous dit ce qui suit :
Les utilisateurs doivent tre considrs comme des codveloppeurs, en suivant les principes Open-Source (...) Avec le Web 2.0, ce principe volue vers une position plus radicale, la bta perptuelle, dans laquelle le produit est dvelopp de manire ouverte, avec de nouvelles fonctionnalits offertes sur une base mensuelle, hebdomadaire, ou mme quotidienne.
Le terme bta perptuelle dsigne le fait que lapplication nest jamais finalise, mais toujours en volution : il ny a pas de livraison de nouvelle version proprement parler. Ce mode de fonctionnement est videmment trs proche de la logique du Continuous Delivery (cf. Continuous Deployment p. 99). Cette volution continue est possible car il sagit ici de services en ligne et non de logiciels : Dans le cadre de logiciels, la gestion de versions suit gnralement une roadmap avec des jalons de publication : des releases . Ces releases sont espaces dans le temps pour deux raisons : la ncessit de dployer les versions chez les utilisateurs, et le besoin dassurer la
133
LES GANTS DU WEB
maintenance et le support des diffrentes versions dployes chez les utilisateurs. Assurer le support, les mises jour de scurit et la maintenance volutive sur plusieurs versions dun mme logiciel est un terrible casse-tte, et un casse-tte coteux. Prenons lexemple de Microsoft : lditeur de Redmond a d, un moment donn, grer les volutions de Windows XP, Vista et Seven. On imagine les trois quipes de dveloppeurs mobilises pour un seul et mme logiciel : une terrible dispersion dnergie et un cauchemar pour un diteur moins fortun que Microsoft. Ce syndrome est appel perversion des versions . Dans le cadre des services en ligne, il est possible de ne grer quune seule version de lapplication. Et comme les gants du Web se chargent de mettre en ligne et dhberger leurs applications, les utilisateurs peuvent bnficier des nouveauts sans avoir grer de dploiement logiciel.
Les nouvelles fonctionnalits apparaissent au fil de leau et elles sont dcouvertes opportunment par les usagers. Ce mode de fonctionnement permet un apprentissage progressif des nouveauts applicatives. En rgle gnrale, les problmatiques de compatibilit ascendante sont bien gres (il existe quelques exceptions, comme le support du mode dconnect dans Gmail, suite labandon de Google Gears). Ce modle est largement utilis par les acteurs du Cloud Computing. La Customer driven roadmap est un lment complmentaire et vertueux de la bta perptuelle (cf. Lean Startup p. 81). Comme les gants du Web matrisent la plateforme de production, ils peuvent faire des statistiques sur lusage de leurs logiciels. Cela leur permet de mesurer laccueil qui est fait aux nouvelles fonctionnalits offertes. Nous lavons dj voqu, les gants du Web suivent de mtriques. On dit dailleurs quils ont le culte de la mesure (cf. Lobsession de la mesure p. 13). De manire plus classique, le fait de matriser la plateforme de production permet de lancer des sondages auprs de certains segments de population afin dobtenir un feedback utilisateurs. Pour utiliser le pattern bta perptuelle, il est indispensable davoir les moyens de faire des dploiements rguliers. Les pr-requis sont donc : la mise en oeuvre dune usine logicielle avec build automatis,
134
des pratiques de Continuous Delivery , la capacit faire un rollback rapide en cas de problme...
Il existe cependant une polmique sur la bta perptuelle : certains utilisateurs considrent que bta est synonyme de produit non fini, et que les services qui suivent ce pattern ne sont pas assez fiables pour tre utiliss. Cette polmique a pouss certains oprateurs de services a supprimer la mention bta de leur site, sans pour autant changer leurs pratiques.

La rfrence tait Gmail dont le logo intgrait la mention bta jusquen 2009 (une fonction vintage back to Beta a depuis t ajoute). La pratique existe chez de nombreux gants du Web : Facebook, Amazon, Twitter, Flickr, Delicious.com, etc. Une bonne illustration de la bta perptuelle est fournie par les Labs de Gmail : ce sont de petites fonctionnalits unitaires que les utilisateurs peuvent dcider dactiver ou non. En fonction de leur adoption, Google dcide de les intgrer la version standard de son service (cf. Feature Flipping p. 107). En France, des services en ligne affichent, ou ont affich, le bta sur leur page daccueil : urbandive.com : service de navigation en vue pitonne du groupe Pages Jaunes, sen.se : service de stockage et danalyse de donnes personnelles.
Patterns connexes
Pattern Continous Deployment , p. 99. Pattern Test A/B , p. 117. Pattern Lobsession de la mesure , p. 13.
135
LES GANTS DU WEB
Exceptions !
Certains gants du Web choisissent de continuer utiliser le principe de coexistence des versions. Il est en particulier utile de maintenir plusieurs versions dune API afin dviter de forcer les dveloppeurs mettre jour leur code immdiatement la sortie dune nouvelle version de lAPI (cf. Open API p. 195 ) . Voir en particulier lAPI Amazon Web Services.
Sources
Tim OReilly, What Is Web 2.0 ?, 30 septembre 2005 : > http://oreilly.com/pub/a/web2/archive/what-is-web-20.html Eric Steven Raymond, La cathdrale et le bazar : > http://www.linux-france.org/article/these/cathedrale-bazar/cathedralebazar.html
136
Architecture
LES GANTS DU WEB
Cloud First..................................................................................... 141 Commodity Hardware.................................................................... 151 Sharding........................................................................................ 163 TP vs BI : la nouvelle approche NoSQL........................................... 179 Design for Failure........................................................................... 189 Open API ou cosystme ouvert................................................ 195
140
Cloud First
ARCHITECTURE / CLOUD FIRST
Description
Comme nous lavons vu dans la description du pattern Build vs Buy (cf. Build vs Buy p. 19) : les gants du Web privilgient le dveloppement spcifique, afin de matriser leurs outils de bout en bout, l o de nombreuses entreprises recourent plutt des progiciels, considrant les outils informatiques comme des commodits[1]. Si les gants du Web, comme les startups, prfrent dvelopper en interne leurs applications critiques, il leur arrive aussi davoir recours des commodits cres par des tiers. Dans ce cas, ils vont jusquau bout de la logique de commodit : ils choisissent une externalisation complte du service en allant vers le Cloud. En privilgiant le Cloud, les gants du Web, comme les startups, appliquent une approche trs pragmatique : bnficier du meilleur des innovations de leurs pairs, vite, et selon un modle dachat peu contraignant, pour focaliser leurs efforts informatiques sur leur diffrenciant business. Ce modle peut inspirer toutes les entreprises qui souhaitent aller vite et rduire les cots dinvestissement pour gagner des parts de march. Pourquoi privilgier le Cloud dans le cadre de commodits ? Le tableau en page suivante en prsente les avantages. On peut dcliner cette approche Cloud selon 3 grands axes : Le recours des API et Mashups : les gants du Web utilisent massivement des services unitaires dvelopps par des acteurs du Cloud (fond de carte Google Maps, identification utilisateur via Facebook, paiement via Paypal, statistiques via Google Analytics, etc.) et les intgrent leur pages selon le principe des mashups. Le dport de commodits fonctionnelles : les acteurs du Web externalisent souvent leurs logiciels de commodit vers des services SaaS (comme Google Apps pour la collaboration, Salesforce pour la gestion de force de vente, etc.). Le dport de commodits techniques : les acteurs du Web recourent rgulirement aux plateformes IaaS et PaaS pour lhbergement de leur services (par exemple, Netflix et Heroku utilisent Amazon Web Service).
[1] Anglicisme : commodity dsigne un produit de consommation courante, un consommable.
143
LES GANTS DU WEB
Modle Axe danalyse Gestion interne Cot

Investissement initial dans les licences, le matriel, le personnel.
Cloud
Paiement la consommation, donc pas dinvestissement initial et pas dengagement.
Time to Market
Achat des licences, puis dploiement par lentreprise en quelques semaines. Pense moyen terme par lditeur selon feedback des groupes dutilisateurs.
Souscription en Self Service et mise disposition automatique en quelques minutes. Excute court terme selon le suivi des comportements utilisateurs sur le service.
Roadmap/nouvelles fonctionnalits
Rythme des volutions Support et mises jour Hbergement et exploitation
Souvent une release majeure par an.
Nouvelles fonctionnalits au fil de leau.
Cot additionnel lanne.
Compris dans labonnement.
Ncessite la construction Dlgu loprateur et lopration dun data- Cloud. center par un personnel comptent.
Scurit physique des donnes
La scurit est assurer par lentreprise.
Les grands oprateurs Cloud assurent la scurit des donnes en conformit avec les normes ISO 27001[2] et SSAE 16[3].
[2] ISO 27001 : > http://en.wikipedia.org/wiki/ISO_27001 [3] SSAE 16 (remplaant de SAS 70 Type 2) : > http://www.ssae-16.com
144
Le dport sur le Cloud de commodits techniques est particulirement intressant pour les acteurs du Web. En effet, avec le modle de paiement la consommation, ils peuvent dmarrer une activit en ligne avec des cots dhbergement quasi nuls. Les charges apparaitront progressivement avec la monte en puissance du nombre dutilisateurs, et donc les revenus, si tout se passe bien. Le Cloud a donc chang drastiquement leurs plans de lancement. Ainsi, la plateforme IaaS Amazon Web Services est massivement utilise par des gants du Web comme Dropbox, 37signals, Netflix, Heroku
Lors de la confrence CloudForce 2009 Paris, un Vice Prsident de Salesforce a affirm que lentreprise nutilisait pas de plateforme IaaS, car ces solutions nexistaient pas la cration de lentreprise ; mais que Salesforce pourrait faire le choix de lIaaS aujourdhui.

Lligibilit du Cloud est variable selon les types de donnes manipules et les contraintes rglementaires. Ainsi : Les banques du Luxembourg nont pas le droit de stocker leurs donnes en dehors dorganismes certifis. Les socits qui manipulent des donnes sensibles, des secrets industriels ou des brevets hsitent les stocker sur le Cloud. En particulier, le Patriot Act[4] agit comme un repoussoir contre le Cloud : il oblige les socits de droit amricain ouvrir leurs bases de donnes sur demande de ltat amricain. Les socits qui manipulent des donnes personnelles peuvent se voir restreindre lusage du Cloud, du fait des rglementations de la CNIL, qui sont respectes de manire incertaine selon les plateformes Cloud (implmentation variable du Safe Harbor[5]).
[4] > http://fr.wikipedia.org/wiki/USA_PATRIOT_Act [5] > http://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles

145
LES GANTS DU WEB
Lorsque ces contraintes nexistent pas, le recours au Cloud est possible. Et de nombreuses entreprises de toutes tailles et de tous secteurs recourent aujourdhui au Cloud, aux USA comme en Europe. Citons un cas dusage qui illustre bien le potentiel du Cloud :
Vivek Kundra, ancien DSI de la maison Blanche avait annonc en 2011 le programme Cloud First qui stipulait que les administrations des Etat Unis devaient utiliser en priorit le Cloud pour leur informatique. Cette dcision est remettre dans son contexte : il existe aux USA des GovCloud , cest dire des offres Cloud tailles pour les administrations, respectant leurs contraintes, hberges sur le sol amricain et isoles des autres clients. Elles sont proposes par Amazon, Google, et dautres oprateurs[6].
Notons quil existe un frein psychologique important lexternalisation des donnes vers le Cloud dans certaines entreprises. Ce frein repose sur les contraintes prsentes ci-dessous, mais aussi sur un dficit de confiance (les oprateurs Cloud nont pas encore atteint le niveau de confiance des banques), et parfois sur un refus du changement. Les gants du Web sont moins affects par les deux derniers freins, car ils sont proches des acteurs du Cloud et ouverts au changement.
Dpendance au Cloud ?
Il convient aussi de se mfier dune trop grande dpendance une plateforme Cloud unique pour lhbergement dapplications critiques. Ces plateformes ne sont pas infaillibles comme on a pu le constater rcemment : pannes de Microsoft Azure (fvrier 2012), Salesforce (juin 2012), Amazon Web Services (avril et juillet 2012). Les pannes dAWS ont point les diffrences de maturit dans lusage du Cloud : Pinterest, Instagram, Heroku qui reposaient sur un seul des datacenters Amazon ont t fortement affects,
[6] Federal Cloud Computing Strategy , Vivek Kundra, 2011 : > http://www.forbes.com/sites/microsoft/2011/02/15/kundra-outlines-cloud-first-policy-foru-s-government
146
Netflix qui utilisait plusieurs datacenters Amazon sen est mieux sorti[7] (cf. Design for Failure p. 189).
Notons que ces pannes sont hypermdiatises alors quon a peu dinformations sur celles des datacenters des entreprises. Il est donc difficile den valuer limpact rel sur les utilisateurs. Voici quelques Service Level Agreement des fins de comparaison avec ceux de vos entreprises : Amazon EC2 : 99,95 % de disponibilit par an. Google Apps : 99,9 % de disponibilit par an.

Quelques exemples dutilisation du Cloud par les gants du Web : Des gants du Web qui utilisent Amazon Web Services : Heroku, Dropbox, 37Signals, Netflix, Etsy, Foursquare, Voyages SNCF. Amazon draine dailleurs 1 % du trafic Web. Des gants du Web qui utilisent Salesforce : Google, LinkedIn. Des gants du Web qui utilisent Google Apps : Box.net.
En France
Quelques exemples dutilisation du Cloud en France : Dans le secteur de lindustrie : Valeo, Treves utilisent les services Google Apps. Dans le secteur de lassurance : Malakoff Mderic utilise les services Google Apps.
[7] Retour dexprience de Netflix sur les pannes AWS : > http://techblog.netflix.com/2011/04/lessons-netflix-learned-from-aws-outage.html
147
LES GANTS DU WEB
Dans le secteur bancaire : la plupart utilisent Salesforce sur une partie de leur activit. Dans le secteur de lInternet : PagesJaunes utilise Amazon Web Services. Dans le secteur public : La Poste utilise les services Google Apps pour ses facteurs.
Et chez moi ?
Si vous tes une PME ou une TPE, il est probable que vous tiriez des bnfices externaliser vos commodits sur le Cloud, pour les mmes raisons que les gants du Web. Et ce dautant plus que les problmatiques rglementaires, comme celles de protection des secrets industriels, devraient tre rsolues avec lmergence de Clouds franais ou europens comme Andromde. Si vous tes une grande entreprise, disposant dun important existant informatique et de nombreuses quipes dinformaticiens, le bnfice du Cloud peut tre rduit par le cot du changement. Il est cependant pertinent de ltudier. Dans tous les cas, vous pouvez bnficier de lagilit et du paiement lusage offerts par le Cloud pour : Des projets innovants : pilotes, Proof Of Concept, incubation de projets, etc. Des environnements dure de vie limite (environnements de dveloppement, test, recette, etc.).
Pattern connexe
Pattern Build vs Buy , 19.
148
Exceptions !
On la vu prcdemment : les contraintes rglementaires peuvent interdire le recours au Cloud. Il existe parfois des cas de r-internalisation : en effet, lorsque la volumtrie des donnes et utilisateurs crot de manire spectaculaire, il peut se relever moins coteux de rapatrier ses applicatifs, de btir un datacenter bas sur une architecture totalement optimise pour son mtier. Ce type doptimisation ncessite toutefois un personnel trs qualifi.
149
Commodity Hardware
ARCHITECTURE / COMMODITY HARDWARE
Description
Bien quinvisibles depuis nos navigateurs, des millions de serveurs fonctionnent continuellement pour que le Web reste disponible 24h/24. Mme si les chiffres restent confidentiels, certains grands acteurs du Web peuvent avoir des dizaines, des centaines de milliers de machines comme EC2[1] voire aux alentours de un million chez Google[2]. La mise en uvre dun si grand nombre de machines reprsente un dfi technique mais surtout conomique. La grande majorit de ces acteurs ont relev ce dfi en utilisant du matriel de grande srie, du commodity hardware terme que nous allons prciser par la suite. Cest lune des raisons qui conduit les gants du Web utiliser un agencement de nombreuses machines de grande srie la place dun seul grand systme. Un seul service aux utilisateurs, une seule application, peut ainsi sexcuter sur des centaines de machines. On parle ce niveau-l de Warehouse Scale Computer[3], des centaines de machines prenant la place dun seul serveur.
Les besoins mtiers

Les gants du Web ont en commun un certain nombre de problmatiques, voques dans divers autres chapitres[4] : Un business model li lanalyse dnormes quantits de donnes par exemple indexer le Web (soit prs de 50 milliards de pages). Des enjeux forts de performance pour que les temps de rponse restent faibles. Une rmunration indpendante de la quantit de donnes stockes : publicit, facturation de lutilisateur au forfait.
[1] Source SGI. [2] L encore, les estimations restent complexes. [3] Ce concept a t largement dcrit par ce trs long papier Data Center as a Computer dont nous ne reprenons ici que quelques concepts. [4] cf. en particulier Sharding , p. 163.
153
LES GANTS DU WEB
Les revenus comme la publicit ne sont pas linaires avec le nombre de recherches et, ramens une requte unitaire, restent faibles[5]. Comparativement, les cots unitaires sur des grands serveurs traditionnels restent trop levs. Lenjeu est donc fort de trouver les architectures avec les cots par transaction les plus faibles. Enfin, les ordres de grandeur des traitements mis en uvre par les gants du Web sont sans commune mesure avec les traitements traditionnels dinformatique de gestion dont le nombre dutilisateurs tait jusque-l born par le nombre demploys. Aucune machine, aussi grosse soit-elle, ne sera en mesure de rpondre leurs besoins. En somme, ces acteurs ont besoin de scalabilit (cot marginal par transaction constant), ce cot marginal devant rester faible.
Machine de grande srie contre serveur haut de gamme

Lorsque la question de la scalabilit se pose, deux grandes alternatives sopposent : Le scale-up, ou croissance verticale, consiste utiliser une machine plus performante. Cette approche a t historiquement utilise du fait de sa simplicit de mise en uvre et parce que la loi de Moore permettait aux constructeurs doffrir rgulirement des machines plus puissantes pour un prix constant. Le scale-out, ou scalabilit horizontale, consiste mettre en commun les ressources de plusieurs machines qui peuvent tre unitairement moins puissantes. Il ny a alors plus de limite lie la taille de la machine.
Or, les composants, technologies et architectures issus du monde du PC offrent un ratio puissance/prix trs avantageux. Leur relativement faible puissance de calcul par rapport des architectures plus efficientes telles que les architectures RISC est compense par des prix plus faibles du fait de la production en grande srie. Ainsi une tude mene partir de rsultat du TPC-C[6] montre un cot relatif la transaction trois fois moins lev pour un serveur dentre de gamme que pour un serveur haut de gamme.
[5] Early on, there was an emphasis on the dollar per (search) query, [Urs] Hoelzle said. We were forced to focus. Revenue per query is very low. > http://news.cnet.com/8301-1001_310209580-92.html [6] Ibid, [3] page prcdente.
154
Aux chelles mises en uvre par les gants du Web plusieurs milliers de machines coordonnes pour excuter une seule fonction dautres cots deviennent extrmement importants : puissance lectrique, climatisation, m. Le cot par transaction doit englober ces diffrents aspects. Ce sont ces constats qui ont amen les gants du Web privilgier la croissance horizontale (scale-out) base de commodity hardware.

La quasi-totalit des gants du Web : Google, Amazon, Facebook, LinkedIn utilisent aujourdhui des serveurs de type x86 et du commodity hardware. Cependant lutilisation de tels composants introduit dautres contraintes et ces Data Centers As A Computer ont des contraintes dchelle diffrentes de nos datacenters. Cest ce sur quoi nous allons nous pencher plus en dtail.
Des caractristiques matrielles impactantes pour la programmation

Les architectures serveurs traditionnelles visent, autant que le permet le hardware, prsenter au dveloppeur une architecture thorique avec un processeur, une mmoire centrale contenant le programme et les donnes, et un systme de fichiers[7]. La programmation que lon connat base de variables, dappels de fonctions, de threads et de processus ncessite de faire cette hypothse. Autant les architectures des grands systmes sont proches de cette architecture thorique , autant un ensemble de machines dans un datacenter sen loigne. Les machines de type SMP (Symetric Multi Processor), utilises dans une optique de scale-up, permettent aujourdhui dutiliser la programmation standard (avec accs toute la mmoire et tous les disques de faon uniforme).
[7] Cette architecture est connue sous le nom darchitecture de Von Neumann.
155
LES GANTS DU WEB
Figure 1 (modifie). Source RedPaper 4640, page 34.
En effet, les chiffres sur le schma montrent leffort fait pour que les dbits et les latences soient sensiblement identiques entre un processeur, sa mmoire et ses disques, quils soient connects directement, connects sur le mme processor book[9] ou sur des processor books diffrents. Sil reste une caractristique NUMA (Non Uniform Memory Access : un accs la mmoire proche est plus rapide que laccs la mmoire dans une autre partie du systme), celle-ci se concentre sur la mmoire centrale avec des diffrences de latence et de bande passante dans un ratio 1
[9] Un processor book est un compartiment regroupant processeurs, mmoire et connecteurs dentre sortie, comparable en premire approche une carte mre. Les grands systmes SMP sont constitus dun ensemble de ces compartiments relis entre eux par une seconde carte : le midplane.
156
2. Les systmes dexploitation et middlewares comme Oracle prennent leur charge ces disparits. Dans une optique de scale-out, un programme sexcutera non plus sur un seul grand systme mais sur un ensemble de machines que ce programme coordonnera pour remplir cet objectif. Cet agencement de machines de commodity hardware offre une vue bien diffrente dune architecture thorique pour le dveloppeur :
Figure 2. Source Data Center As A Computer page 8 L1$ : cache de niveau 1, L2$ : cache de niveau 2.
157
LES GANTS DU WEB
Ainsi, ds que lon passe par le rseau pour accder une donne sur un autre serveur, les temps daccs augmentent et le dbit diminue dun rapport 1.000. Par ailleurs, les quipements rseau en entre du datacenter constituent le facteur limitant par rapport la bande passante agrge de toutes les machines. Par consquent, pour optimiser les temps daccs et les dbits au sein du datacenter, il faut rpartir de faon pertinente les donnes et les traitements entre les serveurs (notamment pour viter de distribuer des donnes couramment accder ensemble entre plusieurs machines). Or, les systmes dexploitation et les couches middleware traditionnelles ne prennent pas en charge ce type de fonctionnement. Il est donc ncessaire de les traiter au nouveau applicatif. Cest prcisment l quinterviennent les stratgies de sharding[10]. La partie frontale des services, servir les pages Web, saccommode assez facilement de ces contraintes du fait du caractre sans tat et facilement routable des requtes HTTP entre plusieurs machines. Les autres applicatifs devront par contre, grer explicitement les changes rseau ou se baser sur des nouvelles couches middleware spcifiques. Les problmatiques de stockage sur ce genre de matriel sont mises en uvre chez les gants du Web galement avec des techniques de sharding.
La prise en charge de la tolrance aux pannes

La seconde diffrence marquante entre les grands systmes et les Warehouse Scale Computers concerne la tolrance aux pannes. Les grands systmes ont au fil des dcennies propos des mcanismes avancs au niveau hardware pour rduire au maximum le nombre de pannes (RAID, changement chaud de matriel, rplication au niveau SAN, correction derreur et failover au niveau mmoire et I/O, etc.). Un Warehouse Scale Computer possde la caractristique inverse pour deux raisons : Les composants commodity hardware sont moins fiables, La disponibilit globale dun systme mettant en uvre simultanment plusieurs machines est le produit de la disponibilit de chaque serveur[11].
[10] cf. sharding , p. 163. [11] Ainsi si chaque machine a une indisponibilit annuelle de 9 heures, la disponibilit de 100 serveurs sera au mieux de 0,999100 0,90%, soit 36 jours dindisponibilit par an !
158
Cela conduit les gants du Web considrer que le systme doit pouvoir fonctionner continuellement avec certains composants en panne. L encore, la couche applicative est responsable dassurer cette tolrance aux pannes (cf. Design for Failure p. 189).
Quels sont les critres de choix de ces machines ?

Pour autant, les machines retenues par les gants du Web ne ressemblent pas toujours nos PCs ni mme aux serveurs x86 des grands constructeurs comme HP ou IBM. Google est sans doute lexemple le plus marquant dans le sens o il fabrique lui-mme ses machines. Les autres grands acteurs, comme par exemple Amazon, font appel des constructeurs plus spcialiss comme SGI[12]. Le premier critre de choix de leurs serveurs est bien sr le prix. Lajustement des composants au plus prs de leurs besoins et le grand nombre de serveurs achets permet aux gants du Web davoir un fort pouvoir de ngociation. Bien que les chiffres restent confidentiels, on estime que le prix dun serveur peut descendre jusqu 500 $ chez eux. Le second critre de choix est li la consommation lectrique. Aujourdhui du fait du trs grand nombre de serveurs utiliss, la consommation lectrique devient lun des postes de dpense les plus importants. Rcemment Google communiquait sur une puissance moyenne denviron 260 millions de watts soit une facture de lordre de 30.000 $ par heure. Le choix des composants mais galement la capacit paramtrer trs finement la consommation de chaque composant permet dconomiser des montants considrables. Au final, mme sils sont constitus de composants issus du monde du PC, la composition et le paramtrage de ces serveurs sont assez diffrents. Hormis quelques initiatives comme OpenCompute de la part de Facebook, ces dtails restent jalousement gards par les gants du Web. Tout au plus peut-on savoir que, chez Google, ils ont remplac les onduleurs centraliss de courant continu par des batteries de 12V directement au niveau des serveurs[13].
[12] SGI est aujourdhui issu de la fusion de Silicon Graphics, Cray et surtout Rackable qui possdait lexpertise dans les serveurs x86. [13] > http://www.youtube.com/watch?v=Ho1GEyftpmQ
159
LES GANTS DU WEB
Exceptions !
Les exemples de gants du Web communiquant sur des technologies hors x86 sont quasi inexistants. Si lon remontait un peu dans le temps, on pourrait trouver un logo Powered By Sun chez Salesforce[14].
Et chez moi ?
Le down sizing[15] cest--dire la volont de remplacer les serveurs centraux par des machines plus petites a connu son heure de gloire dans les annes 90. Lobjectif nest pas ici de plbisciter de la mme faon le commodity hardware mme si au premier abord on pourrait penser que le x86 a envahi toute lentreprise. Le choix extensif du commodity hardware va plus loin que cela en transfrant sur lapplicatif la responsabilit de la scalabilit et de la tolrance aux pannes. trs grande chelle, comme chez les gants du Web, lorsque les cots lectriques et dinvestissement deviennent dterminants, il sagit de la seule solution viable. Pour des applications existantes pouvant se contenter des ressources dun seul gros serveur multiprocesseurs, le cot du (re-) dveloppement en systme distribu et le cot du hardware viennent parfois squilibrer dans les SI. Lutilisation du commodity hardware dans votre entreprise doit donc sinscrire dans un choix darchitecture global : privilgier le dveloppement existant avec des machines plus haut de gamme ou ladapter pour migrer (entirement) sur du commodity hardware. En pratique des applications conues pour la distribution telles des frontaux Web migreront facilement. linverse des applications fortement intgres comme des progiciels ncessiteront forcment une infrastructure spcifique avec redondance des disques peu compatible avec un datacenter commodity hardware tel que ceux conu chez les gants du Web.
[14] > http://techcrunch.com/2008/07/14/salesforce-ditch-remainder-of-sun-hardware [15] > http://fr.wikipedia.org/wiki/Downsizing_(informatique)
160
Patterns connexes
Linformatique distribue est donc indispensable lutilisation du commodity hardware. Des patterns comme le sharding (cf. Sharding p. 163) doivent ncessairement tre implments dans le code pour pouvoir mettre en uvre du commodity hardware pour le stockage de la donne. Lutilisation de trs nombreuses machines complexifie galement ladministration des serveurs, rendant ncessaire des patterns comme DevOps (cf. DevOps p. 63). Enfin, cette propension quont les gants du Web concevoir des ordinateurs ou plutt des datacenters adapts leurs besoins renvoie bien sr la prfrence build vs buy (cf. Build vs Buy p. 19).
161
Sharding
ARCHITECTURE / SHARDING
Description
Dans tout systme dinformation, les donnes sont un actif important quil faut capturer, conserver et traiter de faon fiable et efficace. L o un serveur central joue trs souvent le rle de gardien des donnes, la majorit des gants du Web ont opt pour une autre stratgie : le sharding ou distribution des donnes[1]. Le sharding dcrit ainsi un ensemble de techniques qui permet de rpartir les donnes sur plusieurs machines pour assurer la scalabilit de larchitecture.
Les besoins
Avant de dtailler limplmentation, revenons sur les besoins dorigine. On retrouve chez les gants du Web plusieurs problmatiques communes assez connues : le stockage et lanalyse dnormes quantits de donnes[2], des enjeux forts de performance pour avoir des temps de rponse faibles, des enjeux de scalabilit[3] voire dlasticit[4] lis aux pics de consultation. Nous insisterons sur une particularit de ce type dacteurs qui sous-tend nombre des problmatiques prcdentes. La rmunration des gants du Web est bien souvent indpendante de la quantit de donnes manipules : rmunration par la publicit, facturation de lutilisateur au forfait[5]. Cela ncessite davoir un cot unitaire par transaction trs faible. En effet, dans un SI classique, une transaction peut facilement tre rattache un flux physique (vente, stockage dun produit). Ce flux permet davoir une facturation du SI proportionnelle au nombre de transactions
[1] Wikipedia dcrit ce mot comme une mthode de partitionnement horizontale dune base de donnes ou dun moteur de recherche. (http://en.wikipedia.org/wiki/Sharding.) [2] Enjeux que louverture de nos SI sur Internet tire galement insidieusement (analyse du comportement des utilisateurs, liens avec les rseaux sociaux). [3] La notion de scalabilit est certes lie la capacit dun systme absorber une charge plus importante mais, plus important encore, est la dimension cot. Formul autrement, un systme est scalable sil est capable dabsorber la requte supplmentaire avec un temps de rponse identique et si cette requte supplmentaire cote le mme prix que les prcdentes (autrement dit que les cots dinfrastructure sous-jacent ne font pas exploser la facture). [4] Au-del de la scalabilit, la notion dlasticit est lie la capacit navoir que des cots variables sans lien avec la charge. Autrement dit, un systme est lastique si quel que soit le trafic (10 requtes par seconde ou 1.000 requtes par seconde), le cot unitaire par requte est identique. [5] Par exemple labsence de taille maximale sur les botes e-mail.
165
LES GANTS DU WEB
(conceptuellement par une sorte de taxe). Mais sur un site de commerce marchand par exemple, chaque consultation du catalogue ou ajout dans le panier ne gnrera pas forcment du revenu car lutilisateur peut quitter le site juste avant la validation du paiement. En somme, les systmes dinformation des gants du Web sont contraints dassurer une scalabilit cot marginal trs faible pour rpondre leur business model.
Le sharding pour diminuer les cots

Les bases de donnes restent encore majoritairement sur un modle centralis : un serveur unique, ventuellement redond en mode actif/ passif pour la disponibilit. La solution la plus courante pour supporter plus de transactions est la scalabilit verticale ou scale up : acheter une machine plus puissante (plus dIO, de CPU, de RAM...). Cependant cette approche prsente des limitations : une seule machine trs puissante ne peut pas suffire pour indexer le Web par exemple. Mais au-del, cest souvent laspect cot et investissement qui conduit rechercher une autre approche. Souvenez-vous du chapitre prcdent : Une tude[6] mene par des ingnieurs de Google montre que ds que la charge dpasse la taille dun grand systme, le cot unitaire sur des grands systmes est trs suprieur au cot unitaire sur des machines de grande srie[7]. Mme si lquation pour comparer des cots par transaction nest pas simple poser et peut tre sujette dbat complexification de larchitecture, charge rseau prendre en compte dans les cots les gants du Web ont largement choisi dutiliser des machines de grande srie. Pour mettre en uvre cette scalabilit horizontale, le sharding devient ncessaire.
[6] Cette tude http://www.morganclaypool.com/doi/pdf/10.2200/S00193ED1V01Y200905 CAC006 est galement rsume dans cet article de blog dOCTO, http://blog.octo.com/ datacenter-as-a-computer-une-plongee-dans-les-datacenters-des-acteurs-du-cloud. [7] Cest ainsi que nous traduirons commodity hardware car il ne sagit pas forcment de machines dentre de gamme mais de machines dont le rapport performance/prix est le plus lev dans le systme en question.
166
Limplmentation du sharding
Il existe de fait deux faons de partitionner ( sharder ) la donne : verticalement ou horizontalement. Le partitionnement vertical est le plus communment utilis : il sagit disoler, de sparer des concepts mtier. Par exemple, on dcidera de stocker les clients sur une base et leurs contrats sur une autre. La notion de partitionnement horizontal renvoie lide de rpartir lensemble des enregistrements dune table (au sens dune base de donnes) sur plusieurs machines. Ainsi, on choisira par exemple de stocker les clients de A M sur une machine n1 et les clients de N Z sur une autre machine n2. Le sharding horizontal ncessite une cl de rpartition la premire lettre du nom dans lexemple[8]. Cest principalement le sharding de type horizontal qui est mis en uvre chez les gants du Web. Il prsente notamment lavantage de ne pas tre limit par le nombre de concepts comme cest le cas pour le sharding vertical.
Figure 1.
[8] En ralit la rpartition se fera en fonction de la probabilit des noms de commencer par une certaine lettre.
167
LES GANTS DU WEB
Les techniques lies au sharding

Les gants du Web ont, sur la base de ce choix de scalabilit horizontale, dvelopp des solutions spcifiques (regroupes sous lacronyme NoSQL Not Only SQL) rpondant ces enjeux et ayant les caractristiques suivantes : une implmentation partir de machines de grande srie, une distribution (sharding) des donnes gres au niveau du logiciel.
Si le sharding permet de rpondre aux problmes voqus plus haut, il ncessite aussi de mettre en uvre de nouvelles techniques. La gestion de la disponibilit, devient plus complexe. Dans un systme centralis ou considr comme tel, le systme est disponible ou indisponible et on ne mesurera quun taux dindisponibilit. Dans un systme shard, certains nuds peuvent tre disponibles et dautres indisponibles. Si la chute dun seul nud rend tout le systme indisponible, le taux dindisponibilit est gal au produit de lindisponibilit de chacun des nuds. Ce taux va ainsi chuter trs rapidement : 100 machines indisponibles chacune 1 jour par an donneront un systme avec prs de 3 mois dindisponibilit[9]. Si le systme distribu est capable de rester disponible malgr la chute dun des nuds mais avec un service dgrad, la disponibilit devra alors tre mesure par deux chiffres : le yield - le taux dindisponibilit dfini prcdemment et le harvest la compltude de la rponse qui mesure en quelque sorte labsence dindisponibilit[10]. La rpartition de la charge devra tre gnralement adapte lutilisation qui est faite des donnes. Ainsi un rfrentiel produit (massivement accd en lecture) naura pas les mmes enjeux de performance quun caddie virtuel (massivement accd en criture). Le taux de rplication, par exemple, ne sera pas le mme dans ces deux cas.
[9] (364/365)100 = 76 % = 277/365 soit 88 jours. [10] Ainsi, si lorsquun nud tombe, les autres nuds ignorent les modifications faites sur ce nud puis rconcilient les diffrentes modifications lorsque ce nud est reconnect au cluster, on a diminu le harvest. La rponse nest pas complte car elle nintgre pas les dernires modifications, mais elle prserve le yield. Les solutions NoSQL dveloppes par ces acteurs intgrent diffrents mcanismes pour grer cela : rplication des donnes sur plusieurs nuds, algorithme vector clock, pour rconcilier des mises jour concurrentes lorsquun nud est reconnect au cluster. Plus de dtail dans cet article http://radlab.cs.berkeley.edu/people/fox/ static/pubs/pdf/c18.pdf
168
Ensuite, la gestion de lajout de nouveaux nuds et des problmes de rpartition de la donne (rquilibrage du cluster) sont de nouveaux problmes spcifiques au sharding. Foursquare, par exemple, a subi une indisponibilit de onze heures en octobre 2010[11] suite une surcharge dun des nuds puis des soucis lors de lajout du nud de secours, qui a finalement caus la chute complte du site. Des algorithmes de rpartition des donnes comme le consistent hashing[12] limitent ainsi le cot de recopie des donnes lors de lajout ou du retrait dun nud pour rpondre ces problmatiques.
Le sharding ncessite galement dadapter les architectures applicatives : Les requtes doivent tre adaptes pour tenir compte de la distribution, notamment en vitant toute requte inter-shard car le cot daccs plusieurs nuds distants est prohibitif. Les APIs de ces systmes limitent ainsi les possibilits de jointure des donnes situes sur le mme shard. Que lon utilise des bases relationnelles ou des systmes types NoSQL, la modlisation est mise mal et on se limite majoritairement dans ces systmes une modlisation du niveau cl/valeur, cl/ document ou en familles de colonnes pour lesquelles la cl ou lindex de ligne servent de cl de partitionnement. Latomicit (le A de ACID) est souvent limite afin dviter des mises jour atomiques incluant plusieurs shards et donc des transactions distribues sur plusieurs machines coteuses en performance.

La mise en uvre de ces techniques diffre entre les acteurs. Certains ont simplement adapt leurs bases de donnes pour faciliter le sharding. Dautres ont crit des solutions NoSQL qui leur sont propres. En suivant ce cheminement de SQL NoSQL, dont voici quelques implmentations reprsentatives.
[11] Plus de dtails sur cet incident de la part de FourSquare : > http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/ et lanalyse dun autre blog http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-fromthe-foursquare.html [12] Plus de dtails dans cet article : > http://blog.octo.com/consistent-hashing-ou-l%E2%80%99art-de-distribuer-les-donnees/
169
LES GANTS DU WEB
Wikipedia
La clbre encyclopdie collaborative est base sur de nombreuses instances de MySQL rparties et un cache mmoire memcached. Cest ainsi un exemple de mise en uvre du sharding avec des composants assez rpandus.
Figure 2.
Larchitecture utilise dune part la rplication matre-esclave pour sparer les charges de lecture et dcriture, et partitionne dautre part les donnes par Wiki et par cas dutilisation. Le texte des articles est galement dport dans des instances ddies. Ils utilisent ainsi des instances MySQL avec 200 300 Go de donnes.
170
Flickr
Larchitecture de ce site de partage de photos est base l aussi sur une organisation de plusieurs instances MySQL (les shards) matres et esclaves, mais cette fois autour dun anneau de rplication pour faciliter lajout de nuds.
Figure 3.
Un identifiant sert de cl de partitionnement (le plus souvent lidentifiant du propritaire de la photo) qui rpartit les donnes sur les diffrentes machines. En cas de chute dun nud, les critures sont rediriges vers le nud suivant sur lanneau. Chaque instance sur lanneau est galement rplique sur deux nuds esclaves qui servent en lecture seule en cas de chute du nud matre associ.
171
LES GANTS DU WEB
Facebook
Larchitecture de Facebook prsente lintrt de montrer lvolution dune base relationnelle vers un modle compltement distribu. Facebook a ainsi dbut en se basant sur MySQL, solution Open-Source trs efficace. Ils ont ensuite mis en uvre un ensemble dextensions permettant de partitionner les donnes.
Figure 4.
Dsormais tout stockage de donnes de faon centralise est banni dans larchitecture Facebook. Un accs centralis est assur par du cache (MemCached) ou un service spcialis. Dans larchitecture retenue, MySQL sert alimenter MemCached en donnes sous forme cl-valeur et nest plus requt en SQL. Le systme de rplication de MySQL est galement utilis aprs extension pour rpliquer les instances entre plusieurs datacenters. Cependant son utilisation est trs loigne dune base de donnes relationnelle. Les donnes sont accdes uniquement sous forme cl/valeur. Plus aucune jointure nest ralise ce niveau. Enfin la structure des donnes est prise en compte pour colocaliser les donnes utilises simultanment.
172
Amazon
Larchitecture Amazon se distingue par une gestion plus avance de la perte dun ou plusieurs nuds sur Dynamo. Amazon a dbut dans les annes 1990 avec un seul serveur Web et une base de donnes Oracle. Ils ont ensuite mis en place un ensemble de services mtiers en 2001 avec des stockages indpendants. A ct des bases de donnes, deux systmes utilisent le sharding : S3 et Dynamo. S3 est un stockage de BLOB sur Internet identifi par une URL. Dynamo (utilis en interne puis trs rcemment propos sur Amazon Web Services) est un systme de stockage cl/valeur distribu, rparti, destin assurer une trs haute disponibilit et des temps de rponse trs faibles. Afin de privilgier la disponibilit sur Dynamo, plusieurs versions dune mme donne peuvent coexister : on parle de cohrence terme (eventual consistency)[13].
Figure 5. [13] Il existe des mcanismes de quorum (http://en.wikipedia.org/wiki/Quorum_(distributed_ computing) pour trouver des compromis entre disponibilit et cohrence.
173
LES GANTS DU WEB
la lecture, un algorithme comme le vector clock[14] ou, en dernier recours, lapplication cliente, devront rsoudre le conflit. On jouera aussi sur une rplication plus ou moins importante pour choisir le meilleur compromis entre tolrance la perte dun nud et performance du systme.
LinkedIn
Le cheminement de LinkedIn prsente des similitudes avec celui dAmazon : sortie dune approche monobase en 2003, un dcoupage en services et la mise en place dun systme distribu avec des concepts similaires Dynamo : Voldemort. Contrairement Dynamo, il est distribu sous licence open-source. noter : les index et graphes sociaux ont toujours t stocks de faon spare chez LinkedIn.
Google
Google a, le premier, publi des informations sur son systme de stockage distribu. Celui-ci tire ses gnes non pas des bases de donnes mais des systmes de fichiers. Google voque dans sa publication[15] sur le Google File System (GFS), laspect structurant du choix dutiliser du commodity hardware, avec les faiblesses prcdemment observes (cf. Commodity Hardware , p. 151) Ce systme de fichier distribu sert, directement ou indirectement, aux stockages des donnes chez Google (index de recherche, mails).
Figure 6.
Son architecture repose sur un serveur de mtadonnes centralis (pour orienter lapplication cliente) et un trs grand nombre de serveurs de stockage. Le degr de consistance des donnes est infrieur ce que
[14] Lalgorithme Vector Clock permet de connatre lordre des modifications sur une donne distribue. [15] > http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google. com/fr//papers/gfs-sosp2003.pdf
174
peut garantir un systme de fichiers classique, mais ce point lui tout seul pourrait faire lobjet dun article. Google utilise en production des clusters de plusieurs centaines de machines lui permettant ainsi de stocker des petabytes de donnes indexer.
Exceptions !
Il est cependant indniable quun nombre important de sites restent sur des technologies de base de donnes relationnelles sans sharding (ou sans communiquer sur le sujet) : StackOverflow, Salesforce, VoyagesSNCF, vente-privee.com La liste est difficilement exhaustive dans un cas comme dans lautre. Pourtant nous pensons que le sharding est dsormais une stratgie classique sur les sites web grand trafic. En effet, larchitecture de Salesforce est certes base sur une base de donnes Oracle, mais elle utilise la base de donnes de faon trs diffrente des pratiques qui ont cours dans nos SI : tables avec une multitude de colonnes non types et nommes de faon gnrique (col1, col2), moteur dexcution des requtes en amont de celui dOracle pour prendre en compte ces spcificits, etc. Les optimisations montrent les limites dune pure architecture relationnelle. Lexception la plus marquante vient selon nous de chez StackOverflow, dont larchitecture repose sur une unique base relationnelle SQL Server. Ce site a fait le choix dune architecture entirement base sur la scalabilit verticale, leur architecture initialement inspire de Wikipedia ayant volu pour mieux se conformer cette stratgie. Face cela, il faut noter que le besoin en scalabilit de StackOverflow nest pas forcment comparable celui dautres sites car la communaut cible (celle des experts en informatique) est assez limite, et le modle favorise la qualit des contributions leur quantit. Par ailleurs, le choix dune plateforme sous licence Microsoft, leur offre un outil efficace mais pour lequel les cots de licences deviendraient probablement prohibitifs en cas de scalabilit horizontale.
Et chez moi ?
La distribution des donnes est lune des cls qui a permis aux gants du Web datteindre leur taille actuelle et de fournir des services quaucune autre architecture ne pourrait supporter. Mais quon ne sy trompe pas, ce nest pas un exercice facile : des problmatiques toutes simples dans le monde relationnel (jointures, consistance de la donne) demandent la matrise de nouveaux outils ou de nouvelles mthodes.
175
LES GANTS DU WEB
Les domaines avec de forts enjeux de volumtrie, mais des enjeux de cohrence limits, cas des donnes partitionnables, notamment sont ceux pour lesquels la distribution des donnes aura le plus de bnfice. Des offres autour de Hadoop utilisent ces principes et sont pertinentes dans la BI, et plus particulirement dans lanalyse de donnes non structures. Ct transactionnel, les problmatiques de cohrence sont plus importantes. Les contraintes sur les APIs daccs sont aussi limitantes mais de nouvelles offres comme SQLFire de VMWare ou NuoDB tentent de mixer sharding et interface SQL. suivre, donc. En somme, il faut se demander quelles sont les donnes utilises dans un mme use case (quelle partition est possible?) et quelles seraient pour chaque donne les consquences dune perte de consistance. En fonction de ces rponses, vous pourrez identifier vos grands enjeux darchitecture qui vous permettront de choisir, au-del de la seule problmatique de sharding, loutil qui rpondra le mieux vos besoins. Plus quune solution magique, le partitionnement des donnes doit tre abord comme une stratgie permettant de franchir des frontires de scalabilit inaccessibles sans son utilisation.
Patterns connexes
Lutilisation de produits open-source ou maison, matriss en interne, est inextricablement lie lutilisation du partitionnement des donnes du fait du tuning trs fin requis. Le modle transactionnel ACID est galement remis en question par le partitionnement des donnes. Le pattern Eventually Consistent (consistance finale) propose une autre vision et une autre faon de rpondre au besoin des utilisateurs tout en tolrant cette remise en question. L encore, une matrise de ce pattern est trs utile pour mettre en uvre la distribution des donnes. Enfin et surtout, le sharding est indissociable du choix du commodity hardware fait par les gants du Web.
Sources
Olivier Mallassi, Datacenter as a Computer : une plonge dans les datacenters des acteurs du cloud, 6 juin 2011 : > http://blog.octo.com/datacenter-as-a-computer-une-plongee-dans-lesdatacenters-des-acteurs-du-cloud/
176
The size of the World Wide Web (The Internet), Daily estimated size of the World Wide Web : > http://www.worldwidewebsize.com/ Wikipedia : > http://en.wikipedia.org/wiki/Shard_(database_architecture) > http://en.wikipedia.org/wiki/Partition_%28database%29 > http://www.codefutures.com/weblog/database-sharding/2008/06/ wikipedias-scalability-architecture.html eBay : > http://www.codefutures.com/weblog/database-sharding/2008/05/ database-sharding-at-ebay.html Friendster and Flickr : > http://www.codefutures.com/weblog/database-sharding/2007/09/ database-sharding-at-friendster-and.html HighScalability : > http://highscalability.com/ Amazon : > http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
177
la nouvelle approche NoSQL
TP vs BI :
ARCHITECTURE / TP VS BI : LA NOUVELLE APPROCHE NOSQL
Description
Dans les SI traditionnels, les architectures de traitement de donnes structures se sont gnralement organises en deux ples distincts. Tous les deux sappuient certes sur une base de donnes relationnelle, mais avec des modles et des contraintes propres. Dun ct, le Transactional Processing (TP), base de transactions ACID, de lautre la Business Intelligence (BI), base de tables de faits et de dimensions. Les gants du Web ont mis en place la fois de nouveaux outils et de nouvelles faons dorganiser les traitements pour rpondre ces deux besoins. La distribution du stockage et des traitements est notamment largement utilise dans les deux cas.
Les besoins mtiers

Lune des particularits rcurrentes des gants du Web est de devoir manipuler une donne semi-structure voire non structure, diffrente du traditionnel tableau de donnes que lon utilise en informatique de gestion : pages Web pour Google, graphe social pour Facebook et LinkedIn. La modlisation relationnelle qui sappuie sur des tables bidimensionnelles dont lune des dimensions est stable (le nombre et le type de colonnes) correspond alors mal ce genre de besoin. Dautre part, comme nous lavons vu dans larticle sur le sharding (cf. chapitre prcdent), les contraintes de volume de donnes et de nombre de transactions imposent souvent aux gants du Web de partitionner la donne. Ce modle rend caduque la vision traditionnelle dans le monde du TP dune base transactionnelle avec une donne en permanence cohrente. Les solutions de BI, enfin, sont dans nos SI majoritairement utilises des fins daide la dcision interne. Pour les gants du Web, la BI est souvent le socle de nouveaux services directement exploitables par les utilisateurs : le service People You May Know de LinkedIn, les propositions de nouveaux morceaux sur des sites comme Last.fm[1], les recommandations dAmazon sont autant de services ncessitant
[1] Hadoop, The Definitive Guide OReilly, juin 2009.
181
LES GANTS DU WEB
de manipuler dnormes quantits de donnes pour fournir ces recommandations ds que possible aux utilisateurs.

La nouvelle approche des gants du Web au niveau TP (Transaction Processing) et BI (Business Intelligence) repose principalement sur un stockage gnraliste et une approche favorisant les traitements diffrs. Ainsi, lobjectif principal du stockage sous-jacent est uniquement dabsorber dnormes volumes de requtes de faon redondante et fiable. Nous le qualifions de gnraliste car il est plus pauvre en termes dindexation, dorganisation de la donne et de cohrence que nos bases de donnes traditionnelles. Le traitement, lanalyse de la donne en vue de son requtage et la gestion de la cohrence sont dportes au niveau applicatif. Voici donc les stratgies qui sont mises en uvre.
TP : la contrainte ACID limite aux besoins strictement ncessaires

Le pattern sharding rend trs complexe la vision traditionnelle dune seule base de donnes cohrente utilise pour le TP. Les grands acteurs comme Facebook et Amazon ont ainsi adapt leur faon de considrer la donne transactionnelle. En effet, comme le spcifie le thorme de CAP[2], il nest pas possible davoir simultanment dans un systme la cohrence, la disponibilit et la capacit fonctionner en cas dinterruption rseau entre les instances (tolrance la partition). Dune part la cohrence nest plus permanente mais uniquement assure lors de la lecture de la donne pour lutilisateur. On parle de cohrence in-fine[3] : cest la lecture de linformation que dventuelles versions diffrentes au sein du stockage seront identifies et les conflits rsolus. Amazon a pouss cette dmarche ds la conception de son systme de stockage distribu Dynamo[4]. Sur un ensemble de N machines, la donne est rplique sur W dentre elles avec une information de version. la lecture, N-W+1 machines sont interroges, assurant de toujours fournir
[2] > http://en.wikipedia.org/wiki/CAP_theorem [3] Eventual consistency [4] > http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
182
lutilisateur la dernire version[5]. Le gant du e-commerce a fait le choix de rduire la cohrence des donnes pour gagner en disponibilit sur son systme distribu. Dautre part, pour rpondre ces enjeux de performance, les critres de fracheur de la donne ne sont plus globaux mais catgoriss. Facebook ou LinkedIn conservent une fracheur temps-rel sur les donnes mises jour par lutilisateur : ces modifications doivent tre immdiatement visibles et durables pour que lutilisateur ait confiance dans le systme. En revanche, la cohrence au niveau global est relche : lorsque lutilisateur sabonne un groupe chez Facebook par exemple, il le verra immdiatement mais les autres membres du groupe sont susceptibles de voir son entre dans le groupe avec un peu de retard[6]. Chez LinkedIn, les services sont galement catgoriss. Dans des services non critiques, comme un retweet, linformation est propage de faon asynchrone[7]. Au contraire, toutes les modifications effectues par lutilisateur sur ses propres donnes sont immdiatement propages afin que celui-ci les voie apparatre lcran. Ce choix de traitement asynchrone permet aux gants du Web de mieux grer les forts trafics auxquels ils sont soumis. Au final, pour garantir la performance et la disponibilit, les gants du Web sappuient sur des systmes de stockage dont la cohrence est adapte en fonction de lusage. Ainsi lobjectif nest pas ncessairement dtre cohrent chaque instant, mais plutt de garantir une cohrence terme.
BI : le mcanisme dindexation la base de toute recherche

Pour fournir des informations sur de vastes volumes de donnes, ces acteurs ont galement lhabitude de pr-calculer des index, cest--dire des structures de donnes conues spcifiquement pour rpondre aux types de questions offertes aux utilisateurs. Pour dtailler ce point, nous allons nous intresser la construction de ces index que Google ralise pour son moteur de recherche. Google est le premier exemple dindexation par son ampleur : la taille du Web.
[5] Ainsi est-on certain de toujours lire la donne sur au moins une des W machines sur laquelle la donne la plus frache a t crite. Pour plus dinformation se rfrer http://www. allthingsdistributed.com/2007/10/amazons_dynamo.html [6] > http://www.infoq.com/presentations/Facebook-Software-Stack [7] Interview de Yassine Hinnach, Architecte chez LinkedIn.
183
LES GANTS DU WEB
Au niveau implmentation, Google utilise le sharding pour le stockage des donnes brutes (base de donnes colonne BigTable base sur le systme de fichier distribu Google File System[8]). Des index par mots cls sont ensuite produits de faon asynchrone et ce sont eux qui serviront rpondre aux requtes des utilisateurs. Les donnes brutes sont analyses avec un algorithme distribu implment partir du modle de programmation MapReduce. Celui-ci repose sur un dcoupage en deux grandes phases : map() qui applique en parallle un traitement identique chaque donne et reduce() qui agrge les diffrents rsultats en un seul rsultat final. La phase map() est aisment distribuable en envoyant chaque traitement et la donne correspondante sur une machine diffrente comme visible sur la figure 1.
Figure 1.
[8] cf. Sharding , p. 163.
184
Cette technique est extrmement scalable[9] et permet par exemple, pour un web crawler, de consommer les pages Web parcourues, dtablir pour chacune la liste des liens sortants, puis de les agrger lors de la phase reduce() pour obtenir la liste des pages les plus rfrences. Google a ainsi mis en uvre une squence de jobs MapReduce pour la gnration des index de son moteur de recherche[10]. Cette approche lui permet de traiter dnormes quantits de donnes en mode batch. Cette technique a ensuite t largement reprise, notamment travers le projet open-source Hadoop[11] de la fondation Apache. Celui-ci implmente la fois un systme de fichiers distribu et un framework implmentant le modle de programmation MapReduce inspir directement de larticle de recherche de Google. Il a ensuite t mis en uvre chez Yahoo! pour lindexation et chez LinkedIn pour prparer ses campagnes de e-mailings, chez Facebook pour analyser les diffrents logs gnrs par les serveurs... De nombreuses compagnies, dont plusieurs autres gants du Web (eBay, Twitter), lutilisent[12]. Depuis 2010, Google a mis en place un nouveau mcanisme dindexation fond sur des mcanismes dvnements[13]. Les mises jour ne sont pas faites en temps rel, linverse des triggers dune base de donnes, mais les latences (temps entre la publication de la page et la possibilit de la rechercher) sont beaucoup plus faibles quavec un systme batch fond sur le modle de programmation MapReduce.
Exceptions !
Ces exemples ont un point commun : ils ciblent des besoins assez spcifiques. Nombre de grands acteurs du Web utilisent galement des bases de donnes relationnelles pour dautres applicatifs. Celles-ci, par leur approche gnraliste ( One size fits all ) sont plus faciles utiliser mais aussi plus limites, notamment dans la scalabilit. Les modes de stockage distribu et les traitements dcrits ci-dessus sont mis en uvre uniquement sur les services les plus sollicits de ces acteurs.
[9] Ou capable de passage lchelle, cest--dire la capacit traiter plus de donnes en faisant crotre le systme. [10] > http://research.google.com/archive/mapreduce.html [11] > http://hadoop.apache.org [12] > http://wiki.apache.org/hadoop/PoweredBy [13] Google Percolator : > http://research.google.com/pubs/pub36726.html
185
LES GANTS DU WEB
Et chez moi ?
Cest sans doute sur les solutions dindexation et de BI sur de gros volumes de donnes (Big Data) que le march est le plus mature. Lexistence dune implmentation open-source prouve, Hadoop, a permis le dveloppement dun grand nombre de solutions de support, doutils connexes, de r-implmentations ou de repackaging commerciaux sappuyant sur les mmes APIs. Les projets ncessitant dindexer de grandes quantits de donnes, ou des donnes semi ou non structures sont donc les premiers candidats lutilisation de ce genre de mthodes. Le principal avantage rside dans le fait que toutes les donnes sont conserves grce un stockage plus faible cot. Il ny a plus de perte dinformation lie des agrgations prcoces. Ainsi, les algorithmes danalyse de la donne qui produisent des index ou des rapports peuvent galement tre affins plus facilement au cours du temps car ils fonctionnent en permanence sur lensemble des donnes disponibles et non sur un sous-ensemble pr-filtr. La remise en cause de la base de donnes relationnelle dans le cadre du TP prendra probablement plus de temps. Diffrentes solutions distribues inspires des technologies des gants du Web sont apparues sous le nom NoSQL (Cassandra, Redis). Dautres solutions distribues, plus la croise des bases de donnes relationnelles et des grilles de donnes en termes de consistance et dAPI, apparaissent sous le nom NewSQL (SQLFire, VoltDB). Des patterns architecturaux comme Event Sourcing et CQRS[14] peuvent galement contribuer tablir des ponts entre ces diffrents mondes. En effet, ils permettent de modliser les donnes transactionnelles comme un flux dvnements la fois non corrls et semi-structurs. La construction dune vision globale et consistante de la donne vient dans un second temps pour permettre de diffuser linformation. Les modles des gants du Web ntant pas transposables directement pour les besoins TP gnralistes dune entreprise, de nombreuses approches coexistent encore sur ce march pour rpondre aux limites traditionnelles des bases de donnes.
[14] Command and Query Responsibility Separation.
186
Patterns connexes
Ce pattern est principalement li au pattern du sharding (cf. Sharding p. 163), parce quil rend possible, par des algorithmes distribus le travail sur ce nouveau type de stockage. On remarquera galement ici linfluence du pattern Build vs Buy (cf. Build vs Buy p. 19) qui a conduit les gants du Web adopter des outils trs spcialiss pour leurs besoins.
187
Design for Failure
ARCHITECTURE / DESIGN FOR FAILURE
Description du pattern
Everything fails all the time est laphorisme clbre de Werner Vogels, CTO dAmazon : il est en effet impossible de prvoir toutes les dfaillances qui peuvent se produire sur un systme informatique, dans toutes les couches une rgle de gestion incohrente, des ressources systmes non relches aprs une transaction, une panne de disque dur, etc. Et cest sur ce principe simple que se basent les architectures techniques des gants du Web aujourdhui, rassembles sous le pattern Design for failure, conu pour supporter la dfaillance : une application informatique doit tre capable de supporter la panne de nimporte quel composant logiciel ou matriel sous-jacent. Le hardware ntant jamais 100 % fiable, il est essentiel dabstraire les composants et les applications du matriel (grille de donnes, HDFS...) pour garantir une continuit permanente du service. Chez Amazon par exemple, on value que 30 disques durs sont changs chaque jour dans un datacenter. Cot mettre en regard dune disponibilit quasi-totale du site amazon.fr (moins de 0,3 s dindisponibilit par an) sur lequel, rappelons-le, une minute dinterruption correspond plus de 50.000 de manque gagner. On oppose gnralement le modle traditionnel de gestion de la continuit de service au modle design for failure en illustrant par ces cinq stades de redondance : Stade 1 : redondance physique (rseau, disque, datacenter). Ici sarrte le modle traditionnel. Stade 2 : redondance virtuelle. Une application est distribue sur plusieurs machines virtuelles identiques au sein dun cluster de VM. Stade 3 : redondance des clusters de VM (ou Availability Zone sur AWS). Ces clusters sont rpartis en clusters de clusters. Stade 4 : redondance des clusters de clusters (ou Region sur AWS). Un fournisseur unique gre ces rgions. Stade 5 : redondance des fournisseurs daccs (ex. : AWS et Rackspace) au cas, improbable, o AWS serait compltement arrt.
191
LES GANTS DU WEB
videmment, vous laurez compris, plus on slve dans les stades de redondance, plus les mcanismes de dploiement et de bascule sont automatiss. Les applications conues en design for failure continuent fonctionner malgr les dfaillances des systmes ou des applications connectes, quitte, pour conserver une qualit de service acceptable, dgrader le fonctionnement pour les utilisateurs nouvellement connects ou pour tous les utilisateurs. En dcoulent, par exemple, deux dclinaisons applicatives de design for failure : Eventual consistency : au lieu de rechercher systmatiquement la cohrence chaque transaction, avec des mcanismes souvent coteux type XA[1], la cohrence est assure la fin (eventual), lorsque les services dfaillants sont nouveau disponibles. Graceful degradation ( ne pas confondre avec le pattern IHM Web du mme nom) : en cas de pics de charge intempestifs, les fonctionnalits coteuses en performance sont dsactives chaud.
Chez Netflix, le service de streaming nest jamais interrompu, mme si leur systme de recommandation est arrt, en panne ou trs lent : toujours rpondre, malgr les dfaillances connexes. Dailleurs, pour parvenir ce niveau de disponibilit, Netflix utilise des outils de tests automatiss comme Chaos Monkey (rcemment open-sourc), Latency Monkey ou Chaos Gorilla qui vrifient que les applications rpondent toujours correctement malgr la dfaillance alatoire de, respectivement, une ou plusieurs VM, la latence rseau, une Availability Zone. Netflix illustre ainsi par les actes sa devise : The best way to avoid failure is to fail constantly .

Evidemment, Amazon qui fournit les briques de bases AWS. Evidemment, Google, Facebook qui communiquent beaucoup sur ces sujets.
[1] Transaction distribue, 2-phase commit.
192
ARCHITECTURE / DESIGN FOR FAILURE
Mais galement Netflix, SmugMug, Twilio, Etsy, etc. En France, mme si certains sites ont des taux de disponibilit trs levs, peu communiquent sur leurs mthodes et, notre connaissance, peu sont capables dtendre leur niveau de redondance au-del du stade 1 (physique) ou 2 (machines virtuelles). Citons tout de mme Criteo, Amadeus, Viadeo, les gros oprateurs tlphoniques (SFR, Bouygues, Orange) pour leurs besoins temps-rel.
Et chez moi ?
La redondance physique, les PRA (Plan de Reprise de lActivit), sites DRP (Disaster Recovery Plan), etc. ne sont pas des mcanismes de design for failure mais des stades de redondance. Le pattern design for failure implique de changer de paradigmes, de passer de prvenir toutes les dfaillances les dfaillances font partie du jeu , passer de la peur du crash analyser et amliorer . En effet, les applications construites sur le mode design for failure ne gnrent plus ce sentiment durgence puisque toute dfaillance est matrise naturellement : cela laisse du temps pour lanalyse froide (postmortems) et lamlioration (PDCA)[2]. Cest, pour reprendre un terme du thtre dimprovisation, la dcontraction dans lurgence . Cela implique deux actions, lune technique et lautre humaine. Tout dabord, sur la conception dapplication : Les composants dune application ou dun ensemble dapplications doivent tre dcentraliss et redonds par VM, par Zone, par Rgion (sur le Cloud. Mme principe si vous hbergez vous-mme votre SI) sans zone commune de dfaillance. Le cas le plus complexe est la synchronisation des bases de donnes. Tout composant doit savoir grer pour une panne dinfrastructure sous-jacente. Les applications doivent supporter des ruptures de communication ou des latences rseau fortes.
[2] Plan-Do-Check-Act, mthode damlioration continue, dite Roue de Deming .

193
LES GANTS DU WEB
Il faut automatiser toute la chane de production de ces applications.
Ensuite, sur lorganisation : Sortir de la culture de lAgence Tous Risques (rappelez-vous : la dernire chance au dernier moment ) pour automatiser les traitements en cas de dfaillance des systmes. Chez Google, on compte 1 administrateur systme pour plus de 3.000 machines. Analyser et rsoudre les dfaillances avec mthode : en amont (approche par les risques via FMEA : Failure Mode and Effects Analysis) et en aval (post-mortems, PDCA).
Patterns connexes
Pattern Cloud First , p. 141. Pattern Commodity Hardware , p. 151. Pattern DevOps , p. 63.
Exceptions
Les applications totalement dconnectes, avec peu dutilisateurs, ou peu denjeux business : la redondance doit tre simple, voire absente. Larbitrage entre chaque stade de redondance est ensuite effectu sur des critres de ROI (cots et complexit vs pertes estimes si indisponibilits).
Sources
Don MacAskill, How SmugMug survived the Amazonpocalypse, 21 avril 2004 : > http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survivedthe-amazonpocalypse Scott Gilbertson, Lessons From a Cloud Failure: Its Not Amazon, Its You, 25 avril 2011 : > http://www.wired.com/business/2011/04/lessons-amazon-cloud-failure Krishnan Subramanian, Designing For Failure: Some Key Facts Its You, 26 avril 2011 : > http://www.cloudave.com/11973/designing-for-failure-some-key-facts
194
Open API ou cosystme ouvert
ARCHITECTURE / OPEN API OU COSYSTME OUVERT
Description
Le principe du pattern Open API consiste dvelopper et exposer des services utilisables par des tiers, sans avoir dide prconue sur lusage qui en sera fait. Le dveloppement porte donc essentiellement sur la logique applicative et le systme de persistance. Linterface et la logique mtier seront dveloppes par des tiers, peut tre plus experts dans les technologies dinterface et les problmatiques ergonomiques, ou dans les mtiers spcifiques[1]. Le moteur de lapplication expose donc une API[2], cest dire un ensemble de services. Lapplication finale reposera sur la composition du service avec dventuels autres services fournis par des tiers. Cest par exemple le cas avec HousingMaps.com : le site permet de visualiser les petites annonces issues du service CraigsList.org au travers du service Google Maps. Le pattern rejoint ainsi les principes majeurs des architectures SOA[3] : le dcouplage, et la possibilit de composition. Pendant un temps, on a oppos les architectures des gants du Web, gnralement bases sur le style REST[4], aux architectures SOA dentreprises, souvent bases sur le protocole SOAP[5]. De nombreux bloggeurs ont polmiqu sur lopposition entre ces deux architectures. Nous pensons de notre ct que les API REST exposes par les gants du Web sont une forme parmi dautres darchitecture SOA. Les gants du Web exposent leurs API publiquement, crant des cosystmes ouverts. Cette stratgie leur permet de : Crer des revenus directs, en les facturant. Exemple : Google Maps devient payant au del de 25.000 transactions par jour. tendre une communaut, et donc recruter des utilisateurs. Exemple : grce aux applications drives de sa plateforme, Twitter a atteint 140 millions dutilisateurs actifs (et 500 millions dinscrits).
[1] http://www.slideshare.net/kmakice/maturation-of-the-twitter-ecosystem [2] Application Programming Interface. [3] Service Oriented Architecture. [4] Representational State Transfer. [5] Simple Object Access Protocol.
197
LES GANTS DU WEB
Faire merger de nouveaux usages pour sa plateforme et donc faire voluer son modle de revenu. Par exemple : en 2009, Apple a constat que les dveloppeurs dapplications souhaitaient vendre non seulement des applications, mais aussi des contenus pour leurs applications. Le modle de lAppStore a donc volu pour intgrer cette possibilit. Parfois, externaliser leur R&D, puis racheter les startups les plus talentueuses. Cest ce qua fait Salesforce avec Financialforce.com.
Marc Andreessen, crateur de Netscape, distingue trois types de plateformes ouvertes : Niveau 1 Access API : ces plateformes permettent lappel un traitement mtier sans fourniture dinterface homme/machine. Exemples : recherche de livres chez Amazon, geocoding chez Mappy. Niveau 2 Plug-In API : Ces plateformes permettent dintgrer une application linterface du fournisseur. Exemple : les applications Facebook, les Widgets Netvibes. Niveau 3 Runtime Environment : Ces plateformes fournissent non seulement une API, une interface, mais aussi un environnement dexcution. Exemple : les applications AppExchange dans lcosystme Salesfoce ou liPhone.
Notons aussi que les API des gants du Web sont accessibles en self-service, cest dire que la souscription peut se faire depuis le site Web sans aucune relation commerciale avec le fournisseur. Au niveau 3, il est ncessaire de concevoir un systme multi-tenant (multi-locataire, en franais). Son principe est de grer de manire isole les applications de plusieurs entreprises avec un quilibre entre mutualisation et isolation. Le pattern API First est un driv du Pattern Open API : il suggre de commencer par btir une API, puis de la consommer pour construire les applications destines aux utilisateurs finaux. Lide est de se mettre au mme niveau que les utilisateurs de lcosystme, donc de sappliquer soi mme les principes darchitecture quon propose ses clients, selon le pattern Eat Your Own Dogs Food (EYODF). Un certain nombre
198
darchitectes chez les gants du Web considrent que cest la meilleure manire de btir une nouvelle plateforme. Dans la pratique, le pattern API First reprsente un idal pas toujours appliqu : dans lhistoire rcente, il semble quil aurait t appliqu pour Google Maps ou Google Wave, services tous deux dvelopps par Lars Rasmussen. Par contre, il na pas t appliqu pour Google+, ce qui a provoqu le courroux de nombreux bloggers.

Chez quasiment tout le monde finalement

LAPI de Google Maps est trs fameuse : elle est, avec celle de Twitter, lune des plus utilise par les sites Web selon programmableWeb.com. Elle est devenue le standard de facto pour exposer des objets sur un fond de carte. Elle utilise des jetons dauthentification (client ID) afin de mesurer la consommation dune application donne, et de pouvoir la facturer au del dun certain quota. LAPI de Twitter est trs largement utilise : elle propose des services sophistiqus pour accder aux donnes des abonns en lecture, en criture. Il est mme possible de lutiliser en streaming pour recevoir les mises jours de tweets au fil de leau. Toutes les fonctionnalits du site sont accessibles via lAPI. LAPI offre aussi un systme de dlgation de droit daccs (bas sur le protocole OAuth) qui permet dautoriser une application tierce tweeter en votre nom.
En France
Le service de cartographie Mappy propose des APIs de geocoding, calcul ditinraires, etc. disponibles sur api.mappy.com Orange propose avec api.orange.com la possibilit denvoyer des SMS, de golocaliser des abonns, etc.
199
LES GANTS DU WEB
Et chez moi ?
Le pattern Open API est envisager ds lors que lon souhaite crer un cosystme ouvert des partenaires ou clients, internes ou externes. Cet cosystme peut tre ouvert sur Internet ou limit un usage interne lentreprise. Un cas relativement classique en entreprise est lexposition de lannuaire des collaborateurs pour permettent lintgration de leurs identits dans les applications. Un autre cas classique est lintgration de services exposs par des fournisseurs (par exemple une banque consomme les services dune socit dassurance). Enfin, un cas dusage moins classique consisterait ouvrir une plateforme pour ses clients finaux : Une banque permettrait ses clients daccder lensemble de leurs transactions : voir lexemple de lAPI AXA Banque ou du CAStore. Un oprateur tlcom ou un fournisseur dnergie permettrait leurs clients de daccder leur encourt de consommation
Pattern connexe
Pattern Device Agnostic (cf. Device Agnostic p. 123).
Exceptions !
Tout ce qui ncessite un workflow complexe. Linformatique temps-rel (type avion, automobile, machine outil) : dans ce cas, la composition de services peut poser des problmes de performance. La manipulation de donnes posant des problmatiques rglementaires : il est peu souhaitable de faire transiter des donnes critiques entre plusieurs plateformes.
200
Sources
Style REST (Representational State Transfer) : > http://fr.wikipedia.org/wiki/Representational_State_Transfer Architectures SOA : > http://en.wikipedia.org/wiki/Service-oriented_architecture Livre SOA, Le guide de larchitecte dun SI agile : > http://www.dunod.com/informatique-multimedia/fondements-de-linformatique/architectures-logicielles/ouvrages-professionnel/soa-0 Plateformes ouvertes selon Marc Andreessen : > http://highscalability.com/scalability-perspectives-3-marc-andreesseninternet-platforms Mathieu Lorber, Stphen Prin, Quelle stratgie dAPI pour votre S.I., USI 2012 : > http://www.usievents.com/fr/sessions/1052-what-strategy-for-yourweb-api?conference_id=11-paris-usi-2012
201
LES GANTS DU WEB
A propos dOCTO Technology

Nous croyons que linformatique transforme nos socits. Nous savons que les ralisations marquantes sont le fruit du partage des savoirs et du plaisir travailler ensemble. Nous recherchons en permanence de meilleures faons de faire. THERE IS A BETTER WAY ! Manifeste OCTO Technology
OCTO Technology est un cabinet de conseil et de ralisation IT. Depuis 1998, nous aidons nos clients construire des Systmes dInformation et des applications qui transforment leurs entreprises en intervenant la fois sur la technologie, la mthodologie et la comprhension des enjeux mtier. Ils trouvent chez nous des quipes qui utilisent la technologie et la crativit pour transformer rapidement leurs ides en valeur : Adeo, Altadis, Asip Sant, Ag2r, Allianz, Amadeus, Axa, Banco Fibra, BNP Fortis, Bouygues, Canal+, Cdiscount, Carrefour, Cetelem, CNRS, Corsair Fly, Danone, DCNS, Generali, GEFCO ING, Ita, Legal&General, La Poste, Maroc Telecom, MMA, Orange, Pages jaunes, Parkeon, Socit Gnrale, Viadeo, TF1, Thales, etc. Nous sommes aujourdhui un groupe international avec quatre filiales : le Maroc, la Suisse, la Belgique et plus rcemment le Brsil. OCTO Technology dtient, depuis 2007, la qualification entreprise innovante dcerne par OSEO innovation. OCTO sest positionn la 1re place du palmars Great Place to Work des entreprises de moins de 500 salaris o il fait bon travailler deux annes conscutivement : en 2011 et en 2012. www.octo.com
202
LES GANTS DU WEB
Auteurs
David Alia Marc Bojoly Ludovic Cinquin Vincent Coste Mathieu Gandin Benot Guillou Rudy Krol Benot Lafontaine Olivier Malassi ric Pantera Stphen Prin Guillaume Plouin
203
Illustrations
Les dessins ont t raliss par Tonu avec la collaboration de Luc de Brabandere. Tous deux sont actifs au sein de www.cartoonbase.com qui est base en Belgique. CartoonBase travaille principalement dans le monde de lentreprise et veut promouvoir lutilisation du dessin humoristique et encourager la crativit dans le graphisme et les illustrations en tout genre.
Conu et ralis par OCTO Technology, avec le concours du Studio CPCR www.studio-cpcr.com
Dpt lgal : Novembre 2012. dit par OCTO Technology, 50, avenue des Champs-lyses - 75008 Paris. Imprim par Printco, 19, rue Vauthier - F 92100 Boulogne Billancourt.
Les Gants
du Web
De lautre ct de lAtlantique, mais aussi dautres endroits du monde comme en France, des gens sont en train de rinventer la faon de faire de linformatique. Ils sappellent Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus. On les appelle les Gants du Web. Cet ouvrage collaboratif synthtise et structure les pratiques, les solutions technologiques et les traits culturels les plus saillants de ces pionniers, en dcryptant des sujets passionnants tels que lobsession de la mesure, la bta perptuelle, DevOps, le Design for failure, la contribution systmatique au logiciel libre ou encore le Feature Flipping. Il sadresse tous ceux qui ont envie de comprendre (ou dimiter !) la culture des Gants du Web : responsable marketing, chef de produits, managers, geeks, etc. Si certaines des pratiques dcrites sont assez techniques, la plupart ne ncessitent pas de comptence informatique particulire. En esprant que cela puisse inspirer nos lecteurs pour contribuer une informatique qui transforme nos socits. LOBSESSION DE LA MESURE BUILD VS BUY FLUIDIT DE LEXPERIENCE UTILISATEUR LES ARTISANS CODEURS CONTRIBUTION AU LOGICIEL LIBRE PIZZA TEAMS FEATURE TEAMS DEVOPS LEAN STARTUP MINIMUM VIABLE PRODUCT CONTINUOUS DEPLOYMENT FEATURE FLIPPING TEST A/B DEVICE AGNOSTIC LA BTA PERPETUELLE CLOUD FIRST COMMODITY HARDWARE SHARDING TP VS BI : LA NOUVELLE APPROCHE NOSQL OPEN API OU ECOSYSTEME OUVERT
Prix : 24 TTC
ISBN 13 : 978-2-9525895-3-6

Les Geants Du Web

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Les Geants Du Web

Uploaded by

Copyright:

Available Formats

Les Gants

Table des Matires

LES GANTS DU WEB

> retour table des matires

> retour table des matires

LES GANTS DU WEB

> retour table des matires

> retour table des matires

> retour table des matires

LES GANTS DU WEB

> retour table des matires

LES GANTS DU WEB

CULTURE / LOBSESSION DE LA MESURE

> retour table des matires

CULTURE / LOBSESSION DE LA MESURE

> retour table des matires

LES GANTS DU WEB

[2] > http://highscalability.com/amazon-architecture [3] > http://arstechnica.com/apple/news/2011/06/fourth-times-a-charm-why-icloud-faceslong-odds.ars

> retour table des matires

CULTURE / LOBSESSION DE LA MESURE

LES GANTS DU WEB

> retour table des matires

> retour table des matires

CULTURE / BUILD VS BUY

La juste adquation des solutions

LES GANTS DU WEB

CULTURE / BUILD VS BUY

[4] > http://lwn.net/Articles/357658

> retour table des matires

LES GANTS DU WEB

> retour table des matires

CULTURE / BUILD VS BUY

> retour table des matires

> retour table des matires

Fluidit de lexprience utilisateur

LES GANTS DU WEB

> retour table des matires

CULTURE / FLUIDIT DE LEXPRIENCE LUTILISATEUR

lergonomie nest plus ngociable aujourdhui

Comment assurer cette performance ?

> retour table des matires

LES GANTS DU WEB

> retour table des matires

CULTURE / FLUIDIT DE LEXPRIENCE LUTILISATEUR

Chez qui a fonctionne ?

Les rfrences chez les gants du Web

> retour table des matires

LES GANTS DU WEB

Figure 1 : Sprites dicnes de Gmail.

Les artisans codeurs

> retour table des matires

CULTURE / LES ARTISANS CODEURS

> retour table des matires

LES GANTS DU WEB

> retour table des matires

CULTURE / LES ARTISANS CODEURS

[3] > http://code.google.com/p/google-styleguide/ et https://github.com/styleguide

> retour table des matires

LES GANTS DU WEB

> retour table des matires

CULTURE / LES ARTISANS CODEURS

> retour table des matires

> retour table des matires

Contribution au logiciel libre