Die Zukunft der IDEs – aus Sicht eines „Java-EE-Entwicklers“

Bei unseren Kunden und auch bei codecentric dreht sich alles um den besten und schnellsten Weg, die richtige Software zu entwickeln – und das natürlich in hoher Qualität. Von daher bin ich auch ein fleißiger Leser des „State of DevOps“-Report (hier zum Download verfügbar ), der immer ganz gut widerspiegelt, welche Praktiken Teams einsetzen, die in hoher Frequenz und hoher Qualität ausliefern. Bisher nie unmittelbar Thema in den Reports war die IDE – wie gehen hoch produktive Teams mit dem „Ausrollen“ einer IDE um? Ich kenne verschiedene Möglichkeiten: vom standardisierten ZIP-File bis hin zu integriert im automatisierten Device-Management. Oft sind es bei Kunden durchaus größere Projekte, die das Ausrollen einer IDE automatisieren, da oft auch neue/moderne Hardware („Entwicklerrechner“) damit einhergehen. Aber es ist schon etwas her, seit ich das letzte Mal richtig in einem Kundenprojekt programmiert habe. Ich habe mir öfter während des lokalen Builds einen Kaffee holen können …

Und dann lese ich diese Aussage von Gartner:

By 2025, 30% of large enterprises will use browser-based IDEs to streamline development workflows and enable better manageability.“

Natürlich habe ich den Trend wahrgenommen, auch die IDEs aus einer Cloud heraus anzubieten – gerade, wenn es um reine Cloud-Workloads geht, die man entwickelt (z. B. Serverless). Eine IDE, die vollständig im Browser funktioniert, benötigt keine Installation mehr – auch etwaige Entwickler-Testumgebungen etc. sollten nicht mehr installiert und konfiguriert werden müssen.

Aber was mich überrascht hat, ist die Geschwindigkeit der Verbreitung, die hier prognostiziert wird – wenn ich bedenke, was Kunden da machen müssen, um die Entwicklungsumgebungen umzustellen. Daher wollte ich mir Browser-basierte IDEs einmal genauer ansehen und die Vor- und Nachteile beleuchten.

Vorteile lokaler IDEs

• Aus Sicht eines Java-Enterprise-Entwicklers, wie ich einer war, ist eine lokale IDE erst einmal super. Dafür gab es mehrere Gründe:
  Auch in standardisierten Umgebungen gab es immer genug Möglichkeiten, die lokale Umgebung für sich anzupassen. Durch stärkere Trennung von Entwicklung und Build-Prozess wurde es sogar möglich, verschiedene IDEs zu nutzen.
• Da der erste Test eigentlich immer auf dem eigenen Rechner ausgeführt wurde, erlangte man viel Wissen über die Infrastruktur. Dies vereinfachte oft die Kommunikation mit dem Betrieb im Fall von auftretenden Fehlern. Insbesondere dann, wenn schlanke Application Server auf den lokalen Rechnern auch die schwergewichtigen Application Server in Produktion verdrängt hatten.
• Man brauchte immer einen gut ausgestatteten Rechner, was man als Techie natürlich grundsätzlich begrüßt hat. Für die Developer-Experience schon ein positiver Punkt.
• Die Komplexität einer lokalen Umgebung machte natürlich auch Spaß. Und man konnte alles kontrollieren. Oft hatte man auch bei Kunden Admin-Rechte auf dem Entwicklerrechner.
• Wenn der lokale Build länger dauerte konnte, man nicht nur Kaffee holen, sondern hatte auch das Gefühl, etwas geschafft zu haben. Bei komplexeren Projekten dauerte es länger … und Komplexität macht Spaß.
  Man konnte viel offline entwickeln (während der berühmten Bahnfahrt), war also nicht immer auf Netzwerk angewiesen.

Vorteile Cloud-basierter IDEs

Ich denke, auch heute noch kann man das nachvollziehen. Aber was spricht eigentlich für einen Browser-basierten Ansatz? Als Entwickler hätte man erstmal keinen Grund, die Kontrolle über seine IDE und seinen Entwicklerrechner zu verlieren. Und bin ich dann wirklich schneller in der Softwareentwicklung?

Es sind andere Punkte, die uns auch mit der IDE in die Cloud treiben wollen:

