Wie CDEs wirklich funktionieren - no bs

CDEs sind eine neue Produktkategorie. Viele neue CDE-Produkte wurden 2022 angekündigt. 2023 sind CDEs erstmals in den “Hype Cycle of Emerging Technologies” von Gartner inkludiert worden.

Das Resultat ist: Es wird sehr viel Content zum Thema CDEs geschrieben. Allerdings fokussieren sich die meisten Beiträge nur auf die Benefits. Es wird fast nie (oder nur oberflächlich) aufgegriffen, wie CDEs funktionieren. In diesem Artikel erwartet Sie ein “No-Bs-Überblick“ über die Architektur und die Funktionsweise von CDEs.

Was sind Cloud Development Environments (CDEs)

CDEs sind Arbeitsumgebungen für Softwareentwickler_innen, die alle Tools enthalten, die diese zum Arbeiten brauchen. Sie werden remote zur Verfügung gestellt – oft in der Cloud – wobei es auch möglich ist, CDEs On-Premise, also im internen Netzwerk eines Unternehmens bereitzustellen.

Wie funktionieren CDEs?

Obwohl es sich bei CDEs um eine neue Produktkategorie handelt, zeichnen sich bereits erste Standards ab, wie CDEs in der Regel aussehen.

Typischerweise funktionieren CDEs so:

Ein IDE-Thin-Client einer SSH-fähigen IDE wie VS Code oder die JetBrains-IDEs (z. B. IntelliJ) bleibt auf den Laptops der Entwickler_innen. Das bedeutet, dass die meisten CDEs nicht vollständig die Notwendigkeit lokaler Tools beseitigen oder Entwickler_innen vollständig und unabhängig vom Gerät arbeiten lassen: Normalerweise muss zumindest der IDE-Client lokal ausgeführt und so konfiguriert werden, dass er über SSH mit dem IDE-Backend der CDE verbunden ist.
Die CDE enthält eine Kopie des Code-Repositorys. Durch den Remote-Zugriff auf den Quellcode über das IDE-Backend wird die Sicherheit betreffend den Quellcode etwas verbessert, allerdings können Remote-IDEs den Quellcode immer noch lokal zwischenspeichern.
Alle anderen Werkzeuge, die für die Entwicklung benötigt werden, laufen ebenfalls in der CDE: Sprachlaufzeiten, SDKs, Linters usw. Die Benutzer_innen können konfigurieren, welche Werkzeuge sie in ihrer CDE haben möchten.
- Es gibt zwei Standards für die Konfiguration von CDEs: devfile.yml und devcontainer.json. Beide gehen davon aus, dass es sich bei der CDE um einen einzelnen Container handelt und erlauben die Angabe, welche Werkzeuge in diesem Container deployed werden sollen. Es ist auch möglich auf Skripte zu verweisen, die nach der Erstellung des Containers ausgeführt werden sollen.
- Nicht alle CDE-Produkte verwenden diese Standards. Viele haben benutzerdefinierte Konfigurationsschemata und/oder ermöglichen die Konfiguration mit anderen Tools und Standards wie Dockerfiles oder Terraform-Konfiguration.
- Andere CDE-Produkte verwenden keine Container als CDEs, sondern VMs. Diese Tools verwenden meist ein proprietäres Konfigurationsformat, oft in Kombination mit Tools wie Docker Compose.

Welche Software kann auf einer CDE laufen?

Neben den Entwicklungswerkzeugen müssen Entwickler_innen die Software, an der sie arbeiten, in ihrer Entwicklungsumgebung ausführen. CDEs unterscheiden sich in der Art der Software, die sie ausführen können:

Single-Container-CDEs sind am häufigsten. Damit können Sie jede Software ausführen, die sinnvoll in einem einzigen Container ausgeführt werden kann. Beispielsweise kann ein yarn-Projekt mit einem Webserver problemlos in einem Container laufen – für die Entwicklung eines solchen Projekts eignet sich diese Art von CDE.
Multi-Container-CDEs sind solche, die mehrere Container auf Kubernetes, OpenShift oder Docker deployen. Es wird davon ausgegangen, dass die Anwendung, an der Entwickler_innen arbeiten, aus mehreren Containern besteht. Der CDE-Container wird zusammen mit den Containern der Applikation deployed. Eine solche CDE eignet sich für Entwickler_innen, die an Kubernetes-basierten Anwendungen mit mehreren containerisierten Komponenten arbeiten.
VM-CDEs beschränken Entwickler_innen nicht auf einen Container, sondern gewähren vollen Zugriff auf eine VM. Hier können Entwickler_innen alles deployen, was sie möchten. Dies ermöglicht auch ein Deployment von Multi-Container-Anwendungen, mit dem Unterschied, dass sich die Entwicklertools direkt auf der VM befinden und eine Trennebene zwischen Entwickler_innen und der Container-Anwendung entfällt. VM-CDEs ermöglichen auch die Verwendung vorhandener Deployment- oder lokaler Build-Skripte, die eine VM-basierte Umgebung voraussetzen.

