conteneurs, legos et web 3.0

Les cimetières sont remplis de sociétés qui n’ont pas compris les règles du jeu.

Microsoft a tenu virtuellement sa conférence développeurs du 19 au 21 mai. Une des annonces marquantes est le lancement de Microsoft Fluid.

TheVerge (19 mai 2020):

Microsoft est en train de créer un nouveau type de document Office. Au lieu de Word, Excel ou PowerPoint, la société a créé des blocs Lego de contenu Office qui vivent sur le web. Les tableaux, graphiques et listes que l'on trouve généralement dans les documents Office se transforment en modules vivants et collaboratifs qui existent en dehors des documents traditionnels.

Microsoft appelle ses blocs Lego les composants Fluid, et ils peuvent être édités en temps réel par n'importe qui dans n'importe quelle application. L'idée est que vous pourriez créer des choses comme un tableau sans avoir à passer par plusieurs applications pour le faire, et le tableau persistera sur le web comme un bloc Lego, libre d'utilisation et d'édition pour tout le monde.

"Imaginez que vous puissiez prendre ces morceaux de Lego et les mettre où vous voulez : dans des e-mails, dans des chats, dans d'autres applications", explique Jared Spataro, responsable de Microsoft 365, dans une interview avec The Verge.  "Au fur et à mesure que les gens y travailleront, ils seront toujours mis à jour et contiendront les dernières informations".

Il y a beaucoup à observer et apprendre de l’univers du jeu. Sans les jeux vidéo, Nvidia n’aurait sans doute pas percé, les puces GPUs seraient dans les limbes ainsi que tous les développements autour de l’intelligence artificielle. Le Lego a quelque chose de fascinant. Avec quelques blocs disposés de différentes manières, on peut refaire le monde. Le métavers est déjà là ! Regardez cette chaîne de montage automobile étonnante:

Tout en Lego !

Il est intéressant de voir comment la logique Lego imprègne désormais la Silicon Valley. Faisons un petit tour d’horizon du web 3.0 se dessinant aujourd’hui:

Les données: du data lake au data mesh

L’exploitation des données au sein de l’entreprise est un domaine en pleine évolution. Jusqu’à présent, elle reflétait la structure en silos des différents départements et directions:

• de nombreuses bases de données hétéroclites provenant de tous les recoins de l’entreprise.

• un lac artificiel (data lake) créé pour recevoir l’ensemble des données, lesquelles étaient formatées pour les besoins analytiques et la prise de décisions. Le formatage était opéré par la direction informatique qui devait interpréter les besoins métiers pour structurer les données.

• cette interprétation centralisée reflétait logiquement les silos de l’entreprise, entraînant une sous-exploitation des données.

La prolifération des données de toute sorte, la nécessité de les analyser au fil de l’eau ainsi que de remettre en question en permanence ses métiers (voir mon article Chi et cheng) , oblige à être beaucoup plus souple sur l’analyse des données. Le lac est devenu si je puis dire un marécage, inadapté au tempo de l’internet. Avec le data mesh, les données sont regroupées dès leur origine en domaines, proche des utilisateurs et transformées en briques de lego, ceci pour assurer leur interopérabilité. D’après Trustgrid:

Fonctionnant comme un maillage de services (service mesh),, un maillage de données (data mesh) crée une couche de connectivité qui élimine les complexités liées à la connexion, à la gestion et au soutien de l'accès aux données. Il est utilisé pour assembler les données détenues dans plusieurs silos de données. Le principe d'un maillage de données est qu'il est utilisé pour connecter des données distribuées dans différents lieux et organisations.

Dès lors, l’organisation est plus proche des utilisateurs, plus flexible et rapide sur le traitement des données notamment en IA. On transforme l’entreprise en machine de guerre par rapport à une concurrence engoncée dans ses structures centralisées et hiérarchiques de gestion de l’information.

L’essor de l’architecture microservices

