Faire mieux avec moins

Cloud First

5.0

L’utilisation du Cloud doit désormais être le premier réflexe pour tout nouveau service :

  • Si le service est une commodité, l’utilisation du SaaS est une excellente option.
  • Si le service est un différentiant stratégique, on le développe en spécifique et on doit songer à l'héberger sur le Cloud. En effet, le Cloud est une bonne option pour limiter les coûts d’investissement en phase de lancement. Un bel exemple est Zynga, qui teste ses nouveaux jeux sur le Cloud, puis les réinternalise éventuellement lorsque l’usage est stabilisé et connu.

Les artisans codeurs

5.0

Les géants du Web jouent des coudes pour recruter les meilleurs développeurs car ils ont compris que si une idée valait 1, sa bonne exécution valait 100. Ils soignent donc particulièrement cette population. Le recrutement est très sélectif, mais une fois passé le filtre, un soin particulier est apporté à l’environnement et aux conditions de travail. Les développeurs sont vus comme des contributeurs à l’innovation et une large autonomie leur est laissée. Tout cela dans une culture sans faille d’exigence de la qualité du code.

Chez les géants du Web, Geek is chic. D’ailleurs, vous avez noté, les personnes les plus riches des Etats Unis sont des geeks !

Fluidité de l’expérience utilisateur

5.0

L’unité de temps des géants du Web est le battement de cils, soit le 1/10e de seconde.

Et quelques battement de cils de perdus sont autant de clients et d’agents en moins.

Par conséquent, toutes les stratégies sont bonnes pour rendre aussi fluide que possible l’expérience utilisateur. Cela passe bien souvent par des applications natives sur les mobiles et tablettes, une optimisation poussée de la performance de rendu des sites Web.

Commodity Hardware

5.0

Comment faire quand les besoins en ressources machine explosent ? 2 options : prendre une machine de plus en plus grosse, ou en prendre plein de petites. Les géants du Web ont tranché. Les petites machines finissent par coûter beaucoup moins cher, car ce sont des appareils de grande série, dont on peut multiplier leur nombre bien au delà de ce que saurait faire une très très grosse machine. Et en plus, en cas de panne, pas de problème, on remplace la boîte en panne et c’est reparti.

Bon, dis comme ça, ça a l’air simple... Sauf que ça a un impact sur les architectures et les stratégies de gestion de panne. Et du coup, il faut lire les chapitres qui suivent.

Build vs Buy

5.0

Contrairement aux orientations stratégiques de beaucoup de DSI, les géants du Web ont très peu recours aux packages logiciels et aux progiciels. Ce pour de très bonnes raisons :

  • à l’échelle de leur infrastructure, ça coûte rapidement très cher
  • ils ont besoin de garder la main sur la performance, ce qui nécessite un tuning très poussé, ce que les progiciels ne permettent pas
  • ils respectent l’adage selon lequel il faut faire en spécifique les briques qui sont des différentiants stratégiques

Feature Teams

5.0

Il peut arriver un moment où il faut consacrer plus de personnes à un produit. Pour respecter le principe des Pizza Teams, se pose alors la question du découpage des équipes. Les géants du Web tendent à retenir à un découpage par pan fonctionnel, plutôt que par technologie par exemple. Ainsi, dans une même équipe sont mixées toutes les compétences nécessaires à la réalisation d’un service bout en bout. Cette organisation en feature teams permet de conserver l’agilité et la responsabilisation en dépit de l’augmentation du nombre d’intervenants sur le projet.

Contribution au logiciel libre

5.0

Les géants du Web sont de gros consommateurs d’Open Source mais aussi de gros contributeurs. Nombre de socles technologiques qui annoncent l’informatique de demain sont issus de contribution open source de ces acteurs : Hadoop, Cassandra, GWT, Twitter Bootstrap, …

Les avantages qu’ils y trouvent sont multiples : montrer leurs muscles, influencer leur écosystème, utiliser la foule pour améliorer la qualité de leurs outils, attirer et conserver les meilleurs par l’image qu’ils renvoient.

Design for Failure

5.0

Comment obtenir une disponibilité d’un service à 99,99% à un coût raisonnable ? Réponse des géants du Web : en faisant en sorte que la panne n’ait pas ou peu d’impact !

Ou pour reprendre les termes de Netflix : “the best way to avoid failure is to fail constantly”.

Donc travailler sur la résilience plutôt que sur l’évitement de la panne : travailler sur la disponibilité des services vitaux au détriment du reste, faire en sorte de redémarrer un service très rapidement s’il tombe, notamment en automatisant, analyser le détail de toutes les défaillances et traiter les causes profondes.

De la discipline dans l’analyse d’impact, du pragmatisme, de l’automatisation.

Telecharger le livre
au format PDF
Telecharger
Acheter le livre
sur Amazon
Nous Contacter