Lokale VM vs. Cloud-VM für Entwicklung
Ein praxisnaher Vergleich zwischen lokaler und cloudbasierter Entwicklungs-VM, basierend auf realen Erfahrungen beim Wechsel eines VSCode-Remote-SSH-Workflows von VMware zu Google Cloud.
Als ich mit dem Aufbau meines Startups begonnen habe, war eine der ersten Infrastrukturentscheidungen, wo meine Entwicklungsumgebung eigentlich laufen soll.
Dafür gibt es im Wesentlichen zwei naheliegende Optionen:
- eine lokale Entwicklungsmaschine betreiben
- eine cloudbasierte Entwicklungsmaschine betreiben
Am Anfang dachte ich, dass die lokale Variante automatisch die einfachere Lösung wäre. In der Praxis war meine Erfahrung aber eine andere.
Dieser Artikel beschreibt meinen Wechsel von einer lokalen VM zu einer Cloud-VM und warum ich am Ende bei einer normalen virtuellen Maschine auf Google Cloud gelandet bin.
Der Startpunkt: eine lokale Entwicklungs-VM
Mein erstes Setup war eine lokale virtuelle Maschine unter VMware Workstation Pro. Seit VMware für den privaten Einsatz kostenlos geworden ist und sich leicht herunterladen lässt, wirkt das zunächst wie eine attraktive Option für Entwicklung.
Die VM war so konfiguriert:
- OS: Debian 13
- RAM: 8 GB
- CPU: 2 vCPUs
- Hypervisor: VMware Workstation Pro
Mein Workflow sah so aus:
Laptop (VSCode)
|
| Remote Development (SSH)
v
Linux-Entwicklungsserver
Ich nutze VSCode Remote Development, damit mein Laptop sauber bleibt und alle Tools, Abhängigkeiten und Projekteinrichtungen auf der Entwicklungsmaschine liegen. Unabhängig davon, ob die Maschine lokal oder in der Cloud läuft, halte ich diesen Workflow weiterhin für sehr praktisch.
Wo die lokale VM an Grenzen gestoßen ist
Obwohl der Codebestand noch relativ klein war, fühlte sich die lokale VM überraschend langsam an.
Besonders deutlich war das bei IDE-Erweiterungen, vor allem bei KI-gestützten Tools wie Codex oder Amazon Q. Typische Probleme waren:
- langsame Codeanalyse
- trägere Reaktionszeiten von Erweiterungen
- spürbare Verzögerungen bei Tool-Interaktionen
- insgesamt ein eher zähes Systemverhalten
Obwohl die VM 8 GB RAM hatte, wirkte das Setup gefühlt etwa doppelt so langsam wie die Cloud-VMs, die ich getestet habe. Zusätzlich wurden auch andere Anwendungen auf meinem Laptop langsamer, was die tägliche Arbeit insgesamt unangenehmer gemacht hat.
An diesem Punkt war klar, dass eine lokale Entwicklungsumgebung für meinen Workflow nicht die beste Wahl ist.
Entwicklung in die Google Cloud verlagern
Da mein Startup ohnehin Google Cloud nutzt, war der nächste Schritt naheliegend: die Entwicklungsumgebung ebenfalls dorthin zu verlagern.
Ich habe eine Debian-basierte VM mit folgender Konfiguration erstellt:
- Maschinentyp:
e2-standard-4 - CPU: 4 vCPUs
- Arbeitsspeicher: 16 GB
- OS: Debian
Um Kosten zu sparen, habe ich zunächst Spot-Instanzen verwendet.
Die Region war praktisch kaum entscheidend
Da Spot-Instanzen von freier Kapazität abhängen, habe ich mehrere Zonen getestet:
us-central1-aus-central1-cus-central1-f
In der Praxis war die Performance zwischen diesen Zonen für diese Art von Entwicklungs-Workload sehr ähnlich.
Die Cloud-VM war sofort spürbar schneller
Der Umzug auf eine Cloud-VM hat die Entwicklungsgeschwindigkeit unmittelbar verbessert.
Die Unterschiede waren klar spürbar:
- schnellere Reaktionszeiten der IDE
- schnellere Ausführung von Plugins
- schnellere Codeanalyse
- insgesamt flüssigeres Arbeiten
Wenn die Maschine die meiste Zeit lief, lagen die Kosten grob bei etwa 50 US-Dollar pro Monat. Für den Performancegewinn erschien mir das angemessen.
Warum Spot-Instanzen für Entwicklung nicht gut gepasst haben
Spot-Instanzen haben einen grundlegenden Nachteil: Sie können jederzeit beendet werden, wenn der Cloud-Anbieter die Kapazität anderweitig benötigt.
In der Praxis hatte ich ungefähr drei bis vier Unterbrechungen pro Tag bei einem normalen Arbeitstag von acht bis zehn Stunden.
Die VM ließ sich meistens direkt wieder starten, wurde aber gelegentlich kurz danach erneut beendet. Genau diese Unvorhersehbarkeit wollte ich in meinem Entwicklungsworkflow eigentlich vermeiden.
Dynamisches DNS hat geholfen, aber die Reibung nicht beseitigt
Damit ich nach jedem Neustart nicht die IP-Adresse in VSCode anpassen musste, habe ich ein dynamisches DNS-Setup verwendet.
Dadurch konnte ich mich per Hostname statt per Roh-IP verbinden. Das funktionierte grundsätzlich gut, brachte aber eine weitere kleine Verzögerung mit sich: Nach einem Neustart brauchten die DNS-Änderungen noch etwas Zeit zur Verbreitung. In meiner Erfahrung dauerte die Wiederverbindung oft noch ein bis zwei Minuten.
Für sich genommen ist das kein großes Problem, aber zusammen mit wiederkehrenden Spot-Unterbrechungen entstand daraus unnötige Reibung im Arbeitsalltag.
Der Wechsel auf eine Standard-VM hat das Hauptproblem gelöst
Nach einigen Monaten mit Spot-Instanzen bin ich auf eine normale Standard-VM gewechselt. Die Maschinenkonfiguration blieb gleich:
- 4 vCPUs
- 16 GB RAM
- Debian
Wenn sie durchgehend läuft, kostet eine Standard-VM grob etwa 100 US-Dollar pro Monat. Dafür war die Arbeitsumgebung sofort stabiler, weil die Unterbrechungen vollständig verschwunden sind.
Kostenkontrolle mit automatischem Shutdown
Damit die Kosten trotzdem im Rahmen bleiben, habe ich ein einfaches Skript für automatisches Abschalten bei Inaktivität ergänzt. Die VM fährt herunter, wenn:
- die CPU-Auslastung sehr niedrig ist
- kaum Netzwerkverkehr stattfindet
- keine SSH-Sitzungen aktiv sind
Dadurch läuft die Maschine nur dann, wenn ich sie tatsächlich benutze.
Praktisch hat mir das die beste Kombination geliefert:
- keine Entwicklungsunterbrechungen
- gute Performance
- ein sauberer lokaler Rechner
- Kosten, die näher an der tatsächlichen Nutzung liegen
Das finale Setup
Mein aktueller Workflow sieht so aus:
Laptop (VSCode)
|
| Remote Development (SSH)
v
GCP Standard-VM (Debian)
Dieses Setup bietet mir:
- eine stabile Entwicklungsumgebung
- konstante Performance
- keine Unterbrechungen durch Kapazitätsrücknahmen
- einen aufgeräumteren persönlichen Laptop
Fazit
Die wichtigste Erkenntnis aus diesem Versuch war eigentlich recht einfach: Lokale VMs können bequem sein, sind aber nicht automatisch die beste Lösung für tägliche Entwicklungsarbeit.
Für meinen Workflow galt:
- eine lokale VM war leicht zu starten, fühlte sich aber ressourcenbegrenzt an
- eine Cloud-VM bot bessere Performance, allerdings zu zusätzlichen Kosten
- Spot-Instanzen klangen gut, waren für interaktive Entwicklung aber zu störanfällig
- eine Standard-VM mit automatischem Shutdown war am Ende der beste Kompromiss
Wenn dein Entwicklungssetup stark von Remote-Tooling, KI-gestützten IDE-Funktionen oder einer konstant reaktionsschnellen Linux-Umgebung abhängt, kann eine normale Cloud-VM langfristig deutlich besser passen als eine lokale virtuelle Maschine.