Wo CDEs einen Nutzen bringen (und wo nicht)

In einigen Ecken des Internets sind Cloud Development Environments (CDEs) in letzter Zeit in aller Munde. Gartner hat das bemerkt und CDEs im Hype Cycle of Emerging Technologies aufgenommen. Was sind CDEs? Alexander T. Williams von thenewstack schreibt dazu: „Cloud-Entwicklungsumgebungen, auch als CDEs bekannt, gewinnen schnell an Zugkraft als die nächste Stufe der Programmierproduktivität. Diese Plattformen decken den größten Teil der Entwickler_innen-Erfahrung ab, von den frühesten Phasen der Code-Erstellung bis zum Deployment der fertigen Anwendungen.“

Wie es bei Hypes oft der Fall ist, wurde viel über die allgemeinen Vorteile der Verwendung von CDEs geschrieben:

Steigerung der Produktivität von Entwicklern_innen durch Verringerung des Zeit- und Arbeitsaufwands für die Einrichtung und Wartung ihrer Entwicklungsumgebungen sowie durch Bereitstellung ausreichender Computerressourcen, damit sie die Software, an der sie arbeiten, als Teil ihrer Entwicklungsumgebung ausführen können.
Erhöhung der Sicherheit des Quellcodes durch Entfernung des Quellcodes von den lokalen Workstations.
Verkürzung der Einarbeitungszeit für interne und externe Entwickler_innen durch die Bereitstellung standardisierter Umgebungen mit nur einem Klick.

Soweit so gut. Das sind sehr oft genannte und beschriebene Benefits.

Aber wann bringen CDEs tatsächlich einen Nutzen?

Um einen Nutzen zu bringen, müssen CDEs die Komplexität reduzieren

CDE-Anbieter wollen, dass Benutzer_innen ihr Produkt so schnell und einfach wie möglich einsetzen können.

Einem Kunden zu sagen, dass es einige Tage oder sogar Wochen dauern wird, Automatisierungen und Konfigurationen zu schreiben, bevor er ein CDE-Produkt überhaupt nutzen und bewerten kann, ist ein No-Go: Die meisten Unternehmen würden sich nicht darauf einlassen.

Daher haben CDE-Anbieter einen starken Anreiz, sich auf Software zu konzentrieren, die relativ einfach zu erstellen und einzusetzen ist. Für solche Software kann die Verwendung einer CDE schnell zu guten Ergebnissen führen, was den Verkauf erheblich erleichtert.

Bei Cloudomation arbeiten wir zum Beispiel seit Februar 2023 an unserem CDE-Produkt DevStack. Als ich Daten über andere CDE-Produkte sammelte, fiel mir auf, dass die meisten Anbieter davon ausgehen, dass der Build der Software, an der in der CDE gearbeitet wird, in einer einzigen Konfigurationsdatei ausgedrückt werden kann – oder höchstens in einer Kombination aus z. B. einer Docker-Compose-Datei, die auf Dockerdateien verweist. Das Problem: Für viele Arten von Software ist das nicht möglich. Es gibt eine Reihenfolge für das Deployment und die Abhängigkeiten zwischen Komponenten, die nicht in diesen Konfigurationsdateien ausgedrückt werden können.

Alles Erkenntnisse der Recherche können Sie in dem Whitepaper „Full list of CDE vendors (+ feature comparison table)“ nachlesen.

Es gibt also immer benutzerdefinierte Skripte, die Teil des Build-Prozesses sind. Diese Skripte können nicht ohne weiteres in einen Standard gezwängt werden, da sie per Definition einzigartig für eine bestimmte Software sind. Sie werden erstellt, um genau die Teile der Logik auszudrücken, die für einen Build erforderlich sind und mit den bestehenden Standards nicht ausgedrückt werden können.

Es ist verständlich, dass viele CDE-Anbieter einfach sagen: Nun, unsere CDEs sind für diese Art von Software einfach nicht geeignet. Sie konzentrieren sich stattdessen auf die Software, die mit einzelnen Konfigurationsdateien und in einem einzigen Container deployed werden können.

Wenn Sie aber eine Software mit einem einfachen Build haben, der in einer einzigen Konfigurationsdatei ausgedrückt und der in einem einzigen Container ausgeführt werden kann, ist die Komplexität des Deployments und des lokalen Betriebs dieser Software auf den Workstations der Entwickler_innen gering.

Entwickler_innen haben kein Problem damit, einen Build lokal auszuführen, wenn er in einer einzigen, standardmäßigen Konfigurationsdatei ausgedrückt werden kann.

Entwickler_innen haben kein Problem mit den Rechenressourcen auf ihren lokalen Workstations, wenn ihre Software so leichtgewichtig ist, dass sie in einem einzigen Container ausgeführt werden kann.

Paradoxerweise konzentrieren sich die meisten CDE-Produkte also genau auf die Art von Entwicklern_innen, deren Entwicklungsumgebung bereits eine geringe Komplexität aufweist und die daher am wenigsten von der Verwendung eines CDE-Produkts profitieren werden. Die Unternehmen, die am meisten von der Verwendung eines CDE-Produkts profitieren, sind diejenigen, die eine hohe Komplexität bei der Erstellung und dem Deployment aufweisen.

