Eduards Sizovs im Interview

Pragmatisches Continuous Delivery: „Nicht jeder braucht eine Infrastruktur wie Netflix“

Redaktion JAXenter

Continuous Delivery liegt voll im Trend. Trotzdem gibt es noch immer Unternehmen, denen die Wichtigkeit von Continuous Delivery nicht klar ist – und die nicht verstanden haben, welche Stolpersteine auf dem Weg dahin lauern. Wir haben mit dem DevOpsCon Speaker Eduards Sizovs über die Bedeutung von Microservices für Continuous Delivery Pipelines und einige Methoden gesprochen, die Unternehmen dabei helfen sich über Wasser zu halten.

Eduards Sizovs ist Software Development Coach und Speaker auf der kommenden DevOps Conference In diesem Interview gibt er Einblicke in seine Erfahrungen mit der Einführung von Continuous Delivery, benennt Fallstricke, die Unternehmen dabei umgehen sollten und gibt Tipps, wie Unternehmen diesen Prozess überleben können.

JAXenter: Continuous Delivery ist Dein Thema auf der DevOpsCon 2016. Da es sich bei CD um ein ziemliches Buzzword handelt, macht es Sinn, erst einmal mit einer Definition zu beginnen: Was ist Deiner Meinung nach der zentrale Aspekt von Continuous Delivery?

Eduards Sizovs: Bei Continuous Delivery geht es darum, unsere Ideen schnell, verlässlich und kosteneffizient an den Nutzer auszuliefern. Die Sache mit den Kosten wird allerdings oft vergessen, sodass immer wieder große Summen für Infrastrukturen ausgegeben werden, die höchstens Unternehmen wie Netflix brauchen. Ich bin überzeugt von einem Werte-zentrierten Zugang zu Continuous Delivery. Wir müssen all unsere Ideen mit den Kosten und dem Nutzen abgleichen, die diese Veränderung mit sich bringen würde. Das gilt auch für Verbesserungen an der Auslieferung. Dann suchen wir uns das „wertvollste Problem“ aus, lösen es, danach ist das nächste dran und so weiter.

JAXenter: Du wirst auf der DevOpsCon ja ein paar „Battle Stories“ erzählen, also von realen Problemen bei der Einführung von Continuous Delivery berichten. Wie wäre es mit einer kleinen Vorschau?

Eduards Sizovs: Ich habe in den letzten fünf Jahren daran mitgearbeitet, Continuous Delivery in Unternehmen jeder Größenordnung zu implementieren. Meiner Erfahrung nach verhält sich die Anzahl lustiger Geschichten direkt proportional zum Budget, das ein Unternehmen in dieses Vorhaben steckt. Natürlich kann ich in meiner Präsentation keine Namen nennen, aber so viel kann ich bereits jetzt verraten: Ich werde acht Geschichten darüber erzählen, wie Continuous Delivery so richtig schiefgegangen ist. Kommt vorbei!

JAXenter: Microservices sind gegenwärtig einer der wichtigsten Architektur-Trends. Welche Rolle spielen Microservices bei der Einführung von Continuous Delivery Pipelines?

Eduards Sizovs: Die Bezeichnung „micro“ verwende ich gar nicht. Stattdessen spreche ich lieber von einer „Zerlegung“. Wer Anwendungen klug unterteilt und dabei die Strukturen des Unternehmens beachtet, kann viele unabhängige Contonuous Delivery Pipelines erstellen. Grundsätzlich ist es doch so: Solange kein Grund für eine koordinierte Zusammenarbeit besteht, liefern zwei separate Teams das Doppelte an Durchlauf, drei Teams das Dreifache. In der Realität ist ein so optimales Ergebnis natürlich nur schwer zu erreichen. Ein Ziel ist aber, wie Bruce Lee einmal gesagt hat, nicht immer dazu da, um auch erreicht zu werden. Oft dient es nur dazu, auf etwas hinarbeiten zu können. Wenn es um Continuous Delivery geht, sieht die beste Lösung so aus, dass die technologische Architektur ein gleichförmiges Abbild der Unternehmensstruktur darstellt.

„Bei Continuous Delivery geht es darum, unsere Ideen schnell, verlässlich und kosten-effizient an den Nutzer auszuliefern.“

JAXenter: Du wirst ja einen Vortrag auf einer DevOps-Konferenz halten – lass uns also mal über den Zusammenhang von DevOps und CD sprechen. DevOps besteht zum Teil aus Tools und Methoden, zum Teil aber auch aus einer gewissen Kultur. Welchen Einfluss auf die Organisationskultur konntest du in realen Projekten nach der Einführung von Continuous Delivery beobachten?

Eduards Sizovs: Kurze Auslieferungszyklen üben Druck auf das Auslieferungsteam aus. Das Team wird dazu gezwungen, sich selbst zu organisieren, um mit diesem Druck umzugehen – das ändert die Dynamiken des Spiels total, was super ist! Verschiedene Teams gehen unterschiedlich mit diesem Druck um, der Kreativität sind da keine Grenzen gesetzt. Manche Teams automatisieren beispielsweise sich wiederholende Abläufe, um mehr Zeit für wichtigere Dinge zu haben, oder halten an starren Arbeitsweisen wie verbindlichen Code-Reviews oder TDD fest, um spätere Überarbeitungen zu vermeiden. Manche werden auch besser darin, den Wert bestimmter Aufgaben abzuschätzen, indem sie dem Kunden zuhören, das Problem verstehen, Optionen vorschlagen und so weiter. Unerfahrene Teams zerbrechen allerdings oft unter dem Druck und nehmen Abkürzungen (die dann wieder zu langen Verzögerungen führen). Da kann ich weiterhelfen!

JAXenter: Was ist die Kernaussage deiner Session auf der DevOpsCon, die jeder Teilnehmer aus dem Vortrag mitnehmen sollte?

Eduards Sizovs: Das ist wohl mein Mantra:  KIND ASS – Keep It Need Driven And Simple, Sir!

Vielen Dank für das Gespräch!

J. Eduards Sizovs gibt zwei Sessions auf der DevOpsCon. In der einen beleuchtet er das Konzept des pragmatischen Continuous Delivery, in der anderen erklärt er, warum Continuous-Delivery-Projekte auch scheitern können:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: