Faire face à l'explosion des nombres

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

TP vs BI : la nouvelle approche NoSQL

5.0

Le bon vieux modèle de la base de données relationnelle a vécu. Dès que l’on monte dans les tours (volume de données, débit de transaction, faible temps de réponse), d’autres technologies sont nécessaires. Ainsi les géants du Web assurent la gestion de transactions (TP) avec des solutions très performantes (type dynamoDB de Amazon) mais qui privilégient une cohérence in fine de la donnée plutôt qu’une vision ACID telle qu’on la trouve en SGBD (pour une explication plus détaillé, il faudra lire le bouquin !). Dans le cadre de la Business Intelligence(BI), on trouve des architectures qui répartissent les données sur un grand nombre de serveurs : c’est ce qui a donné naissance à Hadoop. The Times They Are A Changin’ comme disait Dylan.

Sharding

5.0

Pour obtenir une très forte montée en puissance à un coût raisonnable, il faut beaucoup de “petits” serveurs. Sur lesquels typiquement, on ne peut pas mettre beaucoup de données. Et il faut donc trouver des stratégies pour répartir ces données de façon intelligente sur plusieurs nœuds. C’est ce qu’on appelle le Sharding. Ca peut se faire à l’ancienne (et à la main) sur des bases de données relationnelles classiques. Mais une nouvelle classe de technologies, qui viennent précisément des géants du Web est apparue pour aider à résoudre ces problèmes pas si simples : ce sont les technologies NoSQL.

Feature Flipping

5.0

Le Feature Flipping est l’une des clés pour parvenir au Continuous Deployment. Le code est déployé en production dès qu’il a été validé par un jeu de tests automatisés, mais il n’est activé que lorsqu’on le souhaite par des “interrupteurs applicatifs”. D’un point de vue technique, ce ne sont que de règles “if” configurables par paramètres. Et en production cela permet de façon assez simple de faire des montées de version fonctionnelles (ou éventuellement des rollbacks) sans temps d’arrêt de l’application.

Pizza Teams

5.0

Les équipes efficaces ont une taille comprise entre 5 et 12 personnes ce qui permet de les nourrir avec deux pizzas (format américain tout de même...). Cette règle, prouvée par des études scientifiques et que chacun peut vérifier empiriquement, est appliquée avec obstination par beaucoup d’acteurs du Web. Lors du lancement de nouveaux produits, on limite la taille des équipes. Et s’il advient d’un peu réussir, on se résout en dernier ressort à augmenter le nombre d’équipes - mais pas leur taille ! Pourquoi ce principe est si rarement appliqué dans nos DSI ?

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