Cloud-Entwicklungsumgebungen machen glücklich

Autor: Kevin Duss

Aller Anfang ist (unnötig) schwer

Meine Hände zittern. Ist das der Kaffee oder sind es meine Nerven? Ich habe wässrige Augen. Sind das die Pollen oder stehe ich vor einem emotionalen Zusammenbruch? Ich brauche eine Zigi. Dann fällt mir ein: Ich rauche gar nicht. Seit einer Ewigkeit versuche ich, meine lokale Entwicklungsumgebung im neuen Projekt einzurichten. Ein Projekt, bei dem ich als Senior ins Boot geholt wurde. Und jetzt schaffe ich es nicht einmal, die Applikation zu kompilieren. Nach dem dritten erfolglosen «clear cache and restart» meines Editors verliere ich die Hoffnung, jemals mein erstes Umsetzungsticket angehen zu können. Gibt es keinen einfacheren Weg meine Entwicklungsumgebung aufzubauen, als eine veraltete Anleitung manuell durchzuklicken? Ich wische mir die Tränen aus dem Gesicht und mache mich auf die Suche nach zeitgemässen Alternativen.

Eine neue Hoffnung: Cloud-Entwicklungsumgebungen

Bei meiner Suche stolpere ich über GitHubs Produkt Codespaces. Codespaces stellt Entwicklungsumgebungen über virtuelle Maschinen in der Cloud bereit. Container Images dienen hierbei als Templates für die Konfiguration der Umgebungen. Im Selbsttest mit 800 Mitarbeitenden konnte GitHub mit Codespaces die durchschnittliche Onboarding-Zeit von 45 Minuten auf 1 Minute reduzieren. Anstelle von manuellen Konfigurationen tritt ein Knopfdruck, mit dem eine Entwicklungsumgebung automatisch zur Verfügung gestellt wird. Codespaces ist nicht das einzige Produkt in diesem Umfeld. Jeder Cloud-Anbieter mit Rang und Namen hat eine eigene Lösung für Cloud-Entwicklungsumgebungen. Bei Azure ist es Dev Box, bei AWS ist es Cloud9 und bei Google ist es Cloud Workstations (Preview). Im Vergleich zu Codespaces sind diese Lösungen auf Unternehmen ausgerichtet und nicht auf individuelle Entwickler:innen. Meine ursprüngliche Verzweiflung verwandelt sich mehr und mehr in Neugier.

5 Vorteile und 5 Gefahren

Die Vorteile von Entwicklungsumgebungen in der Cloud gehen weit über Effizienzgewinne beim Projekt-Onboarding hinaus. Nachfolgend meine Top 5:

1. Skalierbarkeit: Cloud-Entwicklungsumgebungen können leicht auf die Anforderungen meines Projekts skalieren, ohne dass ich meine eigene Hardware aufstocken muss. Ich muss also nicht mehr einen überdimensionalen 5-Kilo-Entwicklungsnotebook durch die Gegend schleppen.
2. Zugänglichkeit: Ich kann von überall auf der Welt und von jedem Gerät mit einem Browser auf meine Entwicklungsumgebung zugreifen, solange eine Internetverbindung besteht.
3. Einheitlichkeit: Meine Entwicklungsumgebung ist weitgehend identisch mit denen meiner Mitentwickler:innen sowie den Test- und Prod-Umgebungen. Dieser Umstand wirkt dem “it works on my machine” Phänomen entgegen. Es gibt schliesslich kaum etwas Nervenaufreibenderes als einen Bug zu fixen, der lokal nicht reproduzierbar ist.
4. Zusammenarbeit: Beim Coden unterstützen Kommentarfunktionen und Live-Editing das Pair Programming. Beim Reviewen von Code kann ich mühelos einen Pull Request in einem eigenen Entwicklungscontainer auschecken und laufen lassen.
5. Verwaltung: Bestehendes Wissen zur Verwaltung von Containern, zu Build Pipelines und zu DevOps im Allgemeinen kann ich auf Entwicklungsumgebungen übertragen. So ist das automatisierte Ausliefern von Features und Security Patches an Entwickler:innen möglich. Das macht das Leben nicht nur einfacher, sondern auch sicherer. Denn die Software kommt in einem Container verpackt und muss nicht direkt auf Entwicklungsgeräten installiert werden.

Aus meiner Neugier wird nach und nach Begeisterung. Viele der genannten Punkte erinnern an Vorteile, die das Deployment von containerisierten Applikationen in der Cloud mit sich bringt. Entsprechend gibt es aber auch Gefahren, die Cloud-Entwicklungsumgebungen mit Cloud-Applikationen teilen:

