Highlights von der DevOpsCon 2018 in Berlin

Take-aways von der DevOpsCon 2018: DevOps bleibt im steten Wandel

Dominik Mohilo

© Shutterstock / Kim Reinick (modifiziert)

Die DevOpsCon 2018 in Berlin ist vorbei und wieder einmal gab es eine große Vielfalt an Themen, über die gesprochen wurde. Im Zentrum standen diesmal die Unternehmenskultur, der Wandel von DevOps im Laufe der letzten Jahre und dessen zukünftige Entwicklung, Serverless, Kubernetes und das Monitoring. Wir stellen heute einige Highlights der Konferenz vor.

Auch in diesem Jahr begrüßten wir zur „Sommeredition“ der DevOpsCon 2018 zahlreiche Besucher und Speaker in Berlin. Die über 70 Keynotes, Sessions, Labs und Workshops standen dabei wieder unter dem Motto „Rethink IT“, das bereits seit der ersten DevOpsCon im Jahr 2015 der Slogan der Veranstaltung ist.

Das Thema „DevOps“ hat in den vergangenen drei Jahren wenig an Aktualität verloren, die DevOps-Kultur ist aber mittlerweile durchaus in den Unternehmen angekommen. Das zeigt die kurze Umfrage, die Sebastian Meyen, Program Chair der DevOpsCon, nach der Begrüßung auf der Bühne unter den Besuchern durchführte: Nur für einen Bruchteil der Teilnehmer war das Thema DevOps noch Neuland, ebenso wenige sehen sich als DevOps-Profis. Die meisten Besucher, von denen etwa 75 Prozent Entwickler waren und 25 Prozent aus dem Operations-Bereich kamen, ordneten sich eher im gesunden Mittelfeld ein, was den Kenntnisstand in Sachen DevOps angeht.

Monitoring vs. Observability: „Test in production!“

In ihrer Eröffnungskeynote mit dem Thema „Observability for emerging Infra: what got you here won’t get you there“ stellte Charity Majors, CEO und Mitgründerin von Honeycomb.io, zunächst klar, dass sie Monitoring hasst und Honeycomb auch kein Monitoring-Unternehmen sei. Während die Komplexität von Softwaresystemen und -architekturen zunimmt, tritt Monitoring seit 20 Jahren auf der Stelle. Die daraus resultierende Quintessenz war für unsere Speakerin, dass Monitoring ein veraltetes Modell ist und man lieber auf Observability setzen soll.

Beim Observability-Ansatz geht es nicht um Metriken, diese sind dort nutzlos. Auch Dashboards, wie sie beim Monitoring häufig zum Einsatz kommen, sind dort überflüssig. Im Grunde geht es bei der Observability nämlich um Events. Der Vorteil von Events ist laut Charity, dass sie Geschichten erzählen und nicht einfach nur wie Metriken reine Daten geben. Sie zeigen, was gerade im Moment passiert, während Dashboards nur „Artefakte vergangener Fehler“ sind. Diese Geschichten (oder auch: User Stories) sind deswegen so wichtig, weil die User nicht der Status oder der Zustand eines Systems an sich interessiert, sondern lediglich ihre eigene User Experience.

Das wichtigste sei daher, so Charity, in Produktion zu testen. Man könne natürlich auch die Software vorher testen, aber das verleite dazu, sich zu sehr auf Daten und Statistiken zu verlassen. Real-Life-Events, wie unsere Speakerin es nennt, seien für Entwickler noch immer nicht oft genug Maß der Dinge.

DevOps im steten Wandel: „Disrupt yourself or be disrupted!“

Die Tech-Industrie ist eine der sich am schnellsten verändernden Branchen überhaupt. Das passiert oftmals in einem solchen Maße, dass es zuweilen chaotisch wirkt, wie Greg Bledsoe, Managing Consultant bei Accenture, in seiner Keynote mit dem Thema „Use DevOps to identify, embrace, and drive exponential Change“ verriet. Doch Veränderung ist normal: Leben bedeutet Veränderung und Stillstand im Umkehrschluß den Tod. Das gilt insbesondere, aber nicht nur, für die Tech-Branche. Man sehe sich bei dieser Gelegenheit nur einmal an, was die aktuellen Fintech-Startups mit den großen Banken und Uber mit der Taxi-Industrie veranstaltet: Neue Ideen und disruptive Innovationen setzen die „Altvorderen“ unter Druck – keiner ist über Disruption erhaben. Das liegt unter anderem auch daran, dass die Kosten, in einen Markt einzusteigen, immer geringer werden. Durch die Erfindung des Internets und die Verbreitung von Technologien steigt die Zahl der möglichen Innovatoren exponentiell an. Die Revolution, die die Erfindung des Internets ausgelöst hat, ist laut Greg Bledsoe mit der Erfindung des Buchdrucks zu vergleichen.

Ein Problem, das viele klassische und konservative Unternehmen haben, ist das Mindset, wie Greg weiß: Oftmals wird an Abläufen bzw. Prozesen, Technologien und Herangehensweisen festgehalten, obwohl sie sich nicht für die Zukunft bewähren können. Schuld daran sei, dass sich Unternehmen scheuen, Dinge zu ändern, in die sie viel Arbeit, Zeit und Geld investiert haben. Was nutzt das alles aber, wenn man links und rechts von innovativeren Unternehmen überholt wird? Wenn etwas nicht läuft, muss man es ändern, ist die Lehre, die Greg Bledsoe daraus zieht. Man sollte allerdings klar abwägen: Änderungen durchzuführen, nur weil man eben etwas verändern will sei gefährlich.

DevOps ist ein Fallbeispiel, wie man auf exponentielle Veränderungen reagieren muss. Unsere Idee von DevOps verändert sich – wie die Welt in der wir leben – kontinuierlich und von Tag zu Tag. Gleich bleibt dabei nur die Tatsache, dass DevOps eine kollaborative Methode ist, bei der versucht wird, Entscheidungen nicht auf der höchstmöglichen Unternehmensebene zu treffen. Die Welt sei, wie unser Speaker feststellte, einfach zu komplex, um zentral gemanagt zu werden und starke Hierarchien seien zudem vollkommen ungeeignet, um sich den Herausforderungen von sich kontinuierlich verändernden Umständen effektiv zu stellen. Stattdessen empfiehlt er, die Entscheidungen auf der tiefstmöglichen Ebene zu treffen, wie es im Agile- oder LEAN-Ansatz üblich ist.

Zum Schluss fasste Greg Bledsoe zusammen, dass in der modernen Welt der Unternehmen die IT nicht mehr der Falschenhals für Innovationen ist, wie es früher der Fall war. Heutzutage ist die IT nämlich durch die modernen DevOps-Prinzipien bereit, als Speerspitze für das Vorantreiben des Unternehmens zu fungieren – nun müsse lediglich das Unternehmen an sich zu dem aufholen, was die IT heute bereits liefern kann.

Serverless und DevOps: „Owners, not Operators!“

Die Frage ob Serverless Container, Infrastructure as Code oder auch DevOps überflüssig machen wird, ist derzeit heiß diskutiert. Chad Arimura, Vice President of Serverless bei Oracle, gibt Entwarnung: Serverless wird DevOps nicht verändern. In seiner Keynote mit dem Thema „CI/CD in a Serverless World“ stellte er zudem fest, dass Serverless nicht bedeutet, dass keine Server mehr gebraucht würden und auch der Beruf des Operators sei seiner Meinung nach sicher. Serverless stelle viel mehr eine geringere Notwendigkeit von Code dar. Durch Serverless werde, so Chad, die Verantwortlichkeit über die Dinge, die Entwickler und Unternehmen produzieren, über APIs an andere Nutzer delegiert. Außerdem sei Serverless heute noch lange nicht da, wo es sein muss.

Chad Arimura erklärte, dass neue und innovative Technologien oft den gleichen Lebenszyklus durchleben: Zunächst gehe die Begeisterungskure steil bergauf, bis der sogenannte „Gipfel der aufgeblasenen Erwartungshaltung“ erreicht sei. Serverless stehe gerade genau dort. Anschließend, nämlich wenn die Unternehmen und Anwender merken, dass die neue Technologie nicht alle Probleme lösen kann, gibt es einen massiven Absturz ins „Tal der Desillusion“, bevor es dann wieder bergauf geht und man schließlich auf dem „Plateau der Produktivität“ landet. Das Ziel für unseren Speaker sei, das Tal der Desillusion durch die richtige Kommunikation, was Serverless sei und was nicht, schon im Vorfeld zu überwinden.

DevOps wird nicht von Serverless zwar nicht essentiell verändert, allerdings hat der neue Ansatz dennoch Einfluss auf DevOps. Durch neue Funktionen, schnellere und häufigere Deployments, schnelleres Testen und neue Geschäftsideen wird auch das DevOps-Prinzip beeinflusst. Hinzu kommen neue Tools und Plattformen, mit denen sich Entwickler und Operator auseinandersetzen müssen. Da bei Serverless alles ein Service ist, weniger Code geschrieben wird, kleinere Teams und Projekte entstehen, müssen DevOps-Teams die Grenzen von Services erkennen lernen. Auch die Kultur des sogenannten „Ownerships“ wird zunehmend wichtiger, frei nach dem Motto „Owners, not Operators“.

Musik, Kubernetes und der Orchestrierungskrieg: „Keep focus on your use case!“

Eines der Tools, die beim Thema DevOps immer häufiger und immer wieder genannt werden, ist Kubernetes. Bereits Terry Shea, Senior Manager bei Kublr, gab in seiner Keynote „The Kubernetes Evolution and a Use Case with Questback“ bekannt, dass Kubernetes eindeutig den sogenannten „Orchestration War“ gewonnen und Docker Swarm auf seinen Platz verwiesen habe. Auch im Hinblick auf die Bereiche Data Science und Machine Learning sei die Wichtigkeit von Kubernetes immer weiter auf dem Vormarsch, nicht zuletzt durch die native Unterstützung von Kubernetes in Apache Spark 2.3 (Terry Shea schrieb dazu auch einen Artikel für JAXenter).

Die Angst vor Kubernetes wollte Carsten Duch schließlich in seiner Keynote zum Thema „Production ready Kubernetes, easy as beatmaking!“ nehmen. Die Plattform sei komplex, ja, aber nicht so kompliziert, wie man denken möge, teilte er den Besuchern mit. Um seinen Punkt zu verdeutlichen, griff er dabei auf reine Metapher aus seinem Leben zurück: Schon immer wollte er gerne Schlagzeug spielen, habe seinen Use Case also recht eindeutig identifiziert. Da das Schlagzeug seinen Eltern aber zu teuer war, bekam er eine alte Akustikgitarre – das Äquivalent einer Management-Entscheidung, die fernab vom Use Case liegt. Genau wie in der Musikproduktion, muss zwischen Entwicklern und dem Management ein gleiches Verständnis vom Use Case bestehen, ansonsten gibt es unüberwindbare Hürden.

Wichtig sei außerdem, nicht den Use Case aus dem Auge zu verlieren. Wenn man glaubt, man brauche etliche Tools (oder Instrumente, in der Musikmetapher), um produktionsfertige Software (oder Musik) zu erstellen, verliert man schnell den Fokus. Manchmal sei es hilfreich die Komplexität herunterzuschrauben, im Falle Kubernetes heißt das bestehende und bekannte Patterns zu verwenden. Standards helfen ebenfalls, etwa standardisierte Plug-ins. Für Kubernetes-Plug-ins gibt es als Standards zum Beispiel das Container Storage Interface (CSI) und das Container Network Interface (CNI). Falls dies nicht reiche, könne man immer noch auf speziellere oder gar kommerzielle Lösungen zurückgreifen. Für Carsten Duch sind standardisierte Plug-ins und die Nutzung bereits existierender Lösungen in Verbindung mit dem festen Fokus auf dem Use Case der Schlüssel für den erfolgreichen Einsatz von Kubernetes.

Wir bedanken uns bei allen Teilnehmern und Speakern der DevOpsCon 2018!

DevOpsCon Dossier 2018

Free: 40+ pages DevOps knowledge by experts

Learn about Docker, Kubernetes, Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Kai Tödter (Siemens), Nicki Watt (OpenCredo), Tobias Gesellchen (Europace AG) and many more.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: