DevOps Days auf der JAX 2015

DevOps: Zwischen technischer Euphorie und mentalem Realismus

Moritz Hoffmann

Nach ersten Enttäuschungen mit der rein technischen Etablierung von DevOps scheint mit Docker und Micro Services bereits ein neuer Hype in der IT-Community entfacht worden zu sein. Potential und Grenzen der technischen Innovationen standen auch auf der Agenda der Referenten der DevOps Days während der diesjährigen JAX auf dem Prüfstand.

Die Automatisierung des Prozesses von der Entwicklung bis zur Auslieferung neuer Software gilt unter dem Buzzword „DevOps“ immer noch als Königsweg zur Überwindung des Grabens zwischen Entwicklung und Deployment. Zunehmend aber wird von DevOps-Vorreitern auf das notwendige Mindset gedrungen. Obwohl seit dem rasanten Aufstieg der Container-Technologie und der Micro Services wieder verstärkt Tools und Methoden im Vordergrund stehen, bleibt die Frage, ob diese wirklich ausreichen, um DevOps erfolgreich anzuwenden.

Neuer Hype um Micro Services?

Während mit der Container-Technologie das Bauen und Testen neuer Software samt individualisierter Infrastruktur und Umgebung auch virtuell möglich wird, stellen die Micro Services kleine und isolierte Software für einzelne Anwendungen vor, die in schnellen Sprints getestet, analysiert und automatisch deployt werden. Die Stärke liegt hier im geringen Umfang, der Projekteinsteigern den Einstieg und Entwicklern das Bauen erleichtert. Welche Rolle aber können sie für DevOps spielen?

Martin Gutenbrunner (ruxit) stellte in seiner Session den DevOps-Rummel um Micro Services in Frage und die Übersetzungsarbeit in den Vordergrund: Was für Entwickler die Micro Services sind, sind für Ops letztlich Micro Deployments. Deshalb kommt es darauf an, dass das Wissen der Entwickler im automatisierten Deployment auch wirklich weitergegeben wird und jederzeit abrufbar ist. Erst dann ist die Voraussetzung geschaffen, dass Devs wie Ops Micro Services gemeinsam klein, schlank und pflegeleicht ausliefern können.

„Don’t ignore the Operators!“

Das klingt gut und effizient, doch lässt sich ein wenig Chronologie trotz parallel ablaufender Sprints doch nicht vermeiden. Zuerst wird entwickelt, dann getestet, dann deployt. Während Entwickler hier das Glück haben, am Anfang der Deployment-Zyklen zu stehen, müssen sich Admins auf der Ops-Seite mit Problemen oft erst dann beschäftigen, wenn die Hütte längst zu brennen angefangen hat. Zur Lösung dieses Problems tragen Fail Fast, Continuous Delivery Tools und Direktiven von oben nur wenig bei, solange das Management als Flaschenhals der Kommunikation zwischen Dev und Ops fungiert.

Enterprisflight_DevOps_Adamovich

Worauf es bei der direkten Kommunikation in der Product Chain ankommt, zeigte Andrey Adamovich (Aestas/IT) in der kleinen Geschichte von der Development Republic, dem Operations Kingdom und von Jack. Jack ist ein Ops-Developer und beginnt irgendwann zu verstehen, dass er Konfigurationen und Logging für die Operators so verständlich, strukturiert und eben clean halten muss wie seine Codes für die Devs-Kollegen. Die Botschaft war eindeutig:

Don’t ignore the Operators!

Von der Schaluppe zum Triple-E-Containerschiff

Die Container-Technologie trat mit dem Versprechen an, die Kommunikationsprobleme technisch zu lösen, indem sie den Projektstatus von der Entwicklung zum Deployment in verschiedenen Umgebungen jederzeit nachvollziehbar und beeinflussbar hält. Ob der Slogan „Build, Ship, Run, any app, anywhere.“ aber mehr sein kann, als gutes Marketing, versuchte Peter Roßbach (bee42 solutions GmbH) in seiner Session zum Test Driven Development mit und in Docker zu klären.

Deutlich wurde hier, dass es in Dockers Ökosystem die Images sind, in denen das ganze DevOps-Potential von Docker liegt. Mit ihnen kann das identische Produkt in ganz verschiedenen Umgebungen vielfältige Tests durchlaufen und bis zum Release optimiert werden. Dafür muss dann auch die für das Testing gewünschte Infrastruktur-Umgebung implementiert werden. Bei diesem Stückchen Software muss es, so Roßbach, aber nicht bleiben:

„Es geht darum, die Blaupause etwas größer zu gestalten, um wie in der Logistik am Ende Giganten zu bauen.“

Software als Hardware

Bemerkenswert am Bau von Test-Infrastruktur und Umgebungen in Docker sind zwei Punkte:

  • Zum einen wird damit Hardware letztlich durch Software ersetzbar. Die physische Handarbeit, das Umstöpseln von Kabeln und Geräten wird  mit den virtuell erstellten, sehr schlank gehaltenen Umgebungen in die Tastenfinger der Tester gelegt.
  • Zum anderen kann die Infrastruktur selbst Test driven implementiert werden. Das schon lange etablierte Test Driven Development soll dann auch ins ehemalige Ops-Gebiet Konfigurationsmanagement Einzug halten.

Umgekehrt zeigte sich Peter Roßbach (bee42 solutions GmbH) überzeugt: In Zukunft wird das Konfigurationsmanagement nicht mehr nur unter Ops einzuordnen sein. Denn letzlich wird die Test driven Infrastructure mit Docker zum neuen Code und am Ende werden die Entwickler ganze Container bauen:

„Der Anfang ist gemacht. Alles, was wir als Entwickler gelernt haben, können wir jetzt auch für Infrastruktur verwenden. Und das ist gut so.“

Zukünftige Herausforderungen, wie die Bereitstellung eines brauchbaren Basis-Images oder die Möglichkeit, im Container selbst zu testen und zu deployen, harren noch einer befriedigenden Lösung. Die Erwartungen an Docker sind hinsichtlich DevOps aber nach wie vor hoch. Auch Michael Johann (Johann) schlug in seiner Docker-Einführung in die gleiche Kerbe:

„In einem Jahr schon wird jeder mit Docker arbeiten.“

Ob er diese steile These halten kann, wird spätestens auf der JAX 2016 zu diskutieren sein. Schon im Juni diesen Jahres wird die DevOpsCon 2015 Anlass für einen Zwischenstandsbericht bieten.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Geschrieben von
Moritz Hoffmann
Moritz Hoffmann
Moritz Hoffmann hat an der Goethe Universität Soziologie sowie Buch- und Medienpraxis studiert. Er lebt seit acht Jahren in Frankfurt am Main und arbeitet in der Redaktion von Software und Support Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: