Highlights von der DevOpsCon 2018 in München

Von Tauchgängen, Sicherheitssünden und Open Source: 11 Take-aways von der DevOpsCon 2018

Dominik Mohilo, Hartmut Schlosser, Katharina Degenmann

© Shutterstock / Kim Reinick (modifiziert)

Die Definition von DevOps? Eine schwierige Frage, wie die DevOpsCon 2018 in München einmal mehr zeigte. Heute, zehn Jahre nachdem der Begriff zum ersten Mal auftauchte, erscheint die genaue Bestimmung, was mit „DevOps“ eigentlich gemeint ist, noch immer hochkomplex und keineswegs leichter als damals. Vielleicht wird es nie eine genaue Definition geben. Das heißt aber nicht, dass es keine neuen Erkenntnisse auf dem Gebiet gibt: Hier sind unsere 11 Take-aways von der diesjährigen DevOpsCon in München.

Take-away #1: DevOps ist keine Definition

Was ist DevOps eigentlich? Diese Frage ging Sebastian Meyen (Software & Support Media) in seiner Konferenzeröffnung an. Drei Aspekte stachen dabei heraus:
Da ist zum einen der Ansatz, DevOps als Kollaborationskonzept zu sehen. Die oftmals getrennt voneinander arbeitenden Abteilungen Entwicklung und Operations sollen besser miteinander kommunizieren, sich als eine Einheit mit einem gemeinsamen Ziel verstehen. Insbesondere da Software-Systeme zunehmend komplex werden, scheint die einst vielleicht (?) einmal sinnvolle Trennung der Abteilungen nicht mehr opportun zu sein.

Zweitens ist DevOps auch ein Technologie-Thema: IT-Infrastruktur lässt sich heute zu einem großen Teil in Code abbilden. Deployment-Pipelines lassen sich automatisieren. Container-Technologien ermöglichen die Abstraktion von den individuellen Hardware-Gegebenheiten. „In der Cloud wird das Backend zur Commodity“, sagt Sebastian Meyen, und meint damit, dass die Zeiten, als das Technologie-Backend einen signifikanten Wettbewerbsvorteil gegenüber der Konkurrenz geboten hat, vorbei sind. Über Erfolg oder Misserfolg entscheidet heute viel eher die Funktionalität im Frontend, die gelungene User Experience, die Interaktion mit den Kunden.

Drittens gehört DevOps zum Komplex der digitalen Transformation. Die IT ist in vielen Domänen von einer reinen Hilfsdisziplin zu einem zentralen Asset aufgestiegen, ohne das Unternehmen ihre Geschäftsziele nicht erreichen. Die Unvorhersehbarkeit der Märkte erfordert einen neuen Grad der Reaktionsfähigkeit. Die DevOps-Bewegung beantwortet diese Herausforderung damit, das in der Software-Entwicklung viele Jahre lang bewährte Konzept der Agilität auf alle Bereich eines Unternehmen zu übertragen. Technologisch richtet man sich darauf ein, immer kürzere Time-to-Market-Spannen zu erreichen, um Kunden-Feedback und Marktveränderungen schnell berücksichtigen zu können.

Ist DevOps damit ausreichend definiert? Natürlich nicht! Doch liegt die Stärke des Begriffs vielleicht gerade in seiner Unabgeschlossenheit. Denn so können sich die unterschiedlichsten Parteien mit DevOps identifizieren und Nützliches erreichen.

Take-away #2: Sicheres Eintauchen in die IT

Was können wir von professionellen Tiefseetauchern über Security lernen? Mit dieser Frage brachte Ronnie Chen (Twitter) das DevOpsCon-Publikum zum Denken.

Nun, das Tauchen gehört sicherlich zu den Tätigkeiten, bei denen Sicherheitsprobleme fatale Folgen zeitigen können. Das Training für technisches Tauchen zielt deshalb einerseits darauf ab, Fehler zu vermeiden (pre-mortems) – doch nicht nur! Das Tauchen hängt von dermaßen vielen Faktoren ab, dass Fehler – menschliches Versagen, widrige Umstände, Materialprobleme, etc. – nicht ausgeschlossen werden können. Im Tauchtraining werden deshalb Fehler gezielt simuliert, Probanden müssen daran gewöhnt werden, in Extremsituationen adäquat zu reagieren und lebensrettende Entscheidungen zu treffen. Drittens ist es für ein Team von Tauchern wichtig, einmal begangene Fehler offen zu besprechen und das Verhalten beim nächsten Tauchgang entsprechend anzupassen (post-mortems).

Die Sicherheit eines Taucher-Teams berechnet sich nicht anhand des Teammitglieds mit der größten Erfahrung. Es kommt darauf an, dass jedes einzelne Teammitglied einen möglichst hohen Erfahrungswert mitbringt, damit beispielsweise auch beim Ausfall des Teamleiters eine Rettung möglich wird. Aus diesem Grund führen oft die unerfahrendsten Taucher ein Team an, allenfalls angeleitet vom Tauchlehrer.

Analog sollte auch das Wissen eines IT-Teams möglichst gleichmäßig verteilt sein. In Sachen Security gilt es also nicht, die Spitze weiter anzuheben, sondern vor allem das Wissensplateau des Teams zu erhöhen.

Take-away #3: Agile und der „Puls von DevOps“

Agile Transformation kann nicht allein durch die reine Übernahme agiler Prinzipien bzw. DevOps-Methoden gelingen. Mit dieser These eröffnete Sabine Fontanive-Michael (Accenture) ihre Keynote. Viele Unternehmen wollen DevOps im Unternehmen einführen, um die Effizienz zu steigern. Das wiederum erfordert neben den Automatisierungspraktiken, auch Änderungen in der Arbeitsweise und vor allem die Zusammenarbeit zwischen Devs und Ops. Doch das ist nicht das Ende der Geschichte – hier beginnt sie erst!

Wer DevOps erfolgreich umsetzen möchte, darf nicht allein die Mauern zwischen Devs und Ops überwinden, er benötigt ein komplettes agiles Ökosystem im gesamten Unternehmen. Nach Fontanive-Michael müssen hierfür drei große Hindernisse bewältigt werden. Zu Beginn müssen Wasserfall-Strukturen durch Teams abgelöst werden, dann sollten die Mauern zwischen Devs und Ops überwunden werden, bevor als letzter Schritt eine Kombination aus Agile und DevOps entsteht.

Zusammengefasst heißt das, erst wenn alle Unternehmensbereiche den „Pulse of DevOps“ spüren, kann agile bzw. die DevOps-Transformation gelingen.

Take-away #4: Mit Roadmaps geplant zum Ziel

Schlechter Code verursacht 85 Milliarden US-Dollar an Kosten jährlich. Der Grund? Nun, da gibt es sicher viele. Keine gute oder eine zu kurzfristige Planung zu haben, ist sicher essentieller Bestandteil des Problems. Daher sollte man, so Kristen Womack (Hello Mom), Projekte immer mit einer handfesten Roadmap zu starten, die nicht nur die nächsten zwei Wochen abdeckt.

Man könnte sich jetzt Fragen, was gute Planung und Roadmaps mit DevOps zu tun haben. Das ist eigentlich ganz einfach: Da DevOps auch die Automatisierung fördern soll, kann man sich ausreichend Zeit nehmen, um gute und hilfreiche – also weitreichende – Roadmaps für ein Projekt zu erstellen. Wer nicht nur die kommenden zwei Wochen, sondern die kommenden zwei Quartale im Blick hat, wird definitiv erfolgreicher sein, als jene deren Horizont nur bis zum nächsten Testlauf oder Bugfix reicht.