• Cloud Workloads: Die Workloads verschieben sich weiterhin in die Cloud – und das schneller als in den letzten Jahren. Es werden dann auch immer mehr echte Cloud-Anwendungen entstehen, nicht nur Cloud als Host von Kubernetes-Containern. Parallel werden schon viele Build-Prozesse in die Cloud verlagert (oder sind es schon). Diese Trends machen dann natürlich eine lokale IDE irgendwann immer komplexer; oder der Anteil, der wirklich lokal läuft, reduziert sich dramatisch. Dann hat eine IDE in der Cloud irgendwann entscheidende Vorteile.
• Remote Work: Wir alle in der IT haben auf ein Remote-Modell umgestellt (oder umstellen müssen) – d. h. Entwicklungsteams sitzen nicht immer zusammen, nicht mehr im selben, geschützten Netzwerk. Das ändert die Anforderungen an die eingesetzten Rechner, aber macht auch die Entwicklungsinfrastruktur wieder komplizierter – z. B. bei Einrichtung von VPN-Verbindungen ins lokale Netz. Gleichzeitig ist gerade der Bedarf an Softwareentwicklung überall sehr hoch, d. h. Teams werden erweitert, neue Mitglieder kommen an Bord und dies dann auch verteilt. Manchmal werden Lösungen geschaffen, die alles andere als ideal für eine positive Developer Experience sind, z. B. wenn eine IDE über virtuelle Maschinen bereitgestellt wird. Zusammenarbeitsmodelle in den Entwicklungsteams (z. B. Pair Programming) könnten noch besser unterstützt werden. Warum nicht mal unterwegs vom iPad aus noch eine Kleinigkeit korrigieren?
• Compliance: Die Datenschutz- und Security-Anforderungen an einen Entwicklerrechner sind hoch, gerade in regulierten Branchen (z. B. Banken, Versicherungen). Es besteht auch oft Netzwerkzugriff auf kritische Netzwerk-Bereiche. Reagiert wird manchmal damit, dass dedizierte „Entwickler -Laptops“ für die Remote-Arbeit ausgegeben werden, damit man vollständige Kontrolle über den Laptop hat (Virusprogramme, Netzwerkzugänge, Verschlüsselung, etc.). Im Grunde wollen aber Softwareentwickler*innen ihre eingesetzte Hardware selber bestimmen – eigentlich möchte man ja auch nicht externe Entwickler*innen mit Rechnern ausstatten, da dies noch zusätzliche Projektkosten sind. Mit Browser-basierten IDEs könnte man diese Probleme völlig anders adressieren – alles ist in der Cloud, auch die Testsysteme. Compliance-Anforderungen ließen sich einmalig lösen und Entwicklungsteams leichter skalieren.
• Ramp-up: Die Ramp-up-Aufwände für neue Teammitglieder lassen sich reduzieren, ebenso werden Updates an den Entwicklungsumgebungen einfacher. Dies spart Zeit und hilft, Geld einzusparen.

Einschränkungen Browser-basierter IDEs

Natürlich gibt es auch Punkte, die die Verlagerung der IDE in die Cloud verlangsamen – bzw. wo auch noch kritisch hinterfragt werden muss:

• Connectivity: Man braucht halt grundsätzlich immer eine gute und stabile Netzwerkverbindung. In Kombination mit dem Trend zu mehr Remote Work ist es dann wirklich abhängig von der Connectivity, ob und wie gut man arbeiten kann. Dem entgegen steht natürlich, dass sich die Connectivity stetig bessert – und dass man auch mit lokaler IDE kaum noch wirklich lange offline arbeiten kann. Anwendungen sind zu komplex geworden, so dass fast immer Schnittstellen gebraucht werden. Auch das Commit-Verhalten hat sich glücklicherweise geändert – man fühlt sich schon unwohl, wenn man nicht mehrfach am Tag etwas committen kann.
  Es kann aber auch sein, dass man mit einer IDE im Browser weniger Datenvolumen erzeugt als mit einer lokalen IDE. Heute lädt man Docker-Images, JAR-Files, andere Abhängigkeiten auf seinen Rechner … Da kommt schon was zusammen.
• Compliance: War das nicht einer der Treiber? Ja, aber in Europa gilt die DSGVO – die kann hier sehr bremsend wirken auf den Trend zur Browser-basierten IDE. An den Ansatz, die IDE im eigenen Rechenzentrum zu hosten (Private Cloud), glaube ich nicht – das wird dann doch dauerhaft zu teuer.
• Emotional: Es könnte für viele Entwickler*innen ein Schritt sein, den sie nicht gehen möchten. Im Browser programmieren – wirklich? Dies könnte Widerstände erzeugen, die es zu überwinden gilt.

