Probleme mit der lokalen Entwicklungsumgebung: Ist Containerisierung die Lösung?

Welchen Vorteil bringt Containerisierung?

Am besten sind die Vorteile greifbar, wenn wir uns die Unterschiede zwischen der Arbeit ohne und mit Containern vor Augen führen:

Container bieten eine effektive Möglichkeit, Anwendungen schnell bereitzustellen. Nicht umsonst gibt es den Spruch: “Write once, run anywhere.” Sie ermöglichen es, dass Services, unabhängig vom Einsatzort, auf die gleiche Weise funktionieren. Sie sind leicht skalierbar und können verschiedene Versionen einer Anwendung nebeneinander ausführen.

Das Problem mit lokalen Entwicklungsumgebungen & Containern

Das Problem mit lokalen Entwicklungsumgebungen ist, dass die Einrichtung Stunden, wenn nicht sogar Tage dauern kann. Die größte Herausforderung ist dabei oft, die zu entwickelnde Software zum Laufen zu bringen. Nur so können Entwickler_innen schnell überprüfen, ob Codeänderungen zum gewünschten Ergebnis führen. Ein weiteres Problem: Die Wartung ist aufwändig, weil jede Entwicklungsumgebung eine individuelle Problemlösung benötigt.

Nun gibt es glücklicherweise Container. Und genau auf diese Lösung greifen viele Unternehmen zurück, wenn die eben beschriebenen Probleme die tägliche Arbeit und Produktivität negativ beeinflussen.

Aber sind Container auch eine gute Lösung, um die alltäglich auftretenden Probleme mit der lokalen Entwicklungsumgebung anzugehen?

Kurz und knapp: Nein. Warum?

• Komplexität: Entwickler_innen müssen zuerst einmal wissen, wie sie mit Containern arbeiten. Ist das Wissen nicht vorhanden, ist eine Einarbeitungszeit notwendig. Das dauert. Und kostet Geld.
• Konfiguration: Die meisten Anwendungen laufen auf einem bestimmten Port. Mit Port Forwarding kann eine Verbindung zum Container hergestellt werden. Der Teufel liegt aber im Detail, denn dafür muss alles richtig konfiguriert sein. Wenn nicht, sind Netzwerkprobleme vorprogrammiert. Eine falsche Konfiguration kann außerdem zu Sicherheitsproblemen führen.
• Die Fehlersuche und das Debugging werden erschwert, da Logs oft auf mehreren Containern verteilt sein können.
• Das Ausführen von Containern kann ressourcenintensiv sein. Es muss sichergestellt werden, dass der Rechner über die entsprechende Leistung verfügt.

Details zu den Herausforderungen schildert der schon zu Beginn erwähnte Micah Adams. Er beschreibt u. A. Eigenheiten von Docker, die er bei der Verwendung nicht bedacht hat:

• Es war eine beträchtliche Menge an Konfiguration erforderlich, damit die Umgebung tatsächlich funktioniert.
• Adams hat sehr viel Zeit damit verbracht, sich den Kopf über einige einfache Datenbankverbindungsprobleme zu zerbrechen, nur um festzustellen, dass der Datenbankcontainer nicht richtig konfiguriert war

Guillaume Briday meint sogar in seinem Blogpost “Why I stopped using Docker for local development”: “Ich verwende Docker nun schon seit fast 5 Jahren. […] Es hat viele meiner Probleme gelöst und mein Leben als Entwickler vereinfacht, aber ich bin fertig damit. Und warum? Die Probleme, die Docker gelöst hat, sind den Aufwand nicht wert, der für seine Verwendung erforderlich ist. Ich möchte mich nicht mit der Komplexität und dem Workflow-Management beschäftigen.”

Und weiter:

“[…] Man muss so viele Konzepte kennen, um mit Docker wirklich effektiv zu sein.

Warum und wie man Ports freigibt.
Wie man mit Berechtigungen umgeht.
Wie benannte Volumes funktionieren.
Wie Einstiegspunkte funktionieren.
Wie Netzwerke funktionieren und wie Docker internes DNS funktioniert.
Und so weiter…

Die Pflege von hunderten von Zeilen YML-Dateien ist nichts, was Sie produktiver macht.”

Natürlich ist das nur eine Seite der Medaille. Ist Ihr Team mit Containern vertraut, kann mit den Schwierigkeiten – die unternehmenseigene Software lokal zu betreiben und die Wartung der Entwicklungsumgebungen – besser umgegangen werden. Für manche Unternehmen reicht das bereits aus. Andere kämpfen sich weiter durch den Container-Dschungel, haben große Probleme, die Software lokal laufen zu lassen und schlagen sich mit Konfigurationsfehlern herum.

Warum Remote Development Environments die bessere Alternative sind

“Wenn Sie daran interessiert sind, auf eine containerisierte Entwicklungsumgebung umzusteigen, sollten Sie meiner Meinung nach viel Zeit darauf verwenden, einfache Alternativen für den lokalen Betrieb von Anwendungen zu entwickeln.” – Micah Adams

Eine Alternative, um Zeit, Geld und Energie zu sparen, sind Cloud Development Environments (CDEs). Mit Cloudomation DevStack können Entwickler_innen im Self-Service Remote-Umgebungen erstellen, die in wenigen Sekunden verfügbar sind und der Produktionsumgebung so nahe wie möglich kommen. Die zu entwickelnde Software und alle benötigten Entwicklerwerkzeuge laufen in der RDE. Entwickler_innen können aber weiterhin mit ihrer lokalen IDE und ihren individuellen Tools arbeiten.

Da RDEs auf Servern verfügbar sind und im Vergleich zu Laptops individuell mit den benötigten Ressourcen ausgestattet sind, reduziert sich die Wartezeit für Builds und Tests. Probleme mit schwachem CPU oder wenig RAM gehören der Vergangenheit an. RDEs werden zentral, bspw. vom DevOps-Team verwaltet. Die Umgebungen sind standardisiert und Fehler im laufenden Betrieb werden immer für alle Entwickler_innen gelöst. Entwickler_innen müssen sich nicht mehr individuell um auftretende Probleme und Konfigurationsfehler kümmern. Einige Vorteile haben wir im Beitrag: „5 Vorteile von Remote Development Environments“ zusammengefasst.

Und was ist mit Containern und RDEs? Auch der Betrieb von containerisierten Applikationen ist möglich. Da die RDEs zentral konfiguriert sind, greifen Entwickler_innen einfach darauf zu und können damit arbeiten – ohne sehr viel Zeit mit der lokalen Konfiguration von beispielsweise Docker zu verbringen.