Die Wahl der CDE sollte sich nach dem Einsatz der zu entwickelnden Software in Production richten. Wenn die Software in einem einzelnen Container läuft, ist eine Single-Container-CDE die beste Wahl. Wenn die Software in Kubernetes (oder ähnlichem) läuft, sollte eine Multi-Container-CDE verwendet werden. Wenn die Software auf einer VM läuft, dann ist eine VM-CDE die beste Option.

Ein Sonderfall sind Remote Desktop CDEs. Microsoft Dev Box ist derzeit der einzige Anbieter, der Remote-Desktop-Umgebungen speziell für die Softwareentwicklung anbietet. Für die Arbeit an Desktop-Software, die eine Windows-Umgebung erfordert, oder für Fat Clients ohne Web-Frontend sind Remote-Desktop-CDEs möglicherweise die einzige Option.

Was ist der Unterschied zwischen einer CDE und einem beliebigen Container oder einer VM mit Entwickler-Tools?

Devfile.yml und devcontainer.json sind offene Standards zur Definition von (Single-Container-) Entwicklungsumgebungen. Was ist also der zusätzliche Vorteil, wenn man sich für ein CDE-Produkt entscheidet?

CDE-Produkte bieten normalerweise:

Eine Automatisierung zum Erstellen von CDEs basierend auf Konfigurationsdateien. Dies umfasst in der Regel die automatische Erstellung der Infrastruktur sowie das Deployment der CDEs selbst.
Eine Verwaltungsebene, auf der Benutzer_innen CDEs erstellen, starten, stoppen, entfernen und überwachen können – häufig mit zusätzlichen Funktionen wie beispielsweise einer CDE-Zugriffsverwaltung usw. Diese Ebene ist normalerweise als Webportal und/oder als Kommandozeile (CLI) verfügbar.
Infrastruktur, in der die CDEs laufen – zumindest für SaaS-Angebote. On-Premise-CDEs verfügen über ein klares Konzept, wo und wie CDEs und die Automatisierung für diese Infrastruktur ausgeführt werden sollen.
Templates für CDEs mit gängigen Toolstacks sowie Beispiele dafür und eine Dokumentation.

Viele CDE-Produkte bieten zusätzliche Sonderfunktionen wie die ultraschnelle CDE-Erstellung, einen automatische Prebuild von CDEs bei jedem Commit, spezielle Sicherheits- und Insight-Features oder sie sind mit anderen Produkten gebündelt, welche die Softwareentwicklung erleichtern. Diese Sonderfunktionen sind aber spezifisch je CDE-Produkt. Im Allgemeinen macht ein CDE-Produkt die Erstellung, Verwendung und Verwaltung von CDEs so einfach wie möglich.

Was sind CDEs nicht?

CDEs ersetzen nicht die CI/CD-Pipeline, die Ihre Anwendung in Production deployed und umfassende Tests durchführt. Einige der gleichen Tools können evtl. verwendet werden, wie z. B. Docker Compose oder Terraform. Der Sinn von CDEs und der dahinter stehenden Automatisierung besteht aber darin, Ihre Anwendung neben oder innerhalb von Entwicklungsumgebungen zu deployen. Am wichtigsten aber ist, dass CDEs:
- den vollständigen Quellcode im Klartext enthalten, d.h. er ist weder kompiliert noch minimiert oder verpackt.
- Entwickler_innen-Tools enthalten, die in Production nicht benötigt werden, wie bspw. Compiler, SDKs, Debugger, Betriebssystem-Dienstprogramme usw.
CDEs ersetzen keine Laptops. Entwickler_innen, die CDEs verwenden, benötigen zwar weniger leistungsfähige Laptops, die meisten CDEs setzen aber voraus, dass zumindest ein IDE-Client noch lokal läuft. Es gibt einige CDEs, die es ermöglichen, nur im Browser zu arbeiten – die IDE wird hier auch im Browser bereitgestellt. Dies wird aber nicht von allen CDEs unterstützt und die vollständige Arbeit im Browser stellt eine erhebliche Veränderung der lokalen Arbeitsweise dar.

Zusammenfassung

CDEs sind Arbeitsumgebungen für Softwareentwickler, die auf Servern laufen.
Zwar unterscheiden sich alle CDEs geringfügig voneinander, doch die gängigste CDE-Konfiguration beinhaltet die Installation eines IDE-Clients auf dem Laptop der Entwickler_innen, der sich über SSH mit einem IDE-Backend auf einer CDE verbindet. Die CDE ist entweder ein Container oder eine VM. Neben dem IDE-Backend enthält die CDE den Quellcode sowie Tools wie Sprach-Laufzeiten und SDKs, Build-Tools, Linter usw.
Die Hauptunterschiede zwischen den CDE-Produkten liegen in ihrer Kernarchitektur: Single-Container-, Multi-Container-, VM- und Remote-Desktop-CDEs sind mit verschiedenen Softwareentwicklungsprojekten kompatibel.
CDEs ersetzen keine CI/CD-Pipelines und machen auch die Laptops der Entwickler_innen nicht überflüssig.

Wenn Sie einen tieferen Einblick in die verschiedenen CDE-Produkte, ihre Funktionen und Unterschiede erhalten möchten, lesen Sie unser Whitepaper “Full list of CDE vendors (+feature comparison table)”.