Ich baue eine Cloud
(crawshaw.io)- Bestehende Cloud-Abstraktionen machen es schwer, CPU, Arbeitsspeicher und Festplatten nach Wunsch zu kombinieren, und sowohl VMs als auch PaaS bringen mehr Einschränkungen mit sich als ein normaler Computer
- Remote-Block-Storage und hohe Egress-Kosten halten eine Struktur aufrecht, die an Annahmen aus der HDD-Ära gebunden ist, und verschärfen Leistungs- und Kostenprobleme in einer Welt mit SSDs und modernen Netzwerken noch weiter
- Kubernetes verdeckt die schwer handhabbaren Cloud-APIs, kann aber die fehlerhafte Grundabstraktion selbst nicht ändern und übernimmt deshalb die Grenzen von VM, Festplatte und Netzwerk unverändert
- Mit agents steigt der Bedarf an Software und Ausführungskapazität; dadurch werden private Ausführungsräume, einfaches Teilen und geringer Betriebs-Overhead wichtiger, und zugleich wachsen die strukturellen Engpässe bestehender Clouds
- exe.dev will einer Cloud näherkommen, die man tatsächlich nutzen möchte: erst CPU und Arbeitsspeicher bereitstellen, darauf VMs direkt ausführen und dies mit TLS-Proxy, Authentifizierungs-Proxy, lokalem NVMe, asynchroner Replikation und Anycast-basierter Platzierung kombinieren
Warum noch einmal eine neue Cloud bauen?
- Die bestehenden Cloud-Abstraktionen machen es schwer, Computer so zu nutzen, wie man es eigentlich möchte; das war ein direkter Grund für die Gründung des neuen Unternehmens
- Die Computer selbst sind gut, aber in heutigen Clouds wiederholen sich die Einschränkungen in fast jedem Produkt, und der Kern des Problems liegt weniger bei einfacher UX oder API-Fehlplanung als vielmehr bei der Form der grundlegenden Bausteine
- VMs werden als einzelne Instanzen bereitgestellt, die an CPU und Arbeitsspeicher gebunden sind; wünschenswert wäre eher eine Struktur, bei der man zuerst CPU-, Arbeitsspeicher- und Festplattenressourcen reserviert und darauf dann so viele VMs startet, wie nötig sind
- Eine Linux-VM ist ein Prozess, der innerhalb der cgroup eines anderen Linux läuft, und trotzdem ist das in heutigen Clouds nicht leicht zu handhaben
- Um das zu umgehen, muss man gVisor oder Nested Virtualization auf einer einzelnen Cloud-VM betreiben und dabei neben Leistungseinbußen mindestens auch den Betrieb eines Reverse Proxys selbst übernehmen
- Auch PaaS löst dieses Problem nicht, sondern erzwingt sogar anbietergebundene Abstraktionen, die weniger mächtig sind als ein normaler Computer
- Für jeden Compute-Anbieter muss man wieder eine neue Art der Entwicklung lernen
- Erst wenn ein Projekt schon ein Stück vorangekommen ist, zeigt sich oft, dass Aufgaben, die auf einem normalen Computer einfach wären, wegen tief sitzender Plattformbeschränkungen fast unmöglich sind
- Immer wieder denkt man „diesmal geht es“, nur um dann doch wieder an einer halb implementierten Abstraktion zu scheitern
Strukturelle Grenzen, sichtbar bei Festplatten und Netzwerk
- Beim Speicher bevorzugen Cloud-Anbieter Remote-Block-Storage oder noch restriktivere und langsamere Modelle wie S3; in der HDD-Ära war das bis zu einem gewissen Grad nachvollziehbar
- Remote-Speicher verursachte bei sequenziellem Lesen und Schreiben keine großen Nachteile, und da zufällige HDD-Seeks bei etwa 10 ms lagen, war eine Ethernet-Verbindung mit 1 ms RTT ein akzeptabler Preis
- Für Anbieter vereinfacht das den Betrieb, weil bei Standard-Instanztypen eine Achse wegfällt
- Mit dem Wechsel zu SSDs ist diese Annahme jedoch zusammengebrochen
- Die Seek-Zeit sank von 10 ms auf 20 Mikrosekunden
- Die Netzwerk-RTT von Remote-Block-Systemen hat sich zwar verbessert, aber der IOPS-Overhead ist von etwa 10 % in der HDD-Zeit auf mehr als das 10-Fache in der SSD-Ära gestiegen
- Um auf EC2 eine Konfiguration mit 200k IOPS zu bekommen, ist die Einrichtung kompliziert und kostet 10.000 Dollar pro Monat, während ein MacBook 500k IOPS liefert
- Die Netzwerktechnik selbst ist gut genug, aber Egress-Kosten und Geschäftsmodelle wirken in eine Richtung, die die Nutzbarkeit einschränkt
- Hyperscaler-Netzwerke sind hervorragend, aber sehr teuer und erschweren auch die Zusammenschaltung mit anderen Anbietern
- Der Egress-Preis von Cloud-Anbietern liegt pro GB etwa beim 10-Fachen dessen, was beim Racken eines Servers in einem normalen Rechenzentrum anfällt
- Schon bei etwas höherer Nutzung wird dieses Verhältnis noch schlechter
- Kunden mit Ausgaben in zweistelliger Millionenhöhe pro Monat bekommen bessere Preise, aber für Projekte im Bereich einiger Dutzend oder Hundert Dollar pro Monat passt das nicht
- In diesem Bereich wird es unabhängig vom Produkt schwierig, günstig zu betreiben
Kubernetes und APIs verdecken das Problem, lösen es aber nicht
- Cloud-APIs sind schmerzhaft in der Handhabung, und Kubernetes ist entstanden, um diese Ebene zu verdecken und so das Leid für Engineers zu verringern
- VMs bleiben jedoch auch unter Kubernetes schwer handhabbar, weil die Cloud Nested Virtualization letztlich direkt an den Nutzer weiterreicht
- Auch bei Festplatten gab es zur Zeit des Kubernetes-Designs bei Google praktisch keine brauchbaren Remote-Block-Geräte, und selbst wenn heute ein gemeinsames Muster gerade so erfüllt wird, bleibt man am Ende leicht an langsamen Speicher gebunden
- Beim Netzwerk gilt ebenfalls: Würde man es einfach öffnen, könnte man Teile offener benachbarter Rechenzentren per Private Link anbinden und damit eine Null aus den Cloud-Kosten streichen; deshalb gibt es wenig Anreiz, es einfach zu machen
- Kubernetes sollte man nicht als bloße künstliche Beschäftigung abtun, sondern als Produkt eines unmöglichen Problems sehen: eine portable und brauchbare Cloud zu schaffen
- Grundsätzlich lässt sich das nicht lösen, indem man auf eine von Grund auf falsche Cloud-Abstraktion noch eine weitere Abstraktion schichtet; auch Verbesserungen an Kubernetes stoßen deshalb klar an Grenzen
- Die Zeit mit dieser unbequemen Cloud-Welt beträgt inzwischen 15 Jahre, und in dieser Zeit hat man wie bei anderen unangenehmen Teilen des Software-Stacks durchgehalten, indem man den Kontakt auf das Nötigste beschränkt hat
Jetzt ist der Zeitpunkt, es zu reparieren
- Dass jetzt ein Wendepunkt ist, liegt an agents
- Wie beim Jevons paradox gilt: Je leichter das Schreiben von Code wird, desto mehr Software entsteht insgesamt, und sowohl beruflich als auch privat nutzt jeder mehr Programme
- Um diese wachsende Menge an Programmen auszuführen, braucht es private Ausführungsräume, einfache Möglichkeiten zum Teilen und geringen Betriebs-Overhead
- Je größer die Gesamtmenge an Software wird, desto mehr wachsen Cloud-Probleme, die früher nur lästig waren, zu ernsthaften Engpässen heran
- Es wird mehr Compute benötigt, und die Verwaltung muss einfacher werden
- agents helfen zwar dabei, statt Menschen AWS-APIs zu bedienen, aber man muss ihnen Zugangsdaten anvertrauen, und manchmal könnten sie auch die Produktionsdatenbank löschen
- Vor allem stoßen agents bei den grundlegenden Grenzen bestehender Cloud-Abstraktionen gegen dieselben Wände wie Menschen
- Sie verbrauchen mehr Tokens als nötig, und die Ergebnisse sind schlechter als erwartet
- Je mehr vom Context Window eines agents dafür verwendet wird, eine klassische Cloud gewaltsam passend zu machen, desto weniger bleibt für die Lösung des eigentlichen Problems übrig
Was exe.dev zuerst zu reparieren begonnen hat
- exe.dev hat zuerst eine Lösung für das Problem der Ressourcenisolation bei VMs veröffentlicht
- Statt einzelne VMs zu provisionieren, erhält man zuerst CPU und Arbeitsspeicher und kann darauf die gewünschten VMs direkt selbst ausführen
- Unter der Annahme, dass man neue VMs nicht direkt unverändert ins Internet stellen möchte, werden TLS-Proxy und Authentifizierungs-Proxy gleich mit übernommen
- Für Festplatten wird lokales NVMe verwendet, und die Blöcke werden asynchron außerhalb der Maschine repliziert
- Maschinen können in mehreren Regionen weltweit bereitgestellt werden, damit Ausführung in der Nähe des Nutzers möglich ist
- Die Maschinen werden hinter einem Anycast-Netzwerk platziert und bieten Nutzern weltweit Einstiegspunkte mit niedriger Latenz
- Darauf aufbauend ist die Plattform so entworfen, dass bald weitere Funktionen ergänzt werden können
- Es bleibt allerdings noch viel zu bauen
- Relativ klare Punkte wie statische IPs fehlen noch
- Auch Aufgaben wie die UX für den Zugriff auf automatisch erzeugte frühere Festplatten-Snapshots sind noch offen
- Gleichzeitig kehrt man wieder zu dem Schritt zurück, Computer direkt in Rechenzentren zu racken, und überprüft dabei alle Schichten des Software-Stacks neu, einschließlich der Art der Netzwerkanbindung
- Das endgültige Ziel ist, eine Cloud zu bauen, die man tatsächlich selbst nutzen möchte
6 Kommentare
Erst dachte ich: Warum erst jetzt?
Als ich gesehen habe, dass der Autor Mitgründer von Tailscale ist, wollte ich ihn irgendwie anfeuern.
Bitte baut etwas Großartiges!
Die Preistabelle ist ziemlich verwirrend, weil dort so etwas wie 2 Kerne, 8 GB, 50 VMs steht. Ich glaube, man muss es so verstehen, dass man eine VM bekommt und darauf 50 Container laufen lassen kann.
Die Cloud ist aus gutem Grund komplex.
Ich sehe keine Funktion zum Löschen des Kontos – hat die jemand gefunden?
Es wäre schön, wenn man Dienste nur per Drag-and-drop miteinander verbinden könnte.
Hacker-News-Kommentare
Kubernetes wirkt anfangs vielleicht okay, um ein paar Webapp-Container laufen zu lassen, bläht sich aber bald unkontrollierbar auf, sobald man SDN daraufsetzt und alle möglichen Services anhängt
Je mehr man den Cluster „optimiert“ und „härtet“, desto mehr haben sich Cloud-Kosten, Ausfälle, Downtime und Debugging-Aufwand auf das 2- bis 3-Fache erhöht
Am Ende wurde diese DevOps-Trägheit abgelegt, der Cluster entfernt und Docker mit Kamal auf einer einzelnen Debian-VM mit aktivierter Firewall ausgerollt; damit waren Stabilität und Zuverlässigkeit der Infrastruktur am besten und die Kosten deutlich niedriger
Die meisten Business-Apps haben nur Hunderte bis Tausende Nutzer, daher reicht oft eine große VM, und da Clouds wie Google Hardware-Ausfälle abfangen, kann man bei Bedarf einfach nur eine zweite VM hochfahren und in Cloudflare die IP umschalten
Es ist üblich, k8s auch bei viel zu kleinem Maßstab einzusetzen, und dann ist es vermutlich von Anfang an kein Scale, der k8s überhaupt braucht
Deshalb braucht es eine höhere Schicht, die gängige Deployment-Muster vereinfacht; Knative ist ein Beispiel dafür
Lösungen, die versuchen, alle zugrunde liegenden Primitive offenzulegen, werden am Ende zwangsläufig fast so komplex wie Kubernetes selbst
Mein https://github.com/openrundev/openrun behandelt interne Webapp-Deployments für Teams deklarativ, ergänzt SAML/OAuth und RBAC und unterstützt sowohl Docker auf einer einzelnen Maschine als auch Kubernetes
Eine Denkweise, die übermäßig komplex, schwer zu debuggen und teuer ist, kann sich auf VMs genauso reproduzieren
Im Moment liegt die einzelne Debian-VM womöglich einfach außerhalb ihres Policy-Radars und hat deshalb Freiraum
Sobald sich jemand einmischt, will wahrscheinlich gleich jemand HA, Rollout/Rollback, 3 bis 5 VMs, virtuelle Netzwerk-Policies, vier Security-Scanner, zwei Log-Prozessoren, Watchdog, Netzwerk-Monitoring, mTLS und Traffic-Visibility-Tools anhängen
Mit einer zusätzlichen Maschine ist man bei Ausfällen während Upgrades oder Änderungen deutlich weniger nervös
Mein https://github.com/psviderski/uncloud ist von Kamal inspiriert und macht Multi-Machine-Setups so einfach wie eine einzelne VM; es deployed mit einem Zero-Config-WireGuard-Overlay und Standard-Docker-Compose auf mehrere VMs
Man kann ohne Orchestrator- oder Control-Plane-Komplexität mit einer Maschine anfangen und bei Bedarf später über Cloud-VMs und On-Prem hinweg skalieren
In der Produktion war es durchgehend großartig und wirkte fast so, als hätte es das Computing selbst neu definiert
Deshalb habe ich wohl einfach die Perspektive der Leute nicht verstanden, die es so sehr hassen
OP ist einer der Tailscale-Mitgründer, was den Kontext noch interessanter macht
Dass traditionelle Cloud-1.0-Firmen standardmäßig nur etwa 3000 IOPS pro VM liefern, während Laptops auf 500.000 IOPS kommen, scheint ein treffender Punkt zu sein
Die Vision ist wirklich gut und ich bin wohl genau der Zielkunde, aber ich sorge mich, dass mit wachsendem Erfolg am Ende wieder der bekannte Weg eingeschlagen wird, bei dem Umsatzdruck stärker wird als Ideale
Cloud-Preise sind oft nicht kostenbasiert und werden gerade bei Posten wie bandwidth oder NAT gateway, die erst stark steigen, wenn Kunden tief eingebunden sind, so gestaltet, dass hohe Margen möglich sind
OP dürfte diese Struktur ebenfalls kennen
Allerdings ist dieser Storage grundsätzlich ephemeral und nicht ausreichend redundant
Mit RAID1 kann man Hardware-Ausfälle reduzieren, verliert aber nutzbare NVMe-Slots, und wenn eine VM wegen RAM- oder CPU-Problemen des Hosts verschoben werden muss, gibt es dafür keinen sauberen Weg
Solche VMs muss man letztlich fast wie Bare Metal behandeln, und man braucht Redundanz auf Anwendungsebene wie Datenbank-Replikation
Bei Azure muss man davon ausgehen, dass sie VMs jederzeit migrieren und ephemerale Daten dabei löschen können, aber in OpenStack konnten wir bei Bedarf die VM herunterfahren und per lokaler Block-Level-Migration sogar die NVMe-Daten auf einen anderen Host kopieren
Trotzdem bedeutete ein Host-Crash, dass die VM ausfiel, bis der Host wieder da war; App-seitige Redundanz war also Voraussetzung
Beim 99,9-Perzentil lag Hetzner aber bei rund 5ms, DO bei etwa 18ms, und die maximale Latenz war bei Hetzner 7ms gegenüber 85ms bei DO, also ein deutlicher Unterschied
Bei sequenziellem dd lag Hetzner bei 1,9GB/s und DO bei 850MB/s
Auch preislich ist der Abstand groß: Hetzner 4 Euro, die DO-Instanz 18 Dollar
Ich hatte das geschrieben, bevor ich den ganzen Beitrag gelesen hatte, und dann hat OP genau diese beiden Punkte tatsächlich selbst angesprochen
Selbst einfache Server würden damit von lokalen Datenbanken abgehalten und so in Lock-in gedrückt
Die Vorstellung, ein Produkt koste X in der Herstellung und werde deshalb zu 1.y*X verkauft, hat mit realer Marktpreisbildung wenig zu tun
Top-down ist realistischer als bottom-up
So wie die Debatte um AI extrem polarisiert ist, scheint das auch bei Kubernetes zu sein
Ich habe über Jahre Cluster unterschiedlichster Größe betrieben, aber die Ursache eines Ausfalls war nie k8s selbst
Einmal gab es eine komplette Störung von etwa einer Stunde, und alle, die k8s nicht mochten, wollten sofort dem „verdammten k8s-System“ die Schuld geben
Tatsächlich hatte ein Service in einer bestimmten Situation blitzartig Zehntausende Ports geöffnet und sich damit selbst einen DOS zugefügt
Ich halte k8s weder für die gesamte Zukunft noch für Müll, sondern für ein gutes System, wenn man es wirklich braucht
Entweder ist die Lernkurve zu komplex, man braucht es für das eigene Problem gar nicht und klassische Deployments reichen aus, oder es ist gegenüber Bare Metal bei Kosten-/Energieeffizienz unterlegen
Meistens treten beide Punkte gemeinsam auf
Eine halbwegs neutrale oder gleichgültige Haltung wird eher selten, und US-Politik fällt einem sofort dazu ein
Ich selbst kenne mich mit k8s kaum aus und wenn ein Staff Engineer über Pods und Cluster spricht, schweift mein Blick ab, aber für unser Team passt es und es funktioniert tatsächlich
Für jemanden mit nur einem Hammer sieht alles wie ein Nagel aus, und wer eine Axt in der Hand hat, wundert sich, warum alle Holz mit dem Hammer bearbeiten wollen
Wenn die Axt sogar das passendere Werkzeug wäre, aber jemand mit dem Hammer einem trotzdem den Job wegnimmt, fällt es noch leichter, den Hammer zu hassen
Für k8s sind Best Practices für viele Use Cases einigermaßen geklärt, bei LLM weiß man oft nicht einmal, was überhaupt Best Practice ist
Ich kann dem Punkt stark zustimmen, dass man bei VMs wegen ihrer Bindung an CPU und Speicher für Zeit statt für Arbeit bezahlt
Deshalb habe ich mir einen günstigen Hetzner-Auktionsserver geholt und betreibe darauf meinen selbst hostbaren Firecracker-Orchestrator
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
Ich wollte Hardware kaufen, VMs beliebig fein darauf aufteilen und mich weder um Provisioning noch um den Lifecycle kümmern müssen
Unbenutzte VMs schreiben ihren Speicherzustand als Snapshot auf Disk und geben den gesamten RAM zurück; die Hardware gehört mir, die VMs sind disposable und im Leerlauf fast kostenlos
Besonders stark war, weit mehr als erwartet, der Effekt von memory-state snapshot: Plötzlich wird alles wiederaufnehmbar
Ich kann einen eingeloggten Chromium-Zustand snapshotten und bei Bedarf sofort Session-Klone starten; Agenten arbeiten in Sandboxes und auch docker compose für Preview-Umgebungen läuft dort
Wenn nichts läuft, ist der Server praktisch idle, und eine einzige Box für 100 Dollar im Monat erledigt das alles
Details stehen in https://shellbox.dev/blog/race-to-the-bottom.html
Die Doku ist gründlich und nützlich, aber man merkt an vielen Stellen deutlich, dass AI mitgeschrieben hat; etwas knapper wäre gut
Die Sektion „design decisions“ fand ich trotzdem besonders gut und ich habe dort auch Neues gelernt
Falls noch nicht geschehen, könnte es sich lohnen, das auch bei Show HN zu posten
Es gibt bereits massenhaft Software, die niemand benutzt; deshalb verstehe ich nicht, warum so viele darauf fixiert sind, noch mehr Code herauszupressen
Schon im App Store ist alles voll mit Software, die niemand verwendet
Die offensichtlichere Anwendung von LLMs wäre aus meiner Sicht nicht, mehr Software zu erzeugen, sondern bessere Software
Ich hoffe, der Fokus verschiebt sich weg von reiner Code-Generierung; LLMs können auf viele Arten helfen, besseren Code zu schreiben
Das Bild deterministischer Systeme, die sorgfältig gebaut, gewartet und aktualisiert werden, wird bleiben, aber AI verändert bereits, wie Nutzer mit Computern interagieren
Dadurch könnte sehr viel wegwerfartigere Software entstehen
Im Moment sind wir noch bei „Wie kann AI Ingenieuren beim Schreiben von Software helfen?“, aber ich glaube, wir bewegen uns zunehmend in Richtung „Was können Ingenieure tun, damit AI besser Software schreibt?“
Dann wird eine völlig neue Gruppe von Ingenieuren auftauchen, mit einer ganz anderen Sicht darauf, was Software ist und wie Computerinteraktion gestaltet werden sollte
Es wird wahrscheinlich sehr viel maßgeschneiderte Software geben, die nie in einem App Store landet
Dazu müsste die Nachfrage so stark steigen, dass die durch niedrigere Stückkosten bei der Softwareproduktion erzielten Einsparungen überkompensiert werden und die Gesamtausgaben steigen
Das gilt nur in Märkten mit hoher Nachfrageelastizität, also wenn die nachgefragte Menge stark auf Preisänderungen reagiert
Abgesehen von Spielen werden wir vielleicht später darauf zurückblicken, wie seltsam es war, eine einzige Software für Millionen oder Milliarden Menschen zu bauen
Menschen können dann Software erstellen, die exakt das tut, was sie wirklich wollen, statt von widersprüchlichen Prioritäten oder verzerrten Erlösmodellen gesteuert zu werden
Solche Software kann man per Definition auch als hochwertiger ansehen
Damit wurden Kosten und Umsatz auf beiden Seiten besser planbar, aber der Kern bestand darin, möglichst allgemeingültige Software zu bauen
Dadurch wurden UX oder Features, die nur für einen Teil der Nutzer wichtig sind, immer wieder gestrichen
Vibe coding und LLM-beschleunigte Entwicklung könnten das umkehren
Bald kann sich jeder Custom-Software leisten, die zu den eigenen Bedürfnissen und Vorlieben passt; statt 150.000 Salesforce-Kunden, die dasselbe CRM nutzen, könnte man sich 150.000 maßgeschneiderte CRMs vorstellen
Das Potenzial zur Ausweitung von Software ist derzeit enorm
Wenn man den Zyklus der Software-Aufblähung nicht versteht, wiederholt man dieselben Fehler immer wieder
Man beginnt mit leaner Software, dann sammeln sich Nutzerwünsche, es wird zu einem aufgeblähten Chaos, dann braucht es wieder einen kleineren Rewrite und man kehrt zu leaner Software zurück
Reboots scheitern meist oder sie treffen etwas Entscheidendes so gut, dass sie die alten Platzhirsche ernsthaft bedrohen
Die Sicht auf DevOps als reines CV-Polishing und Quelle übermäßiger Komplexität wirkt auf mich eher wie Startup-Denken
In kleinen Firmen mag eine DevOps-Person die ganze Infrastruktur tragen, aber gerade im Finanzbereich geben oft eher Plattform-Engineering-MDs die Richtung vor
Sie zerlegen Software-Ingenieure in viele kleine Gruppen und wollen, dass jedes Team sein eigenes Repo, sein eigenes Deployment und seine komplette eigene Umgebung kontrolliert; microservices geben ihnen aus ihrer Sicht genau diese Macht
Ich garantiere: Die Leute in DevOps hassen Komplexität
Sie sind diejenigen, die nachts und am Wochenende paged werden, und es beginnt fast immer mit der Annahme, es sei „ein Infrastrukturproblem“
Deployment-Logs landen zwar vollständig im Log-Aggregationssystem, aber Entwickler lösen ihre eigenen Deployment-Probleme trotzdem selten selbst anhand dieser Logs; es wird stattdessen sofort ein Incident daraus
Vielleicht sollte man Mikroservices inzwischen wirklich als vergangenen Hype betrachten
exe.dev fand ich positiv, und ich glaube definitiv, dass es Chancen für etwas gibt, das den LLM-Entwicklungsfluss glättet und zugleich die Flexibilität einer Linux-Maschine mit Root-Rechten bietet
Aber als ich den Satz las, man sei „von halb implementierten und halb durchdachten Abstraktionen immer wieder verraten worden“, musste ich ironischerweise genau daran denken, wie ich Tailscale erlebt habe
Es soll Networking vereinfachen, aber warum saugt es dann so stark am Akku, warum verändert es Firewall-Regeln so, dass sie mit anderen Tools kollidieren, und warum ist der Bug-Tracker so still, dass ich am Ende doch die Interna verstehen muss?
Daher dann auch ein „No thank you“
Der Dienst selbst sieht wirklich großartig aus
Ich will keine Router-ACLs schreiben, sondern eine Peer-to-Peer-Netzwerkschicht gestalten, und genau dort bleibt es unbefriedigend
Ich nutze einfach Hetzner
Alles, was Cloud-Firmen anbieten, ist viel zu teuer, und mein selbst betriebenes Postgres-HA mit Backups lief zehn Jahre ohne Unterbrechung und kostete trotzdem nur etwa ein Zehntel von RDS oder CloudSQL in Produktion
Ich autoskaliere Instanzen selbst anhand der in Grafana gesammelten Metriken, und auch ein webhook-basierter Autoscaler läuft sehr einfach und hat nie Probleme gemacht
Deshalb verstehe ich inzwischen kaum noch, warum ich GCP oder AWS nutzen sollte
Alle Services sind HA, und die Backups laufen täglich hervorragend
Damals war das Ziel, das möglichst flexible Dedicated-Server-Erlebnis günstig nachzubilden, und UML machte genau das möglich
Aber ich lag die gesamten 2010er hindurch komplett falsch mit meiner Annahme, dass die meisten Entwickler nicht für ein bisschen Bequemlichkeit jede Schicht ihres Stacks nutzungsabhängig abrechnen lassen würden
Ich frage mich, ob Software-Ingenieure in ihren Zwanzigern heute noch wissen, wie man mit einem bei eBay gekauften Server und Router eine Webapp-Plattform mit hohem Traffic aufbaut
Ich selbst habe auf diese Weise letztes Jahr einen Datastore mit über 50PiB gebaut und frage mich ernsthaft, wie stark solche Ansätze in mittelgroßen bis großen Projekten noch genutzt werden
Hetzner nimmt viel vom physischen Aufwand weg und liefert trotzdem fast den gesamten wirtschaftlichen Vorteil; umso merkwürdiger ist es, dass es nicht der König der Hosting-Welt ist, sondern 2021 bei nur 367 Millionen Euro Umsatz lag
Es fällt mir schwer zu glauben, dass das Know-how zum Umgang mit mehreren Dedicated Servern schon so speziell geworden ist, dass Leute solche enormen Einsparungen einfach ignorieren
Wenn man die richtigen Leute findet, kann Selbstbetrieb aber tatsächlich viel günstiger sein
Jede Minute holt cron per docker pull das neueste Image, und nur wenn es eine neue Version gibt, ersetzt docker up -d den laufenden Stand
Davor sitzt caddy für HTTPS, und so läuft das seit Jahren sehr günstig und stabil
Wirkte wie ein in Großbritannien ansässiger Anbieter mit ähnlicher Philosophie; ich habe ihn noch nicht ausprobiert, aber schon ein Konto als Kandidat für den nächsten VPS erstellt
Wenn man sich von Anfang an einen 5x schnelleren Server leisten kann, braucht man Autoscaling oft gar nicht mehr
Es gibt bereits viele Alternativen, und ich habe https://shellbox.dev gebaut
Im Gegensatz zu exe wird nur die tatsächliche Nutzung berechnet, es skaliert bis auf null, und man kann per SSH sofort eine VM starten
Es ist normales Linux, unterstützt also auch VSCode Remote und Zed Remote, und sogar Nested Virtualization ist möglich
Falls jemand investieren will: 5 Millionen Dollar würden schon reichen
Es gibt keine nach außen exponierten Ports, und alle Web-Frontends sind passwortgeschützt
Ich habe nicht vor, das zu veröffentlichen; es ist meine isolierte Entwicklungsumgebung auf einem privaten Raspberry Pi hinter dem Fernseher
Es kostet praktisch nichts
Viel Erfolg trotzdem mit dem Service
Wo genau die zugrunde liegende Infrastruktur steht und welche Sicherheitsgarantien es gibt, ist nicht klar genug, um dort Workloads anzuvertrauen