Interview mit Tobias Getrost

Docker ohne Microservices – das bringt’s!

Melanie Feldmann

Tobias Getrost

Container und Microservices sind eines der Liebespaare der aktuellen IT-Trends. Ohne einander können sie quasi nicht. Aber weit gefehlt. Container haben noch etwas nebenher mit Monolithen am Laufen. In seinem Talk auf der JAX 2016 hat Tobias Getrost (1&1) darüber gesprochen, welche Vorteile Container-Technologien auch Anwendungen bieten, die nicht trendy aufgesplittet sind.

JAXenter: Sie haben in Ihrem Talk gezeigt, dass Containertechnologien nicht nur bei Microservices sinnvoll sind. Welchen Vorteil bringen Container bei gewachsenen, eher monolithischen Anwendungen? Bei welchen Szenarien lohnen sich Container?

Tobias Getrost: Im Kontext von Microservices ist Docker weit verbreitet. Die Vorteile Portabilität, einfache Verteilung und Isolation von anderen Anwendungen bringen aber auch in klassischen eher monolithischen Anwendungen deutliche Vorteile. Ich will dies anhand von ein paar Beispielen
veranschaulichen:

Die Installation und Konfiguration eines Application-Servers, um Tests auf dem lokalen Entwicklungsrechner zu ermöglichen, ist oft sehr zeitintensiv und mühsam. Durch Docker-Container kann zentral eine vorkonfigurierte Umgebung bereitgestellt werden, die dann auf dem lokalen Rechner mittels „docker run“ genutzt werden kann.

Durch den Einsatz von Containern kommen stets identische Testumgebungen zum Einsatz. Fehler, die durch leicht abweichende Konfigurationen oder Versionen bei lokalen Tests bedingt sind, werden so vermieden.

Ein weiteres Einsatzgebiet, bei dem Container einen sehr großen Vorteil bieten, ist das Testen einer Anwendung auf verschiedenen Versionen eines Servers. Durch die Isolation des Servers innerhalb eines Containers werden aufwendige Anpassungen an der Konfiguration des Testsystems vermieden.

JAXenter: Welche spezifischen Hürden müssen Entwickler bei dem Weg einer Altanwendung in den Container nehmen?

Tobias Getrost: Zunächst einmal sind die Hürden mit Docker grundsätzlich sehr niedrig. Sie hängen sehr stark davon ab, um was für eine Anwendung es sich handelt und in welchem Kontext diese betrieben wird. Die Hürden lagen bei uns zum einen darin, dass die Server-Konfiguration wenig automatisiert war und aus einer Mischung von manuellen Schritten und Skripten bestand. Um automatisiert einen Container erstellen zu können, galt es, die vorhandenen Skripte so zu organisieren und um Shell-Skripte zu erweitern, dass eine automatische Konfiguration möglich war.

Darüber hinaus galt es, das Netzwerk-Setup zu meistern, um die in unserem Fall circa 30 externen
Services in einer SOA mit unserer Software zu orchestrieren. Vor allem der DNS-Lookup von Services
im internen Netz hat sich aus Containern heraus als knifflig erwiesen.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

JAXenter: Docker-Container und der Build Server Jenkins scheinen gesetzt zu sein. Aber Jenkins hat im Einsatz auch so seine Tücken. Gibt es eine einsteigerfreundliche Variante, die Sie empfehlen können?

Im Zusammenspiel mit Arquillian lassen sich auch ohne Jenkins Testszenarien realisieren.

Tobias Getrost: Jenkins hat sich in unserem Fall angeboten, da wir hier bereits über viel Erfahrung verfügen. Docker dagegen ist für uns noch eine sehr junge Technologie, deren Einsatzszenarien wir aktuell evaluieren. Für erste Erfahrungen mit Docker ist eine Installation auf dem eigenen Rechner eine gute und unkomplizierte Ausgangsbasis. Die Verwendung von Containern für lokale Tests bringt gegenüber der manuellen Installation schon einen enormen Gewinn. Im Zusammenspiel mit Technologien wie Arquillian lassen sich auch ohne einen Build Server wie Jenkins bereits Testszenarien realisieren. Für die Evaluation von Jenkins oder auch für den Test neuerer Plug-in-Versionen hat sich das offizielle Jenkins Docker Image als sehr hilfreich und unkompliziert erwiesen. Für erste Tests von Build-Pipelines, die Docker verwenden, kann das Demo Image von CloudBees verwendet werden.

JAXenter: Nach den ersten Schritten mit Continuous Delivery und Docker. Was wäre Ihr Tipp für nächste Schritte eine Altanwendung und ihre Prozesse zu modernisieren?

Tobias Getrost: Ein allgemeingültiges Rezept kann ich hier leider nicht anbieten. Wie so oft, spielen bei der Modernisierung von Anwendungen viele Faktoren eine Rolle. Hilfreich ist es, zu schauen wo im Prozess oder in der Anwendung gerade die größten Schmerzen bestehen. Für diese kann man dann z. B. anhand eines Prototypen evaluieren, ob hier durch den Einsatz moderner Technologien oder Praktiken Abhilfe geschaffen werden kann. Ein iteratives Vorgehen in kleinen Schritten kann schnell erste positive Impulse bringen sowie die Möglichkeit, Technologien auch wieder zu verwerfen.

JAXenter: Danke für das Gespräch!

getrost_tobiasTobias Getrost arbeitet seit 2014 für die 1&1 Telecommunication AG als Lead Developer. Im Rahmen laufender Entwicklungsprojekte etabliert er dort zusammen mit seinen Teamkollegen Continuous Delivery. Zuvor war er als Berater in den Themen Business Process Management, Enterprise Java und Clean Code Development tätig. Als passioniertem Clean Code Developer liegen ihm Themen rund um Softwarequalität, Continuous Delivery und effiziente Entwicklungsmethoden am Herzen. Im Rahmen seiner Tätigkeit leitet er Workshops zu Clean Code Development und Softwarequalität und hält Vorträge zu diesen Themen.
Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: