Warum wir beschlossen haben, Remote Development Environments (RDEs) zu entwickeln

Remote Development Environments (RDEs) / Cloud Development Environments (CDEs) scheinen in letzter Zeit überall Thema zu sein.
Vielleicht ist es aber auch nur meine selektive Wahrnehmung. Denn vor etwa sechs Monaten, im Sommer 2022, begann ich mich ernsthaft und regelmäßig damit zu beschäftigen.

Damals hatte ich nur eine vage Vorstellung davon, was eine RDE ist. Aber auch ohne viele Details zu kennen, war für mich klar, dass RDEs die Zukunft sind. Denn ich habe mich schon lange gewundert, warum die technisch versiertesten Menschen – Softerentwickler_innen – immer noch stark von ihren Laptops abhängig sind, aber währenddessen das Ende der manuell konfigurierten Server-Infrastruktur predigen, während sie selbst weiterhin auf manuell konfigurierte, lokale Entwicklungsumgebungen bestehen.

Für mich ist offensichtlich, dass die Tage des manuell konfigurierten Entwickler-Laptops gezählt sind und sich alles in Richtung RDEs bewegt.

Diese Erkenntnis allein hat bei mir noch keine weiteren Handlungen ausgelöst: Denn schließlich sind Elektroautos die Zukunft. Und davon habe ich mir auch noch keines gekauft. Aber seitdem ist eine Menge passiert.

Hier ist die Geschichte, wie ich anfing, über RDEs als etwas nachzudenken, das wir brauchen könnten, bis zu dem Punkt an dem wir als Unternehmen beschlossen, ein RDE-Produkt zu entwickeln: Cloudomation DevStack.

Warum lokale Entwicklungsumgebungen wichtig sind

Wir sind ein Software-Startup, das 2019 gegründet wurde. Wir sind ein Team aus 8 Personen und haben eine Softwareentwicklerin und vier Softwareentwickler. Wir entwickeln eine komplexe Anwendung: die Automatisierungs- und Integrationsplattform Cloudomation, die aus mehreren containerisierten Komponenten besteht.

Unser Team führt Cloudomation lokal auf dem Laptop aus. Das ist notwendig, um Code zu erstellen und schnell Feedback zu den Änderungen zu erhalten, die am Code vorgenommen werden. Zahlreiche Iterationen werden am Code durchgeführt und lokale Instanzen mehrmals erstellt, bevor die Code-Änderungen in das zentrale Repository übertragen werden. Zu diesem Zeitpunkt sollte sich die Entwicklerin oder der Entwickler sicher sein, dass sein Code zumindest nicht den Build oder die Anwendung beschädigt.

Cloudomation nicht lokal zu entwickeln wäre so, als würde man Code blindlings schreiben – also nichts, was irgendjemand empfehlen würde. Wir haben eine zentralisierte und vollständig automatisierte CI/CD-Pipeline, die bei jedem Git-Push ausgelöst wird. Diese führt nicht nur den Build, sondern auch einen vollständigen Testsatz aus. Die neue Version wird in ein Feature-Branch-System oder direkt in die gemeinsam genutzte Entwicklungsinstanz deployed. Würde man nur die CI/CD-Pipeline für die Entwicklung verwenden, ohne ein lokales Build-System zu haben,

müsste man warten, bis die Pipeline durchlaufen worden ist, bevor man seine Änderungen sehen kann (oder weiß, ob der Build erfolgreich war oder nicht),
noch länger zu warten, wenn sich die Builds anderer Entwickler_innen in der Pipeline aneinanderreihen,
hätte man nur eingeschränkte Möglichkeiten, die Anwendung zu inspizieren, da der Code während des Produktions-Builds auf ein Minimum reduziert wird,
müsste man eine Verbindung zu einem entfernten Server über SSH herstellen, um Protokolle einzusehen und
eine lange Reihe kleinerer Unannehmlichkeiten, die es unwahrscheinlich machen, dass unsere Entwicklerin und unsere Entwickler jemals bereit wären, auf die lokale Ausführung von Cloudomation zu verzichten.

Noch wichtiger: Die Möglichkeit, Cloudomation lokal auszuführen und einen optimierten lokalen Build zu haben, der sich vom Produktions-Build unterscheidet, macht unsere Entwicklerin und unsere Entwickler sehr viel produktiver.

