Uncloud
Uncloud se présente comme un non-cloud un service ressemblant à Heroku ou Render, mais aux sources ouvertes. Le seul point commun que je vois dans ces références est la possibilité de bazarder des conteneurs en prod sans passer par la case adminsys, mais avec la promesse de la montée à l’échelle, le Graal de toute bonne startup. La comparaison avec des services vieillissants est étrange, et même peu flatteuse en vue de l’ambition technique de Uncloud.
L’autre comparaison, l’éléphant dans le couloir, est Kubernetes. Uncloud se présente comme une deux chevaux face à K8s le semi remorque de 38 tonnes.
Adminless
Uncloud permet de gérer sa prod comme son poste de dev. Cette phrase est terrifiante. Mais, avec un peu de rigueur, cette approche est crédible, Uncloud assume une grosse partie du travail, avec le minimum de magie vaudou.
Si on vire les adminsys de l’équation, il faut assumer la correction des incidents en ligne (et les mises à jour, et les sauvegardes, et la configuration fine bas niveau et plein d’autres surprises).
Scaleless
Uncloud est conçu pour ne pas se soucier de l’hébergement, et même d’avoir plusieurs hébergeurs, ou même de l’auto-hébergement. Il crée un grand un réseau virtuel chiffré (avec Wireguard), et tout le monde peut causer avec tout le monde, sur tous les serveurs.
Rappelons que le produit est australien, qui n’ont ni des tonnes d’utilisateurs locaux, ni une connexion réseau ultime avec le reste du monde. Avoir des noeuds distribués proches des clients est plus important pour eux que pour un français qui a du mal à se projeter au dela de la métropole (et de l’Europe pour les plus ambitieux).
L’auto-hébergement est honorable, tant qu’on a la bande passante suffisante pour servir ses utilisateurs, mais l’hébergement à pas cher est, euh, pas cher, et ne souffle pas h24 dans votre salon (ou un placard). Mixer hébergement local et distant est difficilement justifiable, peut-être pour bencher votre jolie carte NVidia en proposant une indispensable fonctionnalité cloud sans vous ruiner en token (ou sans offrir vos données à la Silicon Valley).
Brainless
Uncloud expose une commande, uc qui permet d’agir comme on le ferait avec docker, et même d’utiliser des docker-compose.yml (avec quelques informations complémentaires).
Pour ne pas avoir à gérer un registre de conteneur (ça sonne mieux en anglais : container registry), ce qui peut effectivement être pénible, les images sont directement poussées sur la cible, en SSH, créant ainsi le néologisme pussh.
Uncloud fournit gracieusement un DNS en *.cluster.uncloud.run qui avec un simple alias depuis votre nom de domaine vous permettra d’avoir une résolution de nom en tourniquet (Round Robin DNS).
Lets-encrypt (via Caddy) fournit le certificat TLS.
Toutes les interactions avec les serveurs passent par SSH, même le débug.
Les conteneurs sont déployés sur une machine explicite, et s’il y a plusieurs instances d’un service, une répartition de charge (load balancing) se met en place spontanément.
Le déploiement est promis sans interruption, la fameuse stratégie bleu/vert.
Le réseau privé évite qu’un service soit exposé par accident sur Internet (seuls les ports SSH, HTTP et HTTPS sont accessibles).
La procédure de déploiement est donc : * Chez moi ça marche * Pousse en prod * Si ça pète, on a tout de suite les logs pour comprendre la cause du oups * Correction à l’arrache * Repousse * Pause au babyfoot
Dissection
Les promesses de la plaquette sont bien belles, mais qu’en est-il techniquement ?
Un des concepts de bases, si ce n’est l’unique, est la décentralisation, tous les noeuds fournissent le même service uncloudd, sans spécialisation, sans chef.
Uncloud n’utilise pas de configurations, et promet de ne consommer que 150MB de RAM par noeud.
API réseau
Tous les services sont en grpc, avec la passerelle REST officielle : grpc-gateway.
Le client utilise une connexion ssh pour causer en grpc, ce qui simplifie la gestion des droits.
Conteneurisation
Docker est évidement la brique de base de ce non-cloud, avec en interne des appels directement à Containerd.
Les images ne sont pas centralisées, tout est poussé directement sur la cible, via le sous projet unregistry.
Ce petit sacrilège est bien tentant pour simplifier une pile technique, même si Github/Gitlab fournit des registry privées.
La configuration des conteneurs se fait par des fichiers de conf accédés depuis des volumes. Pour l’instant la configuration via les variables d’environnement n’est pas disponible, ce qui est un crime selon 12 factors.
Réseau privé
La gestion du réseau privé est l’élément le plus complexe de la pile technique.
Wireguard permet de relier les différents noeuds, avec des sous réseaux bien rangés, et du routage. Même choix technique que [Tailscale(https://tailscale.com/)], gage de sérieux.
La coordination des différents noeuds du réseau passe par Corrosion, un concurrent de Consul, crée par Fly.io. Écrit en Rust (what else ?) il expose une base de données sqlite avec la possibilité de s’abonner à une requête SQL.
Un DNS interne permet d’accéder à tout, en suivant des conventions de nommage.
La persistance de la config réseau utilise le datastore CRDT d’IPFS, même si Corrosion propose la même chose et que d’autres pistes sont explorées.
Ingress
Caddy a été choisi comme passerelle HTTP/HTTPS, même si Traefik est aussi évoqué dans le wiki. Il prend en charge le load balancing, l’éviction des noeuds morts, les certificats TLS avec Letsencrypt et HTTP/3.
Caddy est déployé sur chacun des noeuds, laissant au DNS (public) le choix d’un point d’entrée.
Haute disponibilité
Uncloud est terrorisé par les quorums (suffisamment d’électeurs au sein du cluster) qui pourraient empêcher la modification de l’état du cluster.
Dans le théorème CAP, il sacrifie le C, la cohérence des données, et prie pour que les données vont se réconcilier une fois que tous les membres du cluster sont de nouveaux réunis.
Sur le papier, ça ressemble à un choix de lapin apeuré. Concrètement, les clusters Uncloud seront de taille ridicule, avec des services déployés explicitement sur des noeuds n’utilisant que très peu les instances multiples avec répartition de charge.
Tant que le projet Uncloud n’a pas fait le ménage dans la partie gossip et état distribué, il n’a aucune légitimité à faire de pareilles affirmations.
La notion de haute disponibilité de Uncloud est un peu une blague : il ne sait pas re-ventiler les services d’un noeud qui a crashé ou en lancer de nouveau pour accompagner une montée en charge.
Critiques
Uncloud n’est officiellement pas prêt pour de la prod, ce qui limite la possibilté de le défoncer à coups de critiques.
Uncloud est le projet d’un seul homme (one man project), même s’il est talentueux et maintient une documentation exemplaire. Il va falloir qu’il regarde bien des deux cotés avant de travers la route.
Les sources contiennent des paramètres spécifiques à la machine du développeur, même si ce n’est qu’un détail. Le déploiement des services est sauvage (il pousse d’office un binaire docker sur les noeuds).
La notion d’Infra As Code ou de CI/CD ne semble pas l’intéresser, mais c’est un raccourci tentant pour un freelance qui ne fait que des missions en solo. On peut parler de “one man deployment”.
La notion de multitenant ou même d’isolation de différents projets ne paraissent pas effleurer le développeur. C’est un challenge intéressant pour la couche réseau.
La tolérance de panne passe par un service DNS (gratis) est un SPOF qui va embêter tout le monde avec les temps de diffusion (TTL).
Comme toutes les offres d’hébergement distribué avec promesse de tolérance de panne, la partie persistance est planquée sous le tapis. Il faudrait au moins évoqué dans la documentation l’intérêt de Redis-cluster pour les sessions, Minio pour le stockage de fichiers. Ces deux services ont le bon gout de se débrouiller à peu près tout seul. Pour les bases de données, ce n’est pas la même histoire, il faut soit faire des compromis avec des bases exotiques : litefs, scylladb, foundatoindb … ou assumer la réplication primaire/secondaire des classiques base de données relationnelles.
La gestion crédible (à la charge de l’utilisateur) de la persistance casse tout de suite l’ambiance “élégance de la simplicité” d’Uncloud.
Avant de râler, commencez par avoir une procédure de sauvegarde d’équerre, AVEC TEST DE RESTAURATION, ce sera déjà pas mal.
Sinon, affirmer qu’Uncloud est vertueusement soutenable par ce que moins orgiaque que Kubernetes est un peu mesquin.
L’après
Uncloud bénéficie déjà d’une belle visibilité et réputation, ce qui est une grande victoire pour un développeur seul.
Par ses choix, Uncloud ne pourra générer que peu de revenus, juste vendre de l’expertise technique. Le choix de la cible “développeur solo, petits projets, hébergement discount” ne va pas non plus aider à ramener des sous, même si Uncloud risque de plaire aux agences de communication.
Il faut donc lui souhaiter du sponsoring, sous une forme ou une autre, et cibler des projets un poil plus ambitieux que l’infâme Wordpress+Mariadb proposé dans les exemples.
Il y a pour l’instant des parties mal définies qui rend le projet un peu brouillon. Ces zones floues seront rapidement corrigées avec une dose de RTFM et d’aide extérieure.
De toute façon, tout ce qui secoue et remet en cause les admins, devops et autre idolâtre du cloud est rafraichissant, même si la proposition se vautre.
À suivre et à encourager !