Cloud-basierte Entwicklungsumgebung aus Kiel: Gitpod

Die Idee war, eine Remote-First IDE zu entwickeln, die sowohl lokal als auch im Browser läuft und die bereits zahlreich vorhandene VS-Code-Erweiterungen voll unterstützt. Das eigentliche Produkt um Theia herum nannten die Entwickler Gitpod (gitpod.io).

Obwohl es noch heute zahlreiche Theia-Lösungen wie Eclipse Che, Stackblitz oder den Google Cloud Shell Editor gibt, entschied sich Gitpod Ende 2020, zur VS Code Plattform zu wechseln, nachdem Gamma und sein Team den Remote Support in VS Code zur Verfügung gestellt hatten, auf dem unter anderem github.dev basiert.

Da Microsoft aber beschlossen hatte, die Server-Komponente zunächst nicht unter Open Source zu stellen (das kommerzielle Github Codespaces lässt grüßen), erstellte Anton Kosyakov nach eigenen Angaben in vier Tagen eine erste Arbeitsversion des Open VSCode Servers, der im September 2021 veröffentlicht wurde.

Zwar machte Microsoft nicht einmal einen Monat später die eigene Server-Lösung ebenfalls frei verfügbar - allerdings mit einigen Einschränkungen unter anderem bezüglich der Erweiterungen, die bei Gitpod über das Portal Open VSX Registry zu beziehen sind, da der Microsoft Extension Marketplace für Microsofts eigene Produkte vorbehalten ist.

• 

Die Open VSX Registry (Bild: Kristof Zerbe)

Der Name Gitpod verrät schon einiges über die Technik hinter dem Dienst. Git steht für das System der Dateiverwaltung hinter dem Editor und pod für die Servertechnik unter dem Editor.

Der Name und die Technik dahinter

Quellcode liegt heutzutage (hoffentlich) nicht mehr nur lokal auf einer Festplatte, sondern zentral und verwaltet durch eine Quellcode-Management-Software. Der momentane Goldstandard in diesem Bereich ist das von Linus Torvalds 2005 initiierte freie Git, eine verteilte Versionsverwaltung, welche die Basis populärer Entwicklerplattformen wie Github, Gitlab oder Bitbucket darstellt.

Dazu kurz einen Schritt zurück in der Zeit: Es ist noch gar nicht so lange her, da nannten ITler eine Umgebung, auf der sie eine Server-Anwendung veröffentlichten "Maschinen", weil es dafür zunächst Hardware ("Blech") mit Prozessor, Hauptspeicher, Festplatten und dergleichen brauchte. Auf dieser wurde dann ein Betriebssystem der Wahl und darauf wiederum die besagte Anwendung installiert.

Wurde die Serveranwendung aber nur sporadisch genutzt, war die teure Hardware nicht ausgelastet, sprich: Ressourcen wurden verschwendet. Um dieses Problem zu beheben, wurde in den 70ern begonnen, an der Virtualisierung von Hardware zu arbeiten. Damit können sich mehrere logisch voneinander getrennte Systeme die Hardware teilen, um deren Auslastung zu erhöhen. In jeder der so entstehenden virtuellen Maschinen (VMs) können ein beliebiges Betriebssystem und darin die benötigten Serveranwendungen installiert und betrieben werden.

In diesem Konzept gibt es jedoch Redundanzen in Form des Betriebssystems. Will man zum Beispiel auf einem Blech fünf Linux-basierte Webserver laufen lassen, muss man dazu fünf womöglich identische Ubuntu-Installationen mitschleifen, die gewartet werden müssen.