Je suis en train de construire un cloud
(crawshaw.io)- 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
6 commentaires
Je me suis d’abord demandé « pourquoi maintenant ? »..
Puis j’ai vu que l’auteur était le cofondateur de Tailscale, et j’ai eu envie de l’encourager pour une raison ou une autre.
Faites-en quelque chose de bien !
Le tableau des prix est vraiment trop confus, parce qu’il est écrit sous la forme 2 cœurs, 8 Go, 50 VM, etc. Je pense qu’il faut comprendre qu’on vous donne une VM et que vous pouvez y faire tourner 50 conteneurs.
Le cloud est complexe pour une bonne raison.
Je ne vois pas la fonction de suppression de compte, quelqu’un l’a trouvée ?
Ce serait bien de pouvoir connecter des services entre eux par simple glisser-déposer.
Commentaires sur Hacker News
Kubernetes peut sembler correct au début pour faire tourner quelques conteneurs de web app, mais on finit vite par lui ajouter du SDN et toutes sortes de services, jusqu’à en faire une énorme usine à gaz incontrôlable
Plus on « optimisait » et « durcissait » le cluster, plus les coûts cloud, les incidents, le downtime et l’effort de débogage étaient multipliés par 2 ou 3
Au final, après avoir abandonné cette inertie DevOps et supprimé le cluster, on a activé le pare-feu sur une VM Debian unique et déployé Docker avec Kamal : c’est là qu’on a obtenu la meilleure stabilité et fiabilité d’infra, avec des coûts en forte baisse
La plupart des applications métier servent de quelques centaines à quelques milliers d’utilisateurs, donc une grosse VM suffit souvent, et comme des clouds comme Google gèrent les pannes matérielles, il suffit au besoin de lancer une deuxième VM et de ne changer que l’IP côté Cloudflare
On voit fréquemment du k8s imposé à des échelles beaucoup trop petites, et dans ce cas on n’est probablement pas du tout à une échelle qui justifie k8s
Il faut donc une couche supérieure qui simplifie les schémas de déploiement courants, et Knative en est un exemple
Toute solution qui cherche à exposer toutes les primitives sous-jacentes finit inévitablement par devenir aussi complexe que Kubernetes
https://github.com/openrundev/openrun, que j’ai créé, gère de façon déclarative le déploiement d’apps web internes d’équipe, ajoute SAML/OAuth et RBAC, et prend en charge aussi bien Docker sur machine unique que Kubernetes
Une façon de penser excessivement complexe, difficile à déboguer et coûteuse peut être reproduite à l’identique sur des VM
Pour l’instant, il se peut simplement que leur VM Debian unique échappe au radar des politiques internes, ce qui leur laisse de la liberté
Dès que quelqu’un s’en mêlera, il y a de fortes chances qu’on veuille y ajouter HA, rollout/rollback, 3 à 5 VM, politiques de réseau virtuel, 4 scanners de sécurité, 2 processeurs de logs, watchdog, monitoring réseau, mTLS et outils de visibilité du trafic
Une machine de plus réduit le stress si quelque chose casse pendant une mise à niveau ou un changement
https://github.com/psviderski/uncloud, que je développe, s’inspire de Kamal pour rendre une configuration multi-machine aussi simple qu’une VM unique, avec un overlay WireGuard zero-config et du Docker Compose standard pour déployer sur plusieurs VM
On peut démarrer sans complexité d’orchestrateur ou de control plane sur une seule machine, puis étendre plus tard en mélangeant VM cloud et on-prem si nécessaire
Je l’ai utilisé en production et l’expérience a été excellente à chaque instant, au point que ça m’a semblé redéfinir l’informatique elle-même
J’ai donc probablement raté quelque chose dans la vision de ceux qui le détestent à ce point
L’OP est l’un des cofondateurs de Tailscale, ce qui rend le contexte encore plus intéressant
Son observation sur les entreprises traditionnelles du Cloud 1.0 qui donnent par défaut environ 3000 IOPS sur les VM, alors qu’un laptop monte à 500 000 IOPS, me paraît juste
La vision est vraiment bonne et j’ai même l’impression d’être le client cible, mais j’ai peur qu’au fil du succès, on retombe dans la trajectoire habituelle où la pression sur les revenus finit par l’emporter sur l’idéal
Les prix du cloud ne sont souvent pas fondés sur les coûts, et sont fréquemment conçus pour dégager une forte marge sur des postes comme la bandwidth ou le NAT gateway, surtout une fois que le client est profondément captif
J’ai du mal à croire que l’OP ignore cette mécanique
Mais ce stockage est fondamentalement éphémère et n’offre pas assez de redondance
On peut réduire le risque de panne matérielle avec du RAID1, mais ça diminue le nombre de NVMe utilisables, et il n’y a pas non plus de solution propre quand il faut déplacer une VM pour des raisons de RAM/CPU sur l’hôte
Au final, il faut presque traiter ces VM comme du bare metal, avec de la redondance au niveau applicatif comme la réplication de base de données
Sur Azure, il faut partir du principe qu’ils peuvent déplacer la VM quand ils veulent et effacer les données éphémères, mais sur OpenStack, si nécessaire, on pouvait éteindre la VM et copier aussi les données NVMe vers un autre hôte via une migration locale au niveau bloc
Malgré cela, si l’hôte plantait, la VM restait indisponible jusqu’au retour de l’hôte, donc la redondance au niveau applicatif était indispensable
Mais en latence au 99,9e percentile, Hetzner était vers 5 ms contre environ 18 ms pour DO, et la latence max était de 7 ms chez Hetzner contre 85 ms chez DO, donc l’écart est réel
En séquentiel avec dd, Hetzner montait à 1,9GB/s contre 850MB/s pour DO
Et côté prix, Hetzner coûte 4 euros alors que l’instance DO est à 18 dollars, donc la différence est énorme
J’ai écrit ça avant de finir l’article, et justement l’OP pointait exactement ces deux éléments
Ça reviendrait à rendre difficile même l’usage d’une DB locale sur un simple serveur, afin de favoriser le lock-in
L’idée selon laquelle produire un objet coûte X donc son prix serait 1.y*X est très éloignée de la réalité du pricing de marché
Une logique top-down est bien plus réaliste qu’une logique bottom-up
De la même façon que le débat autour de l’IA devient extrême, Kubernetes semble provoquer exactement la même polarisation
J’ai exploité pendant des années des clusters de tailles variées, et jamais la cause d’un incident n’a été k8s lui-même
Une fois, on a eu une panne totale d’environ une heure, et tous ceux qui n’aimaient pas k8s ont aussitôt voulu accuser ce « fichu système k8s »
La cause réelle était qu’un service, dans une certaine situation, ouvrait instantanément des dizaines de milliers de ports et provoquait un auto-DOS
Je ne pense ni que k8s soit l’avenir absolu, ni que ce soit de la camelote ; c’est simplement un bon système quand on en a vraiment besoin
Soit c’est trop complexe à apprendre, pas nécessaire pour mon problème et les méthodes de déploiement classiques suffisent ; soit c’est moins bon que le bare metal en coût/efficacité énergétique
Le plus souvent, les deux vont ensemble
Les positions modérément neutres ou simplement indifférentes deviennent presque rares, et la politique américaine vient tout de suite à l’esprit
Moi non plus je ne connais pas très bien k8s, et quand un staff engineer parle de pods et de clusters j’ai le regard qui se vide, mais chez nous ça convient très bien et ça fonctionne
Pour quelqu’un qui n’a qu’un marteau, tout ressemble à un clou ; et celui qui tient une hache se demande pourquoi tout le monde essaie de couper du bois avec un marteau
Et si le travail exige en réalité une hache, mais qu’on se fait prendre sa place par quelqu’un avec un marteau, il devient encore plus facile de détester le marteau
Pour k8s, les best practices sont déjà relativement établies dans beaucoup de cas d’usage, alors que du côté des LLM, on ne sait même pas encore vraiment ce qui constitue une best practice
Je suis très d’accord avec l’idée que les VM étant liées au CPU et à la mémoire, on paie le temps plutôt que le travail effectué
C’est pour ça que j’ai acheté un serveur aux enchères Hetzner bon marché et que je le fais tourner sur un orchestrateur Firecracker auto-hébergeable que j’ai créé
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
Ce que je voulais, c’était acheter du matériel, le découper librement en VM, et ne plus me soucier du provisioning ni du lifecycle
Les VM inactives snapshotent leur état mémoire sur disque et rendent toute la RAM, donc le matériel m’appartient, les VM sont jetables, et quand elles ne font rien le coût est presque nul
Le point des memory-state snapshots, en particulier, a été bien plus puissant que je ne l’imaginais : une fois qu’on les a, tout devient reprenable
Je peux snapshoter un Chromium déjà connecté, puis lancer instantanément des copies de session quand j’en ai besoin ; les agents travaillent dans des sandbox et j’y fais aussi tourner du docker compose pour des environnements de preview
Quand rien ne tourne, le serveur est pratiquement idle, et une seule machine à 100 dollars par mois gère tout ça
Tout est détaillé ici : https://shellbox.dev/blog/race-to-the-bottom.html
La documentation est complète et utile, mais une bonne partie a clairement un style écrit par IA, et ça gagnerait à être plus concis
Cela dit, la section « design decisions » était particulièrement bonne, et j’y ai même appris des choses
Si ce n’est pas déjà fait, ça vaudrait le coup de le poster sur Show HN
Il existe déjà une énorme quantité de logiciels que personne n’utilise, donc je comprends mal cette obsession pour produire encore plus de code
Rien qu’en regardant les app stores, on voit une masse de logiciels dont personne ne se sert
L’usage le plus évident des LLM ne devrait pas être de produire plus de logiciel, mais de produire de meilleurs logiciels
J’espère qu’on sortira de cette focalisation sur la seule génération de code, car il existe beaucoup de façons pour les LLM d’aider à écrire un meilleur code
L’image d’un système déterministe qu’on conçoit soigneusement, qu’on maintient et qu’on met à jour va certainement subsister, mais l’IA change déjà la manière dont les utilisateurs interagissent avec leur ordinateur
Le résultat sera probablement l’apparition de logiciels beaucoup plus proches du jetable
Pour l’instant, on en est encore à « comment l’IA peut-elle aider les ingénieurs à écrire du logiciel ? », mais on est déjà en train de glisser vers « que doivent faire les ingénieurs pour permettre à l’IA d’écrire mieux du logiciel ? »
Cela fera entrer une nouvelle génération d’ingénieurs avec une vision complètement différente de ce qu’est le logiciel et de la manière de concevoir l’interaction informatique
Il va probablement exister énormément de logiciels sur mesure qui n’apparaîtront jamais dans un app store
Pour parler de paradoxe de Jevons, il faut que le coût unitaire de production du logiciel baisse, mais que l’augmentation de la demande dépasse les économies réalisées au point d’accroître la dépense totale
Ce concept s’applique à des marchés où la demande est élastique, c’est-à-dire où la quantité demandée réagit fortement aux variations de prix
En dehors des jeux, on regardera peut-être un jour en arrière en se demandant à quel point il était étrange de construire un seul logiciel pour des centaines de millions, voire des milliards de personnes
Désormais, les gens pourront créer des logiciels qui font exactement ce qu’ils veulent vraiment, avec moins de compromis imposés par des priorités contradictoires ou des modèles de revenus déformants
Par définition, on peut aussi considérer que ce type de logiciel est de meilleure qualité
Cela a rendu les coûts et les revenus plus prévisibles des deux côtés, mais l’objectif central était de produire un logiciel le plus générique possible
Résultat : des éléments d’UX ou des fonctionnalités importantes seulement pour une partie des utilisateurs sont constamment sacrifiés
Le vibe coding et le développement accéléré par les LLM peuvent renverser cela
Chacun va pouvoir s’offrir des logiciels sur mesure adaptés à ses besoins et préférences, et on peut imaginer un monde où, au lieu de 150 000 clients Salesforce sur le même CRM, il existe 150 000 CRM personnalisés
Le potentiel d’expansion du logiciel est immense aujourd’hui
Si on ne comprend pas le cycle de l’obésité logicielle, on continue à répéter les mêmes erreurs
On part d’un lean software, on ajoute les fonctionnalités demandées par les utilisateurs, on finit avec un bloated mess, puis il faut une nouvelle réécriture plus petite, avant de revenir à nouveau à un lean software
Les reboots échouent le plus souvent, ou alors ils réussissent à toucher quelque chose de vraiment essentiel et progressent assez pour menacer les acteurs en place
La vision qui rabaisse le DevOps en simple remplissage de CV ou en source première d’une complexité excessive me paraît davantage relever d’une mentalité startup
Dans une petite entreprise, une seule personne DevOps peut gérer toute l’infra, mais surtout dans la finance, ce sont souvent les MD de platform engineering qui tiennent réellement la direction
Ils veulent découper les software engineers en une multitude de petits groupes, avec chaque équipe maîtresse de son repo, de son déploiement, de tout son environnement, et ils pensent que les microservices leur donnent ce pouvoir
Je peux garantir que les équipes DevOps détestent la complexité
Ce sont elles qui se font appeler la nuit et le week-end, et tout commence toujours par l’hypothèse que « c’est un problème d’infra »
Les logs de déploiement sont bien tous versés dans le système d’agrégation de logs, et pourtant il est rare que les développeurs aillent eux-mêmes lire ces logs pour résoudre leur problème de déploiement ; ça devient très vite un Incident
J’ai l’impression qu’il faudrait désormais considérer les microservices comme une mode déjà passée
J’ai une opinion positive d’exe.dev, et je pense qu’il y a clairement une opportunité pour un service qui fluidifie le flux de développement avec LLM tout en offrant la flexibilité d’une machine Linux avec accès root
Mais en lisant la phrase sur le fait d’avoir été « trahi en permanence par des abstractions à moitié implémentées et à moitié pensées », j’ai trouvé ironique que ce soit précisément aussi mon expérience avec Tailscale
C’était censé simplifier le networking, alors pourquoi ça vide la batterie aussi vite, pourquoi ça modifie les règles de pare-feu au point d’entrer en conflit avec d’autres outils, et pourquoi le bug tracker est-il si silencieux, au point que je doive finir par comprendre moi-même l’implémentation interne ?
C’est ce qui me fait dire « No thank you »
Le service lui-même a vraiment l’air excellent
Je ne cherche pas à écrire des ACL de routeur, mais à structurer une couche réseau peer-to-peer, et c’est là que ça me frustre
Moi, j’utilise simplement Hetzner
Tout ce que proposent les entreprises cloud est beaucoup trop cher, et mon Postgres HA auto-opéré avec sauvegardes a tourné sans interruption pendant 10 ans tout en coûtant environ un dixième d’un environnement RDS ou CloudSQL en production
J’autoscale moi-même les instances à partir des métriques collectées dans Grafana, et un autoscaler basé sur webhook fonctionne aussi de façon extrêmement simple et n’a jamais posé le moindre problème
Du coup, je ne vois plus très bien pourquoi je devrais utiliser GCP ou AWS
Tous les services sont HA et les sauvegardes quotidiennes se passent très bien
L’objectif était alors de recréer à bas coût l’expérience d’un dedicated server avec un maximum de flexibilité, et UML rendait cela possible
Mais pendant toutes les années 2010, je me suis totalement trompé en pensant que la majorité des développeurs n’accepterait pas de se faire facturer à l’usage sur chaque couche de la stack juste pour un peu plus de commodité
Je me demande si les software engineers dans la vingtaine aujourd’hui savent encore monter une plateforme de web apps à fort trafic avec un serveur et un routeur achetés sur eBay
J’ai moi-même fait ça l’an dernier pour bâtir un datastore de plus de 50 PiB, et je me demande sincèrement dans quelle mesure cette approche est encore utilisée sur des projets moyens à grands
Hetzner retire une grande partie des tracas physiques tout en conservant presque entièrement l’avantage économique ; je trouve donc étrange qu’ils ne règnent pas sur le monde de l’hébergement et restent à seulement 367 millions d’euros de chiffre d’affaires en 2021
J’ai du mal à croire que le savoir-faire nécessaire pour gérer un lot de dedicated servers soit devenu à ce point spécialisé que les gens ignorent des économies aussi importantes
Cela dit, si l’on peut trouver les bons profils, l’exploitation en direct peut effectivement coûter beaucoup moins cher
Chaque minute, une tâche cron fait un docker pull pour récupérer la dernière image, puis ne lance docker up -d que s’il y a une nouvelle version
Devant, j’utilise caddy pour HTTPS, et ça tourne comme ça depuis des années de façon très économique et stable
Ça ressemble à un acteur britannique avec une philosophie proche ; je ne l’ai pas encore essayé, mais j’ai déjà créé un compte comme candidat possible pour mon prochain VPS
On peut souvent se permettre un serveur 5 fois plus rapide dès le départ, ce qui rend l’autoscaling inutile dans bien des cas
Les alternatives existent déjà en nombre, et j’ai créé https://shellbox.dev
Contrairement à exe, la facturation se fait à l’usage, avec scale-to-zero, et on peut lancer immédiatement une VM via SSH
C’est du Linux standard, donc VSCode Remote et Zed Remote sont pris en charge, et la nested virtualization est aussi possible
Si vous voulez investir, 5 millions de dollars me suffisent
Aucun port n’est exposé à l’extérieur, et toutes les interfaces web sont protégées par mot de passe
Je ne compte pas le publier ; c’est mon environnement de développement isolé personnel qui tourne derrière la télé sur un Raspberry Pi
Ça ne coûte pratiquement rien
J’espère que le service marchera bien
Il n’est pas clair où se trouve réellement l’infrastructure sous-jacente ni de quelles garanties de sécurité elle bénéficie, donc il est difficile d’y confier des workloads