Ist der Plan gefasst, kann es mit dem Projekt losgehen, oder? Das ja, doch die Arbeit „drumherum“ ist damit noch nicht vorbei. Denn – wie Kristen Womack anmerkt – ist die Arbeit an komplexen Systemen und Services niemals beendet, es gibt keinen Zustand mit dem Titel “Mission Accomplished”. Hierfür gibt es fünf einfache Regeln, die man beachten sollte:

  1. Vanity-Metriken vermeiden: Metriken, die nur untermalen, was wir gut machen, bringen uns nicht weiter. Sie kratzen nur an der Oberfläche und lassen uns keine Lehren für eine Verbesserung ziehen.
  2. Daten visualisieren: Erst wenn wir Daten visualisieren, können wir aus reinen Informationen Bedeutungen ablesen.
  3. User Patterns finden: Nutzer haben gewisse Ansprüche an das, was Entwickler bauen. Um herauszufinden, was benötigt wird, um diesen gerecht zu werden, müssen User Patterns gefunden werden. Erst anhand dieser wissen wir, was genau zu tun ist.
  4. Überwachung von innen: Um die Qualität der Anwendung möglichst hoch zu halten, sollten Tests in den Entwicklungsprozess implementiert werden (Test-driven Development) und direkt überwacht werden. Angenehmer Nebeneffekt: Zeitersparnis.
  5. Die Kultur überwachen: „Nicht alles, was man zählen kann zählt und nicht alles, was zählt, kann man zählen“, wusste schon Albert Einstein. Es ist daher wichtig, Feedback-Loops in den Entwicklungsprozess einzubinden und immer im Blick zu behalten, was die User wollen. Denn die Software, die wir heute schreiben, so Womack, sind die technischen Schulden von morgen.

Take-away #5: Die sieben größten Security-Sünden

Auch mit agilen Arbeitsweisen lässt sich ein gutes Security-Niveau erreichen, ohne dabei die Vorteile der Agilität einzubüßen. Um das zu ermöglichen, machte Christian Schneider (Schneider IT-Security) auf die sieben größten Probleme bzw. Szenarien aufmerksam, die bei der Integration von Sicherheit in agilen Projekten auftreten. Zu den sieben Todsünden in agilen Projekten gehören:

  • Fehlendes Witheboard Hacking
  • Fehlende Security-Architekturen
  • Fehlende Security-Automatisierung
  • Fehlende Offensive Penetration
  • Fehlende organisatorische Transformation
  • Fehlendes Continuous Training
  • Fehlende Vorbereitung auf Sicherheitslecks

Natürlich hatte Schneider für all diese Probleme auch eine Lösung parat. So setzt er bei fehlender Sicherheitsarchitektur auf Kryptographie. Getreu dem Motto „good crypto really helps“, lasse sich die Sicherheitsarchitektur beispielsweise ausgleichen. Neben technischen, organisatorischen und prozessorientierten Problemen gibt es vor allem auch fachliche Fragen, mit denen sich Teams konfrontiert sehen, wenn sie versuchen, die Sicherheit ihrer Projekte nachhaltig zu verbessern. Doch insgesamt zeigte Schneider mit seinen praxisbezogenen Anleitungen vor allem eines: Für jedes Problem gibt es eine Lösung.

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.

Take-away #6: Open Source ist gekommen, um zu bleiben

Die Nutzung von Open-Source-Software ist immer mit gewissen Risiken verbunden, denn im Prinzip kann jeder an einem Projekt mitarbeiten. Dass es dabei nicht ständig zu Katastrophen kommt, ist fleißigen und gutmütigen Entwicklern zu verdanken, die diese Projekte verwalten und betreuen. Manchmal stecken dahinter Unternehmen (exemplarisch sei hier einmal Red Hat genannt), manchmal einfach nur engagierte Hobbyisten.

Dennoch gibt es die eben erwähnten Risiken, die sich nach Stanislav Sivak (Synopsys), in drei Kategorien einteilen lassen:

Risikofaktor „Informationen“

UnteTake-away #6:rnehmen wollen in der Regel wissen, welche Open-Source-Komponenten in den eigenen Projekten und der eigenen Software genutzt werden. Diese Informationen sind nicht immer schlüssig und manchmal schlicht nicht zu bekommen.

Risikofaktor „Lizensierung“

Beim Einsatz von Open-Source-Software kann es auch aufgrund der Lizensierung zu Problemen kommen. Es gibt viele Open-Source-Lizenzen, etwa die Apache-2.0-Lizenz, die Eclipse Public License 2.0 und die MIT-Lizenz. Manchmal vertragen diese Lizenzen sind nicht untereinander. Auch die Frage, ob kommerzielle Nutzung einer Open-Source-Komponente überhaupt legal ist, stellt sich manchmal.

Risikofaktor „Aktivnutzung“

Die dritte Kategorie betrifft die Software bzw. die Komponenten selbst. Bugs, Fehler, Sicherheitslücken im Source Code etc. können durchaus vorkommen.