Ce qui est valable pour les données l’est également pour les services, c’est à dire le développement logiciel. Partant du principe qu’on ne fait qu’une chose bien, dans une organisation informatique moderne (Amazon, Google, Twitter, etc.), chaque pièce de logiciel, correspondant à une fonction est isolée pour être perfectionnée par les petites équipes ad hoc et peut être rattachée à d’autres par API (façade du microservice). Le service mesh assure la connectivité de ces micro services les transformant en Legos facilement emboîtables. L’ensemble du dispositif logiciel de l’entreprise est ainsi constitué des briques de lego logicielles que la direction de l’informatique aura assemblé en connectant les différentes API. L’avantage de cette approche est de construire rapidement, à faible coût grâce aux économies d’échelle engendrée par l’amortissement des microservices sur plusieurs entreprises éventuellement, et enfin d’adapter la quantité de microservices aux besoins de l’entreprise sans créer d’usines à gaz irréversibles. Cette vidéo explique simplement le fonctionnement des microservices et leur intérêt pour répondre aux exigences de rapidité engendrées par la concurrence de l’internet. Chaque microservice, correspondant à une fonction particulière peut faire l’objet d’une mise à l’échelle et être commercialisé, selon la logique Amazon d’être le premier client, puis de vendre à l’extérieur. Parmi les microservices à succès présentés sous forme d’API, on trouve Twilio pour les communications ou Stripe pour les paiements. Zoom avec son focus sur la visio-conférence peut aussi être considéré comme tel. Avec Fluid, Microsoft est entrain d’adopter cette logique microservices pour la suite Office: le document n’est plus le réceptacle du service (calculer, écrire, présenter), ce dernier est accessible de n’importe quel endroit par API et peut se brancher comme un Lego.

La conteneurisation de l’informatique

Si on élargit encore le viseur, on trouve le conteneur, une abstraction qui permet d’isoler une applications avec les ressources qui permettent de les faire tourner sur n’importe quelle machine équipée d’un OS Linux. La virtualisation avait déjà permis de mieux gérer l’espace machine en permettant une répartition des ressources de stockage, de calcul, de communications et d’OS sur la même machine. Le conteneur permet de s’abstraire d’une machine et d’un OS donnés et de fonctionner dans n’importe quel environnement en y apportant ses ressources. Il permet ainsi de déplacer les applications facilement d’une informatique sur site à un environnement cloud ou d’un cloud à l’autre. Le conteneur permet la portabilité des applications, ce qui était difficile avec la machine virtuelle où il fallait dupliquer l’OS à chaque fois:

La combinaison de ces trois tendances (data mesh, microservices et conteneurs) crée une informatique modulaire et évolutive, adaptée à la vitesse de l’internet, à un coût raisonnable. Quel progrès en terme de pertinence, rapidité et coût par rapport à l’approche cloisonnée, hiérarchique et absconse de l’informatique sur site traditionnelle. Si l’on veut comprendre les implications de cette révolution informatique, il est bon de s’intéresser à une autre bien plus ancienne dont on a pu mesurer les effets et qui ressemble à celle-ci à bien des égards: l’invention du conteneur en 1956.

La révolution du conteneur

Marc Levinson dans son livre The box montre à quel point l’invention du conteneur a rendu possible le processus de mondialisation. Le conteneur a permis de réduire considérablement le prix et le temps de transport sur longue distance. En 1961, avant l’utilisation du conteneur, les coûts de fret maritime représentaient entre 10% et 30% du prix des biens. Il fallait y rajouter l’assurance dommage. Le commerce international était rarement profitable. Avec la généralisation du conteneur il est devenu avantageux de produire là où les coûts de main d’œuvre étaient les moins élevés et en masse. La division internationale du travail s’est enclenchée. Il s’en est suivi une explosion du commerce international, ce dernier passant de 25 % du PNB mondial en 1960 à 60 % en 2018:

On peut tirer plusieurs enseignements de cette « invention », utiles pour l’expansion du Web 3.0:

