Les Patterns des Grands du Web – Build vs Buy
Description
Un écart marquant entre la stratégie des Grands 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 l’informatique : vaut-il mieux investir dans la fabrication d’un logiciel taillé au mieux pour ses besoins ou bien s’appuyer sur un progiciel et des outils pré-packagés qui embarquent la capitalisation et la R&D d’un éditeur (ou d’une communauté) qui a le temps de creuser les sujets technologiques et métier ?
La plupart des grandes DSI françaises ont tranché et ont inscrit la progicialisation maximale dans leurs principes directeurs, partant souvent du principe que l’informatique n’est pas une activité cœur de métier pour elles et qu’il vaut mieux la laisser à des acteurs spécialisés.
Les acteurs du web tendent à faire exactement l’inverse, avec une certaine logique puisque précisément l’informatique est leur cœur de métier et par conséquent trop stratégique pour être laissée à des tiers.
Il y a donc une cohérence dans ces écarts constatés.
Il est néanmoins intéressant de pousser un cran plus loin l’analyse. Car les Grands du Web ont quelques motivations supplémentaires : d’une part la juste-adéquation et la maîtrise des solutions qu’ils retiennent et d’autre part les coûts quand on passe à l’échelle ! Et ces motivations se retrouvent parfois au sein des DSI et peuvent justifier de limiter le recours à des progiciels.
La juste adéquation des solutions
Sur le premier point, l’un des défauts intrinsèques du progiciel réside dans le fait qu’il constitue le PPCM (soit le plus petit ensemble couvrant la somme) des besoins habituellement constatés chez les clients de l’éditeur[1]. Vos besoins à vous ne sont par conséquent qu’un sous-ensemble limité de la couverture du progiciel. Ainsi, prendre le parti du progiciel, c’est accepter par définition d’avoir une solution trop lourde, trop complexe et non optimisée pour répondre au besoin que l’on a ; et l'on paye donc en exécution et en complexité ce que l’on gagne en n’ayant pas investir sur le design et la fabrication d’une application complète.
Ceci est particulièrement frappant dans les modèles de données des progiciels. Une grande partie de la complexité du modèle est induite par le fait que le progiciel doit être configurable pour s’adapter à différents contextes (MCD très normalisé, table d’extension, faible expressivité du modèle car il s’agit d’un méta-modèle, …) Mais les abstractions et « généricisations » que cela implique dans le design du progiciel ont un coût sur les performances à l’exécution[2].
D’autre part, les Grands du Web ont des contraintes en termes de volumétrie, de débit de transaction et de nombre d’utilisateurs simultanés qui font exploser les approches d’architecture traditionnelles et qui requièrent par conséquent des optimisations extrêmement fines en fonctions des patterns d’accès constatés. Telle transaction très sollicitée en lecture ne sera pas optimisée de la même façon que telle autre dont l’enjeu sera plutôt le temps de réponse en écriture.
Bref, pour arriver à de tels résultats, il faut pouvoir soulever le capot et mettre les mains dans le moteur, ce qui n’est précisément pas possible avec du progiciel (pour lesquels la garantie saute si on ouvre le boîtier).
Ainsi la performance étant l’une des obsessions des Grands du Web, dans la plupart des cas, l’overhead et les faibles possibilités d’optimisation induit par la progicialisation ne sont tout simplement pas acceptables pour eux.
Les coûts
Le deuxième point particulièrement critique est bien sûr le volet coût quand on passe à l’échelle. Quand on multiplie les processeurs et les serveurs, la facture grimpe très vite et pas forcément linéairement, et les coûts deviennent dès lors très visibles. Qu’il s’agisse ici de progiciel métier ou de brique d’infrastructure.
C’est précisément l’un des arguments qui a conduit LinkedIn à remplacer progressivement Oracle par une solution maison, Voldemort[3].
De la même façon, nous avons réalisé une étude en 2010 sur les principaux sites eCommerce en France : à la date de l’étude, 8 des 10 plus gros sites (en termes de CA annuel) fonctionnaient sur une plateforme développée en interne et 2 sur des progiciels de eCommerce.
Les Grands du Web préfèrent donc le Build au Buy. Mais pas seulement. Ils ont aussi massivement recours à l’Open Source. Linux et mySQL règnent en maîtres chez beaucoup. Les langages et les technologies de développement viennent quasi-systématiquement du monde ouvert : très peu de .NET par exemple, mais du Java, du Ruby, du PHP, du C (++), du Python, du Scala, etc.
Et ils n’hésitent pas à forker à partir de projets existants : Google travaille à partir d’un noyau Linux largement modifié[4]. C’est aussi le cas d’un gros acteur français dans le domaine du voyage.
La plupart des technologies qui font le buzz aujourd’hui dans le monde des architectures hautes performances sont le résultat de développements réalisés par les Grands du Web qui ont été mises en Open Source. Cassandra, développé par Facebook, Hadoop et HBase inspirés par Google et développés chez Yahoo, Voldemort par LinkedIn…
Une façon au final de combiner les avantages : un logiciel taillé aux petits oignons pour ses besoins tout en bénéficiant des contributions de développement de la communauté, avec, en prime, un marché qui se forme aux technologies que vous utilisez chez vous.
Si on reprend l’exemple de LinkedIn, beaucoup des technologies qu’ils utilisent s’appuient sur des solutions Open Source du marché :
- Zoie : recherche en temps réel basée sur Lucene
- Bobo : recherche à facettes basée sur Lucene
- Azkaban : framework permettant de planifier des tâches Hadoop et des dépendances entre tâches
- Glue : un framework de déploiement
Et chez moi ?
Et dans ma DSI, dois-je renoncer aux progiciels ?
Evidemment non, par pour tout. Le progiciel reste souvent pertinent : par exemple, il ne viendrait aujourd’hui à l’idée de personne de redévelopper un système de paie pour ses besoins propres. Mais le développement spécifique est à envisager dans certains cas : quand l’outil informatique est une clé de réussite déterminante pour votre métier. La pyramide ci-dessous donne des orientations en termes de stratégie.
L’autre contexte dans lequel le spécifique peut s’imposer est celui des hautes performances : avec l’ouverture des entreprises vers du tout web, très peu de progiciels métier sont architecturés pour supporter le niveau de sollicitation que l’on peut rencontrer sur des sites web à fort trafic.
Pour ce qui est des solutions d’infrastructure, l’Open Source est devenue la norme : OS et serveurs d’application en premier lieu. Bien souvent aussi base de données et bus de messages.
L’Open Source sait faire tourner les solutions des Grands du Web. Leurs qualités de performance et de stabilité ne peuvent plus aujourd'hui être remises en cause.
Reste le frein psychologique de l’absence de support qui bloque encore beaucoup de décideurs informatiques. Mais quand on creuse, en cas de problème sur un socle technique commercial, c’est rarement le support de l’éditeur, payé au prix fort, qui fournit la solution, mais plutôt le réseau des experts et des forums d’entraide sur la toile.
Pour les socles applicatifs du type base de données ou bus de messages, la réponse est plus contrastée car certaines solutions payantes offrent des fonctionnalités que l’on ne retrouve pas encore dans les alternatives Open Source. Mais avant de pousser un Oracle dans des zones où MySQL ne peut plus le suivre, il faut quand même avoir des besoins un peu pointus… ce qui n’est pas le cas de 80% des contextes que nous rencontrons.
Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"
[1] On n’insistera pas ici sur le fait qu’il ne faut pas trop s’écarter du standard out of the box du progiciel sous peine de le payer très (vraiment très) cher sur le long terme, notamment sur les montées de version.
[2] Quand il ne s’agit pas de la lourdeur de l’ergonomie.
[3] Comme nous le confiait Yassine Hinnache, architecte chez LinkedIn, à l’occasion de l’USI 2011 – www.usievents.com