Jetzt fragt ihr euch: Von welchen IDEs spricht Rainer da eigentlich? Daher mal im Folgenden ein paar Beispiele. Grundsätzlich muss man genau hinschauen, was die jeweilige Umgebung auch leisten kann und auch möchte – einige sind auf bestimmte Anwendungsfälle optimiert und haben nicht den Anspruch, eine lokale IDE komplett zu ersetzen. Der Überblick hier ist nicht vollständig – es geht nur darum, ein Gefühl für verschiedene Ansätze zu entwickeln.

Eclipse Che

„Run your favorite IDE on Kubernetes“ – der Claim auf der Webpage erklärt auch schon den Ansatz von Eclipse Che :
Browser-basierter Remote-Zugriff auf die präferierte IDE. Momentan direkt unterstützt werden die Jetbrains IDE (basierend auf Jetbrains Projector), Visual Studio Code und Eclipse Theia. Eclipse CHE bringt daher keine eigene IDE mit, sondern kümmert sich primär um das ganze Handling einer kompletten Entwicklungsumgebung.
Die Entwicklungsumgebung insgesamt wird über ein „devfile“ beschrieben, auf dessen Basis die gesamte Umgebung automatisiert zur Verfügung gestellt wird.
Es gibt direkt als SaaS-Umgebungen nutzbare Eclipse-Che-Umgebungen (z. B. von Red Hat), aber man kann Eclipse Che auch auf dem eigenen Kubernetes-Cluster installieren und betreiben.

Eclipse Che ist damit schon eine sehr mächtige und recht individuell konfigurierbare Plattform. Man könnte sogar verschiedene IDEs mixen oder auch leicht IDEs wechseln.

GitHub Codespaces

Komplette Entwicklungsumgebungen basierend auf Visual Studio Code werden über Codespaces zur Verfügung gestellt – der komplette Funktionsumfang von Visual Studio Code steht hierbei zur Verfügung. Die Entwicklungsumgebung wird wiederum über eine Datei beschrieben und automatisiert zur Verfügung gestellt. Das Dev-Team, das GitHub entwickelt, nutzt mittlerweile selber Codespaces – in einem interessanten Blog-Eintrag gibt es Details.
Die IDE wird als VM zur Verfügung gestellt, deren Größe auch konfigurierbar ist – bis zu 32 Cores und 64 GB RAM. Aber natürlich zu entsprechenden Preisen.

GitPod

Der Ansatz von GitPod ähnelt den vorangehend beschriebenen: Es wird eine komplette Entwicklungsumgebung automatisiert bereitgestellt, als IDE-Basis werden Visual Studio Code und auch IntelliJ verwendet. Interessant ist, dass kürzlich eine enge Partnerschaft mit IntelliJ verkündet worden ist – das „Works on my machine“-Problem wird gemeinsam angegangen. GitPod wird als SaaS angeboten, aber auch zur Installation auf dem eigenem Kubernetes-Cluster, z. B. in Azure, AWS oder Google.

Codeanywhere

Codeanywhere basiert grundsätzlich auch auf Visual Studio Code, reichert diese IDE aber um weitere Features an. Insbesondere lassen sich eigene Server mithilfe von Standard- Protokollen einbinden (z. B. SSH) – auf diesen Servern können wir dann aus der IDE heraus Dateien editieren oder sogar SSH-Terminals starten. Aber auch Codeanywhere bringt eine Reihe von vorinstallierten Containern mit, um schnell eine reine Cloud-Programmierumgebung zu schaffen.

AWS Cloud9

AWS Cloud9 ist die Cloud-basierte Entwicklungsumgebung von AWS. Sie unterstützt ebenso eine Vielzahl von Sprachen, ist aber dann doch recht optimiert für den Einsatz im AWS-Ökosystem – auch wenn sich andere Server grundsätzlich mit SSH einbinden lassen. In Zusammenspiel mit dem Baukasten von AWS (CodeStar, CloudFormation, etc.) wird die Umgebung eher richtig sinnvoll bei AWS-Workloads, weniger in hybriden Szenarien.

JetBrains Fleet

