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

  • Veröffentlicht

Docker und Container im Allgemeinen sind in der modernen Softwareentwicklung nicht mehr wegzudenken. Auch lokal werden oftmals Container genutzt, um Probleme mit der lokalen Entwicklungsumgebung und dem Betrieb der zu entwickelnden Software zu vermeiden.

Das bringt allerdings neue Herausforderungen mit sich: Ist das Wissen überhaupt vorhanden, um mit Containern arbeiten zu können? Ist alles richtig konfiguriert? Bringt die lokale Verwendung von Containern überhaupt einen Vorteil, um die zu entwickelnde Software lokal zu betreiben?

Oder ist es eher so, wie es Micah Adams beschreibt: “Die wohl größte Falle, wenn man den Weg einer containerisierten Entwicklungsumgebung einschlägt, ist die Annahme, dass die Vorteile, die man beim Deployment erhält, die gleichen sind, die ein Entwickler lokal erfährt.

In diesem Blogpost beschreiben wir, warum Container ein erster Schritt in die richtige Richtung sind, aber nicht alle Probleme lösen.

Was ist Containerisierung?

Sehen wir uns kurz an, was eigentlich Containerisierung bedeutet. Containerisierung ist eine Technologie, die es ermöglicht, Anwendungen in isolierten und portablen Umgebungen auszuführen. Container sind dabei virtuelle Laufzeitumgebungen, die alle notwendigen Softwarekomponenten, Bibliotheken und Abhängigkeiten für Anwendungen enthalten. Anwendungen können damit schnell bereitgestellt, skaliert und verwaltet werden.

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:

Ohne ContainerMit Container
Abhängigkeiten werden manuell installiert und verwaltet.Abhängigkeiten werden in der Containerumgebung installiert und verwaltet.
Unterschiedliche Systemkonfigurationen können Probleme verursachen.Container bieten eine konsistente Umgebung für Anwendungen.
Anwendungen müssen für verschiedene Umgebungen angepasst werden.Container können auf verschiedenen Systemen ausgeführt werden, ohne Anpassungen vornehmen zu müssen.
Skalierung ist oft aufwändig und erfordert manuelle Eingriffe.Container können schnell und einfach skaliert werden.
Bereitstellung kann zeitaufwendig und fehleranfällig sein.Container können schnell und einfach bereitgestellt werden.

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.

Remote Development Environments vs. Local Development Environments

In diesem Vergleichs-Dokument erfahren Sie im Detail, was die wichtigsten Unterschiede zwischen Cloudomation RDEs und lokalen Entwicklungsumgebungen sind.

Jetzt herunterladen

Fazit

  • Mit dem lokalen Betrieb von Containern wie Docker wird oftmals versucht, die erstmalige Einrichtung der Entwicklungsumgebung effizienter zu machen, die zu entwickelnde Software einfacher betreiben zu können und den Aufwand für die Wartung der lokalen Entwicklungsumgebung zu verringern.
  • Containerisierung der zu entwickelnden Software löst zwar einige Probleme, führt aber zu neuen Herausforderungen: Das Wissen muss intern vorhanden sein, die Konfiguration kann aufwändig sein, Sicherheits- und Netzwerkprobleme können auftreten und der Betrieb kann sich auf die Leistung des Rechners auswirken. Die Fehlersuche und das Debugging werden erschwert, da Logs oft auf mehreren Containern verteilt sein können.
  • Remote Development Environments sind eine Alternative: Im Self-Service steht Entwickler_innen sofort die passende Umgebung zur Verfügung. Sie können weiterhin ihre lokale IDE nutzen und wie gewohnt arbeiten. Die zu entwickelnde Software wird in der RDE betrieben. Muss beispielsweise auf eine andere Version gewechselt werden, wird einfach die passende RDE aufgerufen. Alle Abhängigkeiten sind bereits konfiguriert. Build-Zeiten reduzieren sich, da RDEs auf einem Server laufen, der beliebig skalierbar ist. Das Betreiben von containerisierten Applikationen ist auch in RDEs möglich – ohne individuelle Konfigurationsarbeit je Entwickler_in.

Jetzt den Cloudomation-Newsletter abonnieren

Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Cloud Development Environments“ und „DevOps“ erhalten. 




    Johannes Ebner

    Marketing Manager