Das Ende des Localhost-Zeitalters
(dx.tips)- In Zukunft wird die gesamte Entwicklung nicht mehr auf dem Localhost, sondern in der „Cloud“ stattfinden, und der Laptop wird nur noch ein Client sein
- Wenn man eine Wunschliste für Entwickler in den 2030er Jahren aufschreibt:
- günstiges Gigabit-Internet (5G/Mesh WiFi)
- eine günstige Entwicklungsmaschine mit Akku-Laufzeit von mehreren Tagen
- Apps werden unabhängig von ihrer Größe in wenigen Sekunden gebaut, und Test- sowie Staging-Umgebungen sind in Echtzeit live, sobald man mit dem Tippen beginnt
- die persönliche Entwicklungsumgebung reist mit mir, unabhängig davon, welches Gerät ich benutze
- die umgebungsbezogenen Abhängigkeiten einer App (von HTTPS-Zertifikaten bis zu gesandboxeten Forks der Produktions-DB – also alles) stehen sofort allen Teammitgliedern zur Verfügung, die an einem Feature arbeiten wollen. Ohne Dokumentation und ohne Runbook
- von der Idee bis zur Bereitstellung für Kunden in nur einer Woche möglich (mit Low-Code-Buildern und Backends-as-a-Service)
- vom MVP zum Unicorn in nur wenigen Wochen skalierbar: mit Serverless und Plattformen wie dem „neuen Heroku“. Authentifizierung/Zahlungen/DB/Kommunikation werden über World-Class-SaaS abgewickelt
- Das meiste davon setzt voraus, dass es nicht auf dem Localhost, sondern in der „Cloud“ läuft
Wenn der Browser das Betriebssystem auf „eine Ansammlung schlecht debuggter Gerätetreiber“ reduziert hat,
dann reduziert die Cloud die Entwicklungsmaschine auf „eine Ansammlung schlecht verwalteter Environment-Mocks“
"Future is Just Not Evenly Distributed"
- Große Unternehmen, die massiv in die Produktivität von Entwicklern investiert haben, arbeiten bereits in der Cloud
- Google Cider: Googles Web-IDE. Integriert das riesige Piper-Dateisystem sowie Code-Review/Build/Testing. Es ist nicht nötig, den Code auf die lokale Maschine herunterzuladen
- FB On-Demand: Provisioniert Umgebungen „On-Demand“, damit Feature-Previews in Echtzeit vollständiger möglich sind als lokal. Bei FB gibt es „lokale Entwicklung“ selbst nicht mehr
- Etsy: Die gesamte Entwicklung findet in Cloud-VMs statt. „Da VSCode per SSH auf die VM zugreift, habe ich noch nie Code außerhalb der VM ausgecheckt“
- Tesla: Stellte die Entwicklung des Fahrzeug-OS von lokal auf Cloud um (zuvor stellte man Entwicklern teure Desktops für Builds bereit)
- Palantir: Wechselte zu Remote Ephemeral Workspaces mit Coder (Remote-Entwicklungsumgebungs-SaaS) und EKS
- Shopify: Die meisten Entwickler wechselten zu einer Cloud-Entwicklungsumgebung namens Spin (leichtgewichtige VM, die auf xhyve läuft)
- GitHub: Verlagerte den Großteil der eigenen Entwicklung auf Codespaces
- Da das große Unternehmen sind, stellt sich natürlich die Frage: „Ist das auch für kleinere Unternehmen geeignet?“
→ Die Antwort lautet: „Wahrscheinlich ja, aber möglicherweise nicht in der heutigen Form“
→ Vieles davon erfordert erhebliche interne Investitionen und war möglich, weil bestehende interne Infrastruktur genutzt wurde
→ Aber je stärker diese Technologien produktisiert werden und je mehr Gemeinsamkeiten zwischen Kundengruppen entdeckt werden, desto weiter werden sie sich verbreiten - Die Produktisierung von Preview-Umgebungen gibt es bereits
→ Netlifys frühe Innovation bestand darin, Frontend-Projekte deploybar zu machen, damit man sie als Preview ansehen kann
→ Fast alle Dokumentationsseiten nutzen inzwischen irgendeine Form von Deploy-Preview-System, und bei Jamstack-Apps lässt sich das auch im Release-Prozess einsetzen
Jobs to Be Done of Localhost
- Was bei lokaler Entwicklung passiert, steht inzwischen unter Beschuss
- Code remote bearbeiten und ausführen: GitHub Codespaces, Replit, Code.com, CodeSandbax, GitPod
- Auf einem Remote-Server ausführen, aber den Code lokal bearbeiten: VSCode + Azure VM/Amazon Workspace, Jetbrains Fleet, Okteto Sync
- Code in einem leichtgewichtigen JS-Container im Browser bearbeiten und ausführen: Stackblitz
- Code remote ausführen: Bret.dev
- Staging: Planetscale Branches, Stripe Test mode keys, Railway Ephemeral Environments, Okteto environments, Coherence workspaces
Pushback: It's Still Not Good Enough
- Es ist noch nicht gut genug, also sollte man noch nicht zu begeistert sein
- Damit dieses „Localhost-Töten“ gelingt, muss Provisioning selbst überflüssig werden
- Das ist sicher von Person zu Person verschieden, aber für mich sind selbst 10 Sekunden zu lang, um mit einer Preview meines geschriebenen Codes zu starten
- Mit Netlify Drop dauert das Deployment einer Frontend-Preview 1 Sekunde, aber die Netlify CLI braucht 10 Sekunden
- Trotzdem nutze ich weiterhin gewohnheitsmäßig eine Localhost-Entwicklungsumgebung: weil mein Iterationszyklus im Millisekundenbereich liegt
- Dieses Latenzproblem ähnelt der Anwendung von Moores Gesetz auf Cloud-Infrastruktur
- Wenn es heute noch nicht ausreicht, sollte man in 5 Jahren noch einmal nachsehen
10 Kommentare
Es scheint wirklich so zu sein, dass die Rolle des Laptops auf ein Terminal plus eine Maschine für Meetings reduziert wurde. Ein ARM-basiertes Chromebook mit mehr als 20 Stunden Akkulaufzeit scheint zum idealen Laptop zu werden.
Das wäre großartig, wenn es nur so funktionieren würde, aber bei den Unternehmen, die derzeit virtuelle Cloud-Umgebungen eingeführt haben, wird Entwicklern meist eine Umgebung mit 8 GB Arbeitsspeicher und 4 CPUs aufgezwungen (mit viel Bitten und Betteln bekommt man gerade so 16 GB). Die Kluft zwischen Realität und Ideal ist einfach viel zu groß.
GitPod unterstützt auch das Bearbeiten im lokalen VSCode. Wenn man es ausprobiert, ist es wirklich nahtlos (abgesehen davon, dass die Eingabe im Terminal leicht verzögert ist und das Aufklappen von Ordnern etwas träge wirkt, gibt es beim Nutzungserlebnis praktisch keinen Unterschied).
Erstaunlich, dass sogar Tencent das macht. https://zdnet.co.kr/view/?no=20220620003628
Kommt jetzt die Ära der Workstations ...
Tablets werden dann wohl noch mehr Aufmerksamkeit bekommen als heute.
Ich verlagere persönliche Projekte nach Möglichkeit auf Cloud-basierte Entwicklung, aber nur mit einer IDE scheint es Grenzen zu geben. Es wäre gut, wenn sich auch die Latenz verbessern würde, und ich glaube, man braucht entweder eine Umgebung, in der sich alle einfachen Tools, die man nutzt, frei verwenden lassen, oder irgendeinen ergänzenden Ansatz. Es wäre wirklich großartig, wenn man unabhängig von Windows, Mac, Linux oder VR-Geräten kontinuierlich mit derselben Entwicklungserfahrung arbeiten könnte. Ähnlich wie bei heutigen Xbox-Spielen gibt es sowohl Vorteile der lokalen Umgebung als auch Vorteile der Cloud, sodass es schwer ist, sofort nur eine einzige Methode zu verfolgen, aber am Ende wird nicht sowieso alles in die Cloud gehen?
Persönlich denke ich, dass die Richtung eher dahin gehen könnte, unter Berücksichtigung von Latenzproblemen usw. eine containerisierte Full-Stack-Umgebung auf dem lokalen Rechner zu starten, ähnlich wie bei WebContainers, und die Ergebnisse dann in der Cloud zu speichern und zu übernehmen. Von den im Artikel genannten Beispielen wäre das wohl etwas wie StackBlitz.
Ich würde es weniger als das Ende von localhost sehen, sondern eher als die Wiederkehr des Thin Client...
Es beginnt mit Bequemlichkeit und läuft später vielleicht wegen der Sicherheit darauf hinaus...
Es ist keine vollständige Übersetzung, sondern eine Zusammenfassung, daher lohnt sich auch ein Blick auf das Original.
Am Ende des Textes hieß es in der Zusammenfassung der Reaktionen, dass „auf Reddit / HN alle es hassen, wenn es so wird“ …
Ich kann mir durchaus vorstellen, dass das eine realistische Zukunft ist. Natürlich wird es auf dem Weg dorthin eine Mischform aus „lokaler Code-Bearbeitung + Ausführung auf einer Remote-VM“ geben, aber
wenn in der Cloud eine Latenz auf dem Niveau lokaler Code-Bearbeitung einigermaßen garantiert werden kann, werden sich die meisten Unternehmen meiner Meinung nach dafür entscheiden.
Mir geht es genauso, aber auf Reddit und HN gibt es wohl viele Leute, die „meine Daten auf meinem Gerät“ lieben. Ich möchte die Kontrolle über meine Daten auch nicht aus der Hand geben, deshalb nutze ich Cloud-IDEs eher nur gelegentlich, wenn ich Beispielcode schreibe.