Dies sind zum Beispiel Unternehmen, deren Produkt aus vielen Microservices besteht. Entwickler_innen können das Produkt dann nur schwer lokal deployen, weil die Komplexität der Abhängigkeiten zwischen den einzelnen Komponenten hoch ist. Zusätzlich erfordert die lokale Ausführung vieler Komponenten viel Rechenleistung, was oft mehr ist, als Laptops bewältigen können.

Mit CDEs würden Entwickler_innen sowohl von der mentalen Belastung befreit, die mit dem Erlernen des lokalen Deployments ihrer Software und der Wartung lokaler Builds verbunden ist, als auch von den hohen Rechenanforderungen auf ihren Workstations, die mit den lokalen Deployments einhergehen.

Es benötigt Mühe, um CDEs mühelos zu machen

Es ist aber schwierig, komplexe Builds so zu automatisieren, dass sie mit einem Mausklick ausgeführt werden können. Die Umstellung komplexer Builds auf eine CDE kann bedeuten, dass einige Teile bestehender Build-Skripte überarbeitet und Teile automatisiert werden müssen, die bisher noch nicht automatisiert wurden. Oft gibt es gute Gründe, warum einige Schritte des Builds noch nicht automatisiert wurden: Entweder ist es schwierig, sie durchzuführen, oder sie ändern sich ständig, so dass die Automatisierung nicht Schritt halten kann. In beiden Fällen ist es eine Herausforderung, komplexe Builds für die Arbeit mit CDEs zu automatisieren.

Aber ein großer Teil des Aufwands und der Schmerzen, die einherkommen würden, wenn man auf CDEs wechselt, werden bereits jeden Tag von Entwicklern_innen empfunden, die komplexe Builds lokal verwalten müssen. Die Investition in eine saubere Automatisierung des lokalen Builds und die Verlagerung dieser Komplexität von den Entwicklern_innen weg würde enorme Vorteile bringen. (Kosten, Belastungen auf allen Ebenen des Unternehmens)

Ohne Fleiß kein Preis

Kurz gesagt bedeutet dies, dass der größte Nutzen von CDEs genau den Unternehmen zugute kommt, denen die Umstellung auf CDEs am schwersten fällt.

Es gibt keine Magie

Der eigentliche Vorteil von CDEs besteht darin, dass sie es ermöglichen, die Komplexität des Builds und das Deployment einer Software von den einzelnen Entwicklern_innen weg zu verlagern.

Der Aufwand für die Umstellung auf ein CDE besteht darin, das Deployment einer Entwicklungsumgebung einmal zu automatisieren, einschließlich des lokalen Builds, und sie dann den Entwicklern_innen zur Verfügung zu stellen. Je komplexer und je weniger automatisiert ein lokaler Build derzeit ist, desto höher ist der Aufwand für die Umstellung auf eine CDE und desto höher ist der Nutzen bei der Umstellung auf eine CDE.

Daher sollte meiner Meinung nach der Schwerpunkt eines CDE-Produkts folgendes sein:

So flexibel wie möglich sein, um die Automatisierung komplexer Builds zu ermöglichen.
Die Verwendung bestehender Build-Skripte so weit wie möglich unterstützen – dies beinhaltet die Bereitstellung verschiedener Deployment-Modi (z.B. in einen Kubernetes-Cluster, auf eine VM, serverlos …), die mit bestehenden Skripten kompatibel sind, und
die einfache Nutzung für einzelne Entwickler_innen, die sich nicht mehr um die Komplexität des Builds kümmern müssen.

Während die meisten CDE-Produkte den dritten Punkt erfüllen, ist der erste und zweite Punkt einer, den nur einige CDE-Anbieter langsam zu verstehen beginnen.

Der Grund dafür liegt jedoch nicht bei den Anbietern selbst, sondern bei den Erwartungen der Kunden. Auch wenn wir alle wissen, dass es keine Magie gibt, erwarten wir sie doch oft. Als Verbraucher sind wir oft faul und wollen nicht viel Aufwand betreiben, um ein Produkt zu verstehen. Wenn ich es mir nicht in drei Sätzen erklären lassen kann, ist die Wahrscheinlichkeit hoch, dass ich es nicht kaufe. Schlimmer noch: Wenn der Anbieter mir sagt, dass es zumindest am Anfang schwierig sein wird, es zu benutzen, ist es noch unwahrscheinlicher, dass ich es kaufe.

Schwierige Probleme sind schwer zu lösen

Die Wahrheit ist aber, dass schwierige Probleme schwer zu lösen sind. Das Gleiche gilt für einen hohen Schmerz innerhalb von Entwicklungsprozessen: Wenn diese Prozesse einfach zu lösen wären, hätten Sie diese bereits gelöst.

Ein CDE-Produkt muss Ihnen deshalb den Weg ebnen, das Problem zu lösen, auch wenn es schwierig zu lösen ist.

Das ist die Magie, die CDEs bieten. Sie besteht darin, dass CDEs es möglich machen, das schwierige Problem komplexer Builds und Deployments zu lösen. Und zwar nachhaltig und auf eine Weise, die die Komplexität für Entwickler_innen langfristig reduziert.