1. Tout d’abord, le conteneur n’a pas attendu Malcom McLean, son inventeur officiel en 1956, pour être inventé. On avait déjà entreposé dans le passé des marchandises dans de grosses boites principalement en bois pour les transporter par mer. L’astuce de Malcom McLean a été d’inventer la compatibilité, de faire du conteneur un Lego qu’on pouvait brancher sur n’importe quel moyen de transport (route, rail, mer). Malcom McLean était un outsider de l’industrie maritime; il détenait une entreprise de transport par camion et cherchait un moyen d’aller plus vite pour charger et décharger la marchandise. Le plus simple était de mettre le camion dans le bateau mais c’était difficilement praticable. McLean a pensé à la remorque mais il fallait pouvoir la récupérer, à moins de standardiser toute l’industrie du camion. Finalement, il a opté pour le plus simple: le conteneur. L’invention n’a pas percé sur le champ mais McLean a fait changer l’état d’esprit en pensant Lego (Lego signifie j’assemble). Il a fallu une vingtaine d’années pour que le conteneur domine, car il nécessitait 1/ de convaincre les parties prenantes (transport terrestre et maritime) de ne pas raisonner en silos, 2/ de trouver un standard commun et 3/ de transformer les ports et les bateaux, une entreprise coûteuse. Le transport est resté hybride pendant de nombreuses années, du fait notamment des résistances des ports et des dockers, accrochés à leurs pouvoirs.
   L’informatique d’aujourd’hui est encore largement hybride. Les résistances au système d’information Lego sont encore grandes, car les entreprises ont peur de perdre leur informatique propriétaire sur site qu’elles considèrent encore comme un avantage concurrentiel, un point de passage privilégié pour délivrer leurs produits. Le cloud hybride est la nouvelle coqueluche, permettant de conserver les bienfaits des deux mondes: le monde abscons de l’informatique propriétaire sur site et le monde du cloud complètement modulaire. Il n’est pas sûr que dans les années 60, les observateurs aient pressenti que le conteneur deviendrait le mode par excellence de transport tant terrestre que maritime: beaucoup de ports ont été réticents à se transformer, laissant malgré eux le tonnage aux autres. De même aujourd’hui, en prenant du recul, il est probable que l’informatique de demain sera entièrement modulaire, basée sur le cloud, les poches de résistance tombant les unes après les autres par la loi du marché. Le cloud hybride ne serait alors qu’une transition vers l’inévitable cloud public.

2. Le conteneur a complètement transformé les relations de pouvoir dans le commerce international. Jusque dans les années 60, le chargement et déchargement des marchandises pour l’international requérait une nombreuse main d’œuvre. Pour éviter que les coûts de transport se multiplient, les usines privilégiaient les sites voisins des ports. De grandes villes se construisaient autour de cet écosystème, citons New York ou Londres, les deux plus grands ports de l’époque, et vivaient de l’import/export. Les grands ports étaient les points de passage obligés du commerce international, ils détenaient le pouvoir, face aux camions ou trains qui amenaient les marchandises ou bateaux qui les faisaient naviguer. Ils avaient chacun plus de 50 000 dockers.

   

   Le conteneur a renversé cette relation de pouvoir. Avec la baisse considérable du coût du transport ainsi que la rapidité de traitement permise par le conteneur, le transporteur peut choisir son trajet entre plusieurs options, c’est lui qui prend le pouvoir et va au port le mieux disant. Cela explique pourquoi les transporteurs ont poussé à un standard commun, condition nécessaire pour le décolage, et fini par le trouver après bien des négociations. On comprend pourquoi les ports étaient réticents à une telle innovation, mais ils n’ont pas eu le choix: après avoir fait du lobbyisme pour bloquer la réglementation, il leur a fallu se rendre à l’évidence: soit se transformer, soit se faire évincer par de nouveaux ports plus modernes. C’est ainsi que Rotterdam est devenu le principal port européen, au détriment des ports méditerranéens ou de Londres. En poussant l’analyse, on peut constater que le conteneur a fait glisser le pouvoir de la terre à la mer: plus que les transporteurs, les Etats-Unis, par leur domination incontestable des océans sont devenus les maîtres du commerce international. Dotés d’une flotte de vingt porte-avions quand le deuxième pays équipé n’en a que deux, les Etats-Unis assurent la sécurité des mers, élément crucial pour le transport maritime. Il n’est pas étonnant que les Etats-Unis aient poussé l’utilisation du conteneur. Ce dernier n’a décollé que grâce au gros contrat que Malcolm McLean a pu passer avec l’armée américaine lors de la guerre du Vietnam.
   Revenons à l’informatique et plus précisément à Microsoft Fluid, pour illustrer un phénomène plus général: Jusqu’à présent Excel et Word étaient enfermés dans des documents, puis dans des fichiers hiérarchisés qui constituaient la partie opérationnelle du système d’information de l’entreprise. Le transport de fichier était plutôt lourd, et se heurtait à des problèmes de compatibilité: la valeur était dans le fichier (pensez port). En adoptant la logique Lego et la compatibilité de la suite Office avec des applications externes, Microsoft ne se fait pas hara-kiri: il transfère la valeur non pas à celui qui domine l’océan, comme le conteneur l’a fait, mais à celui qui domine le ciel, le cloud Azure. Plus généralement, la « légoïsation » de l’informatique (le terme est un peu barbare) transfère le pouvoir des entreprises vers les grands fournisseurs cloud (Microsoft, Amazon, Google). Les entreprises peuvent tenter de résister mais risquent de finir comme le port de Londres: 84 ème port mondial après avoir été numéro 1. A la différence du conteneur cependant, où les Etats-Unis règnent en maître sur les océans, le cloud a trois prétendants. Leur stratégie respective pour s’assurer la suprématie du ciel est intéressante à regarder: Microsoft se sert de ses outils traditionnels dominants dans l’entreprise (Office) pour en faire des briques de Lego et rendre l’entreprise dépendante d’Azure. Amazon se bat sur la quantité de Lego qu’il peut transporter (il veut être la plus grosse boîte). Enfin Google, le plus petit cloud, organise le passage vers son propre cloud en faisant la promotion de Kubernetes, le transporteur de conteneurs des temps modernes !

3. Le conteneur a accéléré la division internationale du travail, en supprimant les frictions liées au transport. Les distances étant abolies, la recherche de la main d’œuvre bon marché est devenue une clé de l’avantage concurrentiel. Les effets d’échelle qui dépassaient difficilement le cadre national se sont étendus à l’international. Le conteneur a permis l’émergence des multinationales s’appuyant sur ces deux tendances: les Nike, Intel, Caterpillar, Danone, etc. De même, on peut penser que le cloud va organiser la division de l’information. Les sociétés hyper-spécialisées sur une fonction précise vont proliférer, s’éliminer et se développer sur les économies d’échelle. Aujourd’hui les sociétés de type SAAS essaient de partir d’une fonction puis dérivent sur d’autres pour consolider leur avantage concurrentiel. Par exemple Shopify fournit des sites marchands clefs en main mais essaie de se brancher sur les paiements et la logistique. Cela part d’une bonne intention stratégique: augmenter les barrières à la sortie. Cependant, si la légoïsation de l’informatique se poursuit et se perfectionne, l’avenir sera peut-être aux sociétés qui sauront se cantonner à une fonction unique et la vendre à grande échelle, des sociétés comme Stripe et Zoom. Dès lors, l’intégration sera réservée aux sociétés qui contrôlent le cloud et pourront privilégier leurs solutions internes, même si elles sont inférieures.

---

L’informatique vit une transition, tout comme le transport maritime et inter modal pendant les vingt premières années de l’introduction du conteneur. Il n’était probablement pas facile à l’époque de prévoir ce qui allait sortir de la modularisation du transport. Cette expérience peut nous aider maintenant à comprendre les bouleversements à attendre de la modularisation de l’information pour l’organisation des entreprises: d’un côté trois pourvoyeurs de cloud (maximum), de l’autre une myriade d’applications hyper-spécialisées, entre deux des packagers tentant leur chance. De nouvelles perspectives pourraient s’ouvrir alors pour les entreprises qui réussissent l’intégration software/hardware, repoussant alors les limites de l’effet Lego.

Il n’y aura pas de texte la semaine prochaine.

Bonne fin de semaine,

Hervé

P.S.: je remercie Stephane Lanski, un fidèle lecteur, pour m’avoir initié sur les perspectives du data mesh.