Le marché de l’hébergement Cloud arrive à maturité. OpenStack a réussi à éradiquer tous les pouilleux, la place est libérée pour les trois gros, Amazon, Google et Azure, qui vont pouvoir s’étriper tranquilement.
Le marché du cloud a été découvert par Amazon pour répondre à ses propres besoins. Amazon s’est contentée d’ouvrir son outillage interne, très rapidement organisé en unités autonomes, chacune étant cliente les unes les autres. L’offre d’AWS est un mélange d’outils standards (machines virtuelles, disques distants…) et de services spécifiques dont certains sont maintenant des standards de fait (S3) d’autres non (dynamodb), pour ensuite proposer des services de plus haut niveau, comme les bases infogérées ou les CDN.
Cette offre a parfaitement accompagné la première vague du Web et corresponds tout à fait aux besoins des gros sites américains, qui ont besoin de grosses croissances pour arriver rapidement en position abusivement dominante à l’échelle de l’Occident, pour commencer à être bénéficiaire. Ces sites croissent comme des crabes, chaque changement de carapace correspondant à un tour de table, et il faut devenir bien plus gros. Le fameux “ça scale” tant vanté par le Cloud.
Google a bien vu grandir Amazon, et à toujours eut une technologie plus performante, plus intégrée, plus tout, en fait. Une partie des technos d’Amazon sont issus des white papers de Google. Sauf que Google, à la différence d’Amazon a une approche très cathédrale, très intégrée, très peu ouverte, en fait. Google a zappé l’étape des machines virtuelles en passant directement aux conteneurs (les CPUs n’étaient pas près quand la question s’est posée) bien plus efficaces pour densifier, et tout à fait compatible avec un partage non agressif, coordonné des ressources.
Google, une fois ses services bien installés, a su faire des efforts pour avoir des clients qui consomment ses services (Android, Chrome), mais a été longtemps une grosse quiche pour ses offres d’hébergement. Google semble tout simplement inadapté pour reprendre une idée qui n’est pas la sienne. Un peu comme les humiliations de Google+ ou pire, Google Wave.
Par contre, leurs services sont bons : gmail, calendar, docs. Ils sont surtout encore meilleurs pour bosser en groupe, et remplacent des outils forts pénibles et corporate, comme la suite Microsoft, ou pire encore, IBM Lotus. Outre leur ergonomie agréable, ces outils éradiquent les BOFH, craints par tous, direction comme utilisateurs. Avec ces offres orientés pro, Google à mis un pied dans l’entreprise.
Donc, les services sont bons, les clients sont bons, que reste-t-il à récupérer dans la chaine de valeur? Les serveurs, pas les siens qui sont optimums depuis une grosse décennie, mais ceux des autres.
Première vague, Google App Engine. Google reprends son approche interne, les applications sont contraintes, mais bénéficient d’un ensemble de services de très bonne qualité (comme la BigTable). Sauf que non. Les utilisateurs n’ont que faire de contraintes les obligeants à réinventer la roue alors qu’ils existent tant de trucs open source permettant de sortir trop tôt un gros tas de boue mal fagoté. Les services proposés sont effectivement mythiques et permette de scaler plus haut que sa carte bleue, mais le ticket d’entrées (technique) est rédhibitoire, tout ça pour un truc captif aux performances fluctuantes.
Entre temps apparait Docker, qui réassemble de manière cohérente les bouts de kernel que Google à écrit pour sa propre solution de conteneur, LMCTFY. La première appropriation du logiciel libre des conteneurs, LXC, n’était guère plus qu’un gros POC myope. Docker apporte la notion de services composables, immuables et paramétrable, et, arme secrète, Docker fonctionne très bien sur les ordinateurs des développeurs (Linux, Mac et Windows à égalité), et c’est en fait le premier critère pour l’adoption d’une nouvelle technologie.
Google manque terriblement d’empathie, ils sont capables d’inventer des tas de concepts, mais sont incapables de se mettre au niveau des gros ploucs de développeurs. Ou des gros ploucs de pipelettes des réseaux sociaux, d’ailleurs.
Ils ont du coup mise en place une nouvelle approche, un peu comme leurs withes papers qui deviennent des outils utilisables par le reste du monde. Ils prennent une de leur technologie interne, qui à eut le temps de bien maturer, et ne conservent que les concepts ou les parties bas niveau (comme les patchs kernels) pour les confier à des gens extérieurs, des gens bizarres avec des sentiments. De fait, ils exfiltrent eux même leurs technologies, en petits bouts autonomes. Ils ont réussi ça avec golang, qui a une vraie communauté, et qui a d’ailleurs servi de base à Docker, et à toute une génération des services de bas niveau. Cela dit en passant, un des gros échec d’OpenStack est python, tout à fait inadapté à ce genre de tache, mais bon à l’époque, les autres langages disponibles (java, C++) auraient aussi été un drame.
Donc, pour attaquer l’hébergement, il faut d’abord un socle, et faire des concessions aux ploucs. C’est l’offre Google Cloud, qui expose une couche super standard : de la machine virtuelle avec KVM (avec comme effet de bord de faire chier AMZ qui a choisi l’autre virtualisation, Xen, qui n’est pas dans le kernel vanilla). Réel effort de la part de Google qui n’utilise pas de virtualisation en interne. Ensuite les trucs de base, comme le réseau, les disques distants, du stockage objet compatible S3, du routage, du SQL infogéré, quelques services qui envoient du rêve (à base de big data et de machine learning).
Voilà, ça, c’est le ticket d’entrée pour commencer à discuter. Pour avoir des utilisateurs et donc du débug, Google utilise la technique super classique, une offre massive de crédits à des startoups ambitieuses, des incitations à la création de sociétés de services qui ne font que du Google Cloud, des espèces de franchises, en fait. Pour montrer leur humanité, Google met en place un système astucieux de conseil sur le dimensionnement des services pour que l’on crame moins de sous. Un peu comme une cafétéria qui conseillerait de ne pas remplir son plateau pour pas que ça finisse à la poubelle, en fait. Payer ce que l’on utilise, ça semble bête, mais ça le différencie de AWS, qui eux ont pour motto “la carte bleu comme seul limite”.
Voilà, Google a aussi son offre Cloud crédible, mais comment aller plus loin? la guerre des prix avec AWS est un peu vaine, et ce genre de blague finit souvent en victoire à la Pyrrhus. Non, la cible n’est pas d’aller tout de suite vers le coût marginal et la notion de commodité (pas les WC, le barbarisme traduisant “commodity”). La cible est d’aller là où il y a des sous, d’aller s’occuper des DSI et de l’hébergement de leurs serveurs.
Pour ça, Google est en train de déployer la tactique finaude du tapis de bombe, le carpet bombing des années 1940.
Première vagues, les services, gmail et Google Docs, les utilisateurs veulent du Google et trouvent ringard les services existants.
Deuxième vague, l’hébergement classique. Techniquement, la notion de VM n’est qu’une transition, c’est compliqué, dur à dimensionner, dur à maintenir au fil du temps. Comme solution plus adéquate, il y a bien sûr les conteneurs, standard maintenant officialisé par l’OCI et installé sur tous les postes de développeurs. Docker est mature coté dévelopement, mais pas encore coté hébergement, pour ça, il faut de l’orchestration, et il y a maintenant Kubernetes, offre exfiltrée à partir d’une techno maison de Google, Borg, qui devient tout aussi standard et officiel que les conteneurs de l’OCI, mais dans un autre consortium, le CNCF, avec ses amis Envoy (pour le routage) et Prometheus (pour les mesures).
Kubernetes est open source, bien spécifié, bien maintenu, plein de vie. Pourquoi se méfier de son coté captif? Tout simplement par ce qu’il est tout aussi complexe à héberger qu’un Ceph dont tout le monde vante l’open source sans pour autant le déployer. Kubernetes va éradiquer l’offre Docker Swarm qui n’a jamais convaincu grand monde, et débarquer par défaut sur tout les postes de dev avec le très confortable minikube. Kubernetes a besoin de s’appuyer sur des services de persistances (mode bloques et objets), bien pénible à héberger. En partant de bare metal, il faut donc assumer un Ceph en plus de Kubernetes comme ticket d’entrée.
C’est de plus en plus visible : la notion d’open source fusionne avec la notion de standard et de portabilité. L’hébergement de Kubernetes, même si on garde le choix entre 3 mammouths est de fait propriétaire, tout en gardant le développement open source. L’open source se fait commodifier la gueule, en fait, mais avec le sourire. L’open source est utilisé pour faire chier les autres, Microsoft peut en témoigner.
Une bonne vague d’hardware inaccessible, pour continuer à distancer la concurrence (gpu haut de gamme , tpu) toujours basée sur des frameworks bien libres comme Tensorflow.
La prochaine vague, déjà bien amorcée, est le serverless, un buzzword pour imposer un framework n’exposant que du code métier, facilitant de fait l’hébergement (et basé sur des conteneurs encore plus densifiés).
Une vague de métrologie, avec OpenCensus qui va permettre d’unifier les mesures privées (les services fournit par Google), avec les mesures publics, dans le code déployé.
La vague suivante va être la sécurité avec gVisor pour les conteneurs, et Asylo pour les enclaves.
La tactique est des plus classiques. On abuse de l’exclusivité tant qu’on peut, tout en démolissant la marge de la génération précédente de technologie, tout en maintenant un cout d’entrée énorme, pour exclure les nouveaux entrants. Ça permet à la fois de réduire ses propres coûts tout en asséchant la concurrence. On a ainsi vu récemment passer la libération des frameworks de machine learning, en mode terre brulée (Google, Nokia, Microsoft…), pour finalement se concentrer sur la vente d’hébergement avec du matériel spécifique (les fameux TPU), ou “as a service” pour les utilisateurs aux compétences limités : AutoML.
À l’époque de la ruée vers l’or, le meilleur moyen de devenir riche était de vendre des pelles (avec l’exclusivité), pas de creuser. L’offre Cloud de Google nous vends des pelles.