Transformieren Sie den Workflow Ihres Entwicklungsteams: Warum CDEs die Backend-Entwicklung zu einem Kinderspiel machen

Kürzlich habe ich mit einem Senior Developer über Cloud Development Environments (CDEs) gesprochen. Er arbeitet in einem großen Softwareunternehmen das viel Geld in die Hand nimmt, um die Developer Experience zu verbessern: Es gibt eigens dafür verantwortliche Teams, die sicherstellen, dass Entwickler_innen alle Tools zur Verfügung haben die sie brauchen und sich auf das Schreiben von Code fokussieren können…und sich nicht auf mit dem Fixen von Build-Pipelines oder dem Troubleshooting von lokalen Deployments herumschlagen müssen.

Mein Gegenüber war ein Backend-Developer. Die Software, an der er arbeitet, besteht aus mehreren Dutzend individuellen Komponenten. Viele unterschiedliche Teams arbeiten an diesen Komponenten. Viele davon sind Frontend-Teams, die an verschiedenen Webapps arbeiten. Diese Webapps stellen Benutzer_innen unterschiedliche Funktionalitäten zur Verfügung.

Nach einer halben Stunde merkte er plötzlich, dass er schon einmal von CDEs gehört hat: In seinem Unternehmen gab es eine Initiative, um CDEs einzuführen. Ein dafür verantwortliches Team wurde gegründet, das sich um die Einführung und das Managen der CDEs kümmern soll.

Der Grund, warum er nicht früher daran gedacht hat war, dass das Produkt nicht für seine Kolleginnen und Kollegen bzw. ihn war. Sie arbeiteten am Backend. Die CDEs wurden allerdings nur für das Frontend-Team ausgerollt.

Er schilderte mir, wie das momentane Setup der Frontend-Teams aussieht: Die Webapp wird lokal deployed. Mit vorgefertigten Configs wird sich zu Backend-Services in einem Shared-Dev-Cluster verbunden. Das hörte sich für mich schon wie ein sehr komfortables Setup an. Er erzählte mir aber, dass manche Frontend-Entwickler_innen damit Probleme haben und sich nicht damit herumschlagen wollen, zu welchem Backend-Cluster eine Verbindung hergestellt werden soll und wie das funktioniert. Deshalb führen sie CDEs für Frontend-Teams ein, die dann nur mehr auf einen Button klicken müssen, um die CDE zu deployen.

Aber warum war es nichts für seine Kollegen und ihn?

Weil Backend-Services nicht in diesen CDEs ausgeführt werden konnten. Sie waren nur für “leichtgewichtige Sachen”, sagte er. Die CDEs würden wahrscheinlich nicht mehr funktionieren, wenn er versuchen würde, seinen Stack zu darauf deployen.

Ich bin mir nicht sicher, ob die CDEs nicht mehr funktionieren, oder eine sehr schlechte Erfahrung bieten würden. Jedenfalls machte es mich neugierig. Zwei Fragen beschäftigten mich nach dem Gespräch:

Was ist der Mehrwert von CDEs für Frontend-Entwickler_innen?
Wie würde ein CDE für die Backend-Entwicklung aussehen?

In diesem Beitrag beantworte ich diese Fragen.

CDEs: Was ist der Mehrwert für Frontend-Entwickler_innen?

Frontend-Entwickler_innen, die an einer Multi-Komponenten- und komplexen Software arbeiten, müssen sich mit vielen Abhängigkeiten herumschlagen. Um zu funktionieren, braucht jedes Frontend Daten von einem Backend. Das heißt, der Zugriff auf Backend-Komponenten muss möglich sein, um Änderungen zu validieren.

Frontend-Entwickler_innen müssen also wissen, wie man Backend-Services deployed und darauf zugreift. Abhängig davon, wie automatisiert das Ganz ist, kann das ein signifikanter Zeitfresser sein. Zusätzlich ist das Wissen erforderlich, um Backend-Komponenten zu deployen und eine Frontend-Komponente so zu konfigurieren, dass diese mit den Backend-Komponenten korrekt kommuniziert.

Mit einer CDE sollte das direkt möglich sein: Entwickler_innen sollte es möglich sein, zu spezifizieren, an welchen Frontend-Komponenten sie arbeiten wollen. Die CDE sollte so konfiguriert sein, dass sie automatisch die dafür notwendigen Backend-Komponenten in der richtigen Version deployed oder sich zu bestehenden Komponenten in einem Shared-Dev-Cluster verbindet.

Der Mehrwert von CDEs für Frontend-Entwickler_innen ist deshalb signifikant: Das Wissen, wie Backend-Services deployed und wie diese ausgeführt werden, fällt weg. Berücksichtigt man, dass dieses Wissen auch eine geringe Relevanz für Frontend-Entwickler_innen hat – sie entwickeln keine besseren Frontends, wenn sie beispielsweise wissen, wie sie die Software in Kubernetes-Pods deployen – ist das ein großer Mehrwert. Aber dazu benötigt es CDEs, die auch das Backend ausführen können.

Der größte Benefit in der Nutzung von CDEs würde also sein, dass Backend-Services automatisch deployed werden.

Ob die Frontend-Komponente(n) noch lokal auf dem Laptop der Frontend-Entwickler_innen deployed werden oder nicht, würde eigentlich keinen großen Unterschied machen. Der Grund dafür:

Eine einzelne Frontend-Komponente ist in der Regel nicht sehr ressourcenintensiv und kann problemlos mit der CPU und dem Arbeitsspeicher auf dem Laptop von Entwickler_innen betrieben werden.
Das Deployment von (Web-)Frontend-Komponenten ist in der Regel viel weniger komplex als das Deployment von Backend-Komponenten, da es sich in der Regel nur um eine einzige Komponente mit einem einzigen Tech-Stack handelt, der oft gut automatisiert ist. Frontend-Entwickler_innen sind meist in der glücklichen Lage, ihre Komponente mit einem einfachen „npm (oder yarn) run build“-Befehl deployen zu können.

Infolgedessen ist der Aufwand für das lokale Deployment einzelner Frontend-Komponenten in der Regel gering.

Was Frontend-Entwickler_innen also am meisten brauchen, ist nicht eine CDE, in der sie ihre Frontend-Komponente ausführen können, sondern etwas, dass den Aufwand für das Deployment des Backends reduziert. Eine CDE, die die Frontend-Komponente ausführt, ist ein Nice-To-Have.

Eine Möglichkeit, um das zu erreichen, ist ein Setup, das einer meiner Kollegen erwähnt hat: Deployment Clusters, die Backend-Services ausführen, zu denen sich Frontend-Entwickler_innen verbinden. In dieser dreiteiligen Serie von Blogbeiträgen nehme ich dieses Setup genauer unter die Lupe.

Mit einem Setup wie diesem würde sich der Mehrwert von CDEs für Frontend-Entwickler_innen verringern. Frontend-Komponenten müssten nicht mehr lokal deployed werden und, was noch wichtiger ist, auch nicht mehr mit entfernten Backend-Diensten verbunden werden. Aber das Hauptproblem – das lokale Deployment von Backend-Diensten – würde bereits durch die Verwendung von Remote-Backend-Diensten beseitigt werden.

Ein solches Setup aufzusetzen kann allerdings ein hoher Aufwand sein. Es hat auch ein paar Anforderungen an die Software, die entwickelt wird (Backend-Services müssen gemeinsam genutzt werden können). Eine Alternative sind CDEs, die das Backend und das Frontend deployen können. Das würde eine CDE sein, die auch von Backend-Entwickler_innen genutzt werden könnte.

Wie würde eine CDE für die Backend-Entwicklung aussehen?

Backend-Entwickler_innen stehen vor den selben Herausforderungen wie Frontend-Entwickler_innen, wenn es darum geht, Backend-Komponenten lokal auszuführen:

Backend-Komponenten sind oft in hohem Maße voneinander abhängig, so dass einzelne Komponenten nicht separat eingesetzt werden können. Oft gibt es eine Mindestanzahl von Komponenten, die gleichzeitig laufen müssen, damit eine der Komponenten ordnungsgemäß funktioniert.
Backend-Komponenten haben oft einen höheren Ressourcenbedarf als Frontend-Komponenten. Insbesondere wenn mehrere Backend-Komponenten lokal ausgeführt werden, kann dies die Laptops von Entwickler_innen schnell auslasten.
Das Backend-Deployment ist in der Regel wesentlich komplexer als das Frontend-Deployment, da das Backend oft
- aus mehreren Komponenten besteht,
- eine oder mehrere Datenbanken benötigt,
- verschiedene Technologien (Sprachen, Frameworks, Compilern …) innerhalb desselben Backends nutzt,
- eine viel breitere Palette von Technologien verwenden als Frontends (die immer auf html / css / js hinauslaufen), was zu einer Vielzahl von Deployment-Tools mit unterschiedlichem Reifegrad führt.
In diesem Zusammenhang kommt es häufig vor, dass Backend-Komponenten individuelle Deployment-Anforderungen haben, die für eine bestimmte Anwendung einzigartig sind.

Aber Backend-Entwickler_innen müssen natürlich mit dem Backend arbeiten können. Sie müssen in der Lage sein, das Backend zu deployen, wo sie vollen Zugriff auf die Backend-Komponenten, ihre Logs und ihre APIs haben.

Das bedeutet, dass ein Remote-Entwicklungscluster das Problem des lokalen Deployments für Backend-Entwickler_innen nicht lösen kann. Sie müssen zumindest die Komponente(n), an denen sie arbeiten, immer noch lokal deployen. Log und API-Zugang sind nicht die einzigen Gründe dafür: Wenn Änderungen an Komponenten vorgenommen werden, könnten diese in einem gemeinsam genutzten Entwicklungs-Cluster nicht durchgeführt werden, ohne die Arbeit aller anderen Entwickler_innen zu stören.

Um für die Backend-Entwicklung nützlich zu sein, müsste eine CDE daher:

Das Deployment mehrerer Komponenten ermöglichen,
Ausreichend Rechenleistung, idealerweise hochgradig anpassbare Rechenleistung zur Verfügung stellen, um den Betrieb von Heavy-Duty-Backend-Komponenten oder einer großen Anzahl von Backend-Komponenten zu unterstützen.
Ermöglichung einer hochgradig anpassbare Deployment-Automatisierung, um komplexe und individuelle Backend-Deployments durchzuführen,
Zugriff auf die CDE und die dort ausgeführten Backend-Komponenten.

Betrachtet man die Arbeitsweise von Backend-Entwickler_innen, so wären dies die Mindestanforderungen, die ein CDE erfüllen müsste, um nützlich zu sein.

Ein CDE, die diese Anforderungen erfüllt, würde große Vorteile mit sich bringen: Backend-Entwickler_innen hätten ausreichend Rechenressourcen und vollen Zugriff auf die Komponenten, ohne sich um komplexe lokale Deployments kümmern zu müssen.

Darüber hinaus könnte so eine CDE sowohl von Backend- als auch von Frontend-Entwicklerinnen und -Entwicklern genutzt werden. Problemlos könnten Frontend-Komponenten verwendet werden und den größten Pain Point sowohl für Frontend- als auch für Backend-Entwickler beseitigen: das Deployment komplexer Backends.

Zusammenfassung

Entwickler_innen, die an komplexer, aus mehreren Komponenten bestehender oder anderweitiger Heavy-Duty-Software arbeiten, tun sich oft schwer mit dem lokalen Deployment komplexer Backends.
Aber sowohl Frontend- als auch Backend-Entwickler_innen benötigen (zumindest Teile) des Backends, um ihre Arbeit zu erledigen.
Wenn die Software an der sie arbeiten dies unterstützt, können Frontend-Entwickler_innen auf das lokale Deployment des Backends verzichten, indem sie ihr lokal eingesetztes Frontend mit einem Remote-Backend verbinden (siehe den entsprechenden Blogbeitrag)
Backend-Entwickler_innen benötigen aber direkten Zugriff auf das Backend und können die Komponente, an der sie arbeiten, in der Regel auch nicht gemeinsam nutzen, da sie aktiv Änderungen an dieser Komponente vornehmen.
Eine CDE, die das Deployment komplexer Backends ermöglicht und den Entwicklerinnen und Entwicklern vollen Zugriff auf die CDE und die darauf laufenden Komponenten gewährt, würde große Vorteile bieten, da Backend-Entwickler_innen nicht mehr gezwungen wären, Komponenten lokal zu deployen.
Eine solche CDE könnte auch für das Frontend genutzt werden, da Frontend-Entwickler_innen ebenfalls sehr stark unter der Notwendigkeit leiden, komplexe Backends zu deployen. Frontend-Komponenten könnten auch in der CDE deployed werden.

Und Sie haben es sich wahrscheinlich schon gedacht: Unsere CDE-Plattform Cloudomation DevStack macht genau das. DevStack gibt Entwickler_innen standardmäßig vollen Zugriff auf die CDEs, ermöglicht das Deployment von mehreren Komponenten (oder ein paar Heavy-Duty-Komponenten) und ist sowohl in Bezug auf die Deployment-Logik, als auch auf die verfügbaren Rechenressourcen in hohem Maße anpassbar.

Zusätzlich entwickelten wir unsere CDE-Plattform mit dem Ziel, der lokalen Entwicklung so nahe wie möglich zu kommen. Die Umstellung auf eine CDE sollte reibungslos sein und Ihre bestehenden Arbeitsabläufe so wenig wie möglich geändert werden müssen.

Im Zuge unserer Produktentwicklung sprechen wir mit vielen Entwickler_innen. Und wir hören zu. Wenn Sie eine Entwicklerin oder Entwickler sind und für eine halbe Stunde Zeit für ein Interview haben, lassen Sie es uns bitte wissen. Wir würden uns über Ihren Input und Ihre Expertenmeinung sehr freuen.