DevOps-Kultur, Lean Management, Microservices oder lieber Container, Continuous Delivery, Cloud? Die Bandbreite an Themen auf der DevOpsCon 2016 in München war groß und machte die Auswahl für die Teilnehmer nicht gerade einfach. Wir haben für Sie einige Highlights herausgegriffen – und auch uns fiel die Wahl nicht leicht.

#1 – DevOps Kaizen – das neue Traumpaar

Das Konzept „Kaizen“, bekannt aus der japanischen Automobilindustrie, wird von der DevOps-Bewegung gerade neu entdeckt. Kaizen bedeutet „Veränderung zum Besseren“, gemeint ist damit die schrittweise aber nie endende Optimierung eines Produktes oder Prozesses.

DevOpsCon-Speaker Greg Bledsoe (Accenture) nennt im Interview einige Schlüsselpunkte:

Wie bei DevOps geht es bei Kaizen um kulturellen Wandel. Japan hat nach der Niederlage im zweiten Weltkrieg gewissermaßen seine Arbeitskultur neu erfunden. Im Zentrum stand nicht mehr nur die Ergebnisorientiertheit bzw. das fertige Produkt, sondern die Verbesserung des Herstellungsprozesses und damit also die Menschen hinter dem Produkt.

Der individuelle Arbeiter wurde nicht mehr als reiner Kostenfaktor, sondern als (Human-)Kapital betrachtet, das dabei unterstützt werden sollte, sich mit all seinen Fähigkeiten einzubringen „Kaizen is about empowering the individual workers.“, sagt Bledsoe. Keine kurzfristigen Arbeitsverhältnisse mit austauschbaren Angestellten, sondern eine langjährige Bindung des Arbeiters ans Unternehmen wurde angestrebt. Von daher das Interesse des Arbeitsgebers, in das Know How seiner Angestellten zu investieren.

Ein zweiter Punkt: Das Feedback der Arbeiter wurde ernst genommen: „Early Feedback is key“, lautet die Devise bei Kaizen wie bei DevOps! Denn auch in der Software-Branche gilt, dass Probleme desto ökonomischer und einfacher behoben werden können, je früher sie entdeckt werden. In diesem Sinne plädiert Bledsoe dafür, Security-Aspekte schon früh in den Design-Prozess aufzunehmen: Was uns zum neuen Kofferwort DevSecOps bringt.

#2 – DevOps: Im Zentrum steht der Mensch

Eröffnet wurde die DevOpsCon 2016 von Program Chair Sebastian Meyen, der DevOps als Bewegung einführte, die im Spannungsfeld zwischen Kultur und Technologie den Menschen ins Zentrum stellt – ganz im Sinne der oben beschriebenen Kaizen-Philosophie.

Einerseits fordern neue Technologie-Ansätze wie Cloud-Plattformen, Continuous Delivery, Container und Microservices dazu heraus, die IT in ihrer Funktionsweise und Rolle im Unternehmen neu zu denken. Doch bleiben alle technologischen Innovationen stumpfe Werkzeuge, wenn sie nicht mit der richtigen Einstellung, d.h. im DevOps-Kontext in Hinblick auf die realen Unternehmensziele eingesetzt werden.

Als notwendig identifiziert die DevOps-Bewegung deshalb eine Kultur, in der Transparenz über gemeinsame Werte und Zielsetzungen vorherrscht. Hermetisch abgetrennte Abteilungen – hier eine Entwicklungsabteilung, die schnell neue Features auf den Markt bringen will, dort ein IT-Betrieb, der für Sicherheit, Stabilität und Wartbarkeit der Software bezahlt wird – passen hier nicht ins Bild.

#3 – Eine Roadmap für kulturellen Wandel

Greg Bledsoe (Accenture) knüpfte in seiner Keynote an diese Sichtweise an, indem er den Transformationsprozess einer Unternehmenskultur hin zu den Werten der DevOps-Bewegung aufschlüsselte. Doch was genau macht eigentlich die Kultur eines Unternehmens aus?

Laut Bledsoe ist die Unternehmenskultur zunächst einmal von der sie umgebenden gesellschaftlichen Kultur beeinflusst, von der die meisten Mitarbeiter eines Unternehmens geprägt sind. Im Unternehmenskontext gesellt sich dazu die kulturelle Mentalität der Führungsebene, die auf die Mitarbeiter ausstrahlt.

Deshalb kommt den Führungspersönlichkeiten eines Unternehmens eine Schlüsselstellung zu, um DevOps-Werte wie Kollaboration, Vorwurfsfreiheit, Autonomie, Experimentalkultur vorzuleben und im Unternehmen zu verankern.

Eines der größten Hindernisse für DevOps ist laut Bledsoe, Teams unterschiedliche Anreize zu geben, sodass diese immer nur ihre je eigenen Zielsetzungen im Blick haben. Bledsoe rät dazu, hierarchische Silos im Unternehmen abzubauen, indem die Motivationen der Teams mit den Business-Zielen in Einklang gebracht werden.

Insofern beschreibt Bledsoe DevOps als Bewegung, in der Technologie auf Business Value abgebildet wird, um Verschwendung und Dysfunktionalität zu eliminieren, schneller wertvolle Software auszuliefern und dem Unternehmen somit Wettbewerbsvorteile zu sichern.

#4 – Wie aus Humankapital DevOps wird

Erfolgreiche Unternehmen, die mit ihrer IT schnell auf Marktveränderungen reagieren können, haben eine Gemeinsamkeit: Sie legen einen hohen Wert auf das sogenannte Humankapital, sagte John Willis (Docker Inc.) in seiner Keynote auf der DevOpsCon. Auch hier begegnet uns der Mensch – und nicht etwa Tools oder Technologien – als Kristallisationspunkt der DevOps-Bewegung.

So untypisch, da entmenschlichend der Begriff „Humankapital“ im DevOps-Kontext klingt – bezeichnet wird damit in der Wirtschaftswissenschaft zunächst ganz neutral die “personengebundenen Wissensbestandteile in den Köpfen der Mitarbeiter” (siehe Wikipedia). Dieses personengebundene Kapital in eine Unternehmenskultur einfließen zu lassen, die sich vom Ideal des Lean Management, der Sicherheitskultur und der Learning Organization leiten lässt, ist für Willis der Schlüssel auf dem Weg zu einer hoch-performanten DevOps-Kultur.

Interessant im anschließenden Interview ist aber auch Willis´ Bemerkung, dass es eine Ebene der technologischen Hilfsmittel gibt, die eine kulturelle Transformation begünstigen kann. So ermöglichen etwa Container-Technologien den reibungslosen Übergang zwischen Software-Entwicklung und Software-Betrieb, Microservices-Architekturen die Aufteilung der IT in autonomen Teams, die Cloud das schnelle Aufsetzen technologischer Experimente ohne langfristige Kostenbindung.

#5 – Die Zukunft der Container

A propos Container. Wohin uns die Container-Revolution in den nächsten Jahren führen wird, wurde auf der DevOpsCon ausführlich in einem Panel diskutiert. John Willis (Docker), Peter Roßbach (bee42), Philipp Garbe (AutoScout24) und Roland Huß (Red Hat) waren sich einig, dass mit Docker eine neue Stufe der Virtualisierung erreicht wurde, die Skalierungseffekte in nie zuvor gekannten Ausmaß ermöglicht hat.

„Wir können mit Containern die Arbeit, die früher 2 Monate gedauert hat, in 2 Tagen erledigen – stabil, schnell, reproduzierbar“, brachte es Peter Roßbach auf den Punkt.

Docker ist für Roßbach eine Art „Lego für IT“: Der Welt sei in Form der fertigen Docker-Images ein Baukastensystem geschenkt worden, mit dem selbst Nicht-Entwickler umgehen können. Das disruptive Element der Container sieht Roßbach deshalb auch darin, dass der weltweite Transfer von (IT-)Wissen drastisch erhöht wird – und das, durch die Portierbarkeit der Container über die ganze Bandbreite der IT-Hardware hinweg, von großen Cluster-Systemen bis hin zu kleinsten Devices des Internet of Things.

Was wir indes auf JAXenter in unserer Container-2.0-Debatte bereits thematisiert hatten, kam auch auf dem Panel zur Sprache: Die derzeitigen Diskussionen um ein Standard-Container-Format und –Orchestrierungslösungen sind mitunter von unternehmenspolitischen Dimensionen geprägt, die dem Fortschritt nicht gerade zuträglich sind. John Willis nannte die Orchestrierung gar das Schlachtfeld im Container-Krieg, in dem es letztlich um Anteile an einem Milliardenmarkt geht.

Roland Huß hier auf JAXenter:

Die Entscheidung, docker-swarm als Teil jeder Docker-Installation mit auszuliefern, erinnert stark an die aggressive Strategie, die Microsoft einst mit der Integration des Internet Explorer 6 in das Betriebssystem verfolgt hat.

Mehr zur Container-Debatte in den folgenden Interviews:

Inwiefern der gerade bekannt gewordene Meldung, dass Docker Inc. seine Container-Runtime einer anbieterneutralen Foundation übergeben will, die Wogen glätten kann, darf mit Spannung beobchtet werden.

#6 – Microservices für jeden – auch für Legacy-Anwendungen

Microservices und die Cloud waren allgegenwärtig auf der DevOpsCon 2016. In ihrem Workshop Service-Discovery in einer Microservices-Infrastruktur zeigten Johannes Bumüller, Clemens Heppner, Florian von Stosch, wie komplexe Microservices-Systeme skalierbar und robust bleiben. Ihr Tipp, wie man auch Legacy-Systeme an den Microservices-Stil heranführen kann:

Überlegen Sie sich zuerst, wieso Sie Microservices brauchen, damit Sie ihre Architekturvision gut vermitteln können.
Überlegen Sie dann, wie Sie ihre Fachlichkeit sinnvoll in zwei Teile trennen können, denn eine technische Teilung führt zu stärker voneinander abhängigen Teams.
Daraus können Sie dann den vielversprechendsten ersten “Schnitt” durch den Monolithen ableiten und loslegen.
Versuchen Sie nicht von Anfang an, das System in mehr als zwei Microservices zu zerlegen, denn die technologischen Herausforderungen sind groß! Wenn sie mit einem einzigen “Schnitt” anfangen, lernen Sie vieles, was sie dann beim dritten und vierten Service schon wissen.

Eine inspirierende User-Story zu diesem Thema gab Christian Deger zum Besten, der den ehemaligen Software-Monolithen von autoscout24 in ein Microservices-System überführt hat:

#7 – Vom Microservice zum Nanoservice: Serverless!

Wer die Idee, Software-Systeme als Kombination verschiedener Services aufzufassen, auf die Spitze treibt, landet schnell bei einem weiteren Trend-Thema der Zeit: Serverless Computing bzw. FaaS (Function as a Service) oder Nanoservices, wie es auch schon genannt wurde. Was Amazon mit seinem AWS-Lambda-Angebot vorgemacht hat, findet zügig Nachahmer bei IBM (OpenWhisk), Microsoft (Azure Functions) und Google (Google Cloud Functions).

Bewegen wir uns angesichts dieses wachsenden Angebots an (Nano-)Services also unweigerlich auf eine Welt zu, in der Server keine Rolle mehr spielen?

John Willis attestierte dem Serverless-Ansatz zwar durchaus eine rosige Zukunft; die Bereiche, in denen die Nutzung wiederverwendbarer Funktionen sinnvoll ist, werde zweifellos wachsen. Allerdings gebe es auch zahlreiche Usecases, in denen das funktionale Element nicht wirklich funktioniere – Anwendungen zum Beispiel, für die zustandsbehaftete Komponenten zentral sind. Serverless sieht Willis deshalb eher als einen komplementären denn antagonistischen Ansatz.

Sacha Möllering führte die Möglichkeiten mit AWS Lambda in seiner DevOpsCon-Session Serverless Architecture – Highly scalable Applications without any Servers vor. Im Interview mit JAXenter stellte er schön den Zusammenhang zwischen DevOps und des Serverless-Ansatzes heraus:

Das Ziel von DevOps besteht darin, mehr Agilität zu erreichen, um den Kunden Software schneller bereitzustellen. In diesem Kontext hat sich die Aufteilung der Software in Microservices als vorteilhaft erwiesen, da Teams unabhängig voneinander die einzelnen Services entwickeln können. Serverless ist einfach nur die nächste Evolutionsstufe: Serverless hilft Entwicklern, sich stärker auf die Fachlichkeit zu fokussieren, weil die Infrastruktur bzw. die notwendigen Ressourcen durch Werkzeuge wie Amazon CloudFormation erzeugt werden kann und nicht die Notwendigkeit besteht, sich um diese Komponenten zu kümmern.

#8 – Die richtige Kultur, das richtige Tool

“A Fool with a Tool is still a Fool“ – das haben wir jetzt schon oft gehört: Ohne die richtige Kultur bringt auch das beste DevOps-Werkzeug nichts. Trotzdem spielen die Werkzeuge natürlich eine tragende Rolle etwa bei der Testautomatisierung oder Umsetzung schneller Auslieferungsketten. Neben den Klassikern Jenkins, Ansible, Puppet und Chef wurden auf der DevOpsCon auch Tools wie Habitat, Prometheus und Serverspec samt Best Practices zum Umgang mit diesen thematisiert. Hier einige Spotlights:

Christian Johannsen berichtet, was es Neues aus dem Hause Chef gibt:

Sandra Parsick plädiert für Ansible, wenn es darum geht, typische Java-Artefakte wie WAR-Dateien zu verteilen.

Moritz Heiber von ThoughtWorks rät dazu, Test-driven Development mit ServerSpec zu realisieren:

#9 – DevOps von oben: Das Management in der Pflicht

Damon Edwards, Co-Founder und Chief Product Officer bei SimplifyOps, sieht hier vor allem das Management in der Pflicht:

„DevOps ist eine Aufgabenstellung für das Management“, sagt Edwards, denn ein Unternehmen sei im Grunde die Summe aller vorausgegangenen Entscheidungen des Managements. Kann man also Probleme über das Tooling oder die Technologie lösen, ohne dabei über die vom Management geschaffenen Rahmenbedingungen zu sprechen, die zum heutigen Zustand geführt haben?

Nein. „Das wäre, als ob man versuchen würde, in einem großen, schnellen Fluss gegen die Strömung zu schwimmen. Im besten Fall machen die Mitarbeiter zwar Fortschritte, aber das ist teuer und erschöpft das Team. Im schlechtesten Fall geben sie frustriert auf und werden dahin zurückgetrieben, wo sie angefangen haben – oder schlimmer.“

Im Übrigens schälte auch Edward in seiner Session „DevOps Kaizen: Empowering Teams to find and fix their own Problems“ den Zusammenhang zwischen DevOps-Philisophie und Kaizen heraus:

DevOps, Agile, Lean, Kaizen … das alles baut auf denselben elementaren Ideen auf. Bei allen geht es darum, dass Unternehmen lernen, ihre eigenen Probleme zu erkennen und zu lösen, um die Time-to-Market zu verkürzen und die Produktqualität zu erhöhen, während zugleich die Kosten sinken. DevOps ist dafür entscheidend, weil es auf den Kern aller digitalen Unternehmen ausgerichtet ist, also auf den Weg von der Anforderungsdefinition bis hin zur Ausführung von Features in der Produktion. Wenn DevOps mit Denkweisen aus Lean und Agile in anderen Teilen des Unternehmens verbunden wird, kann man Großes erreichen.

#10 – DevOps von unten: Jeder kann DevOps starten

Helen Beal zeigte in ihrem Talk indes, dass DevOps auch als Grassroot-Prozess – also quasi von unten her – gestartet werden kann. Ihrer Erfahrung nach hat sich hier ein 5-Punkte-Kurs bewährt:

Zu Beginn steht das Individuum, das den Drang verspürt, etwas im Unternehmen zu verbessern. Statt nun gleich das Management mit seinen neuen Ideen zu konfrontieren, rät Beal dazu, zunächst sein grundsätzliches Engagement und die Interaktionen mit dem Rest des Unternehmens zu erhöhen. Die gesteigerte Kommunikation mit Kollegen, auch über Team- und Abteilungsgrenzen hinweg, hilft dabei, Gleichgesinnte zu finden – sozusagen sein A-Team, das motiviert ist und dieselben Ziele verfolgt. An diesem Punkt sei es nun wichtig, durch ein geschlossenes Auftreten und überzeugende Argumente den Support der Vorgesetzten zu gewinnen.

Ist dies erreicht, kann die Phase der Experimente beginnen, in der Veränderungen in einem Pilot-Projekt umgesetzt werden können. Wichtig dabei ist das ständige Einholen von Feedback und das flexible Anpassen der Vorgehensweise und Zielsetzungen. Der wichtige fünfte Punkt besteht darin, Erfolge gemeinsam zu feiern, sichtbar zu machen und andere davon zu überzeugen.

#1: Identify or self-identify (as) a change leader
#2: Assemble your A-team
#3: Gain executive support
#4: Experiment
#5: Celebrate and showcase (tell people about it)

See you in Berlin!

Wie immer können wir nur einen kleinen Eindruck vermitteln, was in den über 50 Talks, Workshops und Keynotes zu lernen war. Für den tiefen Einstieg halten Sie hier auf JAXenter die Augen offen. Dort finden Sie neben Videointerviews mit den Speakern auch demnächst alle Keynotes und ausgewählte Sessions in voller Länge. Wenn das nicht reicht, kommen Sie doch auf der DevOpsCon 2017 in Berlin vorbei!