1. Internetabhängigkeit: Ohne oder mit einer instabilen Verbindung zum Internet kann ich mit Cloud-Entwicklungsumgebungen nicht oder nur schlecht arbeiten.
2. Kosten: Bei einer lokalen Entwicklungsumgebungen fallen Kosten einmalig beim Kauf des Notebooks an. Anbieter von Cloud-Entwicklungsumgebungen verrechnen Kosten hingegen nutzenbasiert. Dadurch sind anfallende Kosten schwieriger planbar (Stichwort FinOps).
3. Sicherheit und Datenschutz: Mein Code lebt in der Cloud, sprich auf fremden Servern. Dort ist er abgelegt und dort verarbeitet er empfindliche Daten. Ich muss mich mit (Cloud) Security auskennen und wissen, welche Datenschutzstandards mein Cloud-Anbieter unterstützt.
4. Vendor Lock-in: Der Klassiker unter den Gefahren der Cloud. Indem ich Entwicklungsumgebungen zu einem Cloud-Anbieter auslagere, mache ich mich von ihm abhängig.
5. Anpassbarkeit: Einheitliche Entwicklungsumgebungen bringen klare Vorteile mit sich (siehe oben). Gleichzeitig schränken sie mich in der individuellen Anpassbarkeit meiner Umgebungen ein.

Die ersten vier Gefahren sind nicht neu für Unternehmen, die bereits Services aus der Cloud beziehen. Für sie ist der Schritt Richtung Cloud-Entwicklungsumgebungen kleiner als für Cloud-unerprobte Unternehmen. Gleichzeitig sind für sie die Vorteile grösser, da sie Synergien zwischen den Cloud-Services nutzen können.
 

Das Beste aus zwei Welten

In Cloud-Entwicklungsumgebungen kann ich Code sowohl direkt im Browser bearbeiten als auch mit einem lokalen Editor, wie Visual Studio Code (VS Code) oder JetBrains Gateway. Letzteres verbindet das Beste aus zwei Welten. Der Container in der leistungsstarken Cloud führt meinen Code aus. Der leichtgewichtige lokale Editor inklusive Terminal sorgt für ein flüssiges und personalisiertes Entwicklungserlebnis. Das folgende Diagramm zeigt das Zusammenspiel zwischen dem lokalen Editor und dem remote Entwicklungscontainer in der Cloud.
 

Containerisierte Entwicklungsumgebungen

So weit so gut. Tatsache ist jedoch, dass die Umsetzung in meinem neuen Projekt (noch) nicht in Cloud-Entwicklungsumgebungen passiert. Ich kann dennoch von den Vorteilen von Dev Containern (Entwicklungscontainern) profitieren. Hierfür tausche ich die virtuelle Maschine beim Cloud-Anbieter in der obigen Grafik mit einer lokalen Docker-Installation aus. Die VS Code Extension «Dev Containers» erlaubt es nämlich, Code in lokalen Docker-Containern zu schreiben und auszuführen. Um einen Dev Container für mein Projekt zu konfigurieren, erstelle ich die Datei .devcontainer/devcontainer.json im Root des Repositorys. Darin enthalten sind unter anderem folgende Angaben:

• Das Base Image und Port Forwards für den Dev Container.
• Commands, die der Container nach seinem Aufstarten ausführt. Das ist nützlich für die Installation von Dependencies.
• Hilfreiche Extensions für das Projekt, wie Linters und Debuggers.

Die Extension Dev Containers macht mit diesen Konfigurationen den Container Build und verbindet mein VS Code danach automatisch mit dem Dev Container. GitHub Codespaces nutzt Konfigurationen via devcontainer.json ebenfalls, um Cloud-Entwicklungsumgebungen bereitzustellen. JetBrains hat noch keine Lösung, die mit VS Code Dev Containers vergleichbar ist.
Einige Nachteile von Cloud-Entwicklungsumgebungen fallen bei lokalen Dev Containern weg. So sind Dev Container beispielsweise nicht von einer konstanten Internetverbindung abhängig. Gleichzeitig gehen aber auch Vorteile von Cloud-Entwicklungsumgebungen verloren. Dazu gehören die Skalierbarkeit und Zugänglichkeit (siehe 5 Vorteile und 5 Gefahren).

Ein Ende mit Aussicht

Am Ende des Tages bin ich nicht um das Einrichten einer lokalen Entwicklungsumgebung gekommen. Ich habe jedoch dafür gesorgt, dass meine Nachfolger:innen es mir nicht gleichtun müssen. Sie brauchen nur Docker und können mit Dev Containers ihre Entwicklungsumgebung auf Knopfdruck hochfahren.

Generell gilt: Wer den Schritt in die Cloud bereits gewagt hat, hat sich implizit schon mit vielen der Gefahren von Cloud-Entwicklungsumgebungen befasst. Wer noch nicht bereit für den Schritt in die Cloud ist, kann von lokalen Dev Containern profitieren. So oder so lohnt sich die Auseinandersetzung mit cloudbasierten und containerisierten Entwicklungsumgebungen. Denn sie führen zu Effizienzgewinnen und mehr Komfort beim Entwickeln. Und das wiederum führt zum Wichtigsten von allem: Glückliche Entwickler:innen.