Wenn JetBrains die „next-generation IDE“ entwickelt, dann lohnt sich ein Blick auf den Ansatz. JetBrains verfolgt ein deutlich anderes Konzept als die bisher genannten Plattformen. Kernidee ist es, dass die IDE selber über eine verteilte Architektur verfügt – kurz: Der leichtgewichtige Editor befindet sich auf der Entwicklermaschine, alle anderen Teile können auf zentrale Maschinen verteilt werden, auch die mächtige Code Engine von IntelliJ. Fokus des Ansatzes ist die bessere Kollaboration aller beteiligten Entwickler*innen. Viele Vorteile einer Cloud-IDE können so auch realisiert werden, aber es ist eine wirklich reine IDE – automatisiertes Hochfahren von Umgebungen ist z. B. nicht Teil der Plattform. Momentan befindet sich Fleet noch in der geschlossenen Beta-Phase. Ich kann mir vorstellen, dass die oben genannten Plattformen von dieser neuen Architektur Gebrauch machen könnten und in der Zukunft auch Fleet integrieren.

Codesphere

Die bisher genannten Ansätze zielten auf sehr generische Anwendungstypen ab, d. h. eine möglichst breite Unterstützung von Programmiersprachen und Container-basierten Architekturen. Es gibt aber auch Ansätze, die klar auf die Vereinfachung der Entwicklung bestimmter Anwendungstypen abzielen und hier nicht nur eine Cloud-IDE mitbringen, sondern eine durchgängige Plattform bis hin zum Betrieb, und dies hoch automatisiert, aber auch hoch standardisiert. Codesphere ist ein noch recht junges Startup und die Kernidee ist es, Entwickler*innen eine durchgängige Plattform zu bieten, die die IDE direkt mit der Infrastruktur verbindet. Hier wird nicht „nur“ eine Cloud-IDE mitgebracht, sondern auch eine Cloud-Infrastruktur für Test und Produktion der erstellten Web-Anwendungen – inkl. integriertem Monitoring.

Replit

Mit Replit erzeugt man sogenannte „Repls“, d. h. konkrete Anwendungen/Apps/Web-Anwendungen, die dann auch direkt auf Replit-Servern ausgeführt werden (Test und Produktion).

CodeSandbox

CodeSandbox fokussiert darauf, Web Development im Team schnell zu machen – durch gute Kollaborationsmöglichkeiten und Optimierung auf Web Development. CodeSandbox kann man aber auch in bestehende Entwicklungsprozesse integrieren, d. h. kann ergänzend sein als IDE und nicht eine komplette IDE ersetzen. Wiederum ein nochmal anderer Ansatz.

Wenn man jetzt noch Low-Code-Ansätze betrachtete, wäre die Liste schnell noch viel länger. Aber auch schon so gibt es wichtige Player im Markt der IDEs, die auf den Browser-basierten Ansatz aufspringen bzw. auch alternative Ansätze zur klassischen Offline-IDE suchen.

Verschiedene Arten von Cloud-basierten IDEs

Ich sehe grundsätzlich verschiedene Typen von Cloud-IDEs:

1. Vollumfängliche Entwicklungsumgebungen und -plattformen, die für möglichst viele Anwendungstypen geeignet sein sollen. Diese sind am ehesten vergleichbar mit aktuellen, lokalen Entwicklungsumgebungen – Beispiele sind Eclipse Che, GitPod oder GitHub Codespaces.
2. Rapid-Development-Plattformen, die für bestimmte Anwendungstypen von Entwicklung bis Produktion (inkl. Infrastruktur) einen durchgängigen Entwicklungsprozess erlaubt, ohne dass man sich um die Infrastruktur kümmern muss (Codesphere, Replit). CodeSandbox würde ich auch hier einordnen, obwohl hier die Infrastruktur im Betrieb nicht im Fokus ist und für Fullstack-Anwendungen keine Durchgängigkeit vorhanden ist.
3. Low-Code-Ansätze, die ich hier nicht betrachtet habe. Diese fokussieren teilweise sogar konkrete Branchen und gehen über die reine Technologie hinaus.

Fazit

Es gibt gute Gründe, weshalb auch die IDEs und die kompletten Entwicklungsplattformen in die Cloud wandern – oder zumindest auch per SaaS den Entwicklungsteams zur Verfügung gestellt werden. Auch der klassische Java-EE-Entwickler (wie ich einer war) wird das zu spüren bekommen. Vor allem, wenn die Geschwindigkeit von der Entwicklung zur Produktion (und zurück) und Kollaboration im Team mit modernen Team-Praktiken im Vordergrund steht, wird der Einsatz von Cloud-basierten IDEs kaum aufzuhalten sein.

Spannend ist, wie sich das Ganze in Zukunft entwickeln wird und vor allem: mit welcher Geschwindigkeit die IDEs adaptiert werden.