Trotz all dieser Risiken und Nebenwirkungen ist sich Stanislav Sivak sicher, dass Open Source in Zukunft eine noch wichtigere Rolle spielen wird. Die Risiken sind bekannt und Lösungsansätze – etwa der Einsatz dezidierter Entwickler und Architekten, die Open-Source-Software vor dem Einsatz prüfen – sind ebenfalls bekannt. Open-Source-Software wird demnach in Zukunft ganz im Sinne des Gedankens „Automate, Scale and Monitor“ in der DevOps-Welt heimisch bleiben.

Take-away #7: Visualisieren was wir denken

Wie arbeiten wir besser zusammen? Ein Teil der Antwort auf diese Frage lautet: Indem wir besser miteinander kommunizieren. Doch wir kommunizieren wir besser? Markus Andrezak (überproduct GmbH) gab in seiner Session „Enabling Communication across Dimensions – Top down, Bottom up, across Silos“ Hinweise.

Im Rahmen der DevOps-Bewegung stellt sich immer wieder die Frage, wie sich Kommunikationsdefizite zwischen getrennten Abteilungen überbrücken lassen. Das Ziel besteht darin, ein gemeinsames Verständnis über Arbeitsabläufe und Ziele herzustellen.

Auf der Suche nach Lösungen stößt Andrezak auf den Writers‘ Room von Game of Thrones. Hier arbeitet ein Team aus über 30 Autoren kollaborativ an den Dialogen der Serie. Wir funktioniert dort das gemeinschaftliche Schreiben? Über eine Pinnwand, auf die die wichtigsten Erzählungsstränge auf Zettel für alle sichtbar angeheftet werden.

Wie lösen die investigativen Teams in Krimiserien ihre Fälle? Über eine Pinnwand, auf der alle noch so unwichtig erscheinenden Erkenntnisse eines Falls für alle sichtbar visualisiert werden.

Ergo: Komplexe Tätigkeiten müssen visualisiert werden, um sie kommunizieren zu können. Und die IT ist ebenfalls eine komplexe Tätigkeit. Am Anfang der Kollaboration zwischen Unternehmenssilos könnte also auch eine ganz einfache Pinnwand stehen, ein Dashboard, auf dem die Tätigkeiten der Abteilungen zunächst in getrennten Spalten visualisiert werden. Irgendwann wird dann vielleicht der Trennstrich zwischen den Spalten etwas durchlässiger. Irgendwann entfällt er vielleicht sogar ganz. Artefakte sind Materialisierungen unseres Denkens.

Take-away #8: Java ist bereit für die Cloud

Die Java-Welt dreht sich und das ziemlich schnell. Hinsichtlich Java, der JVM und dem Java-Ökosystem hat sich einiges verändert. Besonders der veränderte Release-Prozess sorgt für viele Fragen und Unsicherheiten. Ist Java immer noch kostenlos? (Ja) Zahlt man für die Updates? (Kommt darauf an). All diese Fragen beantwortete Sebastian Daschner.

Durch den neuen Release-Prozess hat das gesamte Java-Ökosystem Fahrt aufgenommen, es wurde schneller. Wie kann man als Java-Entwickler dabei am besten mithalten? Durch die Cloud, sagt Daschner. „Mit einer Cloud ist eine bessere Skalierung möglich, da man genau das skalieren kann, was man möchte.“ Und der Java-Anwendungsstapel, die zugehörigen Open-Source-Technologien und das Java-Ökosystem haben sich bereits verändert, um den Anforderungen der Cloud gerecht zu werden. Das spiegle sich hauptsächlich in verbessertem Speicherbedarf, neuen Betriebsarten, unterschiedlichen Bereitstellungsmodellen und auch in neuer Hardware wider. Wer sich darauf einlässt und die neuen Möglichkeiten nutzt, könne also effizienter sein. Java ist offenbar bereit für die Cloud.

Take-away #9: Ohne Daten bist du auch nur jemand mit einer Meinung

Taten zählen oft mehr als Worte und das gilt auch für DevOps. Diese Erfahrung haben zumindest Leonid Igolnik (SignalFx) und Baruch Sadogursky (JFrog) gemacht. In ihrer Keynote erklärten sie daher, wie datenbasiertes DevOps Entwicklerteams helfen kann.