Das Problem: Die lokale Entwicklungsumgebung

Allerdings ist es schwierig, Cloudomation – oder jede andere komplexe Software – lokal auszuführen. Auch, wenn Cloudomation vollständig containerisiert ist – die lokale Ausführung mehrerer Docker-Container, die Verwaltung lokaler Builds und der Abhängigkeiten erweist sich als ziemlich komplex. Und die Ausführung wird immer komplexer, je umfangreicher unsere Software wird.

Wir entwickeln eine Automatisierungsplattform, weil wir von Automatisierung besessen sind. Und deshalb haben wir schon früh, als unser Team noch kleiner war, viel in die Automatisierung unserer Entwicklungsprozesse und in den Aufbau fortschrittlicher Entwicklerwerkzeuge investiert. Unser Team besteht zwar „nur“ aus fünf Personen (von denen zwei Vollzeit arbeiten), aber wir sind schon jetzt unzufrieden mit dem Zeitaufwand, der mit der manuellen Fehlersuche in den lokalen Entwicklungsumgebungen verbracht wird. Jedes Mal, wenn eine neue Person hinzukommt, wird wieder deutlich, wie mühsam es immer noch ist, eine lokale Entwicklungsumgebung einzurichten und Cloudomation lokal zu betreiben.

Darüber hinaus erzählt mein Team in zu vielen Sprint-Retrospektiven von Problemen, die sie mit ihren lokalen Entwicklungsumgebungen hatten – von Problemen mit Docker bis hin zu Problemen mit lokalen Builds. Und alles andere, was dazwischen liegt. Manchmal sind es schöne Geschichten über die Überwindung von Hindernissen und die gegenseitige Hilfe im Team. Aber manchmal enden diese Fehlerbehebungs-Geschichten nicht mit einem Witz oder Lächeln, sondern eher mit einer frustrierten Aussage wie: „Dann habe ich für heute einfach alles hingeschmissen, weil ich einfach keine Geduld mehr hatte.”

Als CEO sitze ich da und höre zu. Ich bin dazu übergegangen, diese Art der Fehlersuche als Teambuilding- oder Lernübung zu betrachten – einfach um etwas Positives daran zu finden. Denn es schmerzt mich, dass nach so viel Zeit, die wir in die Entwicklung guter Tools investiert haben, immer noch so viele Probleme ungelöst sind – Und noch immer so viel Zeit für die Fehlersuche in lokalen Entwicklungsumgebungen aufgewendet wird. Gleichzeitig wird der Ertrag der zusätzlich investierten Zeit immer geringer: Das Hinzufügen einer neuen Funktion zu unserem lokalen Build-Tool, um ein potenzielles Problem für ein bestimmtes Betriebssystem zu lösen, ist die Zeit meines Teams einfach nicht wert. Es besteht eine gute Chance, dass das gleiche Problem in unserem kleinen Team einfach nie wieder auftritt. Die traurige Wahrheit ist, dass die Bandbreite möglicher Probleme zu groß und das gesamte Ökosystem zu veränderlich ist, als dass man allen potenziellen Problemen zuvorkommen könnte.

Und so arbeiten wir weiter: Unsere Entwicklerin und unsere Entwickler verbringen Zeit mit der Fehlersuche, ich höre zu und versuche abzuschätzen, wie viel Frustration sie zu akzeptieren bereit sind und wie viel Produktivitätseinbußen ich bereit und in der Lage bin, zu tolerieren.

Ich bin keine Perfektionistin. Kein_e Unternehmer_in kann sich Perfektionismus auf Dauer leisten. Es ist völlig in Ordnung, dass wir nicht in der Lage sind, alle Probleme zu lösen und eine 100%ige Produktivität unserer Entwicklerin und unserer Entwickler zu erreichen. Aber ich habe hohe Ansprüche. Die Zeit meiner teuersten Mitarbeiterin und Mitarbeiter mit Dingen zu verschwenden, die sie nicht gerne tun und die keinen direkten Nutzen bringen, passt mir einfach nicht. Ich schätze, dass etwa 10 % der Zeit für die Fehlersuche hinsichtlich Entwicklungstools, Laptops und lokalen Cloudomation-Instanzen aufgewendet wird – also für die Fehlersuche in der lokalen Entwicklungsumgebung – sowie für das Warten auf lokale Builds und manchmal auch für das Testen von Tools. Selbst wenn 0 % nicht gehen, sind 10 % einfach zu viel.

Natürlich gibt es Versuche, dieses Problem zu lösen.

Lösungsversuche: Helfen, gehen aber nicht weit genug

In Gesprächen mit meinem Team habe ich erfahren, dass Containerisierung bereits eine große Hilfe ist. Diejenigen, die in früheren Jobs mit Nicht-Containerisierten-Anwendungen gearbeitet haben, erzählten mir, dass die Situation in diesem Fall viel schlimmer war. Unser Team sei sehr effizient. Im Vergleich zu anderen Entwicklungsteams ist der Zeitaufwand offensichtlich gering, den unser Team insgesamt für die Fehlersuche in lokalen Umgebungen aufwendet.

Einige haben erzählt, dass sie mindestens einen Tag (oder mehr) pro Woche (das sind mehr als 20 %!) damit verbringen, auf Builds zu warten, lokale Builds zu reparieren, nach Ursachen für lokale Build-Fehler zu suchen, usw.

In Gesprächen mit anderen Softwareunternehmen hörte ich viele Seufzer: Es ist also ein sehr verbreitetes Problem. Die meisten Teams haben den Status quo einfach akzeptiert. Sie haben sich mit der Frustration und Ineffizienz abgefunden. Die Erinnerung an einige der Gespräche, die ich geführt habe, schmerzt mich sehr.

Beim Versuch, den Zeitaufwand in den Griff zu bekommen, den Entwickler_innen in ihrer Entwicklungsumgebung verbringen, habe ich folgendes von meinen Gesprächspartner_innen gehört:

Der häufigste Grund ist die Standardisierung: Entwickler_innen werden gezwungen, ein bestimmtes Betriebssystem und bestimmte Tools zu verwenden. Diese sind auf Kompatibilität getestet worden. Das hilft…zumindest ein bisschen. Aber diese Standardisierung ist auch sehr schwer durchzusetzen. Sie führt zu Frustration bei den Entwicklern_innen und gleichzeitig bleiben viele Probleme noch immer ungelöst.
Containerisierung – Ein weiterer gängiger Ansatz ist die Containerisierung, die anscheinend wirklich hilft. Es bleiben aber auch hier Probleme, weil der Einsatz von Containern an sich schon komplex ist. Containerisierung kann auch sehr schwierig sein, wenn es sich um eine Software handelt, die ursprünglich nicht für den Betrieb in Containern entwickelt wurde.
Ich habe auch wahrgenommen, dass CEOs, CIOs und sogar Heads of Development viel Vertrauen in automatisierte CI/CD-Pipelines setzen. “Wenn wir die CI/CD-Pipeline eingerichtet haben, werden all diese Probleme verschwinden. Entwickler_innen werden die Applikation nicht mehr lokal ausführen müssen.” Ich habe diese oder eine ähnliche Aussage jetzt schon sehr oft gehört. Leider stimmt sie nicht. Ich empfehle natürlich vollständig automatisierte CI/CD-Pipelines. Und ich empfehle natürlich auch, sich darum zu kümmern, bevor man versucht, Probleme mit lokalen Builds und Deployments zu lösen, da diese schwieriger zu beheben sind. Aber es ist illusorisch zu denken, dass eine CI/CD-Pipeline lokale Builds obsolet macht. Nein, ganz im Gegenteil: Die CI/CD-Pipeline muss separat in Betrieb sein und muss sich von lokalen Build-Tools unterscheiden. Sie hat einen anderen – sehr wichtigen – Zweck und benötigt deshalb andere Funktionen. Eine CI/CD-Pipeline verringert deshalb nicht, sondern erhöht den Aufwand, den Sie in DevOps investieren müssen. Das bedeutet auch: Eine signifikante Qualitätssteigerung Ihrer Software. Es ist also eine lohnenswerte Investition.

Uns blieb also nur, über die Standardisierung nachzudenken. Als einziger Ansatz, den wir noch nicht ausprobiert haben, um den Zeitaufwand für Troubleshooting zu reduzieren. Wir gingen sogar so weit, unserer Entwicklerin und unseren Entwicklern die Verwendung von Windows zu verbieten, da das die meisten Probleme verursacht hat. Weiter wollten wir aber nicht gehen. Unsere Entwicklerin und unsere Entwickler sind äußerst kompetente, motivierte und intelligente Leute. Niemand hat Probleme mit der IDE oder anderen Tools, die sie selbst ausgewählt haben: Denn sie haben diese aus einem guten Grund ausgesucht. Sie haben Probleme mit den Komponenten, die wir ihnen geben: Cloudomation, das lokale Build-Tool, Docker und unser neues Frontend-Testing-Tool, das sich als Ressourcenfresser entpuppt. Die Standardisierung von anderen Komponenten würde keinen weiteren Nutzen bringen, sondern Spannung erzeugen.

Wir haben begonnen, stärkere Laptops zu kaufen, um mit diesem ressourcenfressenden Testtool fertig zu werden. Wir haben uns auch mit dem Gedanken aufgemuntert, dass stärkere Laptops zu schnellen lokalen Builds und zu einer insgesamt besseren Erfahrung führen. Es fühlt sich aber noch immer wie ein sehr grober Ansatz an, der nicht wirklich ein Problem löst, sondern nur die Symptome einer schlechten Situation reduziert.

A new idea: Remote Development Environments (RDEs)

Dann fingen wir an, über Remote Development Environments nachzudenken. Wir haben begonnen, während der Pandemie darüber zu sprechen. Uns fiel auf, wie seltsam es ist, dass immer mehr Menschen immer mehr Arbeit in der Cloud erledigen, aber Softwareentwickler_innen härtnäckig am lokalen Arbeiten festhalten. Softwareentwickler_innen gehören wahrscheinlich zu der Gruppe von Experten, die am stärksten vom Verlust ihres Laptops betroffen wären. Ich als CEO kann meine Arbeit von so gut wie jedem Gerät aus erledigen. Alles ist in der Cloud. Strategie, Marketing, Sales, Produktmanagement, Buchhaltung und Finanzen, Kommunikation, alles: Ich brauche nur einen Browser und meine Login-Daten. Mein Bruder, Co-Founder und CTO: Mach’ seinen Laptop kaputt und er wird ein oder zwei Tage brauchen, bevor er wieder produktiv Software entwickeln kann. Und er ist bei weitem der Geschickteste und Schnellste, wenn es darum geht, seine Tools zu konfigurieren.

Warum ist das so?

Weil es Tools, die es Entwickler_innen möglich machen remote zu arbeiten, einfach noch nicht gibt. Es gibt zwar einige Versuche und Ansätze, aber nichts, was in puncto Funktionalität und Komfort an das lokale Arbeiten heranreicht.

Es hat mindestens ein Jahrzehnt gedauert, bis cloudbasierte Office-Tools nach ihrem ersten Aufkommen zu Beginn der 2010er Jahre so ausgereift waren, dass ein breites Spektrum von Menschen bereit und in der Lage war, sie als Hauptarbeitsmittel zu nutzen. Auch, wenn die Pandemie den Cloud-Plattformen einen ordentlichen Schub gegeben hat – die Mehrheit der Menschen weigert sich immer noch, sich von ihren lokal installierten PowerPoint, Excel- und Word-Programmen loszusagen. Warum sollte es also bei Entwickler_innen anders sein? Sie sind anspruchsvoll und verrichten komplexe Arbeit, die komplexe Tools erfordert.

Sie sind als Gruppe auch viel kleiner als “allgemeine Büroangestellte”. Das heißt: Finanzielle Anreize für die Entwicklung von Produkten wie Office365 oder Google Workspace waren viel größer, als die Entwicklung geeigneter Remote-Tools für Softwareentwickler_innen.

Aber das ändert sich jetzt. Erstens, weil es nicht nur mehr Softwareentwickler_innen gibt, sondern auch, weil der von ihnen produzierten Output-Anteil noch schneller steigt als ihre Anzahl. Der Mangel an qualifizierten Softwareentwickler_innen bedeutet, dass ihre Zeit immer wertvoller wird.

Es hat lange gedauert, bis wir den Zusammenhang gesehen haben: Zwischen der Möglichkeit, Remote zu Arbeiten – dem Hauptmerkmal von Remote Development Environments (RDEs), so wie wir sie anfangs sahen – und dem Potenzial von RDEs, den Zeit- und Arbeitsaufwand für die Wartung von lokalen Entwicklungsumgebungen signifikant zu reduzieren.

Die richtige Trennlinie zu finden, was lokal gespeichert wird und was remote verfügbar ist, könnte wirklich ein realistischer Lösungsansatz sein, um die Probleme, die Entwickler_innen mit lokalen Entwicklungsumgebungen haben, drastisch zu reduzieren. Gleichzeitig könnte das gleiche Maß an Kontrolle und Komfort beibehalten werden, an das sie sich mit ihren lokalen Tools gewöhnt haben (wenn sie funktionieren).

Der Gedanke hat uns nicht losgelassen. Mit der Zeit erkannten wir immer mehr Vorteile: Die Möglichkeit, wirklich leistungsfähige RDEs bereitzustellen, um Builds und Tests zu beschleunigen, die zusätzlich runterskaliert oder gelöscht werden können, wenn sich nicht gebraucht werden. Entwickler_innen bräuchten keine leistungsstarken Laptops, sie bräuchten nicht einmal richtige Laptops. Sie könnten sogar ein Tablet verwenden, wenn sie wollten. Sie könnten Windows nutzen, wenn sie damit glücklich sind. Sie müssten lokal keinen Source Code speichern. Sie könnten Tests durchführen, ohne Testdaten auf lokalen Rechnern zu haben. Wir nutzen keine PII-Daten für Tests, aber für andere Applikationen könnte das eine große Erleichterung sein. Branches zu wechseln würde wirklich einfach werden – oder besser gesagt, überflüssig werden. Man könnte einfach eine RDE für einen anderen Branch oder eine andere Version aufsetzen und parallel arbeiten. Was für eine Erleichterung.

Es war schwer, in der anfänglichen Aufregung einen klaren Kopf zu bewahren. Natürlich: RDEs werden nicht alle unsere Probleme lösen. Und natürlich würde die erste Iteration einer RDE höchstwahrscheinlich eine schlechtere UX bieten, als lokale Umgebungen. Aber wir hatten das Gefühl, dass wir endlich einen Weg nach vorne gefunden hatten. Einen Weg, der die Hauptursachen für all die Zeitverschwendung bei der Fehlersuche in der lokalen Entwicklungsumgebung beseitigt.

Entscheidung: Cloudomation RDEs als neues Produkt

Wir starten unser erstes RDE-Experiment. Und zwar jetzt, Mitte Februar 2023. Mit Cloudomation verfügen wir bereits über das Grundgerüst: Ein Automatisierungstool, mit dem wir benutzerdefinierte Umgebungen mit dem benötigten Tooling für Entwickler_innen bereitstellen können. Es gibt einige zusätzliche Komponenten, die wir benötigen, aber für ein Bare-Bone-MVP wären wir innerhalb weniger Tage startklar.

Für Softwareentwickler_innen sind Probleme mit lokalen Entwicklungsumgebungen allgegenwärtig. Das ist mir nach all den Gesprächen über RDEs, die ich in den letzten Monaten mit einer Reihe von Leuten geführt habe, klar geworden. Mir ist auch klar geworden, dass die am Markt verfügbaren Tools alle limitiert sind und sich in einem sehr frühen Stadium befinden. Das Interesse daran scheint aber gerade zu explodieren, denn viele große Unternehmen haben für Ende 2022 die Einführung von RDE-Produkten angekündigt (z. B. Gitpod, Gitlab).

Daher haben wir uns entschlossen, RDEs nicht nur als Ergänzung zu unseren internen Werkzeugen zu entwickeln, sondern als ein Produkt, dass auch von anderen genutzt werden kann. Ich möchte Sie dazu einladen, uns auf dieser Reise zu begleiten und ein_e erste_r Testnutzer_in zu werden. Wie bei unserem Produkt Cloudomation wollen wir unser RDE-Produkt auf Grundlage von realen Anforderungen und dem Feedback von Benutzer_innen (einschließlich uns selbst) entwickeln.

Wenn Sie eine_r dieser Benutzer_in sein und ein RDE-Produkt nach Ihren Spezifikation entwickelt haben wollen, schreiben Sie mir eine E-Mail an margot@cloudomation.com oder kontaktieren Sie mich über LinkedIn unter https://www.linkedin.com/in/margot-mückstein/. Ich freue mich!