Slides de présentation du petit déjeuner OCTO de novembre 2012. Site : http://www.geantsduweb.com/ De l'autre côté de l'Atlantique, les Géants du Web réinventent la façon de faire de l'informatique. Ils s'appellent Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus. Maintenant que ces pionniers nous ont montré la voie, nous ne pouvons plus continuer à travailler comme avant. OCTO a donc publié son nouveau livre « les Géants du Web », qui présente ces nouvelles manières de faire de l’informatique. Cet ouvrage aborde en détail comment ces géants : réduisent leur Time To Market au moyen de pratiques comme le Lean Startup et le Continuous Deployment ; font face à des enjeux énormes de fréquentation de leur site grâce aux technologies NOSQL et au Commodity Hardware ; conservent une excellence dans la qualité de leurs produits à l’aide d’organisations composées en Pizza team et orientées Feature tout en cultivant l’obsession de la mesure. A l’occasion de la sortie de cet ouvrage, OCTO Technology avait organisé ce petit-déjeuner afin de présenter une synthèse des pratiques les plus saillantes.

1. Les Géants du Web
10 pratiques
Ludovic Cinquin, DG France
Guillaume Plouin, Practice Leader Prospective
Stephen Perin, Consultant Senior
1
© OCTO 2012

2. 2
© OCTO 2012

4. Plus Gros
5
© OCTO 2012

5. 6
© OCTO 2012

6. Build vs Buy
Pas de progiciels
Beaucoup d’Open Source
Bref, le contraire de beaucoup de DSI
7
© OCTO 2012

7. Une certaine logique
8
© OCTO 2012

8. Mais aussi…
… des progiciels souvent peu adaptés au très gros
coût de licence rédhibitoire
Généricité
Architecture
9
© OCTO 2012

9. 10
© OCTO 2012

10. Commodity Hardware
Small is beautiful…
… mais ça change des choses
11
© OCTO 2012

11. NoSQL
Pas SQL ou plutôt pas seulement SQL
(Not Only SQL)
Pour aller là où les SGBDR montrent
leurs limites
12
© OCTO 2012

12. NoSQL
Le théorème de CAP
« Availability »
Les clients peuvent
toujours accéder au
système (lecture écriture)
La stratégie des sites
L’univers des SGBRD
à gros trafic.
Avec cohérence in fine
« Partition tolerance »
« Consistency » Le système continue a
Tous les clients ont fonctionner en cas de
la même vue de la « partition » - plusieurs
donnée sous-ensembles n’arrivent
plus à communiquer
13
© OCTO 2012

13. Open API
14
© OCTO 2012

14. Open API
Ensemble, on va plus loin !
15
© OCTO 2012

15. Plus Vite
« One of the things we most value
at Facebook engineering is moving fast. »
16
© OCTO 2012

17. Minimum Viable Product
« le MVP est la version d’un nouveau produit qui permet à
une équipe de collecter sur les clients early adopters le
maximum d’enseignements validés, et ce avec un minimum
d’effort »
Eric Ries, Lean Startup
Réaliser rapidement un prototype de produit minimal, pour
Vérifier l’existence d’un besoin
Identifier le marché associé
Valider les hypothèses business
18
© OCTO 2012

18. Comment ?
Des itérations courtes
Avec la question « est-ce que la suppression de cette fonctionnalité
rend le produit sans aucune valeur pour mon client ? »
Le minimum qui est réalisé doit l’être à la perfection
19
© OCTO 2012

20. Test A/B
Comparer la perception par 2 populations d’utilisateurs
2 pages d’accueil, 2 visuels, 2 formulaires, etc.
Segmentation de la population ?
date d’inscription, ordre alphabétique, etc.
Condition d’arrêt ?
Échantillon significatif
21
© OCTO 2012

21. Google Website Optimizer
22
© OCTO 2012

23. DevOps ?
1. Infrastructure as Code
provisionner des environnements de manière fiable,
industrielle et dynamique
Dev
2. Continuous Delivery
Le déploiement en continu
Ops
3. Culture de la collaboration
Des rituels communs pour favoriser les échanges
24
© OCTO 2012

24. Continuous Delivery
« Plus il est difficile de déployer,
plus il faut le faire souvent »
Mises en production incrémentales avec un niveau de risque
minimal
Fiabiliser les processus de déploiement par l’automatisation
« Feature Flipping » : décorrélation entre déploiement du code
et des fonctionnalités
25
© OCTO 2012

25. Efficacité opérationnelle extrême
1 Ops 2,3 millions d’utilisateurs
2 MEP / J
26
© OCTO 2012

26. Plus efficace
27
© OCTO 2012

28. L’obsession de la mesure
« In God we trust – everything else we test. »
Principes
Sans mesure, tout n’est qu’opinion
Ce qui ne se mesure pas, ne se pilote pas
29
© OCTO 2012

29. Concrètement
Des métriques partout
Test automatisé
Baser les décisions sur les métriques
Cycles courts d’expérimentation / apprentissage
30
© OCTO 2012

30. L’obsession de la mesure
« Tout le monde doit être capable d’expérimenter,
apprendre et itérer.
La position hiérarchique, l’obédience et la tradition
ne doivent pas avoir de pouvoir.
Pour que l’innovation fleurisse, la mesure doit
régner. »
Werner Vogels , CTO, Amazon
31
© OCTO 2012

31. Quelle est la bonne taille d’équipe pour
fabriquer un produit logiciel remarquable ?
32
© OCTO 2012

32. Pizza teams
5 à 15 personnes
En deçà, manque de créativité
Au delà, perte d’efficacité
33
© OCTO 2012

34. Comment organiser le travail des équipes
lorsque la taille de l’entreprise augmente ?
35
© OCTO 2012

35. Component team

36. Feature Team
Marketing – Responsable produit – Ergonome – Graphistes – Développeurs – Testeurs – Exploitants

37. Features teams
Autonomie / pas de dépendances inter-équipes
Toutes les compétences
Comment assurer la cohérence d’ensemble ?
 « Communautés de pratiques »
38
© OCTO 2012

38. Design for failure
« Everything fails all the time »
Werner Vogels, CTO d’Amazon
39
© OCTO 2012

39. Design for failure
Plusieurs patterns
Eventual consistency
Graceful degradation
Feature Flipping
Simian Army
40
© OCTO 2012

40. Design for failure
« The best way to avoid failure is to fail
constantly »
41
© OCTO 2012

41. Design for failure
Source : http://www.stelligent.com/tag/simian-army/

42. 43
© OCTO 2012