Ein altbekanntes Phänomen und ein Problem unter Programmierern sei der Optimismus. Viele Entwickler verlassen sich zu sehr auf ihre Erfahrungswerte und überschätzen sich dabei selbst, was sie anfälliger für Fehler mache. Zudem fördere diese Selbsteinschätzung den Konkurrenzkampf unter Entwicklern, wer denn nun der Bessere sei. Und genau hier kommt datenbasiertes DevOps ins Spiel. Schließlich sind Daten neutral und beweisen am besten, welche Strategie die geeignetere ist. Oder anders gesagt: „Without data, you’re just another person with opinions“

Datenbasiertes DevOps ist eine Kombination aus Dev, QA and Ops. Für jeden dieser Bereiche präsentierten Igolnik und Sadogursky, neben Do’s and Dont’s, auch aus der Erfahrung gewonnene Beispiele, die Teams bei der Umsetzung von DevOps helfen können. So sei beispielsweise ein gemeinsames Vokabular ein wichtiger Faktor in der Implementierung von DevOps. Geht es um Daten, seien Metriken ein gutes Mittel, um sich eine Übersicht zu verschaffen. Letztendlich können Daten der Schlüssel für eine erfolgreiche Umsetzung von DevOps sein: Durch Daten kann eine gemeinsame Basis für Kommunikation geschaffen werden, damit könne man die gesamte Kultur verändern und DevOps eingeführt werden.

Take-away #10: Man kann auch freitags Deployen!

Aus arbeitstechnischer Sicht ist Freitag ein Tag wie jeder andere. Nur nicht, wenn es um Deployments geht. Offensichtlich gilt das Deployen am Freitag als Horrorszenario für Entwickler. Diese Angst vor Freitagen nimmt Michiel Rook zum Anlass, in seiner Session zu erklären, wie Deploying auch am Freitag gelingen kann bzw. wie man ohne große Zwischenfälle deployed.

Rook setzt dabei zunächst auf kleinere Schritte, denn die seien leichter zu überwachen und reduzieren das Fehlerrisiko. Zudem wird geraten, Pipelines mit Jenkins aufzubauen, Tests zu automatisieren, Continuous zu deployen (continuous deployment) und zum Monitoring. Für diese einzelnen Prozesse könne man trunk based development, feature Toggles und pair programming nutzen. Durch diese Best Practice und das Vertrauen in sein Können, gelingt das Deploying mehrmals am Tag und an jedem Tag der Woche. (KD)

Take-away #11: Warum Gopher die DevOps-Welt erobern

DevOps ist nicht nur eine Frage der richtigen Kultur, DevOps steht und fällt auch mit den entsprechenden Tools. Natürlich funktioniert das ganze Konstrukt nur, wenn beide Bereiche ausreichend und sinnvoll abgedeckt sind. Was genau das bedeutet, muss für jedes Unternehmen individuell entschieden werden. Doch gerade in Sachen Tooling gibt es eine interessante Konstante: Die Programmiersprache Go.

Sieht man von den Automatisierungswerkzeugen wie Puppet, Chef oder Ansible einmal ab, sind die bekanntesten Tools im DevOps-Umfeld in Go geschrieben: Docker, Kubernetes, Istio, Grafana, Prometheus etc. Doch warum genau ist das so? Natalie Pistunovich erklärte dazu, dass vor allem Spracheigenschaften wie Typsicherheit, eine starke Typisierung und die klare Syntax, die sich besonders für Nebenläufigkeit eignet, eine wichtige Rolle beim Erfolg von Go in der DevOps-Welt spielen.



Selbst Speaker werden?

Wer selbst einmal Lust hat, auf der DevOpsCon eine Session zu halten, der hat noch bis 13. Dezember die Möglichkeit, ein Abstract einzureichen:

Verwandte Themen:

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.
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Katharina Degenmann
Katharina Degenmann
Katharina Degenmann hat Politikwissenschaft und Philosophie studiert. Seit Februar 2018 arbeitet sie als Redakteurin bei der Software & Support Media GmbH und ist nebenbei als freie Journalistin tätig.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: