Je suis en train de construire un cloud

• Les abstractions cloud existantes rendent difficile l’utilisation combinée de CPU, mémoire et disque comme on le souhaite, et les VM comme les PaaS imposent plus de contraintes qu’un ordinateur classique
• Le stockage bloc distant et les coûts d’egress élevés perpétuent une architecture héritée de l’époque des HDD, ce qui aggrave encore les problèmes de performances et de coûts à l’ère des SSD et des réseaux modernes
• Kubernetes masque en partie la difficulté des API cloud, mais ne corrige pas la mauvaise abstraction de base, et conserve donc les limites des VM, du disque et du réseau
• À mesure que les agents augmentent la demande en logiciels et en exécution, l’importance d’espaces d’exécution privés, d’un partage simple et d’une faible surcharge opérationnelle ne fait que croître, tout comme les goulets d’étranglement structurels du cloud actuel
• exe.dev cherche à se rapprocher du cloud qu’on aimerait réellement utiliser en allouant d’abord CPU et mémoire, puis en laissant exécuter directement des VM par-dessus, avec une combinaison de proxy TLS, proxy d’authentification, NVMe local, réplication asynchrone et placement basé sur l’anycast

---

Pourquoi reconstruire un nouveau cloud

• Les abstractions cloud actuelles rendent difficile l’utilisation d’un ordinateur comme on le voudrait, au point que cela a été la raison directe du lancement d’une nouvelle entreprise
• Les ordinateurs eux-mêmes sont excellents, mais les clouds d’aujourd’hui répètent les mêmes contraintes dans presque tous les produits, et le cœur du problème tient moins à l’UX ou à des erreurs de conception d’API qu’à la forme même des briques de base
• Les VM sont fournies comme des instances individuelles liées au CPU et à la mémoire, alors que le modèle souhaité ressemble davantage à une allocation préalable des ressources CPU, mémoire et disque, sur lesquelles on peut ensuite lancer autant de VM que nécessaire
  • Une VM Linux n’est au fond qu’un processus tournant dans le cgroup d’un autre Linux, mais les clouds actuels rendent cela difficile à manipuler simplement
  • Pour contourner cela, il faut déployer gVisor ou de la virtualisation imbriquée sur une VM cloud unique, avec une perte de performances et au minimum l’obligation d’exploiter soi-même un reverse proxy
• Les PaaS ne résolvent pas ce problème et imposent au contraire des abstractions propriétaires moins puissantes qu’un ordinateur ordinaire
  • Il faut apprendre une nouvelle manière de développer pour chaque fournisseur de calcul
  • Ce n’est parfois qu’après avoir bien avancé sur un projet qu’on découvre qu’une tâche triviale sur un ordinateur classique est presque impossible à cause de limitations profondes de la plateforme
  • On a plusieurs fois l’impression que « cette fois, ça va marcher », avant de buter à nouveau sur une abstraction à moitié implémentée

Les limites structurelles visibles dans le disque et le réseau

• Côté disque, les fournisseurs cloud préfèrent le stockage bloc distant ou des approches encore plus limitées et plus lentes comme S3, ce qui était relativement rationnel à l’époque des HDD
  • Le stockage distant ne pénalisait pas fortement les lectures et écritures séquentielles, et comme les seek aléatoires d’un HDD étaient de l’ordre de 10 ms, un RTT Ethernet de 1 ms restait acceptable
  • Pour le fournisseur, cela simplifie l’exploitation en supprimant un axe dans les types d’instances standards
• Mais ce raisonnement s’effondre avec le passage aux SSD
  • Le temps de seek est passé de 10 ms à 20 microsecondes
  • Le RTT réseau des systèmes bloc distants s’est amélioré, mais la surcharge en IOPS, qui était d’environ 10 % à l’époque des HDD, dépasse désormais 10 fois cette valeur à l’ère des SSD
  • Sur EC2, configurer 200k IOPS est complexe et coûte 10 000 dollars par mois, alors qu’un MacBook fournit 500k IOPS
• La technologie réseau est en elle-même suffisamment bonne, mais les coûts d’egress et les structures économiques nuisent à l’utilisabilité
  • Les réseaux des hyperscalers sont excellents, mais très coûteux, et rendent aussi l’interconnexion avec d’autres fournisseurs peu pratique
  • Les tarifs d’egress du cloud sont annoncés à un niveau 10 fois supérieur par Go à celui d’un serveur installé en rack dans un datacenter classique
  • Dès que l’usage augmente un peu, ce multiplicateur devient encore pire
  • Les clients qui dépensent des dizaines de millions de dollars par mois obtiennent de meilleurs prix, mais cela ne convient pas à des projets de quelques dizaines ou centaines de dollars par mois
  • Dans cette tranche, quel que soit le produit qu’on construit, on se retrouve empêché de l’exploiter à bas coût

Kubernetes et les API masquent le problème sans le résoudre

• Les API cloud sont pénibles à manipuler, et Kubernetes est apparu pour masquer cette complexité et réduire la douleur des ingénieurs
• Mais les VM restent difficiles à gérer, y compris au-dessus de Kubernetes, car le cloud délègue toujours directement au client le problème de la virtualisation imbriquée
• Pour le disque aussi, au moment de la conception de Kubernetes chez Google, il n’existait pratiquement pas de périphérique bloc distant vraiment satisfaisant, et même aujourd’hui, lorsqu’on s’aligne tant bien que mal sur les schémas communs, on se retrouve facilement lié à un stockage lent
• Le réseau non plus n’est pas simple à ouvrir : si c’était facile, on pourrait relier certains systèmes d’un datacenter ouvert voisin en private link et supprimer un zéro de la facture cloud ; l’incitation à simplifier cela est donc faible
• Plutôt que de considérer Kubernetes comme une simple fausse activité, il vaut mieux y voir le produit d’une tentative de résoudre un problème impossible : créer un cloud portable et réellement utilisable
• En pratique, il est impossible de résoudre le problème en empilant une nouvelle abstraction sur une abstraction cloud fondamentalement mauvaise, et même les efforts pour améliorer Kubernetes atteignent vite leurs limites
• Cela fait maintenant 15 ans qu’il vit avec ces clouds inconfortables, en essayant simplement, comme avec d’autres couches logicielles désagréables, de les tolérer et de limiter au minimum les interactions

Pourquoi c’est le moment de corriger cela

• Si c’est maintenant un point de bascule, c’est à cause des agents
• Comme avec le paradoxe de Jevons, plus il devient facile d’écrire du code, plus la quantité totale de logiciels augmente, et plus chacun utilise de programmes, au travail comme dans ses loisirs
• Pour exécuter tous ces programmes supplémentaires, il faut des espaces d’exécution privés, un partage facile et une faible surcharge opérationnelle
• À mesure que le volume total de logiciels augmente, les problèmes du cloud, autrefois simplement agaçants, deviennent un goulet d’étranglement bien plus important
  • Il faut davantage de puissance de calcul, et elle doit être plus simple à administrer
  • Les agents peuvent aider à manipuler l’API AWS à notre place, mais il faut leur confier des identifiants, et ils peuvent parfois supprimer une base de données de production
  • Surtout, eux aussi se heurtent aux mêmes limites fondamentales des abstractions cloud actuelles
  • Ils consomment plus de tokens que nécessaire et produisent des résultats moins bons qu’espéré
  • Plus la fenêtre de contexte d’un agent sert à forcer l’adaptation au cloud classique, moins il reste de marge pour résoudre le vrai problème

Ce qu’exe.dev a commencé à corriger en premier

• La première chose lancée par exe.dev est une solution au problème d’isolation des ressources des VM
• Au lieu de provisionner des VM individuelles, la plateforme alloue d’abord CPU et mémoire, puis permet d’exécuter directement les VM souhaitées par-dessus
• En partant du principe qu’on ne veut pas exposer directement une nouvelle VM à Internet, elle prend aussi en charge un proxy TLS et un proxy d’authentification
• Pour le disque, elle utilise du NVMe local et réplique les blocs hors de la machine de manière asynchrone
• Elle permet de placer des machines dans plusieurs régions du monde afin qu’elles s’exécutent à proximité des utilisateurs
• Les machines sont déployées derrière un réseau anycast pour offrir aux utilisateurs du monde entier un point d’entrée à faible latence
  • Cette base est conçue pour permettre bientôt l’ajout de nouvelles fonctionnalités
• Il reste encore beaucoup à construire
  • Il manque encore des éléments relativement évidents comme les IP statiques
  • Il reste aussi des sujets comme l’UX d’accès aux instantanés historiques de disque créés automatiquement
• En parallèle, l’équipe revient jusqu’à l’étape consistant à installer directement des machines en rack dans les datacenters, afin de réexaminer toutes les couches de la pile logicielle, y compris la manière d’établir la connectivité réseau
• L’objectif final est de construire le cloud qu’on a réellement envie d’utiliser