Si seulement les fournisseurs de cloud cessaient d'innover, nous pourrions enfin nous contenter de services offrant le « plus petit dénominateur commun » et nous rapprocher une peu plus du véritable « multicloud ». Cela fait des années que j'écris sur ce sujet, à savoir que, si les fournisseurs affirment haut et fort qu’il est possible d'exécuter des charges de travail sur plusieurs cloud, la réalité est que chacun dispose de services natifs qui ne sont tout simplement pas disponibles sur les cloud de leurs concurrents. Libre à vous d’espérer que cela ne soit pas vrai, mais c'est pourtant bien ce qui se passe en réalité. Et c'est d’ailleurs de plus en plus vrai. Même un passage en revue très superficiel du travail effectué par Microsoft, Google, Amazon ou Alibaba permet de voir que les services communs n'existent pas. Pour autant, faut-il penser que le multicloud est totalement mort ? Non, comme semblent déterminés à le démontrer MongoDB et d'autres.

Pas de services communs dans le cloud

Mais commençons par ce qui fait rêver : des charges de travail fonctionnant comme par magie sur différents cloud ! Un rêve qui rend l'analyste Corey Quinn très sceptique. Il a même quelques inquiétudes à ce sujet : « L'idée de créer des charges de travail pouvant être exécutées de manière transparente chez n'importe quel fournisseur de cloud ou sur vos propres datacenters avec la même facilité… est convaincante et j’apprécierais beaucoup une telle simplicité. Mais, cela paraît à peu près aussi peu réaliste que de demander à des développeurs « d’écrire simplement un code sans bogues » ou d'essayer de trouver la « vache sphérique » décrite avec humour en 1988 par Harte John pour augmenter la production de lait ». C'est beaucoup plus difficile qu'il n'y paraît.

Les logiciels (et le cloud) ne fonctionnent tout simplement pas de cette façon. Grâce aux efforts des différents fournisseurs de services cloud, l'univers du « plus petit dénominateur commun » ne cesse de se rétrécir à mesure que des services cloud comme le calcul et le stockage gagnent en différenciation innovante, au lieu de se réduire à un embrouillamini de similitudes. Par exemple, quoi de plus banal que le stockage ? Bien sûr, si vous parlez de « stockage en mode objet », de « stockage en mode bloc », etc., vous pouvez trouver la même chose dans pratiquement tous les cloud. Mais si l'on regarde de plus près la façon dont Google construit le stockage, les choses ne semblent plus aussi « identiques ». Google a construit ses systèmes d'archivage selon une politique plus axée sur le logiciel que sur le matériel, ce qui signifie que son stockage à froid des données, celles qui sont utilisées peu souvent, a la même latence d'accès que le stockage de premier niveau.

Et qu’en est-il du calcul ? Forcément un produit de base ? Eh bien, pas chez AWS, qui a construit une catégorie spécifique de processeurs appelés Graviton. Ce CPU est construit sur des cœurs 64 bits Arm Neoverse et sur un SoC personnalisé conçu par AWS. Il en résulte des performances en virgule flottante par cœur nettement plus rapides pour les charges de travail scientifiques et à haute performance, des coûts réduits, etc. (Pour ceux qui ne le savent pas encore, je travaille pour AWS, mais les opinions que j’exprime ici sont strictement personnelles).

AWS n'est pas seul dans ce cas. Businessweek a récemment souligné ce qui se passe : « Alors qu'Amazon, Google et Microsoft se disputent les clients du cloud, les vertus spécifiques de leurs puces peuvent devenir un argument de vente », a déclaré Don MacAskill, le CEO de Smugmug. « La situation va devenir très intéressante quand ces fournisseurs de cloud commenceront à se différencier encore plus ». C'est déjà le cas, bien sûr, et cela laisse penser qu’il y aura plus d’innovation pour les clients, même si cela peut aussi signifier que la mythologie du multicloud sera un peu mise en veilleuse. Non pas parce que les fournisseurs de cloud essaient de verrouiller les clients et de leur donner moins, mais précisément parce qu'ils essaient de leur donner plus. Ce qui ne veut pas dire que le multicloud est une arnaque.

Le multicloud passe par les microservices

Par exemple, fin 2020, MongoDB a lancé des clusters multicloud. Selon l'entreprise, cela signifie que « les clients peuvent distribuer leurs données dans un seul cluster sur plusieurs cloud publics simultanément, ou déplacer les charges de travail de manière transparente entre eux ». Pour en tirer avantage, des microservices distincts sont emballés dans une seule application et déployés sur différents cloud afin de permettre un accès aux meilleurs services offerts par chaque cloud. Il ne s'agit pas de déplacer une application entre les cloud de manière transparente. Il ne s'agit pas de services du « plus petit dénominateur commun » commercialisés sur différents cloud. C'est plutôt le contraire. Il s'agit d'invoquer le meilleur de chaque cloud, identifié et rendu accessible par des microservices distincts. En fait, un pourcentage non négligeable de clusters multiclouds MongoDB Atlas fonctionne sur les trois principaux fournisseurs de cloud.

Cela semble formidable, et ça l'est, jusqu'à un certain point. En fait, tout commence (et finit) avec les microservices. En fonction de votre application, ils peuvent permettre à différentes équipes de collaborer plus facilement et immédiatement sur le même système sans nécessairement utiliser les mêmes outils (langages de programmation, runtimes, etc.). Étonnant, n’est-ce pas ? Ils facilitent également la création d'applications hautement évolutives, car, au lieu d’avoir à mettre à l’échelle une application monolithique, les équipes peuvent diviser ces applications en petits services et les faire évoluer indépendamment. Génial, non ?

Eh bien, oui… Et non… Les microservices peuvent être exactement le contraire de qu'il faut (oui, les monolithes sont parfois la solution). Selon Ryland Goldstein, chef de produit chez l’éditeur Temporal Techologies, « le premier problème auquel ont été confrontés les gens quand ils sont passés aux microservices, c'est qu'ils sont brusquement devenus responsables d'un grand nombre serveurs et de bases de données différents ». Martin Fowler va plus loin en affirmant qu'il y a au moins trois bonnes raisons de choisir une solution monolithique plutôt que des microservices :

1- Une architecture distribuée, orientée microservices, est plus difficile à programmer, car les appels distants sont lents et risquent toujours de ne pas aboutir.

2- Il est difficile de maintenir une cohérence forte pour un système distribué.

3- La plupart des entreprises ne disposent pas d'une équipe opérationnelle suffisamment mature pour gérer de nombreux services, dont la plupart seront redéployés régulièrement.

Tout cela pourrait signifier que la solution multicloud proposée par MongoDB est prometteuse, mais elle pourrait bien demander plus de travail aux entreprises, au-delà de ce qu’elles auraient envie de fournir. Comme souvent dans l’IT, la réponse au multicloud est : « cela dépend ». Cela dépend de la maturité de votre entreprise et dans quelle mesure elle accepte le surcroît de complexité qu’implique la sélection des meilleures solutions, comparé à une centralisation des investissements. En bref, avec le multicloud, ce qui marche pour une entreprise ne marchera pas forcément pour les autres.