Folge 5: Der State of DevOps Report 2017

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge des Podcasts besprechen Alex Lichtenberger und Dierk Söllner ausführlich den „State of DevOps Report“. Sie thematisieren die Kernergebnisse des Berichts, darunter die Rolle von transformationaler Führung, die Auswirkungen von DevOps auf Organisationsgeschwindigkeit und -stabilität, die Bedeutung von Automatisierung und kontinuierlicher Auslieferung sowie die Herausforderungen der Implementierung von DevOps in Legacy-Systemen. Besonders hervorgehoben wird der Wert von Microservices und Modularisierung sowie der Übergang zu einem Lean Product Management-Ansatz.

Inhalt

  • Einführung in den State of DevOps Report
  • Schlüsselerkenntnisse des State of DevOps Reports
  • Bedeutung von transformationaler Führung in DevOps
  • Beziehung zwischen Geschwindigkeit und Stabilität in DevOps-Praktiken
  • Rolle der Automatisierung in DevOps
  • Herausforderungen bei der Implementierung von DevOps in Legacy-Systemen
  • Bedeutung von Microservices und Modularisierung
  • Lean Product Management und Agilität
  • Zukünftige Entwicklungen und Trends in DevOps

Shownotes

  1. Puppet
  2. DORA (DevOps Research and Assessment)
  3. Scrum Guide Revision 2017

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Hallo und herzlich willkommen zu einer weiteren Folge von dem Podcast
DevOps – auf die Ohren und ins Hirn.
Ich begrüße Sie wieder als Hörer und hoffe, dass wir mit unserer neuen Technik
Alex und ich haben ein bisschen investiert in neue Technik
dass wir mit unserer neuen Technik noch besser die Qualität rüberbringen können
dass die Form stimmt und an dem Inhalt sind wir ja eh immer dran.
Wir haben heute das Thema State of DevOps
den Report, den wir so ein bisschen auseinandernehmen werden
den wir ein bisschen zusammenfassen werden
und insofern würde ich sagen, heute haben wir keinen Gast
Sie haben heute die Chance, Alex und mich mal wieder ganz alleine zu hören
und insofern Alex, gebe ich gleich mal rüber an dich.
Ja, danke Dirk. Herzlich willkommen auch von meiner Seite aus der schönen Schweiz
Es ist ja inzwischen schon der fünfte Podcast, den wir machen
und ja, ich glaube, vorstellen muss ich mich nicht mehr gross
also in dem Sinne, ich freue mich auf das heutige Thema und das Gespräch mit dir.
State of DevOps Report, habe ich eben gesagt, ist unser heutiges Thema
Ja.
Wir beide kennen den ganz gut
wir nutzen ihn auch in unseren Schulungen, in unseren Workshops
aber vielleicht gibt es den einen oder anderen Hörer, der diesen Report noch nicht kennt
oder nur mal so am Rande was davon gehört hat
insofern denke ich, Alex, erzähl doch mal ein bisschen was zum Report.
Ja, gerne. Also das State of DevOps Report ist inzwischen das vierte Mal, dass der erscheint
das ist eigentlich eine Studie, ein Reality Check
also werden Unternehmen gefragt, was macht…
was macht ihr effektiv im Bereich DevOps zu der Erhebungsmethode
kann ich dann gleich noch was sagen
also es ist eigentlich so sehr ähnlich
einige von euch kennen vielleicht den State of Agile Report
der ja dann im Bereich Agile schon seit vielen Jahren schaut
ja, was sind effektiv Praktiken, die die Unternehmen anwenden
was machen die genau
also wie gesagt, der Reality Check
und nun das gleiche im Bereich DevOps
ursprünglich wurde der DevOps Report, der wurde vom Puppet herausgegeben
Puppet ist ja ein bekannter Tool-Hersteller, auch im Bereich DevOps
die haben dann aber gesagt, weil das dann zu…
zu, sag ich mal, vom Hersteller kommt
und dann ist dann die Glaubwürdigkeit auch ein bisschen ein Problem
dann wurde eine neue Organisation gegründet, die DORA
das steht für DevOps Research and Assessment
also…
ein Institut, die diesen DevOps Report dann neu jährlich rausgibt
und vielleicht ganz kurz, eben wie wurde der Report gemacht
also da wurde wirklich darauf geachtet, dass halt sehr breit eine Umfrage stattfindet
also einerseits mal von der Demographie her
also es wurde…
also ich weiß, der Report ursprünglich aus den USA kommt
ist schon die Hälfte der befragten Unternehmen aus den USA
dann ein Drittel etwa…
Europa und 10% Asien und der Rest dann…
der Rest der Welt, also Südamerika, Australien etc.
was auch darauf geachtet wurde
also im Sinne, dass es nach der Repräsentative ist, die Resultate
die eigentlichen Branchen, also es wurden unterschiedlichste Branchen
Unternehmen aus unterschiedlichen Branchen befragt
also einerseits mal Technologie natürlich
etwa ein Drittel dann die Finanzindustrie
Retail, Telekommunikation, Bildung
also die ganze Breite ist abgedeckt
und was sie dann eben gemacht haben
sie haben nicht nur Unternehmen befragt
jetzt die wirklich…
sagen wir DevOps
gut, man kann nicht DevOps machen
aber man kann Continuous Delivery
also Firmen, die einerseits schon wirklich DevOps Praktiken anwenden
aber auch andere traditionell geprägte
um dann auch einen Vergleich zu machen
was ist dann der Effekt von DevOps
da wären wir dann…
da wären wir dann später auch noch drauf kommen
vielleicht für diejenigen, die auch den DevOps Report runterladen wollen
man kann das machen auf…
entweder auf der Webseite von Dirk
auf devops.de
kann man den aktuellsten Report runterladen
oder sonst auch bei meiner Seite
devops.ch
da könnt ihr dann effektiv reinschauen
ja, ich werde ihn bei mir eben genau bei den Shownotes
zu diesem Podcast bereitstellen
dass derjenige, der neben unserer Stimme auch noch ein bisschen was lesen will
auch die Chance hat, das mal im Detail nachzulesen
gut, ja Alex, danke für die…
für die Einführung dazu
ich habe ja gesagt, wir beide nutzen das in unseren Trainings
und in den Schulungen
ich finde es immer sehr, sehr interessant
und wir werden ja auch im Verlauf des Podcasts
noch ein paar wirklich interessante Ergebnisse rausfinden
oder darstellen
und das…
da bin ich schon mal gespannt drauf
gibt es…
zu Anfang gibt es ja so eine schöne Zusammenfassung
so eine Art Summary
was sind denn 2017 die wichtigsten Erkenntnisse gewesen
die Key Findings?
ja, also ich kann das ganz kurz zusammenfassen
wenn wir das eine oder andere noch vertieft anschauen
so sechs Key Findings
also das erste Key Finding war
Stichwort Transformational Leadership
damit ist gemeint, dass halt die Firmen, die erfolgreich DevOps machen
weg vom Tayloristischen traditionellen Management
Richtung DevOps Lean Leadership
also selbst organisierte Teams
und dann mit dem Leader, der dann halt mehr die Vision vorgibt
also eine andere Art von Führung
die auch zentral zu sein scheint für den Erfolg von DevOps
das andere ist auch wiederum die Feststellung
Firmen, die DevOps machen
die sind signifikant
also einerseits schneller
Time to Market
aber gleichzeitig auch die Stabilität
die…
die verbessert wurde
das dritte Key Finding
Automatisierung
also das…
das Automat…
die Firmen sagen, die…
die erfolgreich…
diese High Performing Organisations sagen
Automatisierung ist…
ist zentral für uns
das hat einen…
einen Unterschied gemacht
und dann der nächste
der ist…
ja sorgt dann für Diskussionen manchmal
Stichwort bimodale IT
dass man…
die Firmen kommen weg vom Gedanken, dass
es gibt ein Teil der IT, die macht DevOps
und der Rest nicht
dass man…
die Aussage ist
DevOps applies to all Organisations
dann ein weiteres Key Finding ist
ich würde mal sagen
DevOps is not enough
also es ist natürlich, wenn man unten dran Monolithen hat
architektural wird schwierig
dann DevOps umzusetzen
das heisst, was viele Firmen
Key Finding
man arbeitet an der Architektur
Stichwort SOA
Microservices
Modularisierung
und das letzte Finding war
ist noch das Thema
Lean Product Management
also die Art und Weise wie Produkte
dann weiterentwickelt werden
also dass die
sagen wir das Stichwort Agilität
oder Lean Product Management
auch eine zentrale Rolle spielt
weil viele sehen ja dann
DevOps sagen wir als eine
Erweiterung vom agilen und Lean Gedanken
und das wird da bestätigt
also das sind so zusammenfassend
die Key Findings
und ja vielleicht macht es jetzt Sinn
dass wir vielleicht ein Thema
gerade dann tiefer reingehen
weil das ein Thema
das ja in den vergangenen Reports immer
im Zentrum stand
nämlich
anknüpfen
auch zu den Zielen von
DevOps
DevOps schneller
besser
und hier jetzt der
DevOps Report
also wenn wir jetzt da
diejenigen die den
Report vor sich haben
müssen man auf Seite
muss ich jetzt selber schnell suchen
Seite 21
das wurde ja wiederum bestätigt
eben massiv
kürzere Durchlaufzeiten
und gleichzeitig auch die Stabilität
die erhöht wird
also in der Praxis
durch Umfragen bestätigt
und da könnte man vielleicht
ein bisschen
Dirk diskutieren
also wenn wir jetzt die
das anschauen
da steht zum Beispiel
46 mal häufiger werden
Deployments gemacht
440 mal schneller
Lead Time
96 mal kürzere
Störungsbehebungszeit
das ist sehr beeindruckend
da können wir vielleicht
ein bisschen diskutieren
Dirk auch das
ja das warum
also ich finde es auch interessant
weil das sind Zahlen
die natürlich wirklich
aus der Praxis kommen
die erhoben wurden
und wenn ich an meine
Schulungen denke
dann gibt es dann schon
den einen oder anderen
oder auch bei Vorträgen
den einen oder anderen
der sagt
das kann bei uns aber
nicht funktionieren
das kann bei anderen sein
Facebook schafft das
und Google schafft das
aber wir können
das nicht schaffen
und insofern finde ich
es interessant
und hoffe auch
dass die
Masse
die
Anzahl der Teilnehmer
weiterhin steigt
und dass die
Anzahl der Teilnehmer
weiterhin steigt
dass man einfach
auch da nochmal
Firmen mit reinbekommen
die jetzt eben nicht dabei sind
und für mich ist das
eine Bestätigung
dass das geht
dass das gehen kann
natürlich geht es nicht
von jetzt auf gleich
du hast es ja auch gesagt
so Microservices
ich habe
häufig noch
monolithische
Applikationen
die vielleicht
in einer großen
Datenbank arbeiten
oder wo ich
auch vielleicht SAP
im Einsatz habe
aber prinzipiell
wenn man daran arbeitet
das überschaubarer
zu machen
von den Teams her
dann denke ich
kann man dahin kommen
und es gibt
viele Firmen
die auch die ersten Schritte
dahin machen
das heißt
die haben dann
beispielsweise nicht
jeden Tag
hunderte von
Deployments
oder hunderte von
Produktivsetzung
von kleinen Änderungen
das was man ja auch
den großen
bekannten amerikanischen Firmen
dann nachsagt
die haben das nicht
aber
sie kommen dahin
dass sie eben
statt zweimal im Jahr
ein großes Release
ausrollen
dass sie schon
einmal im Monat
ein kleineres Release
ausrollen
die eben
diesem Weg folgen
aber natürlich
noch nicht so
ganz so schnell
wie das vielleicht
dann die Vorreiter da sind
und das hat ja dann
auch einen positiven
also ich glaube
das Beispiel
das du genannt hast
so ein häufiger Release
das hat einen
positiven Einfluss
auch auf die
Stabilität
im Sinne
also wenn man jetzt
im Report schaut
das Meantime to Recover
also die
Störungsbehebungszeit
ist im Schnitt
bei diesen
sagen wir
DevOps Firmen
96 mal kürzer
und deshalb
ich sage immer
wenn man jetzt
zwei Releases
im Jahr hat
dann
viel Spass
beim finden
einer Fehlerursache
weil es gibt ja
nach jedem Change
gibt es Störungen
und wenn man halt
dann eher kleine
Päckchen hat
dann ist
in der Regel
ist es dann
haben wir viel schneller
auch die Ursache
des Fehlers
gefunden
kann man schneller
einen Rollback
machen
oder gut
die Amerikaner
würden wahrscheinlich
eher fix forward
also das
heißt
39 mal kürzerer
Meantime to Recover
und für mich
auch für
schon
gekommen
aber
calex
mit
sowieso
mein
zu senken und wir werden hier 96 mal schneller. Wie gesagt, das ist ein enormer Wert, ein enorm hoher Wert, aber das zeigt, dass das geht, wenn man eben Dinge verändert und dann einfach startet. Also insofern, für mich ist das eben auch ein Argument zu sagen, auch der Betrieb, der ja vielleicht wirklich klassisch als der langsame Bereich dasteht, hast du ja gesagt, bimodal, sprechen wir nochmal drüber gleich,
dass auch der Betrieb eigentlich ein Interesse daran haben sollte, auch im Sinne von IT-Service-Management, von ITIL, zu sagen, hey, wir müssen uns um das Thema DevOps kümmern.
Genau, das sehe ich auch so. Es ist auch spannend, die Zahl, da wird auch eine Aussage gemacht, das Change-Fail-Rate, also im Schnitt jetzt die Firmen, die DevOps machen, dass die im Schnitt fünfmal weniger Fehler haben.
Und da ist auch eben, das Spannende ist immer die Diskussion, die ich mit den Leuten, also mit Kunden habe, aber auch in den Schulen, warum ist das dann so und bei DevOps ist ja, sagen wir, diese, hatten wir in früheren Podcasts darüber gesprochen, Shift-Left, also you build it, you own it und es wird sehr früh, es werden Tests, auch nicht-funktionale Tests werden und auch Antworten definiert und die Tests dazu automatisiert,
also einen starken Fokus auf ein starkes Test und ich denke, das ist so der Hauptgrund, wieso auch die, also nicht nur die Störungsbehebungszeit zurückgeht, sondern auch die effektive Fehlerrate zurückgeht, also im Kontext mit Test-Automatisierung.
Spannend, also das war jetzt so der Stabilität, wir haben ja alle mal gelernt, also dass wenn man schneller wird, geht die Stabilität runter und umgekehrt, wenn ich mehr Stabilität und mehr Change-Control,
dann geht es besser.
Ja, der Speed runter, aber hier wirklich das Faszinierende, beides geht ja, also DevOps will ja beides erhöhen und jetzt haben wir gesagt, ja, okay, Stabilität besser und dann eben dieses Lead-Time-for-Changes, also die effektiv, die Dauer, die, wie lange es geht, ein Change umzusetzen, sozusagen im Schnitt 440 Mal schneller, also es ist einfach jetzt mal aus der Umfrage raus und das ist natürlich auch wieder, ich würde sagen, das,
das magische Wort dahinter ist auch wieder Automatisierung, also vor allem auf Deployment-Seite, aber auch die ganze DevOps-Pipeline, also der, sagen wir im Idealfall der Entwickler-Check-In-Code und hintendran werden automatisiert die ganzen Tests ausgeführt, wenn man das richtig hinkriegt und quasi dann könnte jederzeit sagen, ja, jetzt meine Software ist in der Releasable-State und ich habe die Zahl, diese, auch wenn sie ein bisschen
Anfang war ich da skeptisch, habe gesagt, das kann ja nicht sein, also traue nie einer Statistik, die du nicht selber gefälscht hast, aber es ist schon, es lässt sich erklären.
Ja, ja, was ich interessant finde, du hast ja eben auf die Tabelle auf der Seite 21 referenziert, wenn man noch ein bisschen weiterblättert, es gibt da noch ein bisschen Unterteilungen, das heißt auf der Seite 23 gibt es die Unterteilung beim Change-Failure-Rate, also bei der Rate, wo Fehler mal nach einem Change
auftreten, 2017 im Durchschnitt fünfmal niedriger, wenn man es aber mal unterteilt in die einzelnen Organisationen, das macht ja der DevOps-Report, der unterteilt ja die Organisationen oder teilt sie ein in High-Performer, in Medium-Performer und in Low-Performer und wir alle wissen, was wir mit Low-Performer meinen, wenn wir über einen Menschen sprechen, also in diesem Fall hier haben wir den Low-Performer von der Organisation her und da ist das Interessante, die Change-Failure-Rate, die ist da im Prinzip
dreimal,
so hoch bei den Low Performern im Vergleich zu den High Performern.
Das heißt, diese fünffache, fünffach niedrigere Rate im Durchschnitt,
die wird nochmal ein bisschen genauer auseinandergerechnet,
indem einfach gesagt wird, dieser Wert wird quasi durch die Low Performer
nochmal nach unten gezogen.
Das heißt, die High Performer und die Medium Performer,
die sind zwischen 0 und 15 Prozent.
Also die haben relativ hohe Erfolgsquote bei Changes.
Ja, das wird ja sehr, und wir haben ja gerade einführend gesagt,
in der Erhebungsmethode wurden tausende von Unternehmen befragt,
aber eben in der ganzen Breite, also wirklich auch ganz traditionell
auf der anderen Seite die Unicorns.
Und da wurde dann so wie eigentlich ein Clustering gemacht
und dann diese Einteilung und die drei.
Das hilft auch noch fürs Verständnis.
Ja, also was ich interessant finde, ist für diesen Bereich die Aussage,
es geht, man kann Agilität, eine schnelle Lieferung,
verbinden mit Stabilität.
Wenn man das im Sinne eines DevOps-Konzeptes
und einer Philosophie macht, dann kann man das verbinden.
Das ist für mich eine zentrale Aussage und du hast es ja auch gesagt,
die kann man nicht vom Tisch wischen.
Man kann sie erklären und das versucht ja der DevOps-Report.
Ja, ich würde mal auf einen anderen Punkt gehen.
Du hast vorhin schon gesagt, Transformational Leadership
und das für die, die nachlesen wollen, finden wir auf den Seiten,
oder ab der Seite 12.
Das ist eben auch ein wichtiger Punkt,
dass man eben nicht nur die Uniformen,
nicht nur auf die technischen Dinge abzielt,
das war ja eben eher Technik oder geht ja stark in die Richtung Technik,
sondern auch in das Thema Führung.
Wie sieht eine Führung anders aus?
Und wenn man sich so, weiß nicht, bei Xingo, LinkedIn und sonst wo,
bei Twitter die ganzen Nachrichten anschaut,
dann wird einem ja als Führungskraft,
müsste einem ja Angst und Bange werden,
weil man alles falsch macht und weil man nicht modern ist.
Hier der Hintergrund ist Transformational Leadership.
Das ist eine Aussage, die getroffen wurde.
Wie hast du diese Aussage,
wie hast du diese Aussage interpretiert?
Was ist für dich Transformational Leadership?
Ja, also ich habe, als ich den Titel gesehen habe, gesagt,
hm, was könnte sich dahinter verstecken?
Aber als ich dann den Inhalt durchgelesen habe,
ich denke, man könnte hier auch genauso von Agile oder Lean Leadership sprechen.
Und ich denke, dass jetzt diese auch grundsätzliche Transformation,
die viele Unternehmen durchmachen,
als sich Richtung agile, selbstorganisierte Teams bewegen,
aber auch, also das eine ist ja, wie man sich als Team organisiert.
Aber es hat auch jetzt einen grossen Einfluss
auf auch das Selbstverständnis des Managements und der Führung.
Wie sehen wir unsere Rolle? Wie führen wir?
Und ich denke da, das ist auch der schwierigste Brocken,
weil wir kennen ja alle den Spruch
Culture eats strategy for breakfast.
Das heisst, die Leute, also man kann die schönsten Pläne haben,
aber wenn die Leute das nicht wollen,
auch das Management halte, nicht loskommen,
sagen wir, von der Art und Weise, wie sie die letzten 30 Jahre geführt haben,
dann scheitert das.
Es ist jetzt auch ein Kulturwandel, der stattfindet im Bereich Führung.
Und ich nehme da immer den Vergleich, also um das ein bisschen zuzuspitzen,
wenn man, ich übertreibe jetzt natürlich masslos,
aber es wird auch schon eigentlich im Report so gezeigt,
dass, wenn man das traditionelle Management,
tayloristische Management anschaut,
dann sieht man, der Manager, der Manager weiss, was gut ist für das Team.
He tells the team, das Team führt aus, wird über KPIs gesteuert.
Also die Welt der hohen vertikalen Gebäude, eben oben der Manager.
Und jetzt eben Transformational Leadership, sagen wir von der Idee her relativ alt,
aus dem Lean Leadership heraus, letztes Jahr, 160er Jahre,
das ist halt eher so die Welt der flachen Gebäude.
Da hat man einerseits das Team, das Team hat gemeinsames Verständnis, wie man arbeitet.
Das Team macht regelmässig Retrospektive, verbessert sich und macht auch Crosstraining.
Und was ist dann mit dem Manager?
Eben der Manager, man spricht nicht mehr vom Manager, sondern vom Leader.
Die Aufgabe des Leaders ist, sie sprechen dann auch eine Vision, eine Vision vorzugeben.
Was wollen wir?
Die Teams sind ja typischerweise um Produkte herum oder Services sorgen.
Was ist unsere Produktvision?
Und dann nicht den Leuten sagen, wie sie das erreichen sollen,
sondern welches Problem muss gelöst werden.
Und dann auch die richtigen Fragen stellen, den Teams helfen,
ihnen die Umgebung geben, dass sie sich weiterentwickeln können.
Und natürlich, ich meine, ich mache selber relativ viel Agile Coaching,
also auch Scrum Coaching, also helft den Unternehmen als Coach, sich Richtung Agile zu bewegen.
Und das ist dort genau der Move, den wir machen.
Also einerseits die Mitarbeiterebene, wie es versteht sich das Team selbst,
aber dann auch der Leader, wenn er zum Beispiel dann Scrum anschaut,
dann wird das in zwei geteilt, zum Beispiel Produktdonor,
der ist mehr für die Vision und die Anforderungen und der Scrum Master,
der schafft die richtige Umgebung.
Und spannend ist ja dann,
dass heute wird, dass er dann das nicht nur auf unten auf Team-Ebene,
sondern dass man das bis zu oberst oben skaliert.
Also man hat dann auch zu oberst auf C-Level,
wie die ihre, dass sie sich auch eher als Leader sehen
und eben nicht als Micromanager.
Das ist so, also auch aus dem Report, der Report sagt eigentlich ja,
dass die Unternehmen sehen diesen Teil als kritisch,
dieses Transformation Leadership als kritisch,
erfolgreich zu sein mit DevOps.
Ja, du hast es angesprochen.
Leadership ist ja ein Thema, was wir auch in dem agilen Umfeld haben.
Insofern, als ich das gelesen habe, fand ich zwei Dinge interessant.
Erstens, dass es ein Modell gibt,
nachdem man dieses Transformational Leadership quasi bewerten kann.
Auf dieses Modell beziehen sich ja die Autoren des State of DevOps Report
und das ist eben ein Aufsatz, der jetzt schon 13 Jahre alt ist,
an der Stelle, und der eben ein Modell beschreibt
mit fünf Charakteristika, wie Transformational Leader quasi auftreten,
wie sie denken, wie sie ticken und wie man eben genau das bewerten kann.
Und diese fünf Punkte finde ich sehr interessant.
Vielleicht ganz kurz, die Vision hast du eben angesprochen.
Charakteristisch für einen Transformational Leader ist eben,
dass er eine Vision hat, wo will die oder wo soll die Organisation
in fünf Jahren sein, als Beispiel.
Es geht um Inspiration.
Inspirierende Kommunikation, das hast du im Prinzip auch schon
ein bisschen angesprochen, eben keine Vorgabe,
sondern ein Transformational Leader kommuniziert in einer Art und Weise,
dass er damit die Leute inspiriert und motiviert.
Also er spricht die Leute eben an, eine inspirierende Kommunikation.
Das ist der zweite Punkt, der quasi in diesem Modell beleuchtet wird
oder der in diesem Modell betrachtet wird.
Dritter Punkt ist die intellektuelle Stimulation.
Das heißt, der Transformational Leader, der macht sich Gedanken über die Probleme
und erregt sich und auch seine Mitarbeiter quasi oder seine Teammitglieder an,
darüber auch nochmal nachzudenken.
Also er stimuliert letzten Endes auf einer intellektuellen Ebene an der Stelle.
Vierter Punkt, Supportive Leadership.
Das heißt also, ein Transformational Leader kümmert sich in einer Unternehmenspolitik,
unterstützenden Weise um die persönlichen Belange seiner Follower, seiner Teammitglieder.
Auch das geht so ein bisschen in Richtung Servant Leadership.
Ich komme gleich noch auf einen anderen Unterschied, auf einen wichtigen Unterschied
zwischen diesen beiden Konzepten, aber Supportive Leadership, der vierte Punkt.
Der fünfte Punkt, persönliche Wahrnehmung, sage ich mal.
Das heißt also, der Transformational Leader hat eine persönliche Wahrnehmung von dem Ganzen.
Also,
hier fünf Punkte, wie man einen Transformational Leader quasi charakterisieren kann.
Und ich habe eben schon gesagt, für mich ein zweiter Punkt, der noch wichtig ist,
als ich gelesen habe, Transformational Leader, habe ich gesagt, hey super,
wieder ein neuer Fachbegriff, wieder was Neues für Servant Leader.
Nein, es gibt einen Unterschied und das ist eben für all die, die Servant Leadership verstehen
und verinnerlicht haben, eben sehr schön beschrieben.
Auf der Seite 14 gibt es so eine kleine Box.
Es gibt einen Unterschied zwischen einem Servant Leader und einem Transformational Leader.
Und der Unterschied ist im Prinzip derjenige, dass der Servant Leader die Entwicklung,
die Performance seines Teams im Blick hat.
Also, er unterstützt die Entwicklung und die Performance seines Teams.
Also, fokussiert sich mehr auf das Team, wenn man das so will.
Hilft dem Team, indem er es eben führt.
Also, dienender Führer, er führt, indem er dem Team quasi dient.
Führt damit aber auch.
Der Transformational Leader, der versucht oder hat als Ziel,
dass sich die…
Follower, sein Team, sich mit der Organisation identifizieren
und eben versuchen, ihre Arbeit sinnvoll so zu gestalten,
dass die Organisation unterstützt wird.
Also, das ist schon, wie ich finde, eine andere Sichtweise.
Und insofern, das sind auch Themen, die man sicherlich nochmal,
ja, auch vielleicht in einem späteren Podcast mal genauer auseinandernehmen kann.
Da gehen wir ja wirklich in die Anforderungen an Führer.
Wobei, wenn wir Deutschen dieses Wort gebrauchen,
müssen wir ja mittlerweile immer noch vorsichtig sein.
Also, ein Leader…
Mal das englische Wort.
Also, ein Leader an der Stelle, der Transformational Leader,
ist ein bisschen anders unterwegs.
Und das, was eben der State-of-Dev-Ops-Report aussagt,
das ist ein Erfolgsfaktor.
Aber wie gesagt, es ist ein kleiner Unterschied,
aber ich finde auch einen wichtigen Unterschied zu einem Servant-Leader,
wie wir ihn aus der agilen Welt kennen.
Das fand ich jetzt so gut, dass du auch die Unterscheidung gemacht hast.
Es ist dann auch, auf welcher Ebene, also ist es mehr auf Team-Ebene
oder geht es darum, sagen wir mal,
dass…
Ja, ja, ja.
Es knüpft dann wieder an die Vision an.
Der Transformational Leader, der auch eine klare Vision vorgeben muss
und das dann in die Organisation reinbringen kann.
Und nicht einfach nur, sagen wir, der Servant-Leader,
der es dann mehr die Teams selber führt.
Haben wir noch andere Key-Findings, die wir ausführen können?
Also, der Report ist ja recht lang.
Aber ich habe mir…
Also, wir haben es ja auch im Vorfeld gedacht,
da müssen wir ein bisschen Fokus setzen,
dass dann der…
Das kann sich zwei Stunden lang werden.
Also, ein Thema, das vielleicht die Leute noch interessiert,
ist, weil…
Wir haben auch schon mal gesagt, man kann nicht DevOps machen.
Aber was man machen kann, sind die ganzen DevOps-Praktiken.
Das interessiert ja die Community immer sehr.
Also, da gibt es dann auch ein Kapitel dazu.
Das hat dann zwar das Kapitel, den Titel
Technische Practices.
Und da ist natürlich an erster Stelle
kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
das als Top-Trio.
Content ist jetzt halt mehr, er spricht von
Technologie, aber auch Prozessen.
Und vielleicht
ist es wert,
das könnte ich auch machen, aber
Continuous Delivery generell
ist ja, baut auf
Continuous, also die, die es vielleicht noch nicht
so kennen, baut ja auf
Continuous Integration auf.
Also bei Continuous Integration
die Praxis, dass man
als Entwickler, man arbeitet
an gemeinsamen Repositoren,
Cori,
und werden automatisierend
ein paar Basistests gemacht, das ist ja auch
ein bisschen alter Hut,
dann aber Continuous Delivery, so dieses
Mindset, dass
das, was, wenn ich
etwas mache, sagen wir als Ingenieur
oder Entwickler, ich will
Feedback bekommen, sofort
ist das, was ich
mache, richtig.
Also richtig, nicht nur jetzt im alten Sinn,
okay, mein Kollege
hat es reviewed, oder ich habe so ein
paar funktionale Tests gemacht,
sondern wirklich so weit, dass man
auch nicht-funktionale
Tests, also zum Beispiel
Security, Performance,
man baut das alles ein
und dass man
dann, eigentlich wird dann mit die Agilität
auch dann zu Ende getrieben,
ich bekomme sofort Feedback, ist es
wirklich dann oder nicht,
und wenn nicht, dann muss ich es eben korrigieren
und ich kriege dann nicht erst in drei Monaten
Feedback, wenn dann irgendwann
später ein Performance-Test
sagt, ist nicht gut. Also da ist jetzt
die Firmen fokussieren sehr stark
einerseits Infrastruktur,
Continuous Delivery,
da hängt natürlich der ganze unten dran,
man braucht
Cloud-Infrastruktur, also
dass man on-demand dann die nötigen
Testumgebungen bekommt, aber
dass auch man
investiert in Test-Driven
Development, früh schon
Tests, anfangen
als Test-Cases
definieren, automatisieren,
und
was da auch, steht glaube ich
auch drin, das kann man ja nicht von heute
auf morgen, sondern das ist auch wieder
ein Weg, das kann Jahre dauern,
wenn man aus dem Legacy kommt, sagt man
okay, jetzt automatisiere ich
mal den Teil, dann mal den Teil,
investiere ich in das,
und dann kommt man diesem Continuous
Delivery, dieser Vision
dann immer ein Stück näher.
Also es ist so, was ich rauslese
aus dem Report, dass es jetzt
extrem Fokus ist, auch bei den Firmen.
Ja, also ich
finde auch, und wir hatten ja gerade vor
ein paar Tagen das
Webinar von Jeff und
Ken Schwaber, von Jeff Sutherland,
Scrum Guide
Revision 2017, die Änderungen,
und da haben sie ja auch das Wort
DevOps auftauchen lassen,
das heißt also, der Scrum Guide
sieht auch, DevOps, da tut sich
was, und du hast eben so ein wunderschönes
Wort gesagt, dann, also wann
ist es fertig, wann ist es wirklich fertig,
und das ist eben das Schöne,
das ist der ganz feine Unterschied, der aber natürlich
viel nach sich zieht, wenn
ich rein nur auf Scrum mich
beziehe, dann bin ich fertig,
wenn die Definition of Done erfüllt ist,
und die ist aus Sicht von Scrum, wenn man
das Scrum ganz eng sieht,
dann, wenn der PO das abgenommen hat, dann muss
es noch nicht in Produktion sein,
und wenn ich dann sage, dann ist es
erst, also es ist erst dann fertig,
wenn es in Produktion ist,
und dort läuft, das ist nur ein kleiner
Schritt, aber ein
Riesenschritt, weil ich muss ja wirklich eine Menge
dabei tun, und das ist eigentlich auch
eine weitere Herausforderung, du hast ja gesagt,
wir reden über technische Praktiken,
Technical Practices, aber da hängt
natürlich auch Organisation und Mindset
wieder dahinter, ein Entwickler, der sagt,
habe ich entwickelt, PO
hat es abgenommen, bin zufrieden,
kann mich zurücklehnen, der muss sein
Mindset an der Stelle eben auch ändern, also
dann heißt, wenn es dann fertig
in der Produktion ist, und nicht auf einem
Entwicklungssystem oder auf einer
anderen Stage. Ja, also ich war gerade
in die, diesbezüglich war gerade
heute Morgen,
ein agiles Team, ich begleite
die, das hat sehr,
sagen wir, sehr Scrum-lastig, und
da habe ich mal gesagt, heute, ja, lass uns
mal ein bisschen über DevOps sprechen,
lass uns über die Definition of
Done sprechen, oder was
macht, würde es nicht Sinn machen, das jetzt mal ein bisschen
weiterzuentwickeln, also was ist
unser Verständnis über
Done, wollen wir uns mal Gedanken
machen, langfristig
gewisse Tests, Einbud
zu beziehen, also dass es dann auch
innerhalb vom Sprint ist,
effektiv erst dann,
wenn man auch weiss, ja,
es wird die Security-Tests
bestehen, es wird die
Performance-Tests bestehen,
und dann ist es eben spannend,
dass die aus den agilen Ecken,
die sagen, für sie ist eigentlich DevOps
doch nicht so neu, man hat zum Beispiel das
Wort Continuous Delivery, das ist ja schon
im agilen Manifest von
2001, taucht
das Wort ja schon auf, also
die Agilen haben ja schon immer gesagt, lass uns über das
Definition of Done, die
muss immer besser werden, immer näher zu,
aber das Problem ist, die Entwickler haben sich einfach nie
für den Betrieb interessiert,
und das ändert sich ja
jetzt, indem man dann, und da
reden wir dann nicht mehr über Technik, sondern
man beginnt
Betriebsleute in solche
Scrum-Teams zu integrieren,
dass sie eben auch ein Stake bekommen,
weil das sind die, dass man
dann diese operativen
Dinge auch bereits schon
in der Definition of Done
einwirkt, und da wir heute,
also da haben wir uns grundsätzlich
gesagt, ja,
lass uns Zeit investieren, das wird
ein langer Weg sein, aber dann immer
näher. Richtig, ja.
Langer Weg, weil ja auch die User-Stories,
die Anforderungen entsprechend kleiner
gepackt werden müssen, denn, wenn du hast
gesagt, Security-Test, viele andere
Tests, die kann ich nicht alle in einem
Zwei-Wochen-Sprint einbauen und die mal
eben dazu packen, das heißt, das ganze
Thema Testen und andere Anforderungen
drumherum, das muss ja auch
vorbereitet werden, dass das überhaupt
macht.
In einem entsprechenden
Sprint an der Stelle, also insofern
vollkommen richtig, da ist noch ein bisschen was
zu tun, aber auch meine
Sichtweise ist, oder meine
Erkenntnis ist, dass die Entwickler eigentlich
damit, ich sag mal so, kein Problem
haben. Wahrscheinlich sind das eher
bestehende Schranken,
bestehendes Simudenken, was
sie davon abgehalten hat,
quasi, oder wo sie abgehalten wurden,
sich auch um den Betrieb mit zu kümmern.
Da wurde einfach übergeben an den Betrieb
und du hast eben gesagt,
dass die Betriebsleute in die Teams
reingeholt werden. Das ist für mich
nochmal ein wichtiger Punkt, weil
ich würde jetzt nicht sagen, ich nehme
meine Betriebsmannschaft, teile die
fein auf, auf die einzelnen Scrum-Teams
und dann mache ich DevOps. Also das wäre ja
ein Missverständnis. Mein Verständnis
ist ja eigentlich eher, dass ich das
Wissen, das Betriebswissen in die
Teams packe. Ja, aber es hat mit
Verantwortung zu tun. Also meine, da gibt es
natürlich unterschiedliche Ansichten, aber
die meisten Kunden, mit denen ich zu tun
habe, die sagen wirklich, das hat der Gedanke
von Spotify. Man hat diese Teams
und die haben, you build it,
you own it. Weil solange
immer noch so ist, dass
jemand anders ist ja dann für den
Betrieb verantwortlich, dann haben
die nämlich gar nie ein Interesse, die
betrieblichen Dinge reinzunehmen. Also wir
versuchen, also nicht unbedingt
fest in die Teams, aber dass
die dann an,
wenn es um Planung geht, etc.,
zum Beispiel Sprintplanung, dass die
vertreten sind drin
und dass, also wir gehen dann so weit,
dass wir sagen, wir haben eine
und das Team hat dann auch betriebliche
Verantwortung. Es werden natürlich gewisse
Scherzdinge, die muss man immer separat
machen, also das ist klar.
Ja, also wir sind ja noch beim
DevOps Report, bei den Technical
Practices, was ich noch interessant finde
ist, du hast ja eben schon was zum
Continuous Delivery gesagt,
da ist auf der Seite 33
nochmal der Punkt
Fast Feedback on the Quality and the
Deployability. Genau.
Ein wichtiger Punkt, was ich da
schön auch am agilen Vorgehen
finde,
ist ja, und auch natürlich am
Lean Management ist, kontinuierliche
Verbesserung. Und kontinuierlich heißt für mich
immer in kleinen Schritten, in kleinen Häppchen,
ich sehe sofort, ob das funktioniert,
ob es nicht funktioniert, habe sofort ein
Erfolgserlebnis, habe sofort eben dieses
Feedback. Und dieses Fast Feedback,
was hier bei der Continuous Delivery
rüberkommt, finde ich eben auch sehr, sehr interessant,
dass eben die Entwickler, wie du es ja auch
gesagt hast, die kriegen schnell das
Feedback. Und egal,
ob das jetzt ein kleines oder ein größeres
Team ist, jeder im Team kriegt
dieses Feedback und kann daraufhin
sich seine Meinung bilden und kann eben
schauen, was muss man tun, um
mit dem Feedback quasi umzugehen
und mit dem Feedback zu arbeiten. Also
auch hier wieder,
es geht zwar um technische Praktiken,
die aber eben auch entsprechend
kulturelle, organisatorische
Veränderungen haben, Mindset-Veränderungen
und hier eben ein Fast Feedback,
also du kriegst ein schnelles Feedback als Entwickler,
ob das, was du gebaut
hast, auch wirklich funktioniert.
Und wie du es eben gesagt hast, nicht nur auf
Testumgebung, sondern
Security-Tests werden bestanden, andere
Tests werden bestanden, es funktioniert in der Produktiv-
Umgebung. Das finde ich eben auch das Schöne
und das Interessante.
Ja, wir haben ja, also wenn man schaut, Continuous Delivery
ist ja ein Punkt, was dann
als nächstes kommt, ist das ganze Thema
Architektur.
Also die
Aussage, dass auch dort jetzt
viel Veränderung
stattfindet. Wir haben ja kurz
über Modularisierung so angesprochen.
Gut, also ein weiterer
Punkt jetzt in dem Kapitel
Technical Practices,
zwar eben jetzt mit Klammer,
es geht ja nicht nur um Technik,
wie auch der Dirk schön gesagt hat,
es gibt Prozesse,
Kultur, du musst das auch unterstützen,
aber ein weiterer Punkt ist Architektur.
Und die Aussage
ist da,
dass die
Fähigkeit, also die, wenn man
sagen wir, man kann nicht
Continuous Delivery machen, man kann
nicht
in kleinen, selbstorganisierten Teams
und man kann auch nicht
inkrementell in kleinen Häppchen arbeiten,
wenn man unten dran immer noch Monolithen
hat.
Die ganze DevOps-Bewegung
kommt ja von diesen sogenannten Unicorns,
also wie Google, Netflix
und die hatten ja den Vorteil,
dass man die von Anfang an
die Architektur halt
DevOps-like gebaut
haben, nämlich
Modular,
in Microservices,
Clouds-Native
und wenn man das unten so,
die Architektur so ist,
dann hat man
es nach viel einfacher,
die anderen DevOps-Praktiken
umzusetzen.
Und ich hatte da auch,
wenn wir jetzt gut vom Report weg,
aber da fällt mir eine Anekdote ein,
oder eigentlich mehrere, ich habe sehr oft,
wenn ich beim Kunden
ein bisschen vorstelle,
DevOps und dann gerade bei den
Grossunternehmen, also bei uns zum Beispiel
die Banken, die machen schon sehr lange
IT in Deutschland, sagen,
das ist bei uns nicht möglich, weil
so Legacy und alles, wir können
die Architektur,
das ist
ein Rieseninvestment
und meine Antwort ist dann, also erstens,
die Frage ist nicht nur,
ist es möglich, sondern der Punkt ist
eben notwendig, wenn
sie jetzt, wenn sie
überleben wollen im kompetitiven
Umwelt, weil sie haben da eine Konkurrenz,
die machen das halt dann
einfach, das ist das eine
und das andere ist auch wieder Architektur,
das ist
das zu ändern, Richtung
Modularisierung,
das ist ein
extrem langer Weg,
also der kann sehr
lange gehen und das
Wichtigste ist einfach, dass man mal anfängt,
damit, man kann lange um den
Brei reden, aber das wollen wir auch hier wieder
in kleinen Schritten
dann die Architektur
graduell,
sie schreiben dann ja auch
auf Seite 36
loosely coupled
well encapsulated
architecture drives
IT performance.
Das braucht auch Zeit, aber es
ist wie, wenn die Architektur
nicht stimmt, in diesem
Sinne, dann gibt es
auch Schwierigkeiten, dann
continuous delivery und selbstorganisierte
Teams umzusetzen.
Also ich finde es interessant, deine
Anekdote an der Stelle, weil natürlich
kommt das Argument immer, das geht bei uns
nicht, weil wir eben
große Systeme haben, weil wir ein SAP
haben, was das nicht zulässt,
alles technisch gesehen erstmal
die richtigen Argumente, aber dann ist die Frage,
ja, können sich
Organisationen diese
Ausflüchte oder diese Erklärungen
noch erlauben oder ist nicht der
Wettbewerb so, der Druck von draußen so
stark, dass man einfach was tun muss
und das geht natürlich auch dann in Richtung
Disruption an der Stelle.
Also du hast
eben auch von den kleinen Schritten gesprochen,
wenn ich jetzt mal so ein bisschen weiterblättere,
Seite 43, da geht es dann, oder auch
Seite 42 geht es dann in Richtung
Lean Product Management und da
finde ich es eben auch interessant, dass
genau auch da so Erkenntnisse sind,
dass das ganze Thema
Lean Product
Management da mit
reinspielt, das heißt, ich
kriege bessere
IT-Performance hin, eine höhere IT-Performance,
wenn ich eben mit
kleinen Badges aber mitarbeite,
mit kleinen Teilchen, also die
und eben auch mit diesen kleinen Teilen
auch wiederum schnell Feedback bekomme und
das ist ja auch eben eine Erkenntnis
hier, die High Performer
sind High Performer oder
deswegen High Performer, weil sie es dann eben
schaffen, auch im Rahmen des
Deployments schnell das Feedback
zu bekommen und das Ganze
kriegt man eben nur hin und das quasi
gegenseitig die Beeinflussung,
man hat eine schlankere Produktion,
kriegt schnell da Feedback und das ist
wiederum dann die Voraussetzung, genau um
eben noch schlanker die Produktion zu
haben, also wirklich, dass
die IT-Performance quasi auch
eine Vorgabe ist und das
Thema Lean Product Management
treibt. Also auch hier wieder,
die Message mit
Small Badges, Short
Feedback Loops, ich denke, das zieht
sich so ein bisschen durch den Report
durch, über die verschiedenen
Themen,
auch im Thema Leadership,
im Thema dann
Continuous Deliveries, ja auch dann
Mittel zum Zweck, um dann
echtes Feedback
zu bekommen, schnell.
Und auch dann in den
Hard Fakten, die wir ganz am Anfang
besprochen haben, mit dem Schnelle
Bessere, das ist ja auch ein
Effekt von diesen
kleinen Badges, also in dem Sinn
dann kleine Päckchen,
kurze Release-Zyklen
und so dann schnelle Feedback-Loops zu bekommen.
Das zieht sich so ein bisschen durch, den ganzen
Report, fällt mir jetzt gerade
auf. Und mir fällt gerade ein, dass wir
vielleicht mal jemanden dazunehmen
sollten in so einem Podcast
zum Thema Microservices. Ich habe da
so ein paar Leute vor Augen, also
insofern habe ich mir ja gerade mal
notiert, dass wir auch mal das Thema
Microservices durch ein paar Experten hier uns
erläutern lassen sollen. Ja, genau, dass
man jetzt da mit ein bisschen Praxis
noch mehr, also Leute, jetzt die, also
wenn man die Report-Themen anschaut,
dann vielleicht den
einen oder anderen schnappt und der dann
auf Kundenseite was
dazu erzählen kann.
Ja, du hast vorhin noch mal
ein Stichwort genannt, was ich sehr, sehr interessant
finde, das Thema Bimodal, hat man ja gesagt,
Bimodal IT, wollen wir auch noch mal kurz
drüber sprechen und
da haben wir beide die gleiche Einschätzung.
Das hat unser kleines Vorgespräch
eben gezeigt. Wir sind da beide ein bisschen
skeptisch, ob das der richtige Ansatz ist
und wir beide haben auch vom Klaus Straub
das Interview oder den Bericht gesehen
von BMW,
der eben als IT-Verantwortlicher
sagt, Bimodal IT
ist für ihn kein Thema mehr oder ist
nicht mehr der richtige Ansatz
und insofern, Alex, warum denkst du,
ist das nicht der richtige Ansatz oder nicht
zeitgemäss? Ja, also ich bin auch ein bisschen
hin und her gerissen, aber ich hatte
ein interessantes Erlebnis
bei Kunden, die hatten die
Strategie eben Bimodal IT
und die haben gesagt,
Bimodal IT heisst ja
DevOps agil, ja,
für einen Teil der IT, aber den anderen
Teil lassen wir klassisch.
Und die haben auch das aus der Not
raus, mussten die die Strategie
haben, weil die haben gesagt, ja, wir haben
jetzt in bestimmten Produkte
Bereich, da wird
bald eine Konkurrenz kommen,
ernsthaft, ja, und wir müssen da
schnell,
wir müssen da Konkurrenz,
die wollten dann neue Leute,
neue Architektur, und da
die haben gesagt, mit der alten IT können
wir das gar nicht, also Bimodal IT,
da denkt man, ja, das macht Sinn
und ich weiss auch, dann haben sie
interviewt
ein paar Experten, das kam damals von
HR, oder, da ging es dann darum,
sie wollen so eine agile Story,
eben für den einen Teil der Bimodalen IT,
um die Leute zu begeistern,
für Agilität, für DevOps, und die haben mich
dann gefragt, ja, Alex, kannst du
das mal eben so, wie würdest du die Leute
für DevOps
begeistern?
Und dann habe ich dann, ja, mir überlegt,
und dann die Gegenfrage gestellt, ja, aber eigentlich
müsste, wieso erzählt ihr nur die Story
und nicht die andere für die andere,
das ist dann das alte Eis, ne,
dann plötzlich haben wir realisiert,
dass wie eine, entsteht
eine Zweiklassengesellschaft,
also der IT, oder, da gibt es die coolen,
agilen, die
jungen, die mit Potenzial,
und dann das alte Eisen, die alten,
die sind dann in der anderen
Legacy, die sind im anderen Teil, und da
ist ja klar, die meisten wollen bei den
coolen sein, aber es gibt dann wirklich so,
also auch emotional schlechte,
und die Firma hat sich dann tatsächlich
auch entfernt vom Bimodalen
Gedanken, die haben dann gesagt,
für uns ist die klassische
Welt langfristig keine Option
mehr, weil sie haben gesagt, und ich finde das auch,
oder man hat, weil DevOps ist,
das geht ums Schnelle, Besser, ich kann auch
in einem Legacy-Umfeld,
kann ich mir Gedanken
machen, wie, wie kann,
wo kann ich ein bisschen automatisieren,
wo kann ich Silos
abbauen, also ich glaube schon,
das ist ja die Aussage im Report auch,
DevOps ist eben
für überall,
also man kann es, es kann überall
nützen, nicht nur ein Teil der IT,
und ich,
ich unterstütze das, ich habe, inzwischen
bin ich mehr Fan, weil Bimodale IT
kommt ja von Gartner,
sie haben es inzwischen, kritisieren sie es ja selber,
sie haben da das neue Modell rausgebracht,
der Pace-Layered Approach,
den finde ich besser, das nimmt auch ein bisschen
die Emotion aus, sie haben einfach gesagt, ja,
das Multispeed-IT, sie haben gesagt,
ja, je nach Bedürfnis
vom Business, auch Änderungsdruck,
muss ich dann halt auch ein bisschen
die Methoden anders anwenden,
also sie sprechen von Systems of Difference,
Differentiation, das ist wirklich die,
diese IT in Business,
also die, die Produkte,
IT-Service, wo ich mich auch im Markt
differenziere, und dort ist das
wirklich die Welt von DevOps und Agile,
dort ist es ganz wichtig,
während andere ist es dann
nicht mehr so, sie sprechen
Systems of
Record,
zum Beispiel ein SAP,
oder ein, gut,
SAP kann auch unterschiedlich aussehen, aber
so die, ich meine nicht so eine Änderung, so, da, da, da, da, da, da, da, da, da, da,
dort ist das dann, ist das dann vielleicht doch nicht
so kritisch. Aber das,
das Modell finde ich dann eine Alternative
zur bimodalen IT,
das ist ja, bimodale IT, das Modell
ist halt ein bisschen schon
spaltet dann, die IT,
finde ich, das Negative.
Wie siehst du das, wie siehst du das?
Ich sehe es auch so, ich sehe es auch kritisch,
versuche ich auch in meinen
Vorträgen rüberzubringen, das eine ist das,
was du sagtest, und was der Klaus Straub hier auch
in seinem Interview gesagt hat,
Zwei-Klassen-Gesellschaft, da haben wir die,
die Leute, die sich alt vorkommen oder langweilig vorkommen, weil sie auf Stabilität achten.
Und wenn ich DevOps richtig verstehe und wenn ich auch die Aussagen aus dem State-of-DevOps-Report nehme,
dann sind das Punkte, die genau diesem Ansatz eben widersprechen.
Ich kann, das haben wir ja vorhin schon ausgeführt, ich kann schnell sein
und ich kann aber auch Stabilität sicherstellen durch mein Vorgehen.
Und insofern, das sind, also für mich sind die Kernaussagen aus dem State-of-DevOps-Report
widersprechend diesem Ansatz bimodaler IT.
Und ich komme ja auch immer mit meiner Metapher, mit der Geschichte vom Hase und dem Igel an der Stelle.
Die meisten werden das kennen, also der Hase, der sich eben über den Igel lustig macht,
über die kurzen Beinchen, dann machen sie ein Wettrennen und der Igel nimmt seine Frau mit dazu.
Und im Prinzip macht er das ganz geschickt.
Der Hase, wenn man die Metapher zu Ende liest, glaubt nach dem 73. Mal fällt der Hase nach dem Wettrennen tot um,
weil er eben wie ein Bekloppter.
Also hirnlos, aber schnell zum Ziel rennt und dort den antrifft, der einfach das Köpfchen eingesetzt hat.
Also für mich ist das eine schöne Metapher, benutze ich immer wieder, wo ich sage,
es ist aus meiner Sicht sinnvoll, das Richtige zu tun.
Und wenn ich das Richtige tue, dann bin ich damit im Prinzip auch schneller,
weil ich mir Nacharbeiten spare, weil ich mir extra Schleifen spare,
weil ich nur das tue, was wirklich benötigt wird.
Und dieses Richtige, das Richtige tun, das ist für mich eben auch Kern,
von DevOps und dann brauche ich keine Nacharbeiten und dann bin ich eben trotzdem schneller.
Das kommt quasi automatisch, wenn ich das Richtige tue, kommt automatisch die Schnelligkeit mit dazu.
Und du hast ja von deinen Kunden gesprochen.
Meine Erfahrung ist auch, in den Scrum Teams, wo ich auch Kontakt zu den Kunden habe,
also zu den Anforderern, die meisten sagen gar nicht, dass die Schnelligkeit für sie der Vorteil ist.
Die sagen, das ist zwar schön, aber die meisten sagen, jetzt habe ich endlich den Kontakt zu den Entwicklern
und ich kann direkt einwirken und ich kriege nicht irgendwann irgendwas vorgesetzt,
sondern ich habe die Chance, mitzuwirken und ich kriege deswegen bessere Software,
ich kriege bessere Ergebnisse und das ist das, was meine Erkenntnis ist aus den Scrum Teams,
die ich, wie gesagt, betreue, wo ich die Rückmeldung bekomme.
Die Kunden sind zufrieden oder zufrieden, weil sie eben das Richtige bekommen
und nicht unbedingt im ersten Schritt, weil sie es schneller bekommen.
Ja, übrigens fand ich eine super Metapher mit der Igel und Hase,
aber ich denke auch, dass dieses Aufgibseln,
auch das Missverständnis der DevOps, es geht auch um schneller, schneller,
aber ich denke, es geht wirklich primär darum, das Richtige zu tun,
weil ich kann ja lang, schneller, schneller und auch Kosten sparen.
Wenn ich zum Beispiel das falsche Geschäftsmodell habe, dann bringt mir das nichts.
Also ich denke auch eben, dass richtige Effektivität und weniger Effizienz.
Gut, natürlich braucht es am Schluss beides, wenn man als Unternehmen florieren will.
Ja, vollkommen richtig.
Also deswegen für mich ist natürlich, die Schnelligkeit kommt,
aber sie kommt quasi als Nebeneffekt.
Und du hast es ja selber gesagt, wenn ich schnell das Falsche mache,
da bin ich eine Zeit lang ganz schön schnell, aber irgendwann bin ich dann gar nicht mehr aktiv,
muss das passende Geschäftsmodell natürlich mit dazukommen.
Ja, hast du noch Punkte, hast du noch wichtige Themen aus dem State-of-Device-Report
oder kommen wir dem Ende näher?
Ja, also wenn man auf die Uhr schaut, ja, wir kommen dem Ende.
Es gäbe schon noch so das eine oder andere Topic,
aber ich denke, wir haben nicht so mal,
wir haben den Großteil abgedeckt und auch aus unserer Sicht jetzt die spannenderen Themen, oder?
Aber ich würde, also ich habe von meiner Seite eigentlich nichts mehr.
Und ich denke auch jetzt angesichts der Zeit sollten wir mal dann Schlusspunkt machen.
Ja, genau, zum Ende kommen, ja.
Was machen wir denn beim nächsten Mal?
Ja, das lassen wir uns mal überraschen.
Also wir haben ein paar Sachen im Köcher.
Wir müssen ja noch finalisieren, wer dann effektiv für ein Intro zur Verfügung stehen wird.
Also wir sind, wir sind agil unterwegs, richtig?
Ja, genau, agil kannst du sagen.
Sorry, ich spreche manchmal ein bisschen lang.
Wir sind agil, genau.
Wir sind agil.
Und heißt ja, wir haben einen Plan, aber den müssen wir eben vielleicht auch kurzfristig anpassen.
Also insofern, wir haben ein paar in der Pipeline.
Unser Product Backlog ist gepflegt, aber noch nicht ready, um es in den Sprint zu ziehen.
Gut, Alex, ja, also ich bedanke mich sozusagen bei dir für die Unterstützung an der Stelle
und würde sagen, das Schlusswort kannst du heute machen.
Mal wieder sprechen.
Ja, also danke auch von meiner Seite, Dirk.
Und ich hoffe, das wird auch für die Zuhörer, dass es für euch interessant ist.
Und ja, ich freue mich dann auf den nächsten Podcast.
Also in diesem Sinn bis zum nächsten Mal und vielen Dank.
Tschüss.
Tschüss.
Tschüss.

Folge 4: Metro Map – Wege durch die DevOps-Komplexität

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode des DevOps-Podcasts werden die Herausforderungen und Strategien der Implementierung von DevOps in Unternehmen erörtert. Die Gäste Volkert Jung und Sebastian Schulze von der Direktgruppe teilen ihre Erfahrungen und diskutieren insbesondere die „DevOps Metro Map“ – ein Instrument zur Visualisierung und Strukturierung der vielfältigen Aspekte von DevOps. Die Diskussion beleuchtet die Bedeutung von Kultur, Prozessen, Technologie, Innovation und IT-Service-Management in DevOps und betont die Notwendigkeit eines kontinuierlichen Lern- und Anpassungsprozesses innerhalb von Unternehmen.

Inhalt

  • Einführung und Vorstellung der Gäste
    • Vorstellung von Volkert Jung und Sebastian Schulze von der Direktgruppe
  • DevOps-Definition und Missverständnisse
    • Diskussion über die irreführende Wahrnehmung von DevOps als Jobtitel
  • DevOps in der Praxis
    • Herausforderungen und Realitäten von DevOps in Unternehmensstrukturen
  • Die DevOps Metro Map
    • Entwicklung und Ziel der DevOps Metro Map zur Visualisierung von DevOps-Komplexität
  • Wichtige Aspekte von DevOps
    • Rolle von People, Process, Technology und Innovation in DevOps
  • IT-Service-Management in DevOps
    • Diskussion über die Integration und Bedeutung von ITSM in DevOps
  • Zukunft von DevOps und die Metro Map
    • Überlegungen zur kontinuierlichen Weiterentwicklung und Anpassung der DevOps-Strategien
  • Abschluss und Dank an die Gäste

Shownotes

  1. Direktgruppe: Ein Beratungsunternehmen, das in den Bereichen IT-Infrastruktur, Softwareentwicklung und IT-Strategie tätig ist. Es ist bekannt für die Entwicklung der „DevOps Metro Map“. Leider konnte ich keine direkte URL zur „DevOps Metro Map“ finden, daher empfehle ich, die Hauptseite zu besuchen und gegebenenfalls direkt nach der Metro Map zu suchen. Direktgruppe Website
  2. DevOps Metro Map: Ein von der Direktgruppe entwickeltes Visualisierungstool, das die Komplexität von DevOps strukturiert. Eine spezifische URL ist nicht verfügbar
  3. Eric Ries – Lean Startup: Das Buch „Lean Startup“ von Eric Ries, das wichtige Prinzipien für die Entwicklung von Minimum Viable Products und Start-up-Strategien bereitstellt.
  4. IT-Service-Management (ITSM): Wichtig für die Implementierung von DevOps, ITSM ist ein zentraler Bestandteil für den effektiven IT-Betrieb. Informationen über ITSM und dessen Praktiken können auf Seiten wie AXELOS gefunden werden, die Best-Practice-Lösungen anbieten.

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zur vierten Folge vom DevOps-Podcast auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begrüße Sie zur Folge, bei der wir heute zwei Gäste haben.
Wir haben heute den Volkert Jung und den Sebastian Schulze von der Direktgruppe.
Und ich glaube, ich muss gar nicht viel einleitend sagen.
Volkert, kannst du kurz dich vorstellen? Kannst du kurz die Direktgruppe vorstellen?
Das mache ich doch gerne. Hallo Dirk, hallo Alex. Vielen Dank, dass ihr uns eingeladen habt.
Mein Name ist Volkert Jung. Ich bin Berater und Prokurist in der Direktgruppe.
Und ich möchte kurz was zum Unternehmen sagen, damit wir auch gar nicht viel Zeit verlieren.
Und dann schnell zu unserem Fachthema übergehen.
Die Direktgruppe ist ein Beratungsunternehmen aus Hamburg.
Wir sind seit 1998 auf dem Markt an verschiedenen Standorten mit über 200 Beratern in verschiedenen Themenstellungen.
Sei es von der IT-Infrastruktur über die Softwareentwicklung zur IT-Strategie
bis hin zur Online-Marketing oder SAP-Beratung bieten wir hier ein weites Feld an.
Für unsere Kunden ist es ein sehr wichtiges Thema.
Für unsere Kunden erbringen wir unsere Leistungen im großen Teil recht individuell.
Und in dem Kontext haben wir halt immer wieder Berührungspunkte mit agilen Ansätzen gefunden.
Genau mit dem Übergang, wie bringe ich entwickelte Produkte in den Betrieb und halte all diese Themenzahlen für uns auf die Ansätze ein, die DevOps verfolgt.
Und in diesem Kontext…
Beraten wir jetzt auch unsere Kunden.
Und damit gebe ich das Wort gern zurück an Dirk, damit wir hier inhaltlich einsteigen können.
Doch zuvor vielleicht noch Sebastian, magst du auch noch zwei Worte zu dir sagen?
Ja, hallo, guten Abend.
Vielen Dank, Dirk und Alex, für die Möglichkeit, uns vorzustellen.
Mein Name ist Sebastian Schulze.
Ich bin in der Direktgruppe seit über acht Jahren bisher tätig als Softwareentwickler und Teamlead in der Softwareentwicklung.
Und mache jetzt seit Anfang 2017 das Thema DevOps und Transformationsberatung.
Ich komme aus dem softwareentwickelnden Bereich der Direktgruppe.
Deswegen liegt mir das in der DNA und kümmere mich eben vornehmlich um Fragestellungen der Digitalisierung von Softwareentwicklungsprozessen, das heißt Continuous Delivery.
Im Wesentlichen…
Und da spielt es natürlich eine große Rolle, dass die große Klammer DevOps, wie kriegen wir hier die Zusammenarbeit im Unternehmen wieder neu geregelt und verbessert?
Wie werden Unternehmen wandlungsfähiger?
Wie kriegen wir in die Unternehmen eine entsprechende Kultur und bilden entsprechende notwendige Haltungen bei den Mitarbeitern und Führungskräften aus?
Ja, sodass deren Unternehmen wieder wandlungsfähiger und schneller werden in der Produktion von Software und IT.
Sebastian Volkert, vielen Dank für die Vorstellung.
Herzlich willkommen auch von meiner Seite, Alex Lichtenberger.
Ja, auch heute wieder das Thema DevOps.
Und ja, DevOps, ich denke, es herrscht ja generell Einigkeit, was wir damit erreichen wollen, auch warum DevOps ein Thema wird.
Aber DevOps dann auch, wenn es um die Umsetzung geht, ist das sehr wichtig.
Es ist sehr komplex.
Und da kommen verschiedenste Elemente zusammen.
People, Process, Technology, aber auch methodisch.
Agile, der Sebastian hat es erwähnt, dann aber auch Lean und Service Management.
Ja, und da hat, denke ich, die Direktgruppe, und das wird auch das Thema heute, eine super Visualisierung gefunden, um diese Komplexität auch ein bisschen Struktur einzubringen.
Also mit ihrer Metro Map, das heute so im Fokus.
Bevor wir aber…
Bevor wir dann auf diese Metro Maps zu sprechen kommen, wir stellen ja inzwischen bei jedem Podcast unseren Gästen die Frage, was ist DevOps?
Also deshalb auch an euch, Sebastian Volkert, die Frage, was versteht ihr unter DevOps?
Kann man das definieren überhaupt?
Wie würdet ihr es definieren?
Ja, bitte.
Ich übernehme mal das Wort zuerst.
Ich nehme vornehmlich wahr, dass es…
…eine irrenführende Wahrnehmung gibt, weil viele glauben, dass DevOps ein Job ist oder eine Jobbeschreibung.
Man sieht das häufig jetzt so in Stellenanzeigen oder so, dass DevOps-Engineers gesucht werden, wo meines Erachtens dysfunktional versucht wird, das mit einer Stelle zu erschlagen.
Ich vergleiche das ganz gerne damit, dass man ja auch nicht als Unternehmen hingehen würde und sagen würde, dass man das mit einer Stelle zu erschlagen würde.
Ich würde sagen, wir stellen jetzt einen Zusammenarbeitsspezialisten ein, der zukünftig die gesamte Zusammenarbeit in einem Unternehmen verantwortet und durchführt.
Insofern wird es auch das Thema DevOps nicht schaffen, zumindest nach dem, was ich mir da so vorstelle und viele andere auch.
Es geht hier vielmehr um ein Mindset, was eben diese Prozesse…
…Culture miteinander in Beziehung setzt und es einfach aus dem Wunsch heraus entstanden oder heutzutage weiterverfolgt, dass Unternehmen schnell und handlungsfähig werden wollen, was das Thema Softwarelieferung angeht.
Wir nehmen das häufig fest, zumindest stellen das fest, das tue ich bei meinen Kunden auch, bei denen ich als Berater auftrete, dass dort häufig gewachsene hierarchische Unternehmen…
…Unternehmenstrukturen da sind, wo IT weniger Enabler ist, sondern sich über die Zeit aufgrund bestimmter Einflussfaktoren vielmehr als Blockierer oder Verwalter darstellt, in denen so Not-My-Job und Verweigerungshaltung an der Tagesordnung sind oder zumindest von den Leuten, die IT in diesen Unternehmen in Anspruch nehmen, den Business Units, den Fachabteilungen…
…dass da das Gefühl entstanden ist, wir kommen hier nicht weiter, wenn wir uns an unsere IT wenden, da braucht es Jahre und das haben natürlich Mitarbeiter wie Entscheider erkannt, dass das in der heutigen Welt mit der Geschwindigkeit, mit der entwickelt wird, dass das nicht mehr so ganz passt und dass wir hier erleben, dass kleine Startups in der Wertschöpfung, was jetzt neue Technologien…
…Nutzung oder auch neue Geschäftsmodelle angeht, die großen etablierten Konzerne, die eigentlich genug Manpower und genug Geld dafür hätten, abhängen, was die Innovationskraft angeht und im Zweifel auch deren Geschäftsmodelle angreifen und das will man sich natürlich hier nicht bieten lassen.
Ich will nicht sagen, dass DevOps nur aus dieser Konzernsicht motiviert ist, aber für uns wandelt es sich.
Von diesem Kerngedanken kriegen wir nicht auch Infrastruktur agil, das war ja mal Keimzelle dieser DevOps-Bewegung, nachdem man ja Agilität in der Softwareentwicklung schon lange Jahre praktiziert hat.
Aber das ist für uns die Realität. Wir sind da bei Unternehmen und müssen erklären, dass es eben nicht nur Technologie ist, die DevOps darstellt oder diesen Gedanken, dieses Mindset, häufig auch als Philosophie bezeichnet,
…sondern im Wesentlichen das Zusammenleben.
…das Zusammenleben von, na klar, Development Operations, aber auch dem Business, was wieder lernen muss, gemeinsam zu funktionieren für gemeinsame Wertschöpfung.
Back to the Roots, ja. Dann die Frage, wie seid, also ihr als Direktgruppe macht ja schon eine ganze Weile Beratung, Technologie, IT-Beratung. Wie seid ihr überhaupt zum Thema DevOps gekommen? Was waren da so die Treiber dafür?
Würde ich sagen, wir haben da Verschuldung.
Wir haben da verschiedene Anknüpfungspunkte, weil wir in der Direktgruppe ja durchaus verschiedene Arten von Beratungen anbieten, was in dem IT-Spektrum, Volker wird das gleich bestimmt ergänzen, für mich als jemand mit Softwareentwicklungs-DNA war das klar geworden in den letzten Jahren, dass eben rein dieses agile Entwickeln nicht ausreicht.
Wir haben dann festgestellt, wir müssen uns selber stetig erneuern.
In der Art, wie wir Softwareentwicklungsprojekte machen. Für uns gehört es zwar immer zum, war immer ein Teil davon, dass wir die Software, die wir selber entwickelt haben für unsere Kunden, meist auch selbst betrieben haben.
Das heißt, uns ist es relativ selten begegnet, dieses klassische Silo-Denken, aber wir haben festgestellt, dass natürlich auch in unserer eigenen Organisation diese Silos entstanden sind.
Und haben dann…
Selbst daran gearbeitet, wie wir das wieder reduzieren.
So sind wir rein aus praktischen Aspekten, weil wir das selber brauchten, um am Markt überhaupt konkurrenzfähig zu sein.
Haben wir dann aber festgestellt, es gibt viele andere Unternehmen auch, die sich mit diesen Fragestellungen plagen und die nicht damit gesegnet sind, diese Erfahrungen gemacht zu haben.
Beziehungsweise die einfach von der Organisation selbst, vielleicht nicht ganz so wendig.
Wie wir das sind und waren.
Deswegen haben wir gesagt, wir möchten gerne unsere Erfahrungen und die, die wir jetzt auch noch sammeln.
Ich möchte nicht sagen, dass wir da die Weisheit mit Löffeln gefressen haben.
Auch wir haben noch viel zu lernen.
Dass wir das unseren Kunden auch als ein neues Portfolio-Element anbieten.
Und die Dinge, die wir da jetzt lernen, selbst lernen und bei Kunden sehen und wie wir uns da weiterentwickeln, fließen.
Wir fließen dann wieder in unsere eigenen Software-Entwicklungsprozesse ein.
Deswegen ist das so ein sich selbst befruchtendes System.
Was einen ganz wesentlichen Aspekt, ich habe es jetzt schon mehrfach wiederholt in meiner Rede, begünstigt, nämlich dieses kontinuierliche Lernen.
Ich denke, das steht für mich jetzt ganz persönlich auch im Zentrum des Ganzen.
Und so sind wir eigentlich dazu gekommen, was wir jetzt da machen.
Und der Volkert hat da jetzt nochmal eine ergänzende Sicht, glaube ich, draus.
Da möchte ich dich bitten, ergänz das doch bitte nochmal.
Letztlich hast du ja gut dargestellt aus der Perspektive Software-Entwicklung, Software-Herstellung und Inbetriebnahme die Aspekte, die zu DevOps gehören.
Aus meiner Beratungswelt und meines Teams komme ich mehr aus der Betriebs- und Organisations- und auch aus der Prozessseite.
Und stelle halt auch hier fest, dass durch neue Technologien, vornean natürlich immer wieder genannt Cloud.
Computing, verschiedene Erwartungen daran gestellt werden.
Und eine der Erwartungen heißt Geschwindigkeit.
Bestehende IT-Organisationen von großen Unternehmen, denen fällt es halt sehr schwer, hier die technische Integration zu realisieren und dabei auch gleichzeitig schnell zu werden.
Und dieses Schnellwerden ist da meines Erachtens ein ganz wesentlicher Treiber für Initiativen im Kontext DevOps.
Projekterfahrungen, Projektmanagement-Erfahrungen sammeln sich dazu, indem man halt,
Scrum-Elemente anwendet und dann iterativ auch Non-Software-Entwicklungsprojekte durchführt.
Also vielleicht IT-Infrastrukturprojekte, Server-Konsolidierung, Rechenzentrums-Zuladenlegung oder ähnliches.
Trotzdem hapert es immer wieder an der Geschwindigkeit.
Und diese Thematik wollen wir hiermit gerne aufgreifen.
Und den Punkt sehen wir da drin.
Innovation ist vielleicht noch eine weitere Thematik.
Die halt aus der Betriebssicht und aus der Entwicklungssicht vielleicht noch teilweise sehr weit weg erscheint, weil ja doch in der Praxis im Allgemeinen die Unterstellung formuliert wird, die IT ist viel zu weit weg vom Business und viel zu weit weg an neuen Geschäftsmodellen, die idealerweise digital sein sollen.
Und aus diesen drei Sichten heraus jetzt mal ein stärkeres Zusammenrücken hervorzubringen.
Und das sind Aspekte, die wir auch mit DevOps verbinden.
So und das führte uns dann zu dem Gedanken, da eine Visualisierung zu schaffen.
Und Alex und Dirk, ich glaube, an der Stelle kommt jetzt auch gleich eure nächste Frage.
Welches Ziel habt ihr denn überhaupt mit dieser Meta-Map verfolgt?
Das ist eine wunderschöne Karte, aber was habt ihr als Ziel damit verfolgt?
Also wir standen ja vor der Frage, als wir jetzt das Thema DevOps als Portfolio-Punkt für uns aufgenommen haben.
Wie kriegt man eigentlich ein gemeinsames Verständnis davon?
Gerade weil wir selbst ja auch verschiedene Sichten innerhalb der Direktgruppe hatten, aber auch mit den Leuten, die wir außerhalb unserer Organisation gesprochen haben, gab es halt immer wieder verschiedene Auffassungen.
Und wir wollten hier eine Möglichkeit schaffen, diesen Begriff DevOps mit allem, was dazugehört, vielleicht eher nicht dazugehört, mal zu strukturieren und haben uns versucht,
an einer Darstellungsform.
Die erstmal Diskussionsgrundlage gibt.
Klarheit schafft über das, was wir darunter verstehen und das, was unsere Ansprechpartner, Kommunikationspartner, Kunden darunter verstehen und haben da verschiedene Dinge ausprobiert.
Man versucht ja immer gerne in hierarchischen Schemata zu denken, wie so eine Ordnerstruktur und daran haben wir uns die Zähne ausgebissen.
Und dann haben wir festgestellt…
Alles, was für uns zum Thema DevOps assoziiert werden muss, müssen wir anders darstellen.
Und so sind wir in diese MetroMap-Darstellung gekommen.
Also ich höre da auch heraus, ich habe verschiedene Dinge ausprobiert und das ist ein Resultat aus dem Entwicklungsprozess.
Und vielleicht auch zum, genau bevor wir zum Aufbau der MetroMap kommen, vielleicht an die Zuhörer, weil das ist ein Podcast, das heißt, ihr könnt die MetroMap nicht sehen.
Also es lohnt sich da, das vielleicht sich jetzt auch…
Vor Augen zu führen, also zum Podcast, also einen Link zur Grafik selber.
Es lohnt sich natürlich, das auch noch anzuschauen.
Aber jetzt vielleicht Frage an euch, Sebastian und Volker, könnt ihr mal so den Aufbau dieser MetroMap kurz erläutern?
Ja, im Wesentlichen haben wir festgestellt, wir haben verschiedene Achsen, auf denen ja eine Einordnung von Begriffen…
… im DevOps-Umfeld einzuordnen sind.
Wir haben jetzt drei große Bereiche, auf jeden Fall klar, Development, die Entwicklung, der IT-Betrieb, Operations.
Aber was uns ganz wichtig war, auch das Business mit reinzunehmen.
Weil aus unserer Wahrnehmung, das teilen ja auch viele andere, wenn man sich so umhört, darf ja IT nicht den Eindruck erwecken, es wäre ein Selbstzweck, sondern es muss immer einen Nutzen.
Deswegen halt der dritte Pol ganz oben, das Business.
In diesem Dreieck haben wir versucht, die Begrifflichkeiten, die sich hier finden, einzuordnen.
Sicherlich ist die Einordnung nicht ganz trennscharf.
Ich hatte ja eben schon ausgeführt, Kategorisierungen gelingen da nicht so einfach.
Man findet immer Argumente für und gegen.
Und es basiert ja jetzt auf keiner empirischen Untersuchung.
Sondern es ist halt eine Meinungsverwaltung.
Außerdem haben wir festgestellt, gibt es noch fünf weitere Achsen, die wichtig sind, immer gern im DevOps-Kontext wiederzufinden.
Das Thema People, Technology und Processes.
Wir wollten aber ganz klar noch zusätzlich reinnehmen, dass für uns das Thema Innovation ein ganz wichtiges ist.
Innerhalb von DevOps, was wir gerne separat herausstellen wollten.
Und zusätzlich ganz wichtig ist, ist das Thema IT-Service-Management.
Weil man darf DevOps jetzt nicht als etwas darstellen oder betrachten oder verstehen, was jetzt im luftleeren Raum neu entstanden ist.
Sondern was ja auch auf Bestehenden aufsetzt.
Und insbesondere das Thema IT-Service-Management ist da wichtig, weil da gibt es ja viele Ansätze, viele Lösungen auch in der Vergangenheit.
Und der Gegenwart, die wir da besonders herausstellen wollten, weil uns dazu auch viele Leute fragen.
Und diese fünf Achsen stellen für uns hier die, ich nenne es mal U-Bahn-Linien dar, um im Bild zu bleiben.
Und deswegen haben wir die miteinander verbunden.
So, das ist der Grundaufbau.
Außerdem haben wir einen Kern, den wir abgetrennt haben, wie eine solche Tarifzone.
Wo wir sagen, für uns gibt es einen gewissen Konsens.
Dass bestimmte Dinge eher im Kern…
…von DevOps liegen und andere wichtig auch dazu gehören, aber für uns jetzt nicht den Kern ausmachen.
Deswegen haben wir hier versucht, nochmal so eine zentrale Tarifzone einzuziehen.
Ja, das ist ja dann das Interessante bei einem Podcast.
Wir reden über irgendetwas, was die Zuhörer nicht sehen.
Aber was wir jetzt schon gehört haben, ist, es ist eine Art U-Bahn-Linienkarte, die nicht nur DevOps hat, sondern auch das Business hat.
Und im Kern haben wir eben quasi die Tarifzone 1.
Also die Tarifzone 0 mit den wichtigsten Themen.
Was ich sehr interessant finde, sind diese fünf U-Bahn-Linien.
Und ihr habt ja auch gesagt, dass ihr das nutzt, um in die Diskussion zu kommen, um Dinge zu besprechen.
Ich sehe zum Beispiel, ganz interessant, wenn wir mal auf die Beispiele eingehen, dass zum Beispiel Service Operations,
was ja auf der ITSM-Linie, auf der IT-Service-Management-Linie liegt, dass das nicht zum Kern gehört.
Also vielleicht gleich die Frage.
Das ist nicht Kern von DevOps aus eurer Sicht.
Also wie diese Map entstanden ist, ist tatsächlich, dass wir uns mit Leuten auseinandergesetzt haben, die jetzt bei uns in der Organisation sind und die auch von außen kommen, sprich Kunden insbesondere, mit denen wir diese Ansätze reflektiert haben.
Und zur Vollständigkeit gehört auch, dass wir sagen, wir leben oder wollen auch mit dieser DevOps-Metro-Map einen Gedanken von Continuous Service Delivery.
Das heißt, das ist nichts, wo wir sagen, das ist für alle Zeit fest, sondern wir bessern das regelmäßig nach.
Gerade wenn wir neuen Input kriegen, der uns überzeugt.
Jetzt konkret auf das Service Operations gegangen, war für uns das Verständnis, Service Operations ist jetzt etwas, was grundsätzlich keine ganz neue Idee ist.
Wir finden hier bestimmt viele Dinge, von denen der eine sagt, ja, neu oder andere nicht neu.
Aber tatsächlich, wenn man jetzt den Unterschied…
…macht zwischen dem auf derselben U-Bahn liegenden Security, sind wir jetzt der Meinung, nach aktueller Entwicklungslage in der Community, was definiert man in DevOps rein?
Dann hat man jetzt mit diesem Begriff DevSecOps, hat man jetzt diesen Security-Begriff mit drin.
Deswegen haben wir den jetzt als eingebaute Security mit in den Kern gezogen.
Das Thema Service Operations betrachten wir jetzt hier als Macher.
Das ist auch sehr nah assoziiert, weil, wie gesagt, wenn ich von Continuous Service Delivery spreche, dann muss ich diesen Service auch betreiben.
Wir sind aber der Meinung, dass das auf dieser IT-Service-Management-Linie nicht mehr zwingend dazugehört, weil das etwas ist, was ich in der Vergangenheit auch schon betreiben musste in diesem Kontext Operations.
Deswegen haben wir uns entschieden, dass das die erste Station außerhalb des Kerns ist.
Ihr habt ja dasselbe immer gesagt.
Vorher ist es schlussendlich ein Produkt von der Meinungsbildung.
Aber es ist ja, man hat wahrscheinlich dann jeder ein bisschen eine andere Meinung.
Gehört es jetzt noch dazu oder nicht?
Aber das Schöne, dass man dann anfängt, darüber zu diskutieren, wenn man so das vor sich hat.
Das war auch noch eine Frage fürs Verständnis, auch der Map.
Ich sehe es jetzt im Sinne so wie eine Metro mit den Linienstationen.
Das hat einen bestimmten Grund, dass es genau in der Reihenfolge, also wenn ich jetzt beispielsweise People,
da sehe ich in Chord, in Know-how, Transfer, Collaborative Culture, Collective Ownership.
Hat das da irgendwas auf sich mit dieser Sequenz?
Also dieses Ordnungsprinzip ist natürlich schwer und es lässt sich häufig was reindeuten.
Aber man muss jetzt auch sagen, dass bis auf einige Highlights, die bewusst gesetzt wurden,
durchaus sich da Argumente reindeuten.
Warum das eine jetzt neben dem anderen steht, zum Beispiel das Thema Resilienz und Anti-Fragile,
das ist jetzt auf der People-Linie gelandet, dass wir gesagt haben,
Anti-Fragile ist etwas stärker noch als Resilienz, aber genauso gut könnte man Argumente dagegen finden.
Was interessant da hervorzuheben ist, aus meiner Sicht, ist jetzt die räumliche Nähe von diesen,
von diesen U-Bahnen.
Wie zum Beispiel, du hast es eben rausgepickt, Collective Ownership und Common Metrics.
Das ist jetzt auf der einen Seite auf der People-Ebene, dieses Collective Ownership,
das heißt, dass wir uns auch gemeinsam den Gegenstand, in dem wir arbeiten,
und die Business-Ziele und die technologischen Lösungen zu eigen machen
und damit auch eine Eigenverantwortung tragen.
Und damit sowas geschehen kann,
wollen wir auf dieser Linie IT-Service-Management das Thema Common Metrics sehr nah dran platzieren,
weil wir durchaus feststellen, ich gehe jetzt mal in dieses Bild rein,
der Wall of Confusion, die ja in DevOps häufig bemüht wird,
wo halt eine Wand ist zwischen Dev und Ops, wo man sagt,
wenn wir nicht auf gemeinsam harmonisierte Ziele hinarbeiten und die entsprechend ja dann auch für uns messbar werden,
auch interdisziplinär, dann könnte es uns schwerer fallen,
diese Collective Ownership für uns zu etablieren oder anzunehmen.
Deswegen haben wir gesagt, na, da könnte es doch vielleicht einen solchen Umsteige-Bahnhof geben,
um weiter metaphorisch zu bleiben.
Ja, das wäre jetzt so ein Beispiel.
Oder vielleicht noch ein schnelles Beispiel hinterher.
Im Kern finden wir auch eine sehr nahe Verbindung oder sehr nah angeordnet,
das Thema Change-Management aus dem ITSM und das Thema Continuous Integration,
was wir jetzt eher auf der Prozesslinie haben.
Da gibt es häufig Diskussionen und irgendwie eine thematische Nähe, die wir darüber darstellen wollen.
Vielleicht kann ich da nochmal ergänzen, genau den Punkt, den du gerade eben genannt hast.
Auf dieser Prozessebene haben wir einerseits Continuous Integration und Continuous Delivery draufstehen
und das verbunden mit einem IT-Service-Management und Change-Management.
Da lässt sich ja wunderbar darauf diskutieren, wie skalieren wir einen Change-Management-Prozess etabliert,
nach Eifel, seit 1998 bei einem Kunden vielleicht implementiert.
Wie skalieren wir denn das in eine Landschaft, die fortwährend Pakete bereitstellt, Software-Pakete?
Wird jedes einzelne Paket ein Change?
Wie wird er autorisiert?
Muss der durch einen Change-Advisor-Report gehen?
Das sind Aspekte, die man halt hervorragend hier draufstellt.
Worauf diskutieren kann.
Und eben One-Size-Does-Not-Fit-All ist sicherlich auch ein Aspekt,
wo doch mitunter individuelle Lösungen zu finden sind, die dann auf die jeweilige Unternehmung anzupassen sind.
Diese Diskussionsgrundlage finde ich sehr wichtig und bekomme auch häufig dann die Frage,
wie ist das hier mit der Reihenfolge?
Und muss da dann halt auch als Prozessberater sagen,
das ist hier keine Prozesskette, die mit den Stationen abgebildet ist.
Und wenn man sich selbst als Fahrer einer U-Bahn oder Straßenbahn bewegt,
fährt man die auch selten immer von Startstation bis Endstation vollständig durch.
Man fährt vorwärts und rückwärts, man steigt um.
Das wollten wir hier auch entsprechend mit anregen, diese Analogie entsprechend weiterzutragen.
Und dann die Nähe der Stationen, die hat ja dann die Bedeutung.
Also man sieht es auch schön, zum Beispiel Continuous Monitoring,
Technology, ja, und das dann verknüpfen mit Incident Problem Management, macht absolut Sinn.
Oder wenn man sich die Innovation-Linie, die gelbe oben anguckt,
dann findet man eine räumliche Nähe, auch auf einer Linie, von dem Thema Lean Startup und Minimum Viable Product,
was ja da von Eric Ries in seinem Buch Lean Startup verortet wurde.
Und dann kommen wir schon recht bald zu Design Thinking.
Also so eine assoziative Nähe ist da grundsätzlich auch,
zu finden, auch bei Culture of Failure und Fast Feedback Loops.
Aber was wir nochmal unterstreichen wollen, wir sind dankbar für jedes Feedback,
was das nochmal klarer macht, ergeben uns aber jetzt nicht einer Hoffnung oder Jagende hinterher,
dass wir hier den heiligen Gral von DevOps haben, sondern wir freuen uns halt immer,
wenn da eine Diskussion in Gang kommt und wenn es da auch mal kontroverse Meinungen gibt.
Und das gelingt ganz gut.
Ja, eine Rückmeldung.
Eine Rückmeldung von mir, was mir sehr gut gefällt, ist, dass das Thema IT-Service-Management bei euch zum Kern mit dazu gehört.
Ihr habt wesentliche Prozesse mit drin im Kern.
Ihr habt überhaupt schon mal eine IT-Service-Management-Linie.
Also insofern finde ich das schon mal sehr schön, weil ich glaube,
dass DevOps schon auch eine Art Weiterentwicklung sein kann von IT-Service-Management,
wenn man sich einfach mal auf Frameworks bezieht.
Also insofern finde ich das als Rückmeldung dazu, Sebastian, schon sehr, sehr interessant.
Ja, also danke für die Vorlage, Dirk.
Denn das Thema IT-Service-Management liegt mir halt auch am Herzen und zeigt halt auch auf,
ja, das hat vielleicht einen leichten Charme mit Patina,
aber hat auch irgendwie eine Berechtigung, wenn es nicht als Selbstzweck verstanden wird.
Und an der Stelle bewegen wir uns hier.
Also ein Incident- und ein Problem-Management ist halt weiterhin wichtig
und auch ein Configuration-Management ist weiterhin wichtig.
Und das gehört halt auch unbedingt zu einem Kern,
so ein Verständnis.
Ja, schlussendlich sind das ja alles Hilfsmittel.
Und auch im IT-Service-Management hat es ein paar super Ideen, die DevOps unterstützen.
Und das ist schade dann, wenn die Diskussion dann zum Teil emotional geführt wird.
Dafür gibt es dann schon die Szene, die dann sagt,
ja, DevOps ist der Tod von IT-Service-Management.
Also das sehe ich nicht so.
Da stimme ich absolut euch auch zu.
Genau, also wir haben da ja auch lange drüber debattiert.
Und ich glaube, nicht nur persönlich,
sondern es sollte auch Konsens innerhalb der Direktgruppe sein.
Und das, was wir auch in unseren Veranstaltungen mit Kunden da als Feedback kriegen.
Irgendwo liegt die Wahrheit dazwischen.
Das heißt, IT-Service-Management stirbt damit nicht aus.
Aber bestimmte Konzepte, beziehungsweise die Umsetzung dieser Prozesse
müssen vielleicht neu gedacht werden unter dem Eindruck der Möglichkeiten der Automation.
Ja, und jetzt komme ich mit einem Hinweis.
Mit einer Frage, wenn man sich das anguckt.
Das Thema Cloud.
Das habt ihr zwar mit aufgenommen, sehr nett, aber es ist nicht zum Kern.
Warum gehört denn Cloud bei euch nicht zum Kern von DevOps?
Ja, interessante Frage.
Bist du nicht der Erste, Dirk, der das fragt?
Wenn man argumentiert, dass man sagt, wir haben software-definierte Infrastruktur,
dann ist es bestimmt ein wesentlicher Enabler von DevOps.
Ohne dieses würde es weniger Möglichkeiten haben.
Nämlich die technologischen Möglichkeiten, der Fortschritt treibt ja überhaupt,
dass wir so etwas wollen, was für uns hinter DevOps steckt und dass wir das können.
Also sprich, Geschwindigkeit aufnehmen und vielleicht auch mehr in Wegwerf zu denken
als in Wiederherstellung.
Ohne Cloud wäre das bestimmt nicht möglich.
Aber wir sind der Meinung, dass jetzt Cloud alleine, gerade vor dem Hintergrund,
derkt.
Ja, dieses Public-Cloud-Gedankens, der da ja am nächsten liegt,
nicht unbedingt notwendig ist, um so etwas wie DevOps zu betreiben
oder in dieser Richtung sich zu entwickeln.
Weil es durchaus auch andere Möglichkeiten gibt,
DevOps zu, oder Werte, die DevOps ausmachen,
in einem Unternehmen zu etablieren.
Dafür braucht man nicht unbedingt die Cloud.
Das heißt, wir wollten damit ganz deutlich machen,
dass man nicht aufgeben muss, nur weil es in einem Unternehmen,
in Klammern noch, keine Cloud-Strategie gibt.
Das ist der Gedanke dahinter.
Ja, ich wollte noch einen Punkt noch einmal ausführen.
Natürlich schauen wir jetzt auf diese Linie, die den Core von DevOps aufzeigt.
Aber das ist halt erstens keine harte Linie, sie ist gestrichelt dargestellt.
Und alles, was auf der Metro-Map zu sehen ist,
sind für uns DevOps-relevante Aspekte.
Und das mag sicherlich außerhalb der Map noch weitere Dinge geben,
die da auch zugehörig sein können.
Aber all das gehört dazu.
Und oft ist natürlich auch die Frage, womit fange ich denn an?
Wenn ich schneller, wenn ich meine Kultur mehr in Richtung Innovation bringen will,
wenn ich ein anderes Werteverständnis schaffen will,
brauche ich dafür Cloud?
Und die Antwort heißt, nicht unbedingt.
Hilft bestimmt.
Und auch…
Auch andere Aspekte, vielleicht Start-up-Aspekte,
die jetzt auf der Innovation-Linie liegen,
die brauche ich auch nicht unbedingt.
Das ist aber auch gestrichelt.
Ja.
Und wenn ich das als praktisch überlege,
wenn ich jetzt in die Diskussion würde gehen mit einer Map,
kann ich es immer kritisieren und jeder hat seine Meinung.
Aber ich glaube, eben darum geht es nicht,
sondern die Diskussion und dann eben auch eine Lücke zu erkennen.
Also wenn man zum Kunden sagt,
ah, okay, ja, aber…
Collaborative Culture,
da haben wir jetzt überhaupt noch nicht dran gedacht.
Und dann das zu erkennen und dann daraus auch so etwas wie Massnahmen abzuleiten,
ist es richtig?
Verwendet ihr das auch in dem Kontext?
Absolut.
Und gerade hier haben wir ja oftmals einen Startpunkt von Continuous Delivery
und agiler Entwicklung.
Ohne das Mindset, ohne Collaborative Culture wird es schwierig.
Und genau deshalb steht der…
Steht die Station halt im Core-Bereich, wo wir sagen,
ja, das ist ein Aspekt, über den man unbedingt nachdenken sollte,
wenn man sich hier mit diesen Ansätzen beschäftigt.
Continuous Testing, da ist es auch…
Gut, kann man jetzt abdiskutieren,
aber für mich ist eigentlich Continuous Testing
ein zentraler Enabler für Continuous Delivery.
Ich will ja Tests automatisieren, Feedback Loops.
Wieso habt ihr…
Müsste man das nicht ein bisschen weiter nach rechts verschieben?
Oder was ist das Argument?
Dass ihr es da draußen habt?
Berechtigte Frage.
So wie du es beschreibst, würden wir das…
Also kann ich dem folgen und würde ich auch sagen,
das kann genauso gut drin sein.
Wir haben das Gefühl gehabt bei der Einordnung,
dass das Thema Continuous Testing ähnlich wie Bildautomation
insofern nichts Neues ist,
als dass wir schon…
schon seit vielen Jahren, sage ich mal,
automatisierte Unit-Tests im Zusammenhang
mit Continuous Integration betreiben.
Vor dieser Argumentation würde ich selber auch infrage stellen,
was tut denn jetzt Continuous Integration da?
Das gab es ja auch schon vorher.
Im Zusammenspiel aber mit dem Change Management
und dann dieser Nähe zur Continuous Delivery
kriegt es, sage ich mal, eine neue…
irgendwie eine Ressistance, will ich gar nicht sagen,
aber etwas nochmal ein anderes Gewicht,
und gehört deswegen da rein.
Ähnliche Argumentationen kann man bestimmt auch
mit Continuous Testing führen.
Deswegen würde ich mich da jetzt persönlich
auch gar nicht so festlegen.
Ich stelle fest, es ist sehr nah am Rand,
an der Tarifzonen-Grenze,
und ich würde mal ganz stark hoffen,
dass da kein Kontrolleur kommt und meine Fahrkarte überprüft,
wenn ich da am Rande unterwegs bin.
Insofern tatsächlich muss man auch sagen,
hier sind wir wieder auf dem Thema Deutung,
und mir ist ganz wichtig, dass man das nicht vergisst.
Und wenn man genau diese Frage stellt,
dann bin ich der Meinung, ist man grundsätzlich
mit dem Thema DevOps und dem Mindset in der Umsetzung
schon gut unterwegs.
Wir haben das ja auch schon in verschiedenen Formaten,
auch in Social Media bereitgestellt,
und da haben wir zum Teil lebhafte Diskussionen gehabt,
insbesondere auch ein Feedback, was wir jetzt häufig wieder kriegen,
woran sich die Leute denken, dass wir das nicht machen,
woran sich die DevOps-Metro-Map messen lassen muss
oder wo sie gemessen wird.
Die Frage, super, dass es da eine Einordnung gibt,
super, dass man eine Übersicht hat,
dass man eben eine Besprechungsgrundlage hat
in bestimmten Situationen, um nichts zu vergessen
oder zumindest Dinge bewusst nicht weiter zu verfolgen
oder zurückzustellen.
Aber was es natürlich auch nicht beantwortet,
ist die Frage, wie komme ich denn jetzt
in eine DevOps-Transformation rein?
Da wäre man falsch verstanden, wenn man jetzt sagt,
ich setze mich jetzt hier in die rote Linie und fahre mal los,
und wenn ich am Ende angekommen bin, bin ich DevOps.
Die Endhaltestelle bei DevOps ist, glaube ich,
sowieso noch nicht gefunden allgemein.
Und ich denke, wenn man das konsequent weiterdenkt,
dann wird es sie auch nicht geben.
Aber hier muss man halt nochmal klar schärfen,
wir schicken uns hier nicht an,
eine Blaupause für eine DevOps-Transformation zu machen.
Das ist viel vielschichtiger,
wenn man in so einen Prozess einsteigt,
sondern hier geht es tatsächlich um eine begriffliche Sortierung,
Einordnung, Gesprächsgrundlage.
Und ich glaube halt auch,
dass die Anlässe je Unternehmen sehr individuell sind.
Und deshalb ist es eben nicht eine Perlenkette,
die aufgereiht ist, die man abfährt, um am DevOps-Ziel anzukommen,
sondern jede Kundensituation, die wir in der Vergangenheit erlebt haben,
war ganz individuell.
Jeder Kunde steigt an einer anderen Stelle ein
und an einer anderen Stelle steigt er wieder aus
und bewegt sich dann aber doch immer in diesem Kernbereich.
Also ich glaube, man kann diese Karte sicherlich sehr gut nutzen,
um in Workshops zu thematisieren,
dass vielleicht einzelne Gruppen die einzelnen Linien erklären müssen
und eine Reihenfolge erklären müssen und so weiter.
Das ist einfach ein guter Ansatzpunkt,
eine gute Möglichkeit, sich mit den Themen,
mit den Begriffen und mit anderen Dingen zu beschäftigen.
Wir reden ja häufig auch über das Erweitern des eigenen Horizonts.
Das heißt, wir müssen ja erstmal die Vertreter
aus dem Business Development und Operations
überhaupt auf eine Gesprächsgrundlage kalibrieren.
Und es ist ja im DevOps-Bereich ja immer dieses
über den Tellerrand hinausschauen,
mit den anderen sprechen, gemeinsam aneinandergehen.
Und das gelingt in dem Zusammenhang hier auch zumindest
als erstmal Einstieg, der noch nicht zu schwergewichtig ist,
wenn man die Vertreter an einem Tisch hat.
Ich wollte noch eine kurze Anekdote ergänzen.
Bei einem Kunden hängt die Metro-Map als Poster an der Wand
direkt neben dem dreijährigen Release-Kalender.
Also das Poster des Release-Kalenders hängt da nicht drei Jahre,
sondern zieht sich halt auch zu einem Zeitraum.
Und es ist mit Bewusst und Intention dort angehängt
und löst wunderbare Gespräche aus.
Wie passt das jetzt zusammen?
Wir haben einen Release-Kalender in einer klassischen Form
und wollen schnell werden, wollen Aspekte aufgreifen,
die dann auf der Metro-Map stehen.
Und wie schaffen wir das?
Ich finde, das sind sehr konstruktive Diskussionen,
die sich daraus ableiten.
Das ist schlussendlich ein super Instrument.
Und wie gesagt,
um in die Diskussion zu gehen.
Und ich denke auch,
wie eingangs gesagt,
DevOps hat so viele Dimensionen.
Und dann auch,
weil oft wird DevOps sehr einseitig,
als eine reine Tool-Geschichte.
Aber andere sehen es als eine reine Kultur-Geschichte.
Und dann kann so ein Bild helfen,
um das Wort zu benutzen,
um eine holistischere Sicht zu bekommen.
Dirk, hast du noch Fragen dazu?
Also ich habe keine Fragen.
Es sei denn, die Frage,
wie wird die Map in fünf Jahren aussehen beispielsweise,
das ist sicherlich interessant.
Also vielleicht trifft man sich ja mal wieder in dem Podcast hier.
Aber für heute, denke ich, hoffe ich zumindest,
haben unsere Zuhörer einfach auch interessiert gemacht an dieser Map,
dass sie sich die anschauen, dass sie die nutzen.
Und vielleicht auch wirklich in mehreren Büros mittlerweile
dann so eine DevOps-Metro-Map
neben einem dreijährigen Release-Kalender hängen.
Und wenn wir jetzt bei dem Metro-Map,
Analogie-Bild bleiben, kann man natürlich sagen,
eine neue Linie lässt sich natürlich hier in dieser Form
viel agiler schaffen, als wenn man sich das in der Realität vorstellt.
Wenn man bedenkt, wie lange der U-Bahn-Bau in Hamburg
in Richtung HafenCity gedauert hat
oder was die Stadt Köln zur Anbindung der Südstadt veranstaltet,
inklusive eines Stadtarchivs,
was dort in Mitleidenschaft gezogen wurde,
kommen wir hier, glaube ich,
relativ schnell in die Richtung.
Schnell voran, sagen aber auch,
die Stationen, die wir hier aufgesetzt haben,
die haben hier erstmal einen gewissen Bestand,
sind aber doch recht flink darin,
gegebenenfalls die Linien noch zu ergänzen.
Gut, dann sage ich Dankeschön von mir
und auf Wiederhören beim nächsten Podcast.
Alex, was haben wir beim nächsten Mal als Thema?
Ja, das ist noch nicht definitiv.
Also wir haben ein paar interessante Themen im Köcher,
aber wir können es im jetzigen Zeitpunkt noch nicht definitiv sagen.
Aber wir würden das dann auf unserer Webseite,
dann, wo bald es bekannt ist,
publizieren, wer als nächstes dran ist.
Aber möchte ich mich auch herzlich von meiner Seite bedanken.
Also ich denke, es war wieder eine weitere Inspiration,
also Thema DevOps.
Und ja, möchte mich herzlich bei den beiden Gästen bedanken,
Sebastian und Volkert,
dass ihr euch die Zeit genommen habt.
Ja, vielen Dank auch an euch, an euer Interesse.
Und ich bin natürlich sehr gespannt,
ob das jetzt auch bei den Hörern hier auf Resonanz stößt.
Und wäre natürlich sehr erfreut,
wenn da das eine oder andere an Feedback
vielleicht dann auch an uns zurückfließt.
Vielleicht wird dann auch Dirks Spannung aufgelöst,
wie das Ding denn jetzt in der Zukunft dann sich weiterentwickelt.
Ja, genau. Ich bedanke mich auch.
Und in diesem Fall an die Zuhörer, denen wurde noch nicht gedankt,
dass sie es jetzt soweit bis zum Abschluss dieser Podcast-Folge
mit uns aufgenommen haben.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Wir freuen uns, wie gesagt, auf Interesse oder Feedback dazu,
um hier entsprechend Gedanken einfließen zu lassen
und die Diskussion vorzuführen.

Folge 3: Von der Anforderung in die Produktion in einer Stunde

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Podcast-Episode erörtern Olaf Garves und Ralf Knobloch von T-Systems MMS ihre Erfahrungen mit der Implementierung von DevOps-Prinzipien in ihrem Unternehmen. Sie betonen die Bedeutung von Schnelligkeit und Qualität in der Softwareentwicklung, diskutieren Herausforderungen und Vorteile der Integration von Entwicklungs- und Betriebsteams und unterstreichen die Rolle von Automatisierung, Continuous Integration und Continuous Delivery. Besondere Aufmerksamkeit wird der Überwindung traditioneller Silos zwischen Entwicklung und Betrieb geschenkt, sowie der Notwendigkeit, Kultur- und Einstellungsänderungen im Unternehmen zu fördern, um die Effizienz zu steigern und auf zukünftige Trends wie Container-Technologie und künstliche Intelligenz vorbereitet zu sein.

Inhalt

  • Einführung und Vorstellung der Gäste
  • Grundlagen und Philosophie von DevOps
  • Implementierung von DevOps bei T-Systems MMS
  • Herausforderungen und Vorteile der Integration von Entwicklung und Betrieb
  • Rolle der Automatisierung und Continuous Integration/Delivery
  • Überwindung von Silos und Kulturwandel im Unternehmen
  • Zukünftige Trends: Container-Technologie und KI in der Softwareentwicklung
  • Diskussion über Sicherheit und Datenschutz in DevOps-Umgebungen
  • Fallbeispiele und praktische Anwendungen von DevOps-Prinzipien
  • Abschlussdiskussion und Ausblick

Shownotes

  1. DevOps-Manifesto – Ein zentrales Dokument, das die Philosophie von DevOps beschreibt. DevOps Manifesto (ähnlich dem Agile Manifesto, da kein spezifisches DevOps-Manifesto bekannt ist).
  2. T-Systems MMS – Ein Full-Service-Projekthaus. T-Systems MMS
  3. Phoenix Project von Jim Kim – Ein Buch, das die DevOps-Prinzipien veranschaulicht.
  4. Docker – Eine Plattform zur Containerisierung von Anwendungen. Docker Offizielle Website
  5. Amazon Web Services (AWS) – Ein wichtiger Cloud-Service-Anbieter, der auch DevOps-Praktiken anwendet.

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zur dritten Folge unseres Podcasts
DevOps – auf die Ohren und ins Hirn.
Mein Name ist Alex Lichtenberger und ich bestreite diesen Podcast zusammen mit Dirk Söllner.
Der wird sich dann auch gleich vorstellen.
Ja, das Thema des heutigen Podcasts
DevOps in der Praxis – von der Anforderung in die Produktion in einer Stunde.
Das tönt ja schon mal sehr vielversprechend.
Ich möchte dazu auch ganz herzlich unsere beiden Gäste
Olaf Garves und Ralf Knobloch von der T-Systems MMS begrüssen.
Sie werden uns heute vorstellen, wie DevOps bei Ihnen bei der T-Systems MMS umgesetzt wurde.
Sie begleiten aber auch Kunden auf diesem Weg.
Also sicher ein sehr spannendes Thema.
Ja, dann würde ich mal sagen, bevor ich an den Dirk übergebe,
Olaf, Ralf, stellt euch doch mal vor, gleich mal zu eurer Person,
wer ihr seid, was ihr macht und dann auch zur Firma, was die machen.
Ja, sehr gerne. Hallo, mein Name ist Olaf Garves.
Ich leite ein sogenanntes,
Service-Feld, wo wir halt seit drei Jahren DevOps machen.
Meine Vergangenheit ist allerdings ein bisschen bewegter.
Ich komme aus einem Umfeld, wo ich auch immer schon interdisziplinär gearbeitet habe.
War früher Projektleiter für Software-Entwicklung,
habe dann eine Software-Entwicklungseinheit geführt
und dann kam mir der Gedanke, dass das Support-Geschäft
eigentlich auch eine ziemlich coole Idee ist, halt langfristig auch Umsatz.
Und Services zu bieten, weil unsere Kunden das auch verlangt haben.
Und daraufhin halt auch eine betrieblich orientierte Einheit mit aufgebaut.
Die ist inzwischen auch gewachsen.
Da steht auch ein Team dahinter, das habe ich nicht alleine gemacht.
Und als das Thema DevOps so vor vier, drei Jahren auch in Deutschland so auftauchte,
habe ich mich auch daran erinnert, dass ich ja früher auch mal Software-Entwicklung gemacht habe
und dass eigentlich die Zusammenarbeit eigentlich immer ein erfolgskritischer Faktor war.
Und so bin ich halt auch in das Thema DevOps auch reingekommen.
Ja, dann möchte ich mich als Zweiter vorstellen.
Ralf Knobloch mein Name.
Ich bin seit circa zweieinhalb Jahren bei der T-Systems MMS
und ich arbeite als verantwortlicher Lead-Architekt für das interne DevOps at MMS Programm.
Das Ziel dieses Programmes ist es, die MMS, die ein Full-Service-Projekt
House ist mit 1.800 Mitarbeitern und einer hundertprozentigen Tochter der großen T-Systems,
dass wir die Dienstleistungserbringung in den Dingen Software-Entwicklung,
Consulting, Test, Betriebsüberführung und den IT-Betrieb selber
möglichst so weit miteinander verbinden und automatisieren,
dass wir unsere Marktfähigkeit und Wettbewerbsfähigkeit am Markt
und in der T-Systems MMS weiter ausbauen.
Ich habe auch ein Leben vor der MMS.
Dort habe ich ein Cloud-Startup mit aufgebaut, wo ich auf die grüne Wiese
eine hochverfügbare Cloud-Lösung Software S-Code aufgebaut habe
und diese DevOps-Prinzipien umgesetzt habe.
Und noch davor war ich bei einem DAX10-Konzern und habe mich seit 2008 beginnend mit dieser DevOps
Thematik, Zusammenwachsen von und Automatisierung von Software-Entwicklung,
Test-Betrieb im Großkonzern verbunden mit vielen, vielen Dienstleistern beschäftigt
und konnte dort auch aus Sicht eines Großkonzerns erste DevOps- und Cloud-Automatisierungserfahrungen sammeln.
Wie gesagt, seit 2009 bis 2010.
Dort zu diesem Zeitpunkt konnte man den Begriff DevOps,
noch gar nicht so recht definieren.
Ich habe mit meinen Mitarbeitern damals, wo ich eine erste DevOps-Plattform,
die nannte sich Lifecycle-Management-Plattform, aufgebaut habe,
auch versucht, in der deutschen Wikipedia den Begriff DevOps zu definieren und zu bringen.
Diejenigen, die dort in 2010 den Begriff DevOps dann freigeben sollten, haben gesagt,
das ist kein richtiges Wort und haben das nicht verstanden, was zu diesem Zeitpunkt
sein sollte.
Das heißt, ich habe also einen recht frühen Umgang mit dieser, mit DevOps gefunden und
geprägt und bin auch dann von der MMS genau zu diesem Zweck, das Internet-DevOps-at-MS-Programm
bei der Umsetzung architekturell, technisch mit zu unterstützen, geholt worden und arbeite
immer noch in dieser Aufgabe.
MARKUS TRANTOW Ja, sehr schön.
Dann glaube ich, dann kannst du ja, Ralf, als …
Ralf, als erstes auch aus deiner Historie mal versuchen, wie man DevOps definieren kann
oder wie würdest du DevOps definieren, wie würdest du DevOps beschreiben?
RALF SCHMIDT Ja, ich würde, also mein Credo ist dabei immer, dass ich das DevOps-Manifesto
zu Rate ziehe oder heranziehe.
DevOps ist aus meiner Sicht eine Philosophie, die sehr viel Leidenschaft beinhaltet.
Es ist eine kulturelle, professionelle Bewegung mit Haltung und Wunsch.
RALF SCHMIDT Ja.
RALF SCHMIDT Ja.
RALF SCHMIDT Verちょ бы certificate
der EU.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SPEN iTunes, ja.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SPEN iTunes, ja.
Duke indications.
GRAetics.
der Software-Defined-Everything-as-Code-Bereitstellung
erfolgt, wo Sales Services entstehen
in der Infrastruktur, aber auch für Corporate
Integration oder Continuous Integration und Continuous Delivery
Pipelines. Und es ist auch
für mich eine Definition,
dass hier Software entsteht, die eigentlich, wenn alles gut
und richtig gemacht wird und DevOps gut umgesetzt wird, keinen oder kaum
Support benötigt wird im laufenden Run oder im laufenden Betrieb,
dass Teams aus Entwicklung und Betrieb auch
testintegriert zusammenwachsen und dass
Service-Verantwortungen entstehen, die die heute vorhandene
Silo-Trennung zwischen Entwicklung, Test und Betrieb zum Teil
aufheben, beziehungsweise wo diese Aufgaben
verschwimmen, weil der eigentliche
Entwickler versteht immer besser die Herausforderungen des Betriebes
und der Betriebler, der ja immer sagt
Never touch a running system, versteht langsam, dass man seine Infrastruktur
auch ständig kodieren und ändern kann.
Und wir haben dort ein Zusammenwirken von
System, das ist der Ausgangspunkt, hin zu unserer eigenen Philosophie,
wie wir im Programm, im DevOps at MMS-Programm arbeiten.
Every time change a running system.
Und das ist also eine totale Brain-Änderung an dieser Stelle.
Und das bedeutet auch, dass im DevOps eine kontinuierliche
Rückkopplung zwischen Entwicklung, Test und Betrieb erfolgt.
Und jetzt mal gemappt auf unser Unternehmen.
Also DevOps ist die eigentliche interne Digitalisierung
unserer eigenen Firma, also unseres IT-Full-Service-Projekthauses.
Ja, ich würde nochmal auf das eingehen,
was du eben gesagt hast, bevor wir dann zu Olaf nochmal rüber wechseln,
wie er DevOps sieht. Ich denke, und da haben wir ja noch ein bisschen Zeit,
das zu besprechen, ich denke, dass manchen Betriebler jetzt die Ohren klingeln
bei dem, was du eben gesagt hast. Und da haben wir bestimmt noch ein bisschen
Gesprächsthema. Olaf, wie würdest du denn DevOps definieren
oder beschreiben?
Ich würde das folgendermaßen beschreiben, dass natürlich
im Fokus der Kunden und die Funktion, die er benötigt für den
Markt, halt möglichst schnell, aber bei hoher Qualität
erstellt und in die Produktion gebracht werden.
In der heutigen Markt, im dynamischen Markt geht es
wirklich sehr schnell.
Und ich denke, das ist ein sehr, sehr wichtiges Thema,
weil es ist eine digitale Transformation, die sämtliche
Arbeits- und Lebensräume durchdringt. Es wird halt alles digital, es gibt
digitale Services. Und wer das halt so kennt von
seinem Smartphone, wenn da irgendwie eine App nicht so richtig funktioniert,
dann ist die in einem Wisch halt mal weg. Und das ist wirklich auch die
Veränderung, die wir auch selber als Dienstleister ja selber
unterliegen. Dazu hat die erst ja auch dieses Programm mit aufgesetzt.
Auf der anderen Seite möchten wir ja unsere Kunden auch damit beliefern,
damit die halt auch in einem Markt erfolgreich sind.
Und DevOps ermöglicht es wirklich in einer engen Zusammenarbeit
mit der Entwicklung, mit einer externen Entwicklung, das ist nicht unbedingt immer eine
interne Entwicklung sein, dass man da wirklich interdisziplinär zusammenarbeitet,
dass man auch die die das Verständnis
hat, gegenseitig. Und dass man auf Augenhöhe sich begegnet mit dem Ziel, auch mit dem Business, mit den Fachbereichen zusammen, mit der Testabteilung, dann ein gemeinsames Ergebnis auch zu liefern. Denn auf das Ergebnis kommt es drauf an und nicht, wer sozusagen jenseits der Mauer nun recht hat oder vielleicht was falsch gemacht hat.
Und was Ralf schon sehr richtig sagte, diese Feedback-Schleifen sind extrem wichtig, dass man sich gegenseitig Feedback gibt, Retrospektiven auch gibt und dass man sozusagen die Kultur des jeweils anderen, die früher vielleicht mal getrennt war, respektiert, aber auch da absolut Vorteile gegenseitig nutzt.
Und wir werden sicherlich später im Gespräch mal auf Beispiele kommen, wie sich das dann auch tatsächlich dann halt auch ausdrückt in der täglichen Praxis.
Ihr habt euch ja schon sehr früh mit dem Thema DevOps angefangen zu beschäftigen und wir werden dann die Beispiele und wie ihr das auch umgesetzt habt oder zum Teil vielleicht Kunden auch geholfen habt, darüber sprechen.
Eine Frage, die ich aber vorher noch spannend finden würde, ist eigentlich dann das Warum. Was waren eigentlich für eine T-Systems, MMS, weil DevOps hat ja keinen Selbstzweck.
Wir machen jetzt Agile oder DevOps und da gibt es ganz bestimmte Treiber.
Oft sind das auch externe Markttreiber.
Was hat euch, die Frage, was hat euch bewogen, das Thema DevOps schlussendlich anzugehen für die T-Systems, MMS?
Na ja, starte ich mal mit einer Antwort.
Da gibt es viele Antworten drauf.
Es wurde festgestellt, dass wenn wir als Projekthaus einen Full-Service,
also das Erbringen zu einem Kunden, also Entwicklung, Test und Betrieb, alles in einer Hand für einen Kunden machen,
dass die Überführung aus der Entwicklung dann auf ganz andere, im Betrieb teilweise auf ganz andere Eingangsvoraussetzungen getroffen ist.
Und das hat dazu bewogen zu sagen, oder das war unter anderem ein Treiber, lasst uns doch mal eine Infrastruktur definieren und finden,
sodass schon bei Beginn.
In der Entwicklung der Zielbetriebs- oder die Zielbetriebsumgebung genutzt wird.
Und diese Zielbetriebsumgebung, die muss natürlich feststehen und die muss Plattformen, Plattformen, damit meine ich zum Beispiel Cloud oder Server-Backend,
überall gleich funktionieren, ja, also gleich funktionieren sein.
Also ist egal, welche Cloud, sage ich jetzt mal, man nutzt.
Das entwickelt vielleicht auf einem Lohn.
Also bei einem lokalen Laptop oder PC, bei einem Entwickler entwickelte Software-Stück sollte überall gleichartig funktionieren,
möglichst bei den Plattformen, die man als Dienstleister oder als Projekthaus bedient.
Das war unter anderem ein Treiber.
Und ich glaube auch natürlich, dass es Kundennachfrage gab.
Ich selbst war ja auch mal auf einer Kunden- oder auf Kundenseite.
Und Olaf, du erinnerst dich sicher, wo ich sehr früh schon mal bei deinem,
du erst hier vorgesprochen habe und die Anforderungen, die man dort gerne umgesetzt bekommen hatte, skizziert hat.
Also auch Kundenanfrage, Kundenausschreibung, glaube ich, sind zunehmend der Treiber,
diese DevOps-Thematik stärker zu liefern und umzusetzen.
Und wir haben dadurch auch, glaube ich, das Ziel, alles oder mehr aus einer Hand liefern zu können.
Weil wenn man mit seiner, mit automatisierten Prozessen,
einem Kunden überzeugt bei der Dienstleister-Erbringung,
so gelingt es durchaus mehr als vielleicht nur Entwicklung oder nur Test oder nur Betrieb
von dem Kunden beauftragt zu bekommen.
Hat da der Wettbewerbsdruck, die Konkurrenz hat auch eine Rolle gespielt?
Also weil oft ist ja dann plötzlich ab einem Mitbewerber oder sagen wir mal Marktbegleiter,
der eben schon, der macht DevOps, der kann sehr schnell und konsistent,
solche Service auf dem Markt bringen. War das auch ein Treiber?
Wenn ich jetzt aus meiner Perspektive antworten darf, weil ich antworte ja sozusagen mehr aus der Produktion sozusagen,
der, wir haben mehrere externe Kunden, da ist es natürlich auch ein Treiber von den Fachseiten,
mit denen wir zusammenarbeiten, die natürlich auf dem Markt, wie gesagt, Marktanteile verteidigen.
Müssen oder halt wirklich auch sehr schnell sein müssen, weil halt neue Trends entstehen,
die halt schnell bedient werden müssen oder eine Marketingkampagne, die schnell umgesetzt werden muss.
Und viele Softwareentwicklungsagenturen, die für unsere Kunden arbeiten oder halt auch vom Kunden selber kommen,
die arbeiten ja schon bereits agil und die müssen halt einfach auch sehr schnell sein.
Das nützt nichts, dann mit einer dritten guten App im Markt zu kommen, wenn es schon eine sehr,
sehr gute gibt und die sehr schnell eine Verbreiterung hat.
Und diesen Trend sozusagen, da unterstützen wir natürlich unseren Kunden, damit er sozusagen einfach diese Agilität hat.
Der kommt auch sehr viel mit unterschiedlichen Entwicklungseinheiten.
Natürlich wäre das Ziel für uns als MMS prima, wenn der Kunde jetzt alles aus einer Hand nehmen würde.
Das ist auch der Fall bei vielen Kunden.
Es gibt aber auch Kunden, die bewusst sagen, nee, ich möchte eine gewisse Unabhängigkeit haben.
Ich möchte sogar unterschiedliche Entwicklungsdienstleister haben.
Und die funktionieren halt von der Kultur manchmal auch total unterschiedlich und haben sozusagen auch ihre eigenen Entwicklungsprozesse unterschiedlich umgesetzt.
Und für einen Großkunde ist es natürlich wichtig, dass sie doch einheitlich irgendwo aufgegleist werden,
damit sozusagen hier nicht diese Energien verloren gehen, sondern, wie Ralf das schon sagte,
dann hinterher auf einer konformen Infrastruktur dann auch landen und auch möglichst dort,
stabil betrieben werden kann.
Also es ist auf jeden Fall ein externer Marktdruck.
Wenn man jetzt die Konkurrenz sieht in Deutschland, denke ich mal, ist das Thema auf jeden Fall zunehmend verbreiteter und bekannter.
Und da ist durchaus auch für die MMS selber der Anspruch da, aber auch weiter Vorreiter zu sein.
Ralf, ich würde nochmal auf das eingehen, was du eben gesagt hast.
Du hast bei der Definition von oder Beschreibung von DevOps gesagt, es geht darum auch,
ein gegenseitiges Verständnis zwischen Dev und Ops herzustellen.
Und deine Antwort eben auf die Frage von Alex war ja auch, dass ihr für diesen Fall damals eine gemeinsame Infrastruktur definiert habt.
Wie haben denn die Entwickler darauf reagiert, dass sie sich ja quasi jetzt in ihrer Freiheit,
in ihrer künstlerischen Freiheit vom Betrieb etwas vorschreiben lassen mussten?
Das.
Das ist ein Gefühl oder dass es dort eine Vorschreibung gab, die Entwickler, das ist die Rückmeldung, die wir bekommen, sind jetzt eigentlich zufrieden,
dass sie sich in ihrem Projekt nicht, ich sag mal, Tage, Wochen, manchmal vielleicht sogar Monate lang um den Aufbau und die Konfiguration der Infrastrukturelemente kümmern müssen,
sondern dass sie dadurch, dass es eine standardisierte Infrastrukturbereitstellung gibt, die man auch per Code-Definition, also Infrastruktur,
DrS-Code verändern kann, dass sie sich sofort und viel schneller anders entwickeln, eines Services oder einer Anwendung machen können.
Sie müssen sich also nicht selbst Tage, Wochen lang mit dem Infrastrukturdesign und dem Aufbau des Ganzen beschäftigen.
Und sie fühlen das schon als eine echte Entlastung.
Okay.
Dadurch, dass diese Infrastruktur, wenn sie automatisiert ist, bereitsteht.
Und man das alles im Source-Code hat.
Also wir tun Infrastruktur auch per Source-Code beschreiben, wie ein Anwendungsprogramm.
Dadurch kann man diese Infrastruktur auch schnell nachnutzen, weil automatisiert aufgebaut.
Und wenn man sie verändern muss, nehmen wir mal an, ich brauche jetzt für einen Cloud-Service eine gewisse Skalierbarkeit,
weil dieser Cloud-Service zum Beispiel an bestimmten Zeiten des Jahres,
viel mehr genutzt wird, als in den Ferienzeiten,
dann kann ich diese Cloud mit einer variablen Serveranzahl in der Software-Definition versehen
und bin dann ganz schnell auch in der Veränderung einer kundenspezifischen oder anwenderspezifischen Infrastruktureinstellung unterwegs.
Und muss nicht, ich sage jetzt mal, Monate oder Wochen lang auf die Beschaffung eines Hardware-Servers warten,
beziehungsweise auf die Konfiguration des selbigen.
Dadurch, dass wir eben auch auf Cloud- und Virtualisierungstechnologien, Containertechnologien zunehmend aufsetzen.
MARKUS TRANTOWSKI Ja, das, was du eben als Vorteil beschrieben hast, was die Entwickler jetzt sehen,
das haben sie ja vielleicht noch nicht zu Anfang gesehen.
Also wie habt ihr diesen, den von mir vorgestellten Widerstand gebrochen?
Oder wie habt ihr die Leute überzeugt, die Entwickler, diesen Weg mitzugehen?
Oder war da gar kein Widerstand?
War da gar keine Abneigung?
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
Also, Widerstand war eigentlich aus meiner Sicht kaum welcher zu spüren. Es war wirklich teilweise ein Unverständnis, dass es einfach im Betrieb notwendigerweise eine aus Sicherheitsgründen Anforderung gibt, so wenig wie möglich Services oder Funktionalitäten in einem Serverbetriebssystem zu haben oder nur so wenig wie notwendig.
Der Entwickler hat gerne alles, was er irgendwo mal finden konnte, drauf konfiguriert und wollte das auch haben. Um, nehmen wir an, ein Debugging von einer Anwendung im laufenden Betrieb durchführen zu können und so weiter.
Und er hat auch dann nicht darauf geachtet, unter Umständen, dass man da mal ein bisschen ein paar Funktionalitäten runterschrauben muss, Ports zumachen muss, eigentlich nur aus Sicherheitsgründen.
Zum einen.
Zum anderen, die Entwickler haben eigentlich aber jetzt auch erkannt, das braucht natürlich ein bisschen Zeit, dadurch, dass sie die Infrastruktur auch als Code vorliegen haben.
Also sie speichern jetzt ihre infrastrukturelle Bereitstellungs auch mit dem Business Source Code zusammen ab, innerhalb eines Service oder eines Projektes oder für einen Kunden.
Und das kommt ihnen und ihrer Fähigkeit, alles zu jeder Zeit ändern, anpassen können oder zu wollen.
Entgegen.
Und natürlich der Betriebler oder die Betriebsleute, die haben dort ihre Gedanken oder ihre Forderungen nach Stabilität, nach Robustheit jetzt auch viel stärker eingebracht.
Und das ist ein Weg, den beide Seiten gehen können oder auch bei uns Stück für Stück gehen und wo dann auch Vertrauen entsteht.
Wir haben.
Aber auch um diese, dieses, dieses bessere Verständnis und das Wissen von einem anderen, also von Entwicklung oder DevOps zu übertragen, haben wir auch eigene Mittel innerhalb der MMS genutzt.
Zum Beispiel das Mittel einer Jobstation, wo in dieses DevOps Programm Entwickler, Tester oder auch Leute aus dem Betrieb in dieses DevOps Programm für eine gewisse Zeit rotiert sind.
Und dort mit ihren Spezialkenntnissen den anderen ihre Kenntnisse beigebracht oder auch überliefert haben und sich natürlich auch andere Kenntnisse angeeignet haben.
Wir haben auch Schulungen durchgeführt und vor allen Dingen, was aber das eine ist ja nicht nur technisches Wissen oder technische Fertigkeiten, sondern das gegenseitige Verständnis.
Und das ist das, wo ich auch sage, es ist eine Haltung, es ist eigentlich eine Philosophie, DevOps umsetzen zu wollen.
Und wir haben auch ständige Befragungen dieser Jobrotierer durchgeführt und die sind dann nach circa sechs Monaten, manche auch nach zwölf Monaten in ihr ursprüngliches Arbeitsgebiet zurück rotiert und haben natürlich dann das, was sie erlebt haben, ihre Ideen, auch ihre Haltung, die sie mittlerweile angenommen und verkörpert haben.
Es waren grundsätzlich sehr positive Rückmeldungen, die wir bekommen haben.
Die tragen das jetzt in die anderen Organisationsgruppen.
Mit zurück, dieses Wissen, was man mit DevOps alles machen kann, was geht und zu welchen, ich sage jetzt mal Beschleunigungen und auch schnelleren Lieferfähigkeiten das Ganze führen kann.
Ich würde es gerne mal ergänzen, was Ralf da gesagt hat, weil wir haben sozusagen auch dieses gegenseitige Verständnis auch ganz bewusst auch gefördert,
dass wir zum Beispiel in unserer Betriebsseite.
Das Team, was vorher für die Verantwortung für geschäftskritische Anwendungen, Application Management gemacht hat, Transitions durchgeführt hat, nach Heidel gearbeitet hat und in diesem Aspekt CICD Pipeline, also die Schnelligkeit der Software Delivery sicherzustellen, ist ein Software Architekt in das Team mit aufgenommen worden und man hat voneinander gelernt.
Und das ist auch das Wichtige daran, dass man da zusammenarbeitet.
Dass man ein gemeinsames Ziel hat, nämlich zum Beispiel diese CICD Pipeline aufzubauen für die Kunden Software und dieser Architekt beispielsweise, der ist dann natürlich mit dem Betriebswissen, was er zwangsweise mit aufnehmen konnte, dann halt in das nächste Projekt gegangen, also nächstes Kundenprojekt und halt auch umgekehrt die Betriebsmannschaft, die bei mir sitzt, hat halt auch eine neue Technologie.
Und dann hat man auch Aspekte der Softwareentwicklung mitbekommen.
Und so wachsen halt beide Bereiche wirklich tatsächlich mehr und mehr im Verständnis zusammen und erbringen halt sozusagen da dann auch einen ziemlich guten Job, weil das Ergebnis ist nach wie vor, es geht darum, hochqualitative Software in möglichst schneller Zeit in den Markt zu bringen.
Oder halt für interne Anwendungen, also ich rede jetzt, ich habe immer so die Brille auf, so nach draußen.
Das geht natürlich genauso darum, halt auch für interne Bereitstellung von IT-Services halt auch schnell zu sein und den Mitarbeitern halt auch entsprechende Software bereitzustellen.
Also gegenseitiges Verständnis, also der Jim Kim, der Autor des Phoenix Project, hat ja auch mal schön gesagt, eigentlich brauchen wir Entwickler, die eben denken können, wie auch wie Betriebsleute und Betriebsleute, die denken können wie ein Entwickler.
Also dieses gegenseitige Verständnis.
Und auch diese ursprüngliche Konfliktstabilität versus Flexibilität, um das aufbrechen zu können.
Also ich habe schon jetzt das Konzept, das ihr erklärt habt, auch mit der Team-Rotation, das da sehr hilft, um dieses gegenseitige Verständnis zu bekommen.
Das geht sogar auch an dieser Stelle in diesem DevOps-Programm, was wir intern in der MMS machen, soweit, dass wir erste leichte Organisationsänderungen probieren.
Wo eine Entwicklungsorganisationseinheit und eine Betriebsorganisationseinheit zusammen wirklich geschlossen werden und dann für Kunden gemeinsam arbeiten.
Also dort integrativ DevOps vertikal in einer vertikalen Entwicklungstest und hoffentlich dann auch Betriebsverantwortung zu erbringen.
Also das ist ein erster Organisationsprobe.
Und das ist ein erster Ballon, könnte man sagen.
Eventuell ist das ein Weg, wie sich Kunden, Erbringungsorganisationen wandeln könnten.
Und das kann man nicht pauschal, so jetzt wandeln wir mal das ganze Unternehmen, sondern das muss man mit kleinen Schritten, Organisationsschritten ausprobieren.
Was ist der richtige Weg?
Und wir sind ein 1800 Mann starkes Unternehmen.
Und da kann man nicht mal sagen, wir ändern jetzt mal die ganze Organisation.
Und wenn das nichts ist, dann probieren wir es nochmal.
Sondern es wird ganz bewusst auch getragen, committed von der Geschäftsführung, diese Organisationsprobierballon ausprobiert.
Also Ralf, ich finde, das ist für mich ein ganz wichtiger Punkt, weil ich, wenn ich jetzt unterwegs bin bei größeren Unternehmen, dann sind die häufig von jährlichen Reorganisationen geschädigt, die Mitarbeiter.
Jedes Jahr wird was Neues gemacht oder alle zwei Jahre.
Und das, was du eben gesagt hast, ist aus meiner Sicht immer ein ganz zentraler Punkt.
Ich habe nicht ein neues Framework, wo ich mich hinentwickeln muss, was ich sozusagen quasi umsetzen muss, wie ITIL oder Scrum, sondern ich muss schrittweise dahin kommen, diese Philosophie umzusetzen, dieses gegenseitige Verständnis hinzubekommen.
Und das eben schrittweise, mit kleinen Schritten und nicht mit einem Riesenprogramm, weil das geht in die Hose und dann gibt es das nächste Programm.
Und damit ist der Begriff DevOps.
Und das ist dann auch wieder verbrannt.
Kann ich bestätigen.
Ich hatte auch in einem Großkonzern, also auf der Kundenseite gearbeitet und im mittleren Management.
Und dort ist eine solche Umsetzung von oben dann, naja, ich sag mal durchgesetzt worden.
War auch erfolgreich, was Kosten und Schnelligkeit betrifft.
Aber das Mitnehmen der Leute ist dort nicht so gut erfolgt.
Also dort war der Erfolg da nicht so.
Mitnehmen der Leute bedeutet, dass sie sich also in einer veränderten Zuständigkeitssituation mit anderen Anforderungs- und Aufgabenbereichen schneller zurechtfinden.
Wir sind ja, oder die meisten Menschen sind ja so, dass sie Veränderungen nicht ganz so von sich aus wollen oder treiben.
Und das wurde dort mehr von oben dann verordnet und durchgesetzt.
Und so etwas, so eine Kulturänderung, die sollte nicht nur von oben vorgehen.
Und durchgesetzt werden, sondern das ist eine Kombination aus geführter Governance und dann auch wirklich Graswurzelbewegung,
die in einer gemeinsamen oder in einer mit wollenden Menschen umgesetzt werden sollte,
die willens sind, sich verändern zu wollen und die auch sehen,
dass eine solche Ausrichtung auf DevOps für alle Seiten auch etwas bringt.
Man wird schneller, wettbewerbsfähiger und lernt unheimlich ständig.
Immer.
Dazu.
So eigentlich ein Mix dann, wenn man über die Vorgehensweise, sprich für eine Transformation, so Top-Down, Bottom-Up.
Es ist klar, einerseits Management-Commitment ist wichtig, aber dann, ich glaube, das haben wir auch schon beim letzten Interview gehört.
Wir sehen auch hier in der Schweiz, wenn ich schaue, wie die Firmen DevOps umsetzen, es sind eben so kleine, kleine Schritte, jeweils Feedback holen.
Und auch die Leute dann, ich sage immer, die,
die Leute, die sind eigentlich offen gegenüber Veränderung, aber wenn es darum geht, dann sich selber zu verändern,
da kommt der Widerstand und der Trick ist dann irgendwie auch, dass man wie, wenn die Leute das Gefühl haben,
ah, das war ja meine Idee oder die auch dann, dann eben die Transformation selber agil zu machen,
dass die selber das vorantreiben, dass es dann auch getragen wird von den Leuten.
Also ich kann das nochmal bestätigen, das ist, wir sind Menschen, wir kommunizieren,
es gibt Missverständnisse, es ist halt auch Kultur, Bereichsdenken manchmal, Silo-Denken.
Und das ist sehr, eigentlich die Veränderung auf einer technischen Ebene herbeizuführen, ist eigentlich relativ einfach, in Anführungsstrichen,
weil da kann man, da kann jeder eigentlich gleich darüber sprechen, auch das Management, die verstehen das, die Mitarbeiter verstehen das,
aber so eine Kultur, das ist so ein wabbeliger Begriff, na, was ist denn das eigentlich?
Und ich finde es halt da extrem wichtig und das machen wir.
Das machen wir in der MS auch und das machen wir ja auch mit den Kunden, dass wir sagen, dass man frühzeitig alle Beteiligten an Bord holt,
dass man auch durch Community-Gründungen auch verschiedene Kanäle bereitstellt, wo wir darüber diskutiert werden können.
Das setzt natürlich eine offene und Kommunikationsbereitschaft Unternehmenskultur auch voraus
und die hat es dann halt letzten Endes dann auch leichter, solche Modelle sozusagen auch sukzessive schneller umzusetzen.
Als eine Unternehmenskultur, die vielleicht sehr stark hierarchisch geprägt ist.
Ich würde nochmal auf einen Punkt eingehen, auch vorhin noch ein bisschen aus der Einleitung, das, was ihr eben ja im Prinzip auch angedeutet habt.
Raif hatte gesagt, zur Definition, was ist DevOps? Das ist Leidenschaft, das ist Kultur.
Und dann noch weiter ausgeführt, es geht darum, Serviceverantwortung hinzubekommen und eben weg von,
von den Silos. Du hast es ja eben auch gesagt, Olaf, es geht um Kulturwandel.
Was mache ich denn oder welche Erfahrungen habt ihr denn mit Personen gehabt, mit Menschen gehabt?
Denn wir haben es ja mit Menschen zu tun, die eben nicht mit Leidenschaft zur Arbeit gehen,
die eben genau sich nicht verändern wollen, auch wenn sie vielleicht sogar einen Vorteil davon hätten.
Also habt ihr da so ein paar besondere Tricks entwickelt oder habt ihr etwas, wo ihr gemerkt habt, das hat bei euch funktioniert?
Also ich kann…
Ich habe ja nur eine Support-Abteilung verantwortet, die nach wie vor.
Und das sind durchaus auch als so zum ersten Mal die Themen wie DevOps angesprochen worden sind,
kamen da auch Bedenken, naja, da habe ich ja dann nichts mehr zu tun, wenn alles automatisiert ist
oder wenn halt einfach hier die normalen Betriebsaufgaben weniger werden durch die CICD-Pipeline.
Und ich glaube, da hat man als Führungskraft eine ziemliche Verantwortung.
Die sollte man auch wahrnehmen, man soll sich darüber auch klar werden.
Diese Veränderung kann nicht alleine von unten oder nur von oben passieren,
sondern die muss parallel geführt werden, so eine Diskussion.
Und ich habe tatsächlich mit meinen Mitarbeitern auch die Begeisterung wecken können.
Sagt, da gibt es neue Perspektiven, neue Chancen.
Denkt mal voraus, was das bedeutet.
Ihr könnt mehr Verantwortung übernehmen und man ist dann halt nicht mehr,
wie früher vielleicht so das Bild,
naja, man kriegt die Software über den Zaun geschmissen,
sondern nee, ihr seid auch bei diesem Prozess mit dabei, wie das passiert,
wie man halt zusammenarbeitet und dann halt auch am Ergebnis letzten Endes mit beteiligt.
Und dass das halt auch eine ganz andere Wertschöpfung ergibt,
eine viel höherwertige Wertschöpfung, als wenn man sozusagen einem nur sagt,
naja, mach das mal bitte jetzt hier, das ist eilig und das muss nachts installiert werden,
damit es morgen läuft und im Übrigen in der nächsten Nacht darfst du dann das nächste Release in Empfang nehmen.
Und das sind…
Ja, völlig von ab.
Und diese Begeisterung, die Ralf auch so schön erklärt hat,
das kommt dann insbesondere, wenn der Kunde dann wirklich auch sieht,
Mensch, ich habe die Software für meinen Fachbereich schneller deployen können.
Die Endkunden sind begeistert.
Und das wird dann halt als Feedback dann auch dem Team,
dem gemeinsamen Team auch wieder gespiegelt.
Und dann sind die auch richtig motiviert.
Okay, das heißt als Lerneffekt oder auch als Argument würdest du ansprechen,
abgesehen davon, dass es natürlich dann den Arbeitsplatz erstmal sichert,
weil wenn ihr es nicht gemacht hättet, hätten es andere gemacht,
dass es den Arbeitsplatz auch wertvoller macht, wertvoller auch für die eigene Tätigkeit.
Und das wären so quasi die beiden Argumente, die ich aus deinen Ausführungen, Olaf, mal rausziehen würde.
Also es geht wirklich darum, dass die Fähigkeiten des Mitarbeiters,
die müssen an dieser Stelle weiterentwickelt werden, weil aus betrieblicher Sicht und aus der Brille gucke ich,
ja hier auch hauptsächlich, müssen mehr Richtung Deployment,
mehr Richtung Entwicklungsverständnis gehen, weil ja auch die, wie Ralf das ja schon sagte,
die Infrastruktur, Cloud-Technologien, da wird es nicht mehr so sein,
dass man da den Server und sechs Wochen ist er da und dann muss er installiert werden,
sondern das ist tatsächlich auch auf Knopfdruck da.
Und der Systemingenieur von heute wird sich in einen DevOps-Ingenieur umwandeln,
der halt das Ganze orchestriert.
In dem Kontext hätte ich noch eine Frage, weil auch Dirk hat vorhin gefragt,
es gibt ja manchmal Leute, die wollen nicht, wie geht man die an?
Jetzt sprechen wir auch darüber, ja die Leute müssen sich weiterentwickeln,
aber manchmal können sie vielleicht nicht.
Also ein schönes Beispiel ist ja im Testing, also das manuelle Testing, das abnimmt
und jetzt mehr Richtung Testautomatisierung, Scripting, das braucht eine ganz neue Art von Skills,
aber vielleicht sind die Leute…
die dann gar nicht in der Lage, sich in die Richtung zu verändern, oder?
Habt ihr solche Fälle auch gehabt, wo ihr sagt, ja, das wird jetzt einfach schwierig, oder?
Also, der Ralf, ich hatte so etwas in dem Großkonzern natürlich auch in der ganz Frühzeit erlebt.
Man muss dann schon auch als Unternehmen ist man in der Verantwortung,
oder die Unternehmen sind eigentlich in der Verantwortung dort,
die Weiterbildung und der Mitarbeiter zu sorgen.
Natürlich gibt es auch eine gewisse Weiterbildungsresistenz unter Umständen,
die man feststellen, oder die ich auch erlebt habe.
Aber da helfen meiner Ansicht nach dann Überzeugungsgespräche und so weiter.
Der größte Hebel oder den besten Hebel, den ich immer gefunden habe, um dann bei Mitarbeitern,
Um dann bei Mitarbeitern, um dann bei Mitarbeitern,
Um dann bei Mitarbeitern, um dann bei Mitarbeitern,
wo das ein bisschen schwieriger war, die zu erzeugen,
war, dass sie durch die Übernahme neuer Skills ihren Marktwert eigentlich steigern konnten.
Und dass sie dadurch einen ganz anderen Selbstwert, ein Selbstwertgefühl kriegen und einen höheren Marktwert.
Denn wir wissen alle, dass Arbeitssituationen, dass man in einem Unternehmen anfängt und dort 40 Jahre bleibt,
dass das immer unwahrscheinlicher wird.
Und dass auch Arbeitgeberwechsel durchaus öfter stattfinden können, nicht müssen, aber können.
Und gerade wenn man mit dieser DevOps-Fähigkeit oder mit Fähigkeiten Entwickler-Test und Operations-Skills ausgestattet ist
und bei beiden immer oder bei allen drei Richtungen zunehmend die Softwareentwicklungsnotwendigkeit,
ob das Scripting oder Testautomatisierung oder Softwareentwicklung selber ist,
zunimmt, beziehungsweise dann das Wissen um solche neuen Technologien, die ja auch damit verbunden sind,
sei es jetzt Cloud, sei es Test, Driven Development oder was es da alles noch Neues gibt, Big Data-Technologien.
Also der Marktwert des Einzelnen erhöht sich.
Und das war aus meiner Erfahrung immer der größte Hebel, dass man dort ein bisschen Eigenmotivation schaffen konnte.
Okay.
Frage von mir noch mal zum Thema Sicherheit.
Das ganze Thema Sicherheit, Datenschutz und so weiter, das wird ja manchmal so dargestellt, dass das ein Showstopper ist für DevOps.
Oder dass es zumindestens die Schnelligkeit, von der ihr vorhin gesprochen habt, beeinflusst.
Seht ihr das auch so? Und wenn das bei euch auch ein Problem ist, wie geht ihr damit um?
Also da würde ich eine erste Antwort geben.
Dadurch, dass wir bei der…
Bei der Definition von den einzelnen Komponenten und Schritten in der Umsetzung dieses DevOps-Programmes,
von Beginn an die IT-Sicherheit als Design mit oder als Design-Abhängigkeit in den zehn…
Wir haben so eine Art zehn DevOps-Gebote uns gegeben.
Und Security by Design für alles das, was man dort an Automatisierung, an Standardisierung macht,
wenn man das von Beginn an berücksichtigt und auch die Sicherheitstests möglich macht,
wenn man das Testmöglichkeiten und Sicherheitsmonitoringmöglichkeiten automatisiert von Beginn an einbaut,
dann kann Sicherheit oder automatisierte Sicherheit auch zu einer Entwicklungsbeschleunigung führen.
Also ich kann das vielleicht auch nochmal von der anderen Seite beleuchten.
Ich sehe das nämlich ähnlich wie Ralf.
Es führt eigentlich zu mehr Sicherheit, weil nämlich durch die Automatisierung viele manuelle Schritte einfach entfallen.
Und da entstehen dann halt Fehler bei den manuellen Schritten.
Und dadurch, dass man sehr viel wiederholbar macht und halt automatisiert, wird eigentlich die Sicherheit da erhöht.
Dann ist es auch so, dass man in der CI-CD-Pipeline, also sozusagen technische Ausprägung von DevOps,
ja eine Reihe von Tests drin hat, die halt beginnen schon sehr früh im Code,
schon Code-Quality-Analysen zu machen bis hin zu Last- und Performance-Tests,
wo die Tests ja dann halt auch dazu führen sollen, bewusst dazu führen wollen,
die Software unter Druck zu setzen, damit halt Schwachstellen offengelegt werden können.
Und ein dritter Aspekt, den man vielleicht auch dazu sehen könnte,
die ganze CI-CD-Pipeline mit den ganzen unterschiedlichen Testverfahren, die da drin sind,
mit den Deployments, automatisierten Deployments von Stage-to-Stage,
das ist ja selber auch ein Qualitätssicherungssystem in der Gänze.
Es kann natürlich trotzdem vorkommen, das ist ja so, man macht die CI-CD-Pipeline ja auch so,
dass es halt schneller ist und nicht nur schneller, sondern natürlich auch mehr Deployments hat,
dass natürlich in der ersten Phase, so wie es bei jeder Software ist,
also auch die CI-CD-Pipeline ist natürlich auch Software,
dass dann natürlich Probleme schon entstehen können.
Und da ist halt aber auch wieder diese enge Zusammenarbeit, dieses enge Verständnis notwendig,
weil man dann ja auch sagt, es gibt eine gegenseitige Schuldzuweisung,
na, du hast ja hier irgendwie nicht aufgepasst, sondern es ist alles transparent,
man setzt sich schnell zusammen im interdisziplinären Modus und tut das halt dann auch lösen.
Okay.
Vielleicht noch auch ein Hinweis, also dadurch, dass man Dinge automatisiert und wenn ein Fehler auftritt
und diese automatisierten Tests, die man dann ja auch im Betrieb als Monitoring-Element einsetzen kann,
wodurch dann aus dem Betrieb immer wieder für einen neuen Software-Entwicklungszyklus
eine Rückwirkung da ist, dass man das Monitoring-Skript gleich auch wieder zum Testen in der Software-Entwicklung nehmen kann,
entsteht auch eine Über-die-Zeit-Situation.
Das heißt, man hat eine viel höhere Robustheit der Infrastruktur und des Applikations selber,
weil alle Tests, die ich einmal automatisiert habe, werden bei jedem Build oder Commit,
wie wir das nennen, wenn also eine Software eingecheckt wird, wird immer wieder durchlaufen.
Das heißt, die Testdurchlaufzahl, die Testabdeckung wird durch die Automatisierung auch wesentlich erhöht
und über die Zeit werden die Systeme immer robuster und damit auch immer sicherer, hoffentlich.
Also mit anderen Worten, weil im Titel des Podcasts steht ja auch von der Anforderung in den Betrieb in einer Stunde,
das könnte ja zur Schlussfolgerung verleiten, okay, dann geht die Qualität runter,
aber das ist ja nicht, also da, wie du jetzt gerade beschrieben hast,
die Robustheit und die ganze Testautomatisierung, dass sie dem entgegenwirkt.
Ein Beispiel, mal ganz konkret, das habe ich heute auch in einem internen Cloud-Tutorial gehalten.
Wir erstellen aus Software-Beschreibungen unsere Betriebssysteme.
Das nennt man ein Betriebssystem-Image.
Und dieses, bei dem Erstellungsprozess, der automatisch abläuft,
werden mehr als 400, 500 verschiedene automatisierte Infrastruktur-Tests für das Bauen aus einem Software-Repository,
wie Git oder Subversion, für das Bauen eines Betriebssystem-Images.
Genutzt und laufen ab.
Und dieses Bauen des Betriebssystems allein, die allein nur aus Software-Definition heraus erfolgt,
wird jede Nacht immer wieder für die unterschiedlichen Plattformen gemacht
und es tritt unter Umständen doch mal ein Fehler auf, da muss man danach suchen.
Und mit jeder weiteren Fehlerbehebung wird das Stück für Stück schon das Betriebssystem eines Servers,
auf dem Applikationen laufen, immer robuster.
Und ich sag mal,
damit auch hoffentlich immer performanter und vollständiger.
Wir wissen alle, Software ist nie fehlerfrei.
Wenn man sich die Lines of Code von der Software, die für eine Applikation gebraucht werden, mal aufaddiert,
das Betriebssystem, die Datenbank und so weiter, aus denen die alle bestehen,
da ist man sehr schnell für eine kleine einfache Anwendung,
da ist man sehr schnell dabei, dass man da mehrere Millionen Lines of Code hat
und die übereinandergelegt einen Riesenturm zu Babel an Lines of Code ergeben.
Und natürlich, wir wissen, dass die nicht fehlerfrei sind,
aber durch die ständige Automatisierung, durch das Härten und das Rausnehmen von Funktionen, die man nicht braucht,
das Abschalten von Funktionen, wird es sicherer, robuster, hoffentlich auch performanter über die Zeit.
Ich komme mal auf den Titel zurück.
Alex hatte da eben auch schon mal darauf hingewiesen.
Olaf, ich habe dich ja bei einem Vortrag mal gehört, wo du vor einer Zeit,
ich sage mal, versammelten IT-Service-Management-Mannschaft, vor ITIL-Freunden gesagt hast,
dass ihr wirklich von der Anforderung bis zur Produktivsetzung eine Stunde braucht.
Die haben ihren Mund nicht wieder zugekriegt und konnten sich nicht vorstellen,
wie man zum Beispiel in einer Stunde ein Change Advisory Board einberufen kann.
Also ist das so? Schafft ihr das? Schafft ihr das in einer Stunde Produktivsetzung?
Also Ralf hat es eben schon gesagt.
Also bei uns beginnt die Uhr zu ticken bei dem Commit.
In dem Moment, wo der Entwickler halt den frischen Code eincheckt, wird das erkannt aus dem System
und dann geht die Pipeline halt auch los und darauf bezog sich auch diese eine Stunde.
Und natürlich, wenn man jetzt sagt, die hohe Kunst ist es wirklich in einer Stunde zu machen oder auch schneller,
dann geht das. Wenn man aber jetzt sagt, man hat eine komplexere Anwendung, wo halt auch längere Lasttests stattfinden,
da muss man halt dann mehr Gehirnschmalz reintun, wie man die Tests parallelisieren kann,
beispielsweise um so eine Stunde dann auch zu erreichen.
Es gibt sicherlich auch Anwendungen, wo das auch schneller geht, wo einfach auch aufgrund der Vigna-Komplexität
dann halt auch einfach gewisse Stages auch wegfallen können.
Ich glaube, die besondere Herausforderung, die noch auf uns zukommen wird, ist das Thema Docker.
Ich tue das einfach mal voraussetzen, dass so ein gewisses Verständnis über Container-Technologie da ist.
Ich glaube, dass sich da auch nochmal ein Shift in der IT-Verständnis, in der Betriebsverantwortung tun wird,
die von so einer Layer-Verantwortung, da ist die Applikation und darunter ist der Betrieb
und der macht halt sozusagen die Systeme darunter, Datenbank, Infrastruktur,
dass sich das auch aus diesem Grunde auch nochmal ändert.
Das heißt, man wird in eine Betrachtung von Inside-Container und Outside-Container.
Und das Thema DevOps wird durch das Thema Docker noch sehr viel mehr beschleunigt.
Und ich glaube, da wird es noch eine ganze Menge an Gesprächsbedarf geben,
weil dann tatsächlich die Möglichkeit ist, Anwendungen überall zu deployen,
egal in welcher Cloud und in einer noch höheren Geschwindigkeit, wird natürlich dazu führen,
dass eine Unübersichtlichkeit auch entsteht.
Und ich glaube, deswegen ist das auch so richtig, diese Kulturaspekte noch zu betrachten,
dass man sagt, okay, man braucht über alles eigentlich immer eine gewisse Transparenz.
Wer macht denn da was? Wie ist die Qualität?
Ist dann Testdokument wirklich auch gemacht worden im Sinne einer Revisionssicherheit?
Also das wird alles, diese Governance darüber, die wird immer eine größere Rolle spielen.
Man wird auch immer mehr auf die Prozesse gucken.
Und das wird für mich sozusagen die zukünftige Herausforderung sein.
Also es wird nicht einfacher, glaube ich, sondern es wird eher noch komplizierter,
wo man dann halt auch wieder entsprechende Mitarbeiter braucht,
die auch mit dieser Komplexität umgehen können, das managen.
Die werden dann nicht mehr den Apache-Server neu starten,
sondern die werden sich mit solchen Themen auseinandersetzen.
Stimmt denn der gesamte Prozess? Wo hakt da was?
Ein weiteres Thema, was dazukommen wird,
auch was das Thema Robustheit auch angeht,
ist, glaube ich, die KI, also künstliche Intelligenz,
zu der Robustheit von Softwareentwicklung mit einzubeziehen.
Und ich glaube, das wird, wenn man so ein bisschen in die Zukunft guckt
und vielleicht trifft man sich ja in drei Jahren wieder im Podcast
und sagt, nee, das war alles Quatsch, was hier der Olaf erzählt hat,
KI ist noch lange nicht so weit.
Aber ich glaube, da fängt jetzt irgendwie so eine neue Generation an,
die wieder neue Herausforderungen angeht.
Und das ist dann, um diese Komplexität in den Griff zu kriegen,
wäre halt auch aus meiner Vision sozusagen KI auch ein Schlüssel dazu.
Weil allein in unserem Bereich betreiben wir knapp 50 ICT-Pipelines parallel.
Und das kann man auch nicht mehr alles manuell prüfen und checken.
Und wenn es dann halt um 100 Commits pro Tag geht,
dann potenziert sich das ja alles.
Man hat ja eine unglaubliche Masse von Durchläufen dann.
Und dazu brauchen wir halt auch Mechanismen,
auch Verständnis da, sozusagen den Überblick zu behalten
und halt nicht die Kontrolle zu verlieren, genau.
Ich möchte da nochmal auch einhaken auf die Frage
und kann das nur unterstützen, was Olaf sagte.
Die Frage war ja, was passiert mit dem Kasten,
mit dem Change Advisory Board?
Gewöhnlicherweise über die letzten Jahre haben sich Customer
oder Change Advisory Boards meistens in großen Firmen,
die in gewissen Outsourcing-Beziehungen standen
oder in großen Organisationen, auch wenn man ein Insourcing hatte,
der IT ausgebildet.
Durch die Beschleunigung von der Automatisierung
und dadurch, dass sich CI, CD-Pipelines,
die ständig übereinander automatisiert wirken und deployen,
und dadurch, dass ich Testalgorithmen habe,
die mit immer größeren Testabdeckungen dazu führen,
dass, wenn festgestellt wird durch Automaten,
das ist grün, das ist grün, das ist grün
und man dort eine gewisse Regel-Rollenauswertung,
KI-Intelligenz drüber legt,
dann können Rollout- und Freigabeentscheidungen,
die entweder durch ein Change Advisory Board
durch Menschen gemacht werden,
Stück für Stück auch ersetzt werden durch Automaten,
die, wenn sie dann sagen, alles ist grün,
rolle aus, mache eine nächste Stage
oder rolle es sogar in Produktion aus,
das mehr und mehr zu einer Reduzierung der Aufgabe
von menschlichen Entscheidungen im Change Advisory Board führt.
Und meine Messlatte, beziehungsweise unsere Messlatte,
auch für die MMS, ist eigentlich Amazon Web Services.
Amazon Web Services hat seinen Change Advisory Board Vorgang
von menschlichen Entscheidungen auf Roboterentscheidungen umgestellt.
Warum?
Weil die menschlichen Entscheidungen bei den ständigen Durchläufen,
die die Automatisierungs-Pipeline bei Amazon Web Services macht,
zu großen Fehlern geführt hat.
Das heißt, die KI- und Automaten, die CI-CD-Pipelines,
die mit hohen Testabdeckungen durchlaufen,
treffen größtenteils automatisch die Entscheidung,
rolle ich das jetzt aus, rolle ich das jetzt nicht aus?
Und dort werden wir mit KI- oder AI-Methoden im Betrieb
und auch in Change Advisory Board dazukommen,
Freigabeentscheidungen, die eigentlich ein Change Advisory Board trifft,
die Aufgaben eines menschlichen CABs weiter und weiter zu reduzieren.
Ich würde das nochmal aufnehmen, was Ralf gesagt hat.
Also das Ganze hört sich jetzt sozusagen so ein bisschen an,
als wenn das jetzt alles von alleine geht.
Ich glaube, es gibt ja auch mehrere Arten von Changes.
Und sicherlich kann ein Minor-Change oder halt ein Odd-Fix schneller durchlaufen
und da braucht man auch keinen Change Advisory Board.
Man kann gewisse Typen vordefinieren, wo es sozusagen so eine Art
Pre-Authorized-Change-Prozess gibt, wo das auch im Risiko auch bleiben kann.
Ich glaube, aktuell ist es so, ein Kunde, der wirklich eine wichtige Geschäftsanwendung hat,
der wird immer noch sagen, nee, ich brauche anderen Gewissen,
an einer gewissen Stelle brauche ich hier immer noch eine menschliche Freigabe.
Und das ist das, was wir unseren Kunden ja auch anbieten wollen,
dass sie sagen, okay, dass er natürlich immer die Hoheit darüber hat,
was er dann letzten Endes da auch im Markt auch deployt.
Wo ich Ralf aber absolut recht gebe, ist einfach in einem hochstandardisierten Umfeld,
da wird man ohne solche sehr starken Automatisierungen
und Selbstbestimmungen,
Selbstlernen-Systemen dann nicht mehr auskommen.
Bei einer großen individuellen Geschäftsanwendung,
da würde ich mal interpretieren, da wird es noch ein bisschen dauern.
Sehr schön. Also, ich gucke auf die Uhr.
Wir haben fast eine gute Stunde gefüllt und ich glaube,
da steckt ganz viel drin von dem, was ihr so berichtet habt.
Das muss man sich wahrscheinlich zwei- oder dreimal nochmal anhören,
weil ihr einfach sehr viel aus der Praxis berichtet habt.
Ich habe keine Fragen mehr.
Alex, wie sieht es bei dir aus?
Ich fand es unglaublich spannend.
Wir können natürlich lange weiter diskutieren,
aber vielleicht dann mal beim Folge-Podcast.
Keine weiteren Fragen.
Ja, recht vielen Dank.
Also, ich möchte mich auch bei euch bedanken,
dass ich hier bzw. dass wir hier teilnehmen durften
und unsere Meinung äußern konnten.
Sicherlich haben wir an der einen oder anderen Stelle
auch ein bisschen einen Ausblick in die Zukunft gegeben,
aber man muss sich weiterentwickeln.
Und nur dann, wenn wir wettbewerbsfähig bleiben,
dann hat unser Unternehmen auch gute Chancen auf Wachstum
bzw. weiterer Daseinsberechtigung.
Also, es bleibt spannend, definitiv.
Und DevOps ist ja eine Reise, nicht ein Ziel,
das man dann morgen erreicht hat.
Also, auch herzlichen Dank von meiner Seite.
Ja, ich danke auch.
Und ich sehe das genauso.
Eigentlich fängt das Spannende jetzt erst an.
Also, die IT ist jetzt sozusagen jetzt soweit,
wo man wirklich sagen kann,
jetzt beginnt auch eine aufregende Zukunft mit Chancen für alle.
Möchtest du vielleicht, Dirk, noch auf den,
wir haben ja noch einen nächsten Podcast geplant.
Jawohl, der nächste Podcast ist der,
den wir beim letzten Mal schon als nächsten angekündigt haben.
Also, wir sind gerade aktuell richtig agil in unserer Planung,
müssen uns immer auf veränderte Situationen einstellen.
Also, beim nächsten Mal hören wir dann,
was wirklich was zur MetroMap von der Direktgruppe.
Die wird ihre MetroMap vorstellen.
Und da werden wir auch wiederum zwei Gesprächspartner haben.
Wird bestimmt genauso interessant.
Wird dann vielleicht ein bisschen eher so in Beratung reingehen.
Aber trotzdem, wie gesagt, wird mit der MetroMap,
werden wir tolle Dinge besprechen.
Ich sage auch Dankeschön.
Und Alex, dann würde ich sagen, du mal das Schlusswort heute.
Ja, herzlichen Dank.
Ich denke, auch dieses Mal wird es super spannend.
Super spannender Beitrag.
Und auch, ich denke, aus der Praxis heraus,
die Herausforderung, die eine T-Systems MMS gesehen hat
und wie sie das dann effektiv umgesetzt hat.
Am Schluss ist auch, das Technische muss man natürlich auf die Reihe bringen,
aber dann der Faktor Mensch, der hat sich auch jetzt wieder gezeigt.
Also, die Leute, die begeistern, das Feuer wecken in den Leuten,
dass sie dann auch mitmachen.
Und ich fand irgendwie am Schluss dann die Diskussion Richtung,
ich meine da Artificial Intelligence,
das ist sicher so das nächste grosse Thema.
Da ist jetzt sehr viel mit Chatbots auch,
die jetzt eingesetzt werden.
Das wäre dann vielleicht auch mal ein spannendes Thema.
Aber in diesem Sinn, vielen Dank.
Vielen Dank.
Vielen Dank.

Folge 2: Das Periodensystem der DevOps-Tools

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode des Podcasts diskutieren die Gastgeber Alex Lichtenberger und Dierk Söllner mit dem Gast Matthias Zieger von Xebia Labs ausführlich über das Periodensystem der DevOps-Tools. Sie erörtern die Entstehung und Bedeutung des Systems, seine Struktur, und wie es die Auswahl und den Einsatz verschiedener DevOps-Werkzeuge in der Softwareentwicklung vereinfacht und verbessert. Der Fokus liegt dabei auf der Integration der Tools in den Continuous Delivery Prozess und der Rolle der Automation, mit besonderer Berücksichtigung verschiedener Technologien und Plattformen.

Inhalt

  • Einführung und Vorstellung der Teilnehmer
  • Entstehungsgeschichte des Periodensystems der DevOps-Tools
  • Struktur und Klassifizierung der Tools im System
  • Bedeutung und Anwendung von Continuous Delivery
  • Unterschiedliche DevOps-Tools und ihre Funktionen
  • Herausforderungen und Lösungen im Bereich der Tool-Integration
  • Wichtigkeit von Automatisierung und Effizienz in der Softwareentwicklung
  • Community-Einfluss auf die Entwicklung des Periodensystems

Shownotes

Transkript (automatisiert, keine Gewähr 🙂 )

Hallo und herzlich willkommen zum zweiten Podcast, zur zweiten Folge des Podcasts. DevOps auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich bin einer der beiden Gastgeber. Und der Alex wird sich auch gleich nochmal ganz kurz vorstellen.
Ja, die zweite Ausgabe, die zweite Folge, die wir hier an den Start bringen. Wir haben heute zu Gast den Matthias Zieger von Xebia Labs.
Auch der wird sich nachher noch vorstellen. Wir haben das Thema Periodic Table of DevOps Tools. Ein sehr interessantes Thema.
Wir freuen uns, dass wir den Matthias dabei haben. Hallo Matthias, mal ein herzliches Willkommen schon mal an der Stelle.
Danke.
Ja, zweite Folge. Wir haben bei der ersten Folge dazu aufgerufen, ein paar Rückmeldungen zu geben. Und wir haben uns gefreut, es gab ein paar Rückmeldungen.
Und eine Rückmeldung war bezüglich der Technik. Da kam die Rückmeldung, dass die Aufnahme ein bisschen nivellierter sein könnte, ein bisschen mehr Qualität rein.
Das machen wir schon. Das, denke ich, werdet ihr merken oder hören, dass wir ein bisschen an der Technik gearbeitet haben.
Und insofern da.
Ja, herzlichen Dank für die Rückmeldungen. Alex, dann übergebe ich mal an dich.
Ja, vielen Dank, Dirk. Herzlich willkommen auch von meiner Seite.
Ja, wir haben ja ursprünglich, haben wir angekündigt im letzten Podcast, dass wir heute das Value Stream Mapping machen.
Das hat sich jetzt verschoben, weil die Leute müssen natürlich immer auch verfügbar sein für ein Interview.
Das hat für das Value Stream Mapping nicht geklappt. Aber wir werden das dann, denke ich, im übernächsten Podcast werden wir das bringen.
Aber wir haben heute auch ein ganz spannendes Thema, die Periodic Table of DevOps von Xebia Labs.
Bevor ich da übergebe an den Matthias, ja, die meisten von euch kennen wahrscheinlich diese Periodic Table.
Und wenn wir über DevOps sprechen, egal über welches Thema, eigentlich ist es immer so People, Process, Tools.
Also im Falle von DevOps, People, wie setze ich eine DevOps-Kultur?
Durch die neue Art und Weise zusammenzuarbeiten. Dann Process, wie bringe ich ein Continuous Delivery auf die Reihe?
Und wenn es dann um die Tools, die Technologie geht, wie bringe ich das dann effektiv auf den Boden?
Da hat sich ein riesen Tool-Universum aufgetan.
Verschiedenste Tools rund um Cloud, Continuous Delivery, Artifactory etc.
Und da, als ich das erste Mal diese…
Diese Table gesehen habe, das ist eigentlich so dann so wie, weil die Leute sind ein bisschen dann verloren in diesem ganzen Tool-Universum.
Eigentlich eine wunderbare Sache. Das gefällt den Leuten sehr gut.
Deshalb denke ich, ist heute auch das heutige Thema sehr spannend für die Leute.
In diesem Sinne möchte ich gerne jetzt an den Matthias übergeben.
Vielleicht mal kurz, dass du dich als Person vorstellst, auch Xebia Labs und was ihr macht.
Ja, vielen Dank.
Vielen Dank für die Einführung.
Mein Name ist Matthias Zigger. Ich bin bei Xebia Labs in Deutschland für die Technik zuständig.
Das heißt, ich mache alles von Produkt-Demos über Messen bis hin zu POCs, Piloten und Produkteinführungen.
Ich mache das jetzt seit zweieinhalb Jahren für Xebia Labs, eine ganze Zeit auch mit einem Partner zusammen, mit der Co-Centric.
Mittlerweile hat Xebia Labs ein eigenes Team in Deutschland und wer Xebia Labs nicht kennt, wir kommen ursprünglich aus Holland.
Da ist auch immer noch unser Hauptsitz, unsere Entwickler.
Das sind so 70 Entwickler, die wir haben, die an den Produkten arbeiten.
Die sitzen alle in Holland, in der Nähe von Utrecht, in Hilversum.
Und wir sind mittlerweile weltweit vertreten, haben ein zweites Headquarter noch in Boston, hauptsächlich aus Gründen Venture Capital und so weiter.
Aber Technik ist alles in Europa, von daher passt das auch alles so weit.
Bevor ich bei Xebia Labs und Co-Centric das Thema gemacht habe, war ich bei Microsoft und habe da das Thema Team Foundation.
Server gemacht.
Da hieß das noch gar nicht DevOps, da hat man noch Application Lifecycle Management gesagt.
Aber eigentlich ging es immer darum, wie bekomme ich meine Produkte eigentlich schneller vom Entwickler bis in Produktion.
Das ist das, was mich so die letzten 10, 15 Jahre mittlerweile umtreibt.
Sehr schön.
Dann, Matthias, vielen Dank für die Vorstellung, für die Einführung.
Ich habe ja vorhin gesagt, wir haben Rückmeldungen bekommen.
Und eine Rückmeldung war auch zum Thema.
Was ist DevOps?
Und der Teilnehmer hat gesagt, dass er das sehr interessant fand.
Insofern, Frage an dich, Matthias.
Wie würdest du denn DevOps definieren?
Kann man das definieren?
Wie würdest du DevOps beschreiben?
Was ist DevOps für dich?
Ja, man kann es versuchen zu definieren.
Es gibt ganz unterschiedliche Definitionen.
Es gibt natürlich die Definition und der Alex hat es ja schon genannt.
Es gibt ja die drei Perspektiven immer.
People, Process, Technology.
Wenn wir mal bei People anfangen, ist das natürlich ein Thema.
DevOps.
Das ist ein Kulturwandel.
Ein Kunde hat mal zu mir gesagt, wir haben Silos of Excellence,
die wir jetzt aufbrechen müssen im Sinne von DevOps.
Das heißt, wir müssen unsere sehr arbeitsteilige Arbeitsweise,
die wir hatten, wo es Requirements-Spezialisten gab.
Dann gab es die vielleicht Architekten, Modellierer, Entwickler,
QA-Teams, Produktionsteams, die häufig noch mal unterschieden waren
nach Infrastrukturbetrieb und Anwendungsbetrieb und Monitoring.
Das müssen wir eigentlich aufbrechen.
Ja, und das ist die Kernidee von DevOps.
Daran erkennt man schon, dass der Name eigentlich ein bisschen zu kurz gegriffen ist.
Ich sage immer gerne amerikanisch vereinfacht.
DevOps, ja, aber eigentlich müsste es bis Dev QA Security Ops irgendwie heißen.
Ja, so in der Richtung ist aber viel zu umständlich.
Deswegen hat sich DevOps eigentlich eingebürgert.
Aber im Kern geht es eigentlich darum, eine bessere Zusammenarbeit
der verschiedenen Spezialisten, die man hat, zu erreichen in sogenannten
cross-funktionalen Teams.
Das ist, glaube ich, der Kern von DevOps auf der People-Seite,
dass man diese, ja, ich bleibe bei dem Begriff Silos of Excellence einfach aufbricht
und sagt, wir gehen da hinüber, dass wir alle zusammen an einem Produkt
oder einem Problem arbeiten und nicht in so einer Fließbandartigen Geschichte
an dem Thema arbeiten, sondern eher in Gruppen daran zusammenarbeiten.
Das ist so das People-Thema.
Dann haben wir natürlich das Process-Thema.
Das ist dann noch ein bisschen größer und das
geht auch sehr stark dann in den kulturellen Wandel natürlich an den Kern der Unternehmen tatsächlich ran.
Und da ist natürlich das Thema, das geht deutlich über Technik und Technikabteilung auch hinaus.
Also da reden wir dann darüber, dass auch Unternehmen eine andere Art des Controllings
und der Steuerung eigentlich machen müssen.
Also deutlich mehr als ja, wir führen jetzt mal ein paar Tools ein und dann wird das schon gut werden.
Ja, das wird so nicht funktionieren.
Und das sagen wir auch als Toolhersteller natürlich.
Unseren Kunden, dass das so nicht funktionieren kann, wenn man das quasi vernachlässigt am Ende.
Und dann kommen wir ins Spiel.
Geht natürlich auch um Technologie, es geht um Werkzeuge, es geht um Automatisierung.
DevOps als manueller Prozess, glaube ich, kann nicht funktionieren.
DevOps hat als technischen Fokus den Anspruch Automate Everything, also alles zu automatisieren.
Das ist der Anspruch, den wir auch haben.
Beim Kunden kann man dem immer zu 100 Prozent erfüllen, wahrscheinlich nicht.
Aber man sollte das Ziel haben, möglichst weit zu kommen beim Automatismus
und möglichst wenig manuelle Geschichten zu haben.
Das ist so für mich das Thema DevOps.
Verschiedene Perspektiven.
Wir sind jetzt kein Beratungshaus.
CBA Labs ist ein Produkthaus.
Das heißt, wir kümmern uns rein um das Thema Technology.
Wir haben aber Partner an der Hand, wie eine Cozentrik, wie eine Direktgruppe, wie eine M-Vice,
ein paar andere noch, die sich um das Thema People and Process auch kümmern.
Ist jetzt nicht unser Fokus.
Aber wir sagen, das muss eigentlich sein.
Das muss eigentlich vorher geklärt sein, bevor wir mit unserer Technologie dann ins Spiel kommen.
Gut, vielen Dank.
Sehr gute Definition, finde ich.
Auch sehr schön, dass ihr als Produkthaus das schlussendlich holistisch seht.
Also nicht nur Technologie, sondern auch Prozesse und Kultur.
Bevor wir zur eigentlichen Table, also zum Inhalt selber kommen,
wäre vielleicht noch spannend, wie ist das Ding eigentlich entstanden?
Genau, in Vorbereitung auf den Postcard musste ich auch erst mal nachschauen,
wie alt ist eigentlich dieses Periodic Table of DevOps Tools.
Und die erste Version, die wir davon rausgebracht haben, war im Jahr 2015.
Also es ist ungefähr zwei Jahre alt, kann man sagen.
Entstanden ist das deswegen, weil wir bei den Kunden immer wieder die Diskussion geführt haben,
wir reden über, am Ende des Tages reden wir über Toolchains und Werkzeugketten mit den Kunden.
Und dann kam immer wieder die Diskussion, welche Bestandteile muss so eine Werkzeugkette haben?
Welche Prozessschritte sind darin überhaupt notwendig?
Und was sind so die typischen Vertreter, die wir in so einer Werkzeugkette halt sehen,
auch bei anderen Kunden am Markt?
Und dann hat sich unser Marketing überlegt, wie könnte man das eigentlich ganz gut visualisieren?
Und sind dann auf die glorreiche Idee gekommen, das so bei den Chemikern quasi sich zu holen.
Und dort das ja wohl,
bekannte Periodensystem der Elemente quasi zu adaptieren auf das Thema DevOps und Tools.
Und das ist so ein bisschen die Hintergrundgeschichte.
Mittlerweile ist online die zweite Version verfügbar von dem System.
Das heißt, das wird auch ständig abgedatet.
Da kann man aber nachher noch mal kurz drüber sprechen, welche Möglichkeiten es da gibt.
Und wir arbeiten gerade an der dritten Version davon.
Das heißt, das lebt auch so ein bisschen über die Zeit.
Das ist vielleicht der größte Unterschied zum Chemiker.
Ja, genau.
Also, das ist ein bisschen wie in einem chemischen Periodensystem, wo ja Naturgesetze quasi abgebildet sind.
So weit sind wir, glaube ich, in der IT noch nicht, dass wir über Naturgesetze reden.
Aber ja, die Idee ist einfach griffig, weil viele Leute damit ganz gut zurechtkommen.
Und vielleicht als Info mal, wir haben durchaus sechsstellige Downloadzahlen aus dem Internet für das PDF
und verteilen auch jedes Jahr so ein paar Tausend dann noch auf Messen und Konferenzen
in einem Format quasi als Poster.
Das vielleicht mal so als Info für die Zuhörer auch, dass ganz gut verbreitet ist, das Periodensystem.
Spannend.
Jetzt kommen wir, ist ein guter Zeitpunkt, mal auf den Inhalt zu kommen.
Mal gleich einen Versuch zu machen, die, also einerseits die Struktur der Periodic Table,
aber auch den ganzen Inhalt, das mal uns näher zu bringen.
Matthias.
Genau.
Also die Table, für die, die sie jetzt nicht vor sich haben, ist tatsächlich angelehnt an das Periodensystem der Elemente.
Das heißt, wir haben eigentlich eine Matrix.
Diese Matrix hat verschiedene Säulen, die quasi durch Farben repräsentiert sind.
Und diese Farben sind eigentlich dann die Prozessschritte, die man im Continuous Delivery quasi dann finden kann.
Das heißt, fängt ganz vorne dann an mit dem Thema Versionierung und Repositories,
geht dann über CI-Werkzeuge, also Continuous Integration, quasi auch die Grundvoraussetzung,
dass ich überhaupt etwas automatisieren kann, dass ich automatisierte Bills habe.
Geht dann über Artefakt-Repositories, wo dann meine gebauten Binär-Artefakte quasi reinfließen.
Oder wenn man eher moderner unterwegs ist, seine Container-Images auch dann liegen können.
Über Testing-Tools bis zu Deployment-Werkzeugen, Release-Werkzeugen.
Und am Ende haben wir natürlich dann das ganze Thema Orchestrierungs-Werkzeuge dann für Container.
Also sowas wie Kubernetes, Mesos, OpenShift.
Und ganz rechts findet man das, worauf alles dann aufbaut, quasi Infrastruktur-Themen.
Das sind die Sachen, über die auch die Continuous Delivery Lehrbücher, sage ich mal, sprechen.
Wir haben uns dann dafür entschlossen, unter dem Periodic Table nochmal einen separaten Absatz zu machen.
Für ergänzende Tools, die normalerweise in den Continuous Delivery und DevOps Lehrbüchern gar nicht auftauchen.
Das sind dann eher Collaboration-Werkzeuge.
Also da taucht dann sowas auf wie agile Planungs-Werkzeuge.
Also sowas wie ein Jira zum Beispiel oder ein Rally oder ein Version 1.
Dann gehören natürlich heute auch Chat-Werkzeuge dazu.
Also da taucht dann sowas auf wie ein Slack oder ein HipChat von Atlassian dann auch.
Bis hin zu sehr speziellen Werkzeugen, die das Thema Security,
Adressieren, die dann quasi so eine Querschnittsfunktion haben.
Die haben wir separat, so ein bisschen auch räumlich separiert von den anderen Themen,
weil sie ursächlich natürlich nichts mit Continuous Delivery oder DevOps zu tun haben,
aber aus unserer Sicht eine gute Ergänzung sind.
Das ist quasi die Abbildung des Prozesses.
Und das eignet sich eigentlich sehr gut, beim Kunden darüber zu reden,
welche Prozessschritte hat er überhaupt in seinem Unternehmen,
weil wir natürlich auch bei Kunden sind, die zum Beispiel sagen, wir sind Software-Lieferant,
wir haben gar nicht den Betrieb, weil den macht der Endkunde am Ende des Tages mit der Software,
die dann von einem Softwarehersteller zum Beispiel ausgeliefert wird.
Oder man hat vielleicht Kunden, die sagen, ja, wir wissen, dass Testautomation wichtig ist,
aber wir haben noch nicht da rein investiert.
Das heißt, wir haben da so einen kleinen Spot, so ein bisschen an der Stelle.
Und das sind so die Themen, wo man eigentlich sehr gut mit dem Kunden erstmal auf einer Prozessebene sprechen kann,
indem man sich anhand der Farben langhangelt und mit dem Kunden spricht und sagt,
was ist so dein Gefühl dafür, wo bist du gut aufgestellt, wo geht es so einigermaßen
und wo siehst du noch Verbesserungspotenzial.
Also eine reine Prozessbetrachtung.
Dabei helfen quasi die Farben dieses Periodensystems einfach sehr gut,
weil man wirklich die Prozesse als Säulen dann hat.
Und das Zweite ist dann, in den Säulen hat man natürlich dann die einzelnen Werkzeuge.
Also ich sage mal, beim Thema Versionskontrolle haben wir eine relativ große Bandbreite abgebildet.
Von Git-basierten Systemen, von Git-Pur über Bitbucket vielleicht, GitHub.
Aber auch noch Subversion natürlich drin, weil es immer noch Kunden gibt,
die auch eher auf älteren Systemen natürlich unterwegs sind
und noch nicht jeder auf die neueste Technologie an der Stelle gesetzt hat.
Und unsere Strategie ist eigentlich so, dass wir in jeder Säule die Tools abgebildet haben,
die wir bei unseren Kunden, und das ist die wichtige Aussage bei unseren Kunden,
als führende Tools dann in den jeweiligen Bereichen halt sehen.
Und das ist dann eine bunte Mischung aus Open-Source-Tools,
wenn wir jetzt mal beim Code-Repository bleiben, Open-Source-Werkzeuge wie Git zum Beispiel,
bis hin zu kommerziellen Werkzeugen, vom Schlager eines Bitbucket dann oder auch eines GitHub Enterprise.
Also es ist immer eine bunte Mischung aus Open-Source-Werkzeugen und kommerziellen Werkzeugen
und deckt so ein bisschen die Realität ab, die wir beim Kunden halt sehen.
Und das erhebt natürlich keinerlei Anspruch auf absolute Vollständigkeit.
Das geht gar nicht, wenn man sich allein mal das Thema Testen anschaut.
Da hat man natürlich, wenn ich mit dem Java-Entwickler rede,
Unit testen ist die Antwort relativ einfach, machen wir mit JUnit.
Aber wenn ich schon auf das Thema Oberflächen gehe, dann kommt schon sehr stark natürlich rein in Unterscheidung.
Der eine sagt, er nimmt Selenium,
der andere sagt, er testet Oberflächen.
Wenn ich zum Beispiel native Applikationen auf mobilen Geräten testen will,
brauche ich ganz andere Testwerkzeuge.
Also beim Testen ist es dann auch nicht mehr so einfach, einen Marktführer zum Beispiel dann rauszufinden,
weil das einfach auch technologieabhängig ist.
Wenn ich auf einem Windows-Client eine Microsoft.net-Applikation testen will,
brauche ich ganz andere Werkzeuge.
Also da ist es dann auch nicht mehr so einfach.
Und ja, wir haben quasi uns Mühe gegeben,
das so best of the best quasi in diesem Periodensystem abzubilden,
aber keinen Anspruch auf Vollständigkeit.
Das merkt man auch immer wieder, wenn wir zum Beispiel mit Kunden reden,
die jetzt eher aus dem Embedded-Umfeld kommen.
Da findet man plötzlich ganz andere Werkzeuge natürlich,
die man so in der klassischen Business-Applikationswelt gar nicht findet.
Und da muss man ein bisschen aufpassen.
Es ist quasi eine repräsentative Darstellung des Marktes,
aber auch eine sehr verallgemeinernde Darstellung des Marktes.
Und kann natürlich nur eine geringe Auswahl an den tatsächlich vorhandenen Tools geben.
Aber es deckt so ein bisschen die Marktführerschaft quasi dann aus den einzelnen Bereichen dann quasi ab.
Das vielleicht dazu.
Wir haben dann die Tools noch klassifiziert so ein bisschen.
Das sind quasi die Sachen, die man im Periodensystem so als kleingedruckt auch findet.
Auch wieder angelehnt an das chemische Periodensystem.
Wir haben dann nochmal klassifiziert, welches Business-Modell steckt eigentlich.
Hinter dem Anbieter ist es rein Open Source oder ist es zum Beispiel ein Freemium-Model,
wie man es vielleicht bei Jenkins hat, wo ich sage, es gibt eine Open Source-Variante
und darauf aufbauend gibt es eine kommerzielle Variante.
Oder ist es ein rein kommerzielles Angebot, was man quasi da findet, wie es bei vielen Herstellern halt auch der Fall ist.
Mal als Beispiel bei den Atlassian Tools.
Das sind halt reine kommerzielle Werkzeuge halt dann.
Und das ist dann quasi, bildet das dann das Periodensystem.
Also zusammenfassend könnte man nochmal sagen, wir haben quasi die Säulen, die die Farben bilden.
Das ist eher der Prozessgedanke, über welche Schritte muss ich eigentlich nachdenken und wo muss ich mir etwas auswählen.
Und der zweite Gedanke ist dann quasi, welches Tool nehme ich eigentlich.
Und dann kommen wieder Berater ins Spiel oder der Kunde selbst, wo er dann quasi die Qual der Wahl hat, sage ich mal.
Weil er muss aus jeder Farbe sich ein Werkzeug natürlich aussuchen.
Um die Kette komplett zu haben.
Ja, also wir nutzen das auch sehr oft, um in die Diskussion zu gehen mit dem Kunden.
Das ist ein super Instrument dafür.
Und schlussendlich ist es wahrscheinlich eine Illusion, dass man ein Tool hat, das alles abdeckt.
Stattdessen will man eher eine Toolchain, das ist eigentlich wie ein Puzzle, das man zusammenfügen muss.
Und wenn halt, sage ich mal, ein Element fehlt, also man sieht das auch schön am Continuous Delivery.
Wo ein manueller Bruch drin ist, dann hat man kein Continuous Delivery.
Vielleicht noch kurz zur Auswahl.
Du hast ja selber gesagt, das Tool-Universum ist riesig.
Ihr müsst eine Selektion vornehmen.
Ihr habt das ein bisschen nach Bestenwissen und Gewissen.
Was sind so die grossen Player für die einzelnen Bereiche?
Gibt es da vielleicht auch die Möglichkeit, das als Community zu beeinflussen?
Was da auf dir, zum Beispiel in der nächsten Version, aufhört?
Was kommt auf die Table drauf?
Genau, das ist ein wichtiger Punkt.
Die Frage ist, warum sind jetzt gerade die Tools drauf, die drauf sind?
Also bei ein paar Sachen kommt man einfach nicht drum rum, glaube ich.
Dass da ein Git draufsteht, ist, glaube ich, unstrittig.
Und dass bei CI-Tools halt ein Jenkins drauf ist und ein Bamboo und vielleicht dann noch ein TeamCity.
Ja, das sind die drei Großen.
Aber die Frage ist, wer wird dann Nummer 4 und Nummer 5?
Und da haben wir eigentlich mehrere Methoden, wie wir das ermitteln.
Die erste Methode ist eigentlich die,
dass wir natürlich ein Voting-Mechanismus haben im Internet.
Das heißt, man kann quasi voten und sagen, da soll jetzt ein neues Tool drauf.
Das hat eine gewisse Relevanz, das brauchen wir.
Der zweite Kanal, den wir dafür nutzen, ist quasi der Kanal,
dass wir selbst eine sehr aktive Community auf GitHub haben.
Da gibt es eine XebiaLabs-Community-Seite, wo quasi die Plugins für unsere Tools dann drauf sind.
Und das beobachten wir auch sehr genau.
Was macht die Community? Welche Plugins werden da gefragt?
Welche steigen massiv an von den Download-Zahlen her?
Und wir monitoren das sehr genau.
Und das ist natürlich für uns auch ein Indikator dann.
Was soll dann als nächstes vielleicht auf dieses Periodensystem?
Was können wir dafür rausschmeißen?
Weil der Platz ist halt auch nur beschränkt.
Ja, wir können nicht alle Tools draufnehmen, sonst wird es zu unübersichtlich.
Und die dritte Methode ist natürlich die, wenn wir auf Konferenzen sind, auf Messen sind,
in die direkte Interaktion gehen mit den Kunden.
Das ist quasi der dritte Kanal, wo wir dann auch Feedback dazu bekommen und dann fragen,
welche Tools nutzt ihr? Was glaubt ihr, was nächstes Jahr bei euch im Haus eine Rolle spielt?
Und da kommt man auch ganz gut auf Ideen, was dann als nächstes quasi auf diesem Periodensystem dann drauf sein soll.
Ja, also Community kann hier wirklich aktiv mitmachen und kann uns Hinweise geben und sagen, da fehlt was
und da hätten wir gern noch was dazu gebaut.
Ja, super. Das macht das Ganze auch viel glaubwürdiger.
Also wenn das dann auch von der Community gefüttert wird.
Noch eine andere Frage, die in den Sinn gekommen ist.
Kann man daraus auch so eine Art wie Beispielkonfigurationen ableiten?
So im Sinne von Starterkit, billige Variante, Open Source, Enterprise?
Eher nicht. Also die Idee ist eigentlich nicht, dass man jetzt sagt,
okay, ich nehme jetzt, sag ich mal, aus jedem Bereich nur die Open Source Tools zum Beispiel
und lande dann bei, sag mal, so eine typische Pipeline wäre, wenn ich sage, ich darf nur Open Source Tools nehmen,
dann wäre es halt Git, Jenkins-freie Version plus vielleicht Deployment und Provisionierung dann mit Ansible
und das Ganze lasse ich dann auf einem Kubernetes zum Beispiel laufen, ja, als Laufzeitumgebung.
Und das kann man zwar machen, ja, und kann sagen, okay,
das ist quasi dann die Billigvariante, aber das trifft eigentlich nicht den Kern,
weil der Kern ist eigentlich, den Kunden zu fragen, welche Anforderungen hast du eigentlich?
Und dann kommt man sehr schnell drauf, dass man am Ende eine Mischung haben wird,
vielleicht aus Open Source Tools, aus kommerziellen Tools.
Wir sehen relativ wenig Kunden auch, die jetzt ihre Pipeline komplett nur mit Open Source haben
oder komplett nur mit kommerziellen Tools. Meistens ist es eine ganz gute Mischung.
Meistens ist es auch so, dass man bei größeren Kunden, sag ich mal,
bei Banken, Versicherungen, große Handelsunternehmen, Logistiker, mit denen wir halt sprechen,
auch gar nicht mit einer Continuous-Delivery-Pipeline am Ende des Tages auskommt,
sondern man hat vielleicht verschiedene. Also es gibt natürlich Themen in dieser Pipeline,
die sind technologieunabhängig. Ob ich jetzt in einem GitHub-Repository
Java-Code, Node.js oder .NET Sachen verwalte, ist eigentlich egal.
Beim Build-Server wird es dann schon ein bisschen anders, da ist es nicht mehr ganz so egal.
Weil da muss ich dann schon mal Cross-Plattform unterwegs sein.
Das heißt, der muss im Zweifel dann auf Linux laufen oder auf Windows,
wenn ich Windows-Applikationen baue, oder muss vielleicht andere Technologien unterstützen.
Und spätestens beim Thema Testen bin ich plattformabhängig.
Da habe ich Plattformabhängigkeiten, weil ich einen Browser testen muss, der auf Windows läuft,
weil ich einen Browser testen muss, der auf macOS läuft. Und ähnlich ist es eigentlich auch bei Provisionierungstools.
Weil die meisten Provisionierungstools natürlich dann auch Betriebssystemabhängigkeiten haben.
Das heißt, es ist schon ein Unterschied, ob ich einen Windows-Server provisionieren darf
oder ob ich ein Linux- oder Unix-System provisionieren muss. Das ist dann natürlich ein Unterschied.
Bei Container-Orchestrators ist es dann wieder ein bisschen einfacher.
Da bin ich dann doch zum großen Teil plattformunabhängig. Aber spätestens dann, wenn es dann wieder darum geht,
meine Firmenstrategie eigentlich alles im eigenen Rechenzentrum zu haben oder gehe ich in eine Public Cloud
und wenn ja, ist es dann nur eine oder vielleicht zwei. Ist es AWS oder Azure oder AWS und Azure und Google Cloud.
Dann bin ich plötzlich wieder beim Thema, welche Tools unterstützen das eigentlich?
Und dann wird es auch manchmal sehr schnell dünn. Und dann kommt man auch schnell auf den Punkt, wo man sagt,
vielleicht reicht auch nicht eine Toolchain, sondern du brauchst vielleicht unterschiedliche Toolchains pro Technologie.
Also deine Java-Entwickler kriegen einen anderen CD-Toolchain in einer gewissen Ausprägung wie deine Microsoft-Leute.
Und SAP ist nochmal ein ganz anderes Beispiel, wo ich dann über ganz andere Tools wieder rede.
Und dann kommt man wirklich sehr schnell dahin, dass man sagt, wir haben Gemeinsamkeiten wie zum Beispiel GitHub und Nexus Artifactory.
Technologieunabhängig kann ich alles damit machen.
Aber die restlichen Sachen sind dann nicht da.
Und vielleicht Stack-spezifisch auszuwählen. Das trifft eher die Realität eigentlich.
Und da muss man ins Detail gehen. Dann kommen wieder die Berater ins Spiel, beim Kunden dann solche Sachen quasi auszusuchen.
Genau, es ist dann eben doch nicht so einfach. Und schlussendlich, wie du gesagt hast, hat man ja verschiedene Toolchains, verschiedene Pipelines.
Da kann man ja, denke ich, noch schön den Link machen, dann so die Dimensionen, Prozesse und People,
was jetzt viele IT-Abteilungen machen. Sie richten ihre Teams entlang ihrer Produkte aus.
Also Cross-Functional Teams, die sich dann End-to-End, also von der Anforderung bis in die Inbetriebnahme um das Produkt kümmern.
Und je nach Produkt sind dann natürlich auch eigene Plattformen darunter oder eigene Tools.
Aber zum Teil gibt es natürlich auch übergreifende dann. Und da wäre vielleicht auch mal schön, jetzt mal so ganz praktisch,
das ist auch immer eine Frage, die ich bekomme, weil die Leute haben in der Regel ein gutes Verständnis.
Was heisst jetzt kulturell DevOps mit dieser neuen, sagen wir, die agile Philosophie, die grundsätzliche Agile Leadership, das reinkommt.
Dann Prozesse, sagen wir, der Continuous Integration Delivery Prozess. Und wie das jetzt ganz konkret, also so ein Beispiel End-to-End.
Also ich würde mal so, aus meiner Erfahrung, also der Traum ist vom Entwickler, es fängt immer aus,
alles an mit der Anforderung, also man hat beispielsweise User Stories, man formuliert Testfälle dazu und dann geht man hin,
man entwickelt, man checkt ein, es durchlaufend, das ist ja dann Continuous Delivery, man testet die automatisiert ablaufend,
so dass man eigentlich jederzeit könnte live gehen. Also Software is always in a releasable state.
Value Stream von Anfang bis Ende, da hat man so auch aus Kundensicht, also der Kunde will was und er bekommt das relativ schnell, das Feature.
Kann man da mal so ein Beispiel durchspielen? Ich habe es jetzt mal so prozessmässig erklärt.
Und wie würde das jetzt an beispielsweise Tools, wie würden die untendran entlang von dieser Pipeline interagieren? Ist das etwas, das du könntest?
Ja klar, weil das ist das, was wir quasi täglich machen, uns genau in solche Themen,
quasi rein zu integrieren. Wenn wir jetzt mal das Beispiel, was du genannt hattest, mal entlang gehen mit so ein paar typischen Tool-Vertretern,
dann würde quasi im Idealbild natürlich die Anforderung nicht irgendwie in Word oder in Excel gebaut werden,
sondern würde vielleicht in einem Tool wie Jira dann stehen. Das heißt, ich habe da meine User Stories, die vielleicht dann runtergebrochen sind,
die fangen oben an relativ grob in irgendwelchen Epics, dann User Stories und dann geht das immer weiter.
Nach unten auf beliebig viele Hierarchiestufen. Dann hattest du einen wichtigen Punkt gesagt.
Was machen wir eigentlich mit den Testfällen? Die sollten eigentlich direkt auf die Anforderungen gemappt sein.
Ich sage jetzt eigentlich, weil das bei vielen Kunden immer noch ein blinder Fleck so ein bisschen ist.
Wir wissen alle, wie die Idealwelt aussehen sollte. Ich habe meine Testfälle, die zu meinen Anforderungen gehören und die sind irgendwie verlinkt.
Die könnte ich zum Beispiel auch in einem Jira machen. Da gibt es Ergänzungen für Jira, dass ich da auch Testfälle verwalten kann.
Oder ich habe ein separates Test-Management-Tool. Da gibt es auch verschiedene von HP, von Micro Focus und so weiter, die da eine Rolle spielen.
Dann arbeiten natürlich meine Entwickler mit einer IDI. Das heißt, im Java-Umfeld sehen wir dann Eclipse oder auch andere Systeme, die da eine Rolle spielen.
Vielleicht IntelliJ, bei Microsoft dominierend natürlich Visual Studio, die da eine Rolle spielen.
Und da bauen dann die Entwickler ihren Code, haben vielleicht auch von da direkt Zugriff auf die Anforderungen, was nicht so ganz schlecht wäre, wenn sie ihre IDE nicht verlassen müssen, um auf Anforderungen zuzugreifen.
Und dann wird der Code quasi ständig gebaut und dann relativ kleinteilig, sage ich mal, auch eingecheckt dann in eine Versionskontrolle.
Das macht natürlich dann mit Git viel mehr Spaß als mit so althergebrachten Systemen wie vielleicht Subversion oder noch älter wie Clear Cases.
Oder Clear Quest, ja, von den älteren Zuhörern, die werden sich noch daran erinnern können.
Die jungen Leute wissen heute gar nicht mehr, wie gut sie es eigentlich haben, weil sie direkt mit Git eigentlich einsteigen können.
Da wäre natürlich auch die Idee, dass ich dann eine Traceability habe von meinen Anforderungen bis zum Code.
Das heißt, meine Anforderungen im Jira vielleicht sollten natürlich auch verbunden sein mit meinen Codefragmenten, die ich dann gebaut habe.
Und aus der Versionskontrolle geht es dann quasi nach vorne.
Da kommt dann natürlich ein Jenkins ins Spiel, der dann quasi on demand ein Bild macht.
Wenn ich Continuous Delivery tatsächlich so auffasse, wie es gemeint ist, wird ja dann jede Codeänderung quasi isoliert gebaut und dann hoffentlich auch isoliert getestet.
Das heißt, da spielt dann gleichzeitig das Thema Testen mit rein.
Aber nicht nur Testen, sondern da sollte ein bisschen mehr noch passieren.
Das heißt, mit den Jenkins dann zum Beispiel orchestriert oder auch andere CI-Tools, die können das auch alle, wie ein Bamboo oder ein TeamCity.
Da sollten dann auch Codeanalysen natürlich laufen, statische Codeanalysen.
Da wäre so ein Vertreter mal typischerweise ein SonarCube mal zu nennen für die, sag ich mal, Java- und .NET-zentrierten Geschichten oder auch andere Technologien.
Wenn man eher so im Embedded-Umfeld ist, gibt es dann sehr spezielle Tools, die auch Codeanalyse für C zum Beispiel machen.
Oder sogar Assembler machen können, die kann ich auch alle in Jenkins natürlich reinhängen.
So, dann haben wir unseren Code gebaut und dann geht der Flow natürlich weiter.
Unser Value-Stream vom Jenkins aus sollen die Sachen natürlich nicht auf irgendeinem File-Share landen.
Das sehen wir auch mittlerweile nur noch relativ selten.
Die meisten Kunden haben dann doch schon sowas wie Artifactory oder Nexus im Einsatz als Binär-Repository.
Warum sollte ich dafür ein spezielles Repository nehmen?
Das ist einfach der Grund, dass die Source-Repositories einfach nicht dafür ausgelegt sind, dann groß mit Binär-Artefakten zu hantieren.
Und vor allen Dingen das Thema Abhängigkeiten-Management eigentlich nicht gut da abgebildet ist.
Von daher macht es auf jeden Fall Sinn, sowas wie ein Artifactory oder Nexus zu haben.
Und von da geht es dann natürlich nahtlos in das Thema eigentlich Deployment über.
Das heißt, da reden wir dann darüber, wie kriege ich jetzt eigentlich die Artefakte auf meine Zielumgebung.
Ich sag mal, da sind wir jetzt nicht ganz neutral als XebiaLabs, weil wir da selber ein Tool haben.
Aber ich sag mal, was man am Markt findet, ist eigentlich alles von, wir haben Millionenzeilen, selbstgeschriebene Bash-Skripte oder PowerShell-Skripte, die das Deployment machen.
Über klassische deskriptive Deployment-Verfahren, wie zum Beispiel ein Ansible oder auch ein Chef.
Und dann ganz oben stehen dann die modernen Deployment-Tools, die tatsächlich so ein modellbasiertes Deployment machen.
Und dann abbilden können. Das ist so die Bandbreite, die man halt am Markt sieht.
Und die Deployment-Tools, egal welches, die sollten sich natürlich die Artefakte dann aus dem Artefakt-Repository dann holen und sollten sie dann auf die Stages bringen.
Dann muss man noch ein bisschen mit der Herausforderung kämpfen, dass ich natürlich Stage-abhängige Parameter dann habe.
Mal als Beispiel mein Datenbank-Passwort einfach im Testsystem ist ein anderes, hoffentlich, als auf dem Produktionssystem.
Mein Paket, was ich aber deployen will auf die Datenbank, sollte umgebungsunabhängig sein.
Das heißt, da muss ich mir Gedanken machen, wie kriege ich das Thema Configuration-Management eigentlich damit untergebracht in dem ganzen Prozess.
Da muss man ein bisschen reingucken, dass das vernünftig funktioniert.
Und dann ist eigentlich, sage ich mal, aus der Sicht von Continuous Delivery eigentlich mein Value-Stream schon zu Ende.
Wir glauben aber, dass noch ein bisschen mehr kommen muss.
Was zum Beispiel sinnvoll wäre, ist, wenn ich ein Monitoring-Programm,
ein Monitoring-System zum Beispiel habe in Produktion, dass ich dem Monitoring-System zum Beispiel sage, hier gibt es jetzt ein neues Release von der Applikation.
Das Monitoring-System kann dann darauf reagieren und kann sagen, okay, hier gibt es eine gewisse Downtime vielleicht.
Wenn ich noch keine Architektur habe, die jetzt Zero-Downtime mir ermöglicht, dann habe ich halt eine Downtime.
Da sollte mein Monitoring-System Bescheid wissen.
Das heißt, ich muss so ein bisschen mich um die Randsysteme auch noch kümmern.
Was ist mit Netzwerkkonfiguration, Firewall und Loadbalancer?
Nicht nur, mein Deployment ist nicht zu Ende, nur weil ich jetzt ein Artefakt auf eine Zielumgebung deployed habe, sondern es ist noch ein bisschen mehr.
Sachen, die auch Entwickler nicht immer so im Blick haben.
Also mehr mit den Ops-Leuten dann auch mal reden, was die denken, was zu so einem Prozess dann noch dazugehört.
Und dann war es das eigentlich.
Und was ich eigentlich mache während diesem ganzen Prozess ist, dass ich eigentlich messen sollte, wie lange hat das gedauert, was hat das gebracht.
Ich sollte eigentlich jederzeit sagen können, welche Anforderung ist jetzt in welcher Stufe.
Weil nur das ist interessant für den Kunden.
Denen interessiert nicht, ob da ein IR-File deployed ist auf einen Application-Server oder ein Docker-Container XY auf einem Kubernetes läuft.
Das ist dem Anwender egal.
Denen interessiert, welche Anforderung ist morgen verfügbar von dem System.
Und da brauche ich eigentlich was, was mir diesen ganzen Tool-Zoo, sage ich mal, am Ende des Tages so ein bisschen zusammenhält.
Das heißt, ich brauche so einen Kleber zwischen den Tools.
Der meine Sachen quasi orchestriert.
Und da muss ich auch darauf achten, dass ich mir da was Vernünftiges hole.
Ich glaube, wir sind uns alle einig, dass Excel da am ungeeignetsten ist dafür.
Aber dummerweise ist Excel der Marktführer in dem Bereich, den wir halt sehr, sehr häufig sehen.
Was versuchen die Leute, wenn sie so einen Prozess managen müssen?
Sie versuchen das mit Excel zu machen.
Und das ist eigentlich das ungeeignetste Werkzeug.
Und das steht auch nicht auf unserem Periodensystem.
Von daher ist das ein Punkt, wo wir sehr häufig mit Kunden reden.
Schmeißt Excel aus diesem Prozess raus.
Schmeißt E-Mails aus diesem Prozess raus.
Schmeißt SharePoints und Wikis aus diesem Prozess raus.
Also alles, was so eine Art Checklisten sind, haben in dem Prozess nichts zu suchen.
Sondern das muss ein Automatismus eigentlich sein.
Und dann hat man eigentlich auch ganz gut einen Blick, wo stehe ich eigentlich in meinem Value Stream?
Und welche Anforderung befindet sich eigentlich gerade in welchem Status?
Und was kann ich meinem Kunden versprechen?
Was kann ich morgen eigentlich davon auf der Produktion?
Weil nur darum geht es.
Nur Sachen, die in Produktion sind, haben am Ende einen Wert produziert.
Und das ist ja auch ein Kerngedanke von DevOps.
Was zum Thema Excel noch.
Also das heißt, wenn etwas oft genutzt wird, das heißt noch lange nicht, dass es auf der Table landet.
Das stimmt, ja.
Wir sagen ja den Kunden immer, wir können über jedes Tool,
das wir diskutieren, was ihr im Einsatz habt.
Das Einzige, worüber wir nicht diskutieren, ist Excel.
Da reden wir über Ablösung.
Ja, das ist halt eine Realität.
Es gibt auch den berühmten State of Agile Report, also in der agilen Projektmanagement.
Was wird am häufigsten genutzt?
Und da ist auch Excel auf Platz 1.
Aber das kann natürlich langfristig nicht die Lösung sein.
Ja, also ich glaube, das war jetzt, ich denke, ein sehr schönes, also beeindruckendes Beispiel.
Ich glaube, wir haben uns den ganzen Values, wie das beispielhaft durch Tools unterstützt werden kann.
Und am Schluss ist ja, wenn man sich das Ganze aus Kundensicht anschaut, es geht ja auch um Time to Market.
Das heisst, wenn der Kunde will, was er hat, ein Requirement, und aus seiner Sicht bekommt er es geliefert.
Klar, die Welt hört nicht dort auf, wenn man dann auch den Betrieb im eigentlichen sieht.
Aber wenn man das so hinkriegt, ohne Brüche,
dass man eigentlich die Time to Market drastisch verkürzen kann,
und auch die Qualität verbessern.
Wenn man das so mit dem Testing, und ich meine, wir arbeiten auch viel mit Kunden zusammen,
und da ist auch ganz klar, das ist ja nicht etwas, was man von heute auf morgen erreichen kann,
sondern es ist ja mehr ein Weg.
Also man will ja irgendwann eine Toolchain, man will Tools automatisieren, man will Tests automatisieren.
Das ist ja eher ein Weg, der sehr lange gehen kann, Jahre auch.
Das ist sicher auch etwas, das ihr seht auf eurer Seite, wenn ihr jetzt Kunden unterstützt.
Absolut, also es ist ein Weg, der gegangen werden muss, aber der muss, und das ist ein wichtiger Punkt,
man muss irgendwann mal anfangen, diesen Weg zu gehen.
Das sehen wir auch bei sehr vielen Kunden, die sagen, ja, wir entwickeln jahrelang erst mal so ein Konzept, wie sowas aussehen kann.
Das funktioniert aus unserer Sicht nicht, sondern man muss eigentlich irgendwann mal anfangen.
Es gibt ein paar einfachere Sachen, wie eine Versionskontrolle, eine vernünftige, sage ich mal, einzuführen.
Das ist auch bei den meisten Kunden schon passiert.
Es gibt ein paar Sachen, die sind bei vielen Kunden relativ schwierig, weil sie immer noch dort sehr arbeitsteilig unterwegs sind
und zum Beispiel immer noch eigene Testabteilungen haben, die nicht mit der Entwicklung so eng verzahnt sind.
Dann wird es mit der Automation ein bisschen schwieriger, aber man muss einfach mal anfangen, diesen Weg zu gehen.
Ich glaube, das ist die wichtige Aussage.
Das ist ein Weg.
Man muss einfach mal den ersten Schritt gehen für diesen Weg und ansonsten werden meine technischen Schulden quasi so hoch,
dass ich den Berg gar nicht mehr besteigen kann.
Ich muss quasi die ersten kleinen Schritte tun und dann ist eigentlich der Weg in die richtige Richtung.
Genau, und wenn es ich nicht mache, dann macht es ein anderer und da hat dann das Business ein Problem,
wenn es die Konkurrenz macht und da schneller ist.
Genau, das ist ein wichtiger Punkt.
Das sehen wir natürlich auch so ein bisschen nach Branche unterschiedlich.
Im E-Commerce spüren den Druck alle, im Bankenversicherungsumfeld fängt es jetzt so gerade an.
Im Automobilumfeld ist natürlich im Moment ein anderes Thema weiter oben, aber auch da wird das das nächste Thema sein.
Wie kriege ich eigentlich auch im Automobil meine Applikationen schneller ausgeliefert und so weiter.
Ich glaube, dass das auf alle Branchen quasi übergreift mit unterschiedlicher Intensität,
aber ich glaube, es kann sich niemand da rausziehen.
Gut, vielen Dank.
Für den Moment habe ich keine weiteren Fragen.
Möchtest du, Matthias, vielleicht noch irgendwas ergänzen?
Ich habe auch keine Ergänzung.
Ich bedanke mich, dass ich bei euch sein durfte und wünsche noch viel Erfolg mit weiteren Podcasts und mit anderen Teilnehmern.
Vielleicht hört man sich ja mal wieder.
Ja, und vielen Dank von unserer Seite für deine Bereitschaft, da mitzumachen.
An diesem Punkt möchte ich noch gerne hinweisen auf den nächsten Podcast, circa in einem Monat.
Da werden wir jemanden von der Direktgruppe interviewen, der wird uns die MetroMap vorstellen.
Das ist eine DevOps-Implementation.
Sicher auch ein sehr entspannendes Thema.
Vielen Dank.
So, dann auch ein Dankeschön von mir in die Runde.
Ich weiß nicht, ob es allen Teilnehmern aufgefallen ist.
Ich war recht still.
Ich hatte technische Probleme.
Insofern hat Alex das super zu Ende geführt mit dem Namen Matthias.
Matthias, von mir auch herzlichen Dank an der Stelle.
Und insofern freue ich mich auf den nächsten Podcast, dann ohne technische Probleme.
Und ja, schönen Abend noch.
Vielen Dank.
Vielen Dank.
Vielen Dank.

Folge 1: Was ist DevOps?

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode erörtern Dierk Söllner und Alex Lichtenberger detailliert die Welt von DevOps, beginnend mit einer Diskussion über die Philosophie und Entwicklung von DevOps, den Unterschieden zu anderen Frameworks wie ITIL und Scrum und den spezifischen Herausforderungen in der Implementierung. Sie gehen auf verschiedene Praktiken wie Continuous Integration und Delivery, Kanban, Value Stream Mapping und DevSecOps ein, betonen die Bedeutung von Kultur und Kommunikation in der DevOps-Praxis und diskutieren, wie DevOps in verschiedenen Unternehmensgrößen skalierbar ist. Der Podcast schließt mit Überlegungen zur Integration von DevOps in traditionellere IT-Strukturen und einem Ausblick auf zukünftige Episoden.

Inhalt

  • Einführung in DevOps
    • Was ist DevOps und wie hat es sich entwickelt?
    • Unterschiede zu anderen Frameworks wie ITIL und Scrum.
  • DevOps-Philosophie und Praktiken
    • Die „Three Ways“ des Feedbacks.
    • Bedeutung von Kultur und Kommunikation.
  • Umsetzung von DevOps in Unternehmen
    • Herausforderungen und Ansätze für verschiedene Unternehmensgrößen.
    • Beispiele für DevOps-Praktiken: Continuous Integration und Delivery, Kanban, Value Stream Mapping.
  • Technologische Aspekte in DevOps
    • Rolle von Automatisierung, ChatOps und künstlicher Intelligenz.
    • Integration von Sicherheit in DevOps (DevSecOps).
  • DevOps in traditionellen IT-Strukturen
    • Anpassungen und Skalierung von DevOps-Methoden.
  • Ausblick auf zukünftige Episoden und Kontaktinformationen

Transkript (automatisiert, daher keine Gewähr 🙂 )

Hallo und herzlich willkommen zum Podcast
DevOps auf die Ohren und ins Hören.
Ich begrüße Sie zu der ersten Folge
und wenn ich sage, ich begrüße Sie,
begrüße ich alle Zuhörer
und ich begrüsse natürlich auch Alex Lichtenberger,
mit dem ich zusammen diesen Podcast erstelle und bespreche.
Insofern würde ich sagen, Alex, stell dich doch mal ganz kurz vor.
Vielen Dank, Dirk, und willkommen von meiner Seite.
Mein Name ist Alex Lichtenberger.
Ich bin seit rund 20 Jahren in der IT,
damals begonnen in der Softwareentwicklung bei IBM.
Wir haben damals schon iterativ, adaptiv entwickelt,
um nicht das Wort agil zu nennen.
Ich bin dann später sehr stark im Operation-Umfeld gewesen,
auch im Outsourcing.
Und etwas, das ich dann immer gesehen habe, ist,
dass so Dev und Ops, das sind schon zwei verschiedene Welten.
Und als ich mich vor ein paar Jahren beschäftigt habe mit DevOps,
habe ich gesehen, dass das eine sehr gute Lösung bietet,
um dieser Problematik zu begegnen.
Deshalb würde ich mich als DevOps-Enthusiasten bezeichnen.
Und ich arbeite…
Ich arbeite als Berater zurzeit,
auch als Trainer im Bereich DevOps, Agile und Scrum.
Jetzt mal von meiner Seite.
Vielleicht du, Dirk, möchtest du dich auch kurz vorstellen?
Ja, Dirk Söllner, mein Name.
Ich bin ähnlich wie der Alex schon etwas länger im Geschäft.
Ich bin sogar 25 Jahre im Geschäft, habe gestartet,
bin gestartet als Berater für klassische Themen wie ERP-Software,
Controlling-Applikationen und bin dann später zu dem Thema IT gekommen,
zum Thema IT-Service-Management und bin heute Berater, Trainer und Coach
für IT-Service-Management und agile Organisationsentwicklung.
Das ist genau das, was auch Alex schon bei sich angesprochen hat.
Wenn ich mir die klassische IT-Welt angucke,
die klassische IT-Service-Management-Welt,
bin ich so vor vier, fünf Jahren auch auf das Thema Scrum und Agile gestoßen,
habe das für mich als Geschäftsmodell entdeckt, weiterentwickelt
und bin eben dann heute auch als Trainer aktiv, bin auch als DevOps-Trainer aktiv.
Seit drei, vier Jahren bin ich wirklich sehr stark als agiler Coach unterwegs
und helfe da eben Unternehmen und einzelnen Personen,
das ganze Thema Agilität für sich zu entdecken und weiterzuentwickeln.
Das heißt, bei mir ist es eben genauso wie bei dir, Alex, Enthusiasmus,
was das Thema Agilität angeht, aber natürlich mit einem klassischen Background,
mit einem Background-IT-Betrieb.
Danke, spannend.
Das ist ja jetzt das erste Mal, dass wir diesen Podcast machen.
Eine erste Frage, die sich aufdrängt, ist ja, wieso überhaupt so ein DevOps-Podcast?
Ich glaube, es war ja du, Dirk, der die Idee hatte.
Vielleicht kannst du da ein bisschen ausführen.
Jawohl. Ja, ich hatte die Idee, weil ich mir gesagt habe,
Blogbeiträge schreiben, Vorträge halten, Veröffentlichungen dazu schreiben,
das ist sicherlich eine interessante Sache, aber es fehlt noch irgendwas Neues.
Und da ich selber gerne Podcasts höre und auch den einen oder anderen recht gut finde,
habe ich mir überlegt, Mensch, das wäre auch mal ein Thema,
wo ich mich einer neuen Technik widmen kann und habe dann auch geschaut,
gibt es deutschsprachige DevOps-Podcasts, die mir gefallen, die mich ansprechen.
Und ja, ich habe keinen gefunden.
Und dann habe ich für mich gesagt, so, jetzt musst du einen Podcast machen,
das ist was Neues, kannst du deine Freude an diesem Thema eben auch mit rüberbringen.
Und habe dann überlegt, mit wem mache ich das am besten zusammen
und habe dann eigentlich sofort auch an die Schweiz gedacht.
Das ist natürlich thematisch was ganz Schönes, da mit dir, Alex, das zusammen zu machen.
Außerdem finde ich es sehr interessant, wenn wir nicht nur so eine hochdeutsche Sprache haben,
wie ich habe, sondern dass wir auch so ein bisschen
schweizerisch da reinbringen.
Also insofern, das Ziel, was ich dabei verfolge, und das siehst du ja genauso,
dass wir das versuchen, das Thema DevOps ein bisschen locker rüberzubringen,
authentisch rüberzubringen und auch ansprechend gestalten.
Ja, und ansprechend heisst, man kann einfach auch mal reden dazu,
man muss nicht immer nur schreiben.
Wie sieht es bei dir aus? Warum machst du mit?
Ja gut, für mich ist Podcasts so wie ein neuer Kanal, der für mich persönlich sehr spannend klingt.
Ich bin bereits recht aktiv in der DevOps-Szene, schreibe viele Blogs,
auch war letztens an den DevOps-Days dort in Zürich, habe einen kurzen Speech gehalten.
Und Podcasts, ich habe es früher persönlich auch schon oft genutzt,
wenn man zum Beispiel im Auto sitzt und man kann halt nicht lesen während dem Autofahren,
ausser man hat ein selbstfahrendes Auto, aber da ist der Podcast eigentlich ein idealer Kanal.
Da dachte ich ja, mache ich mit.
So, das heisst, wir beide gestalten diesen Podcast.
Von der Idee her werden wir natürlich das nicht nur alleine machen,
wir werden uns Gäste dazu holen, wir werden uns thematisch natürlich breit aufstellen.
Aber die Frage ist ja überhaupt, was ist DevOps überhaupt?
Das sollte man als allererstes klären, bevor man überhaupt in so eine DevOps-Podcast-Folge einsteigt.
Alex, was ist DevOps?
Ja, die Frage tönt einfach, aber die Antwort ist gar nicht so trivial,
weil DevOps ist ja kein Standard, kein Framework.
Es ist nicht wie ETIL oder Scrum, wo man auch im Buch nachlesen kann,
kodifiziert, Regeln etc., sondern DevOps ist mehr eine Bewegung,
wo sich viele Dinge verändern zurzeit.
Und vermutlich ist es auch die falsche Frage, um zu starten, nicht was ist DevOps,
sondern eher, wieso ist DevOps überhaupt entstanden und ein Thema geworden.
Und diese Frage nach dem Wieso und sich auch im Klaren zu werden,
was ist Ihr Wieso, das Wieso Ihrer Firma, das kann sehr individuell sein.
Aber in der Regel gibt es so zwei Wieso, warum DevOps.
Das eine Warum, das hat wirklich mit Digitalisierung zu tun.
Wenn man da ein bisschen zurückschraubt in der Zeit,
sagen wir so 90er Jahre, wenn man schaut, wie Projekte gemacht wurden,
das war damals noch klassisch, Wasserfall-Vorgehen.
Man hat halt auch sehr lange gebraucht für Projekte,
also ich spreche jetzt auch von Software-Projekten.
Was dann plötzlich gekommen ist, ist auch so IT als Innovationstreiber.
Also ich spreche jetzt nicht von Business IT allein, sondern mehr IT im Business.
Also beispielsweise bei uns in der Schweiz,
die Banken, die haben angefangen, E-Banking-Lösungen zu bauen.
Und das ist dann halt zwei, drei Jahre gegangen, bis mal was live gegangen ist.
Und jetzt könnte man sagen, ja gut, das ist kein Problem.
Zwei, drei Jahre, that’s how it is.
Aber was, wenn plötzlich der Konkurrent, die andere Bank,
die gleiche Lösung in einem halben Jahr zustande bringt.
Dann wird das zum echten Problem für das Business, zum Wettbewerbsnachteil.
Was dann eben passiert ist, und das ist einfach passiert,
ist, dass die Software-Entwickler, die haben angefangen, auf agil umzustellen.
Also vor allem dort, wo halt auch die Antworten nicht von Anfang an klar waren.
Man hat in Sprints gearbeitet, beispielsweise nach Scrum Feedback abgeholt.
Weil die Idee, dass man da alle zwei Wochen
schon ein Potentially Releasable Increment hat.
Aber das Problem war halt immer noch, was nützt das Ganze,
wenn eigentlich das ganze System nicht erlaubt,
dass man beispielsweise alle zwei Wochen mit was live geht.
Also ein bisschen das Problem war so schon ein bisschen Operation.
Und der nächste logische Schritt, und das ist dann halt auch einfach passiert,
und das waren dann nicht so die grossen Firmen, die damit angefangen haben,
sondern mehr die Startups zu jener Zeit, so wie Google, Netflix.
Die haben angefangen mit Continuous Delivery.
Continuous Delivery heisst, that software is always in a releasable state.
Das heisst, nach jedem, wenn eine Anforderung implementiert wird, Check-in,
dann durchläuft man halt alle Tests, vorzugsweise automatisiert,
dass man jederzeit live gehen könnte.
Also plötzlich waren grosse Firmen konfrontiert mit diesen kleinen Startups,
die sehr schnell Features am Markt testen konnten,
mit Features live gehen konnten.
Und das waren dann plötzlich Konkurrenten.
Also your next competitor could be a startup with an app.
Und das betrifft inzwischen fast jede Branche.
Das ist so das eine Warum.
Und es gibt noch ein anderes Warum.
Das hat mit dieser, vielleicht haben Sie schon davon gehört,
Dev und Ops, also Entwicklung und Operation, und dazwischen die Wall of Confusion.
Das ist halt schon so, wenn man die Entwickler anschaut, die sind getrieben von Change.
Was wollen die? Die wollen in Projekten arbeiten, Änderungen umsetzen.
Während Operation hat eine ganz andere Motivation.
Die wollen Stabilität.
Jeder, der mal in Operation gearbeitet hat, weiss genau, was ich meine.
Und das ist dann der klassische Zielkonflikt.
Also man hat, Dev will Flexibilität, Ops will Stabilität.
Und was dann verloren geht manchmal, ist so die gemeinsame Sicht auf die Services.
Weil das will ja beides.
Und man hat dann angefangen, Value Streams zu identifizieren, gemischte Teams zu bilden, um diese,
und das war wahnsinnig erfolgreich.
Und das dann halt unter dem Label DevOps.
Das sind so diese zwei Warums.
Das eine Digitalisierung, so wirklich DevOps als Enabler für die Innovation.
Das andere, diese Dev und Ops-Geschichte mit der Wall of Confusion,
wo sich auch die meisten Leute in der IT können sich mit der nicht zufriedenstellenden Situation identifizieren.
Das ist halt die Motivation, wie es entstanden ist.
So, mal das Warum.
Und jetzt zur Frage, was ist DevOps, ist vielleicht, weil ich habe jetzt ziemlich viel gesprochen,
vielleicht die Frage an dich, Dirk, weil du kennst dich auch bestens aus im Bereich DevOps.
Was ist denn so für dich denn die Philosophie von DevOps, nachdem wir jetzt das Warum verstanden haben?
Ja, ich würde gerne, bevor ich auf diese Frage eingehe, nochmal einen weiteren Punkt ergänzen.
Was du gesagt hast, diese beiden Warums, stimme ich natürlich vollkommen zu.
Was ich glaube, was auch noch ein wichtiger Punkt ist, ist das Thema Automation,
ist das ganze Thema Software-Unterstützung.
Das, was so Firmen wie Netflix, Spotify und so weiter, du hast ja ein paar Beispiele genannt,
was die einfach nach vorne getrieben hat, ist natürlich auch das Thema das, was wir unter DevOps verstehen,
Continuous Delivery und so weiter.
Das hängt eng auch mit Software zusammen.
Natürlich wollen wir jetzt hier keine Software-Werbung machen, keine Software-Produkte vorstellen.
Wir werden sicherlich das eine oder andere nochmal in späteren Podcast-Folgen behandeln.
Aber für mich ist immer ein weiterer Punkt, dass wir dort auch einen Technologietreiber haben,
dass wir Software haben, die das ganze Thema unterstützt und damit auch eben dazu beiträgt,
dass wir überhaupt über DevOps reden.
Denn das, was wir eben als Warum haben, das ist natürlich etwas, was nicht unbedingt im ersten Moment
für große Firmen wie Automobilindustrie, wie Versicherungsbranche wirkt,
weil die natürlich sagen, Spotify ist nicht mein Konkurrent, Amazon ist nicht mein Konkurrent, nicht mein Mitbewerber.
Also es gibt noch ein paar Gründe mehr, das wollte ich vielleicht nochmal ganz kurz ergänzen.
Und wenn ich da eben schon so ein paar Namen genannt habe, große Firmen, dann sind das auch die Firmen,
die genau mit dem, was du vorhin gesagt hast, aus meiner Sicht manchmal ein Problem haben.
Wenn ich in den Trainings bin und dann erzähle, dass hinter DevOps kein Framework steckt,
dass da kein Eigner hinter steckt, der eine Deutungshoheit hat, sondern dass es eigentlich eine Bewegung ist,
so wie du das ja eben auch gesagt hast, dann kommen schon die ersten Fragezeichen.
Warum steht denn der da vorne und will mir als Trainer was erzählen? Ist aber gar kein Framework.
Und insofern würde ich jetzt genau auf den Punkt überleiten, den du eben angesprochen hast.
Gibt es denn überhaupt eine DevOps-Definition? Was ist DevOps?
Und ich sehe das ja auch als eine Philosophie, das hast du ja selber auch schon angedeutet.
Und unser beliebter Rob England hat sich dem Thema ja auch mal gewidmet.
Er hat eine wunderschöne Webseite dazu gemacht, weil er wohl mal gefragt wurde von einem seiner Leser,
er sollte doch bitte mal eine Definition von DevOps geben.
Und was ich interessant finde, ist, dass er doch einige Punkte auf seinem Blogbeitrag eingestellt hat, wo ich sagen würde, interessant.
Also für uns, für mich ist das,
das ist auf jeden Fall eine Philosophie. Und der Rob England sagt zum Beispiel,
dass einer der Begründer von DevOps, falls man überhaupt von so etwas sprechen kann, der Patrick Dubois,
dass der zum Beispiel überhaupt nichts zu einer Definition sagt.
Das heißt, wie gesagt, einer der Begründer, der Initiatoren von einer DevOps-Bewegung, der sagt dazu gar nichts.
Und wenn man dann beispielsweise mal bei Wikipedia reinschaut, dann finde ich, kommt man genau schon auf den ersten falschen Weg.
Auf Wikipedia steht ja zum Beispiel, dass das ein Zusammenschluss ist, eine Verballordnung von dem Begriff Software Development.
Und Wikipedia sagt, DevOps is a software development method that stresses communication, collaboration and integration between software developers and information technology professionals.
Da sage ich mal, es ist nicht nur eine Softwareentwicklungsmethode, es ist mehr.
Es ist eben die Philosophie. Und wenn ich sage Philosophie, heißt das für mich, dass ich dort in den Betrieb eigentlich auch die agilen Gedanken hineinbringe.
Dass ich das, was wir beide unter Agilität verstehen, was wir auch da so interessant daran finden, das ist etwas, was wir mit DevOps eigentlich in den Betrieb einbringen.
Ich denke, was sagst du? Haben wir die Philosophie halbwegs erklärt oder sollten wir noch ein bisschen was dazu aufhören?
Ja, absolut. Also ich schließe mich da an.
Das ist sehr gut zusammengefasst. Da habe ich ergänzt.
Aber warum machen wir dann überhaupt DevOps? Was sind denn die Ziele von DevOps?
Genau, die Ziele. Du hast ja auch gesagt, die Frage, was ist DevOps? Dass es auch eben mehrere Definitionen gibt oder sogar Leute, die sich da gar nicht rauslassen und sagen, es gibt keine definitive Aussage dazu.
So ja, Ziele. Dirk, was sind denn die, mal ganz kurz zusammengefasst, was sind die Ziele von DevOps?
Also aus meiner Sicht, wenn ich DevOps als eine Philosophie betrachte, würde ich sagen, wir wollen schneller und besser werden.
Wobei ich dieses schneller eigentlich so ein bisschen in Klammern setzen möchte. Also eigentlich heisst es für mich nur besser werden.
Wenn ich an meine Scrum Projekte denke, dann sind die großartig.
Ich glaube, dass die Kunden, die die Ergebnisse dieser Scrum Teams bekommen, häufig erfreut und für die ist es quasi vollkommen ausreichend, bessere Lösungen zu bekommen.
Die meisten Kunden, die in Fachbereichen sind natürlich auch daran interessiert, etwas schneller zu bekommen.
Aber wie gesagt, der Hauptfokus, der Hauptvorteil sehen sie als von Scrum und damit in der Folge auch von DevOps, dass sie bessere Ergebnisse bekommen.
Das heisst, für mich ist ein ganz wichtiger Punkt.
Dass wir mit DevOps, wenn wir eine Organisation nach DevOps-Philosophie aufbauen, dass wir bessere Ergebnisse liefern.
Und bessere Ergebnisse heisst, dass sie natürlich dann auch in der Folge schneller werden, weil wir keine Nacharbeiten haben und so weiter.
Aber wie gesagt, ganz klar für mich, bessere Ergebnisse, damit wir besser auf die Kundenanforderungen reagieren können und die dort besser umsetzen können.
Passt das für dich auch, Alex?
Ja, ich finde das spannend ist ja, dass diese schneller und wie du sagst, vor allem schneller,
besser, das wird ja klassischerweise als Zielkonflikt angeschaut.
Also wenn ich schneller werde, ich was schnellere, kürzere Time-to-Market, dann leidet die Qualität darunter und vice versa.
So, DevOps versucht auch ein bisschen diesen Zielkonflikt aufzulösen, in dem dann halt, sehen wir dann später, Automatisierung etc.
Und auch aus der Agilität heraus, es geht ja nicht, schneller stimme ich dir zu, ist vielleicht ein bisschen falsch, sondern was ich eben will, ist,
wenn ich mir am Anfang noch nicht sicher bin, was die Anforderungen sind, ich will Feedback vom Kunden, ob ich auf dem richtigen Weg bin.
Also fail-offen, fail-early, aber ich will echtes Feedback.
Das heisst, ich will halt das so bauen, wie es dann auch in der Produktion ausschauen würde.
Das so als Ergänzung.
Jetzt haben wir ja über die Ziele auch gesprochen, was auch noch spannend wäre mal generell.
Was sind denn so Handelsteine?
Was sind so Handlungsfelder?
Also wenn ich jetzt diese Ziele erreichen will, was sind so die verschiedenen Dimensionen, Handlungsfelder, in denen ich mich auf dem Weg dorthin bewegen kann?
Dirk?
Ja, also ich persönlich sehe dort fünf Handlungsfelder.
Und wenn ich sage Handlungsfelder, meine ich damit, das sind Gebiete, wo Unternehmen etwas tun müssen oder auch tun können, um sich in Richtung einer DevOps-Organisation zu entwickeln.
Und ich habe gesagt, DevOps ist kein Framework, es ist eine Philosophie.
Das heisst, ich kann nicht wie bei ITIL oder Scrum irgendwo mir ein Buch kaufen, sei es 17 Seiten Scrum Guide, sei es 2000 Seiten ITIL und dann sagen, ich mache das.
Nein, für mich ist das eben wirklich etwas, wo ich Organisationsentwicklung betreiben muss.
Und diese fünf Handlungsfelder, von denen ich eben gesprochen habe, das ist für mich das Wichtigste ist zuerst die Kultur.
Ich muss eine Kultur schaffen dafür und wenn man sich da in den DevOps-Blocks mal umtut, dann ist das ein Punkt, der sich eigentlich überall durchzieht.
Das heisst, selbst die Automatisierungsurus, die Automatisierung als einen ganz wichtigen Punkt von DevOps ansprechen, selbst die sagen, man braucht eine entsprechende Kultur.
Und das ist genau das, was letzten Endes, denke ich, auch die Arbeit ist, wenn ich über DevOps nachdenke, dass ich einfach eine Kultur schaffe für DevOps.
Zweiter Punkt wäre Organisation.
Ich denke, es reicht nicht einfach nur zu sagen, wir machen jetzt DevOps und wir haben vielleicht ein paar Scrum Teams, die machen den Betrieb jetzt mit.
Also, ich muss natürlich ein bisschen was organisieren.
Und da habe ich natürlich auch den Punkt, dass bei der Organisation ich auch mir überlegen muss, wie gestalte ich eine Organisation.
Dann dritter Punkt die Prozesse.
Ich habe natürlich in einem größeren Unternehmen habe ich das schon.
IT-Service-Management-Prozesse und die prallen natürlich jetzt mit ihrer
Stabilität auf die agilen Softwareentwickler und umgekehrt
natürlich. Insofern muss ich mir auch Gedanken machen über die Prozesse.
Das heißt, diese drei Themen sind so ein bisschen was Allgemeines,
sind etwas Organisatorisches. Und dann ein ganz wichtiger Punkt,
das Thema Automation. Ich habe es vorhin schon angesprochen. Ich glaube,
dass das eben ein ganz wichtiger Punkt ist. Die IT hat die letzten
Zehnte damit verbracht, andere Bereiche zu automatisieren,
Abläufe zu automatisieren. Jetzt ist die IT selbst
dran. Jetzt muss die IT ran und die eigenen Abläufe automatisieren.
Das heißt, das wäre für mich das vierte Handlungsfeld, wo man etwas tun muss,
um in Richtung DevOps zu gehen. Und dann mein Lieblingsthema,
die wir nicht kennen, ich weise immer wieder darauf hin, kontinuierliche
Verbesserung. Das ist für mich eigentlich das A und O, weil ich eben
sehr viele Implementierungen von IT-Service-Management gesehen habe,
aber auch von Scrum, die einfach für sich sagen, wir haben einen Status erreicht
und da bleiben wir jetzt stehen. Und ich glaube, dass man mit kleinen Schritten,
also mit diesem berühmten iterativen, inkrementellen Vorgehen,
dass man dort auch die DevOps-Organisation bauen kann,
sprich kontinuierliche Verbesserung von Anfang an aufsetzen. Und natürlich
hängt die kontinuierliche Verbesserung zusammen mit dem Thema Automation.
Das ist ein sehr wichtiger Punkt. Das ist ein sehr wichtiger Punkt.
Das ist ein sehr wichtiger Punkt. Das ist ein sehr wichtiger Punkt. Das ist ein sehr wichtiger Punkt.
Und das, was ich messen kann, kann mich auch beeinflussen.
Ja, also ich denke, du hast zuerst angesprochen Kultur.
Und ich denke auch, das ist die wichtigste Voraussetzung, die richtige
Kultur zu haben, sich dorthin zu bewegen. Es gibt auch den schönen Spruch
Culture eats strategy for breakfast. Und das stimmt wirklich.
Man kann die schönsten Pläne haben oder das Management kann
die schönsten Pläne haben. Wenn die Leute das nicht wollen,
dann kann man es gerade vergessen. Und ganz praktisch
heisst das ja dann auch, wenn, das sind dann vor allem halt die
Ex-Operation-Leute, wenn die sich nicht mit der agilen Idee
anfreunden können, dann wird es schwierig, sich Richtung
DevOps zu bewegen. Also man muss sich zuerst mal den Kulturaspekt
den anschauen. Das sehe ich schon auch als
die wichtigste Voraussetzung.
Ja, vielen Dank, Dirk.
Du hast gesprochen über die Ziele von DevOps, schneller, besser, die
Handlungsfelder, die Werte.
Jetzt hört man ja auch oft über diese sogenannten Three Ways.
Das sind drei unterschiedliche Philosophien, wie die Ziele von DevOps
angegangen werden.
Die wurden ja das erste Mal beschrieben in dem berühmten Buch von
Jin Kim, The Phoenix Project, ein Buch, das ich sehr empfehlen kann.
Dirk, willst du uns diese Three Ways vielleicht mal ein bisschen näher
bringen?
Ja, gerne.
Vielleicht, bevor ich auf diese drei Wege, drei Prinzipien eingehe.
Das Buch, was du angesprochen hast, ist für dich auch sehr, sehr lesenswert.
Interessant finde ich, wenn ich das meinen IT-Service-Management-Kollegen empfehle oder
mit denen ich darüber austausche, über meine Freude an DevOps.
Die meisten, die das Buch lesen, die ertappen sich, dass sie sagen, stimmt, habe ich auch
erlebt.
Also insofern, wer das Buch noch nicht gelesen hat.
Das ist sehr interessant.
Sehr nett, sehr locker geschrieben, lässt sich eben gut lesen, ist vielleicht nicht
eine Urlaubslektüre, aber zumindest eine Lektüre, die man sich gerne so am Wochenende
mal antun könnte.
Und wie gesagt, viele Leute, die ich mit dir darüber spreche, die sagen, ja, das habe
ich genauso erlebt, das ist bei uns auch so.
Also insofern, das kann man einfach nur empfehlen.
Ja, Jin Kim, hast du eben gesagt, der hat drei Wege für Feedback aufgezeigt.
Three-Ways-Principles, drei Prinzipien, wie Feedback laufen kann.
Das Feedback brauchen wir natürlich, wenn wir uns verbessern wollen.
Und wenn wir Dinge verbessern wollen, müssen wir Feedback-Schleifen einbauen.
Und seine drei Wege, im Prinzip der einfachste, der erste Weg ist der, der auch noch auf einer
Silo-Organisation aufbaut.
Der sagt, wenn ich eine Silo-Organisation habe, dann habe ich Projekte, ich habe eine Entwicklung
und die Entwicklung hat einen ganz einfachen Weg.
In Richtung Ops, das heisst, ich habe eigentlich nur einen Weg, wie Informationen laufen.
Wir haben eben noch nicht mal ein Feedback.
Es gibt nur Informationen von dem Bereich Development, von der Entwicklung an den Betrieb,
an Operations.
Und da gibt es den zweiten Weg, Alex, aber ich denke, den kannst du auch erzählen.
Ja, der erste ist ja recht offensichtlich mal.
Da geht es ja darum, wie du gesagt hast, Dirk, wenn man sich jetzt praktisch vorstellt, in
der Entwicklung, man definiert Anforderungen, es wird entwickelt, Check-in, verschiedene
Tests und dann geht es Richtung Deployment bis hin in die Produktion, so First Way.
Was der Second Way zusätzlich reinbringt, ist Feedback-Loops und zwar nicht einfach
Feedback, sondern schnelle, kurze Feedback-Loops, beispielsweise automatisiertes Testing.
In einem agilen Umfeld.
Wenn ich was mache, ich will wissen, ob ich das Richtige mache und deshalb brauche ich
diese Feedback-Loops.
Also idealerweise, so der Traum auch aus dem Continuous Integration Delivery, ich check
Code ein, ich bekomme sofort Feedback aus den automatisierten Tests, ob ich das Richtige
mache.
Wenn nicht, stop the line and go back, eine Philosophie, die sehr alt ist, die aus dem
Lean herauskommt.
Entstanden.
Es gibt viele andere Beispiele für Feedback-Loops, beispielsweise das klassische Problem-Management,
man hat wiederkehrende Störungen, man will jetzt mal die Ursache herausfinden, dauerhaft
beheben, Feedback nach links geben, Monitoring ist auch, Continuous Monitoring ist ein gutes
Beispiel.
Das sind so diese Feedback-Loops, der Second Way, man versucht, das überall reinzubringen.
Und so schlussendlich auch die Qualität zu erhöhen.
Und dann gibt es ja noch den Third Way, soll ich kurz erklären oder willst du?
Also Third Way geht dann wieder in eine ganz andere Richtung, das hat mit kontinuierlichem
Experimentieren und Lernen zu tun, das hat auch mit Fehlerkultur zu tun, weil Fehler
passieren, das ist absolut menschlich.
Das Problem ist, wenn man aus Fehlern nicht lernt, dann ist es einfach nur ein Fehler.
Also erstens hier eine Kultur aufbauen, der kontinuierlichen Verbesserung und andererseits
auch Experimente nutzen, um zu lernen.
Also ich mache hier das Beispiel von Google, bei Google ist alles ein Experiment, beispielsweise
Google Maps hat als Experiment, ist das entstanden, hatte einer eine Idee, man hat das implementiert,
geschaut, man weiss halt nicht zum Vornherein, funktioniert das oder nicht.
Und das ist dann wirklich auch ein Mindset-Shift, weil oft wird zu Tode argumentiert, ist jetzt
Lösung A oder B richtig, soll ich zwei oder drei Fenster haben auf meinem kleinen Client?
Und die Sache ist die, keine Ahnung, niemand kann das wissen.
Beides ausprobieren, Experiment machen, Impact messen, Feedback, das ist das, was wir hier
machen.
Und das, was funktioniert, das behält man.
Kontinuierliches Experimentieren und Lernen, das ist so der third way.
Und dann eben auch den Leuten die Zeit geben, Experimente einzugehen.
Es gibt Firmen, auch in der Schweiz, die machen dann zum Beispiel so Hackathons oder sie geben
den Leuten 10% der Zeit, wo sie eben so Experimente durchführen können und ihre Hypothesen testen.
Das wäre so von meiner Seite so der third way.
Ja, was ich da interessant finde ist, aus meiner Sicht, wenn man diese drei Wege mal
sozusagen nebeneinander stellt, dann brauche ich für den zweiten und dritten Weg eine
andere Organisation, dann brauche ich autonome Teams, brauche Teams, die das, was du eben
aufgeführt hast, für den zweiten und dritten Weg, die das quasi im Team umsetzen können.
Denn wenn ich natürlich lange Rückmeldezyklen habe.
Ich muss über irgendwelche Anzeichen gehen.
Ich muss über irgendwelche Anzeichen gehen.
Ich muss über irgendwelche Anzeichen gehen.
Ich muss über irgendwelche Gremien gehen.
Ich muss über Abteilungen gehen.
Ich muss Projektwege, Reportingwege einhalten.
Dann funktioniert das alles nicht.
Das heißt, das Ziel ist ja nicht nur diese Zyklen einzubauen, das Feedback einzubauen,
sondern auch schnell einzubauen.
Du hast das eben gesagt.
Schnell heißt nicht zwei Wochen.
Schnell heißt im Extremfall stündlich oder heißt zumindest sehr, sehr zeitnah zu dem
Start eines möglichen Experiments.
Das heißt ganz.
klar, für mich, was ich interessant finde und dann auch als Herausforderung
für die Unternehmen sehe, der Weg 1 auf 2
oder 1 auf 3 bedeutet eine Veränderung der Organisation.
Ich muss meine Organisation anders aufbauen und
das, glaube ich, ist noch ein wichtiger Punkt, den wir behandeln sollten.
Wir reden immer davon Netflix, wir reden von Amazon, wir
reden von Google, ganz tolle Firmen. Die Frage ist ja, können
wir das, was diese Firmen praktizieren, was wir hier auch so schön als
DevOps darstellen, können wir das einfach so in die deutschen
Unternehmen bringen? Wenn wir uns ein Mittelständler anschauen, wenn wir uns große Unternehmen
angucken, kann man das einfach so übertragen? Wie können
diese Firmen das, was wir so erzählen, eigentlich auch nutzen und
zufrieden bringen?
Ja, das Ganze hat ja, wie du sagst, angefangen mit diesen sogenannten
Unicorns. Für die ist das
eine Notwendigkeit, DevOps zu machen und
die grossen Firmen oder diese sogenannten Horses, sagt man
im DevOps-Slang, Enterprise-IT, wollen das nun
adaptieren. Und es ist ja nicht so, dass man DevOps
machen kann. Was man aber beispielsweise machen kann und
das ist auch schon recht etabliert in vielen grösseren Firmen ist
beispielsweise all diese Continuuses, Continuous Integration,
Delivery, Deployment.
Es gibt auch Praktiken wie beispielsweise Kanban, Value Stream
Mapping. Wenn wir das jetzt alles versuchen würden, ein bisschen auf die Reihe
zu bringen, nicht so anknüpfen nach, was du gesagt hast, Dirk,
mit den Three Ways, vor allem der First Way, weil was
ein bisschen verloren gegangen ist in den grösseren Firmen, ist die Sicht
des Value Streams. Man hat stark funktionale
Organisationen, man hat viele Handoffs, man hat
überall Prozessmanager, aber
wer ist eigentlich noch irgendjemand, wo der Value Stream
für die einzelnen Produkte und Services ist? Also von der Anforderung
bis hin ins Deployment. Also ein erster
Schritt ist mal, dass man sich vielleicht irgendeinen Service
rauspickt und man macht beispielsweise ein Value Stream Mapping.
Man identifiziert mit den Leuten, die da involviert sind,
nicht zuerst mal, wie der Prozess
theoretisch ausschauen soll,
sondern wie es im Moment läuft. Die Japaner sagen dem auch so
Gemba, also Gemba heisst dort, wo es passiert, Gemba Walk.
Man schaut durch, wie wird zur Zeit gearbeitet
und dann, wenn man dieses Bild hat, versucht man die
Bottlenecks oder Verschwendung auch zu identifizieren. Das kommt aus
dem Lean raus. Man sieht dann beispielsweise, dass man wahnsinnig
viel Zeit braucht für das Deployment oder dass man
sehr viel manuelle Arbeit, alle Tests manuell
und wenn man das sieht, dann denkt man an schrittweise Verbesserungspotenzial
zu identifizieren. Dirk, du hast ja gesagt, du bist ein Fan
von kontinuierlicher Verbesserung. Genau die Philosophie
kommt da rein. Also aus dem Value Stream Mapping,
das ist jetzt ein Beispiel von einer DevOps Praxis.
Wir haben zur Zeit ein Projekt, wo wir das beim Kunden machen
und wo wir kontinuierlich versuchen, schneller und besser
zu werden. Das ist mal so eine Möglichkeit. Eine andere
ist, das geht dann eigentlich so Richtung Kultur, weil
die Leute sind ja oft skeptisch gegenüber agiler
Vorgehensweise, DevOps, vor allem aus dem Bereich
Infrastruktur. Die haben ja oft auch ein Leben lang gekämpft gegen die Agilen
und da kann zum Beispiel ein erster Schritt sein,
in einem Team seine Arbeit zu organisieren mit Kamban.
Kamban ist ein einfaches Tool.
Viele von euch haben sicher auch schon diese Boards, Kamban Boards gesehen,
To Do, Doing, Done, wo man eben entlang des Value Stream
versucht, seine Arbeit zu visualisieren,
regelmässig zusammenzukommen, Fortschritt
zu diskutieren, den Work in Progress zu
managen. So ein erster Schritt. Was dann natürlich das andere
das ist ein riesen Thema, weil so der Kern von DevOps ist
für viele schon das Continuous Delivery.
Der Anfang von Continuous Delivery ist auch zuerst mal
sich über den Value Stream im Klaren zu werden. Also ganz simpel, wenn
Sie jetzt an eine Ihrer Applikationen denken,
es muss nicht eine Applikation sein, aber von der Anforderung
übers Bauen, Testing bis Deployment sich zu sehen,
wie es im Moment läuft und dann sich Richtung Continuous Integration
and Delivery zu bewegen. Also angefangen mit Continuous Integration,
das heisst, es ist eigentlich ein alter Zopf, Continuous Integration.
Das ist die Praxis, dass man mindestens auf täglicher
Basis Code eincheckt, in ein gemeinsames
Repository und ein paar automatisierte Tests läuft.
Das Ganze wird dann erweitert durch Continuous Delivery,
was dann heisst, dass man versucht konsequent diese
Value Chain, auch die Tests vor allem, die stattfinden,
die zu automatisieren und auch zu erweitern,
weil klassisch, wenn man schaut aus der Entwicklung, ein Problem ist ja
der Entwickler, der konzentriert sich immer auf Features,
funktionale Anforderungen. DevOps heisst jetzt,
dass man nicht funktionale Anforderungen,
sondern funktionale Anforderungen einbezieht,
dass man auch Tests dafür, beispielsweise Performance Tests,
Security Tests, man identifiziert
die, man automatisiert
die und macht sie Teil dieser Continuous Delivery
Pipeline. Ganz praktisch gesagt, nach jedem Check-In
vom Entwickler werden auch die Tests automatisch durchlaufen,
sodass man Software dann theoretisch immer in einem
Releasable State hat. Und das klingt jetzt, wenn man sich
im Legacy-Umfeld bewegt, dann klingt das natürlich nach
Mission Impossible, weil niemand hat gesagt, es ist einfach,
aber es ist eher ein Weg, den man beschreiten muss,
hier automatisieren, dort automatisieren, bis hin an so eine
Continuous Delivery Pipeline und eine Tool Chain.
Das ist ja auch was, wenn man irgendwo einen Bruch hat,
einen manuellen Bruch.
Dann habe ich kein Continuous Delivery.
Das sind so ein paar Beispiele. Es gibt ja noch so, und das kommt
da zum Teil wie Pilze, schiesst das jetzt heraus,
so neue Praktiken wie zum Beispiel ChatOps.
Das ist relativ neu. Es gibt dann so
Dinge wie, jeder von euch kennt WhatsApp.
Jetzt könnte man das gleiche Mechanismus nutzen für die
IT-Welt in der Zusammenarbeit. Also beispielsweise das
man so ein Chat-Tool nutzt, das ist dann integriert in die
bestehende Umgebung. Und wenn irgendwo ein Instant aufpoppt,
dass man direkt einen Kanal aufmachen kann, auch mit dem
Second Level, Third Level und gemeinsam an den Problemen
arbeiten kann. Da gibt es ja ganz verrückte Dinge, wie zum
Beispiel, es geht in Richtung Artificial Intelligence, dass
man solche Bots einbaut dort. Man will beispielsweise in diesem
Chat und sagt ja, bitte bring mir das jetzt in die Produktion
und der Bot verarbeitet das dann und agiert entsprechend.
So eine Art Siri für DevOps. Das ChatOps. Es gibt weitere
Beispiele, was jetzt gross am Kommen ist, ist Rucked DevOps
oder DevSecOps. Da geht es darum, Security Praktiken oder
Security Tests. Eben nicht wie früher, wenn man so eine
Partie macht, dass man sagt, ja, das ist ein separates Team,
das dann irgendwann später die Security Tests macht, sondern
dass man das versucht, früh in die Pipeline zu bringen, Tests
zu automatisieren. Das ist so die Idee dahinter. Ja, es gibt,
ich meine Dirk, du hast das sicher auch aus deiner Erfahrung,
oder? Da gibt es vielleicht noch so weitere Praktiken oder
Dinge. Man kann nicht DevOps machen, aber man kann eben
so diese, da hast du ein paar Ideen da. Ja, ja, wenn ich mir
das anhöre, was du jetzt auch gerade zum Schluss so erzählt
hast, das sind natürlich tolle Ideen, tolle Umsetzungsmöglichkeiten.
Wenn ich das so mir anschaue, das ist ja alles sehr stark in
Entwicklungsgebung. Und dann sehe ich vor mir den Delivery Manager,
sehe den Leiter des Rechenzentrums, den Leiter der IT-Infrastruktur
und der sagt sich, was soll ich damit anfangen? Das heißt, für
mich würde ich bei diesem ersten Schritt, von dem du angefangen
hast in deinen Ausführungen, ich würde diesen ersten Schritt
nochmal ein bisschen praktisch umsetzen, praktisch erläutern.
Was kann man denn tun, um mit DevOps zu starten? Und das heißt
für mich ganz klar, Kommunikation. Ich muss es hinbekommen, ein
Unternehmen muss es hinbekommen, die beiden Bereiche zusammenzubringen.
Die beiden Bereiche müssen miteinander reden, die müssen
miteinander Verständnis entwickeln. Das heißt, die beiden Bereiche
müssen zusammenarbeiten. Und das glaube ich, da sind viele Unternehmen
schon auf einem sehr guten Weg, dass sie einfach sehen, die beiden
Bereiche müssen im Sinne des Kunden zusammenarbeiten. Und dort glaube ich,
wenn ich jetzt auf die Betriebsseite schaue, ist es einfach auch interessant
und sehr gut, sich zum Beispiel mit den Community of Practice
zusammenzusetzen. Das heißt, in einem agilen Umfeld, dass ich meine
Betriebsanforderungen eben von Anfang an einbringe. Ich kann sie einbringen,
indem ich, wie gesagt, den Community of Practice gründe, wo ich mich mit
den agilen Teams auseinandersetze, wo wir gemeinsam darüber sprechen, wie
kriegen wir die agile Entwicklung dann auch schnell in einen Betrieb?
Das heißt, Kommunikation. Dann glaube ich, wird noch viel zu selten der
Standardweg benutzt, dass ich die Definition of Done vernünftig formuliere,
dass ich wirklich meine Betriebsanforderungen in eine Definition of Done
reinschreibe, dass ich meine Betriebsanforderungen auch in den User Stories
als Akzeptanzkriterium reinschreibe. Das sind für mich auch ganz praktische
Hinweise. Und an diesen Punkten, da wird schon viel diskutiert. Da gibt es
sicherlich viel Kommunikation, aber das, denke ich, ist neben den anderen Themen,
die du vorhin genannt hattest, einfach auch ein ganz wichtiger Punkt, dass ich
eben praktisch das hinbekomme, DEV und OBS zusammenzukriegen. Und was ich auch
noch wichtig finde, was meine Rednerin schon gesagt hat, ist, dass ich auch
in diesem Podcast nicht klären kann, was man regeln muss. Was wir sicherlich
heute hier in diesem Podcast nicht klären können, ist das ganze Thema Skalierung.
Wenn wir jetzt davon reden, das hast du ja selber gesagt, ich habe einen
Value Stream, ich habe eine Applikation, ich gucke mir einen Teil an, dann steckt
dahinter vielleicht auch wirklich nur ein Scrum Team. Dahinter stecken vielleicht
ganz wenige Scrum Teams. Aber die Frage ist ja, wie kriege ich meine gesamte
Umgebung, meine ganze Entdeckungsabteilung mit meinem Betrieb zusammen? Und da,
glaube ich, müssen wir uns in einem späteren Podcast nochmal ein bisschen so
auslassen, wie kriege ich das einfach skaliert? Wenn ich das jetzt hier nochmal
zurückführe auf den ersten Schritt, von dem ich eben gesprochen habe, glaube ich,
dass es einfach ganz wichtig ist, Kommunikation hinzubekommen, Offenheit auf
beiden Seiten hinzubekommen und dann einfach, dass beide an einem Ziel arbeiten.
Und das Ziel heißt, Kunden zufriedenstellen. Und das, glaube ich, ist ganz wichtig.
Und dort auch das, was wir vorhin schon hatten. Du hast ja gesprochen, dass die
Kunden zufriedenstellen. Und das, glaube ich, ist ganz wichtig. Und dort auch das, was
wir vorhin schon hatten. Du hast ja gesprochen, Culture eats strategy for breakfast.
Es muss an einer gemeinsamen Kultur arbeiten und das, glaube ich, ist eine der
großen Herausforderungen an DevOps. Und da würde auch ein Framework nicht helfen.
Das hatten wir vorhin auch als Punkt. DevOps als Philosophie, ja, es kann
kein Framework geben, was eine Kultur schafft. Dass die beiden Bereiche
miteinander sprechen, dass beide Bereiche zusammenarbeiten. Gut, also insofern,
Das wäre so meine Ergänzung dazu, zu dem Thema ersten Schritt.
Und ich glaube auch, ich habe dir eben gesagt, Betriebsseite,
ich glaube auch, dass wir dort sehr viel aus dem IT-Service-Management
an Wissen und an Erfahrung mitbringen können.
Und wenn ich das Thema DevOps als organisatorische Komponente betrachte,
dann komme ich ja dazu, ich habe es vorhin gesagt, autonome Teams zu bilden.
Und diese Teams, die kommen dann häufig sicherlich aus der agilen Entwicklung
und ich packe jetzt ein bisschen Betriebsaufgabe dazu.
Das klingt jetzt so einfach, heißt aber, dass ich ja eigentlich den gesamten Bereich
Service Design, Service Transition, Service Operation und natürlich
Continuous Service Improvement, dass ich diese Bereiche alle in das Team reinpacke.
Und das geht natürlich nicht in einem großen Framework,
aber die muss ich schon irgendwie regeln.
Es reicht eben jetzt nicht nur zu sagen, hey super, wir testen automatisiert
und haben eine Kontinente.
Wir haben das Delivery Pipeline, ich muss das Ganze ja auch organisatorisch regeln.
Und das, glaube ich, ist auch ein Punkt, wo DevOps einfach auch diese beiden Bereiche zusammenbringt.
Das heißt, wir haben schon eine agile Entwicklung, wir haben dort viele, viele Vorteile,
wir haben ein Schlangenprinz-Vorgehen und wir bringen aber IT-Service-Management-Gedanken
und Wissensgut mit ein.
Das würde ich noch einfach mit dazu packen, wenn wir nämlich über DevOps reden,
das ist ja Thema unseres Podcasts heute hier, was ist DevOps?
Dann wäre das quasi so ein bisschen mein Schlusswort, meine Erklärung, was ist DevOps?
Natürlich ist es eine Philosophie, es ist aber eigentlich nichts Neues.
Ich glaube, DevOps besteht eigentlich nur darin, dass ich die bestehenden Ansätze
wie agile Softwareentwicklung, Scrum beispielsweise, wie Lean Management,
mit Kanban als Beispiel und IT-Service-Management, ITIL oder andere Frameworks,
dass ich das zusammenbringe.
Ich glaube, das ist das, was ich unter DevOps verstehe und da denke ich,
dass wir in diesem Podcast noch das eine oder andere auch mal die einzelnen Bereiche beleuchten werden,
dass ich auch unsere Aufgabe in diesem Podcast quasi auch für Verständnis
auf der jeweiligen Seite zu werben, denn das hast du ja auch erzählt von deinem Freund.
Wenn wir mit DevOps zu klären sind, dann ist das, was ich unter DevOps verstehe,
das ist das, was ich unter DevOps verstehe, und das ist das, was ich unter DevOps verstehe.
Wenn wir zu kleineren Softwarehäusern kommen, die das schon lange machen,
dann machen die das schon so, aber die nennen das nicht DevOps.
Das heißt, das, worüber wir hier philosophieren, das ist für die Standard,
das ist für die Tagesgeschäft und das, was wir hier so schön ausbreiten,
ist etwas, was die schon seit Jahren leben und insofern glaube ich,
dass wir die einzelnen Bereiche mit diesem Podcast auch zusammenbringen.
Gut. Ja, es gäbe natürlich noch viel zu sagen.
Auch über DevOps, eben auch über die einzelnen Praktiken.
Und ich denke mal so jetzt als erster Podcast, mal so auch eine Einführung ins Thema,
warum DevOps, was ist DevOps, DevOps-Praktiken, das mal für den ersten Podcast gut ist.
Was ich jetzt lohnen würde für einen Nachfolge-Podcast,
mal sich ganz konkret so eine DevOps-Practice anzuschauen.
Und ich habe ja erzählt vom Value-Stream-Mapping.
Das ist etwas, das sich grosser Beliebtheit erfreut, mal zu identifizieren,
was sind eigentlich meine Value-Streams, so als Ausgangspunkt.
Und was wir da planen für den nächsten Podcast, ist ein Interview mit dem Kunden,
ein Real-Life-Beispiel, wie das dort umgesetzt wurde und wieso innerhalb von relativ kurzer Zeit
auch effektiv Ziele von DevOps erreicht wurden, nämlich schneller und besser zu werden.
Das so als…
Aussicht auf den nächsten Podcast.
Dirk, hast du da noch was zu ergänzen?
Ja, ich freue mich.
Das war eine sehr schöne Zeit mit dir hier, diese dreiviertel Stunde so circa.
Und ich bin zufrieden mit dem Ergebnis, aber vielleicht geht es ja unseren Hörern nicht so.
Vielleicht gibt es ja Rückmeldungen, vielleicht gibt es Hinweise.
Also insofern, wir freuen uns natürlich, wenn wir die Hörerschaft erweitern.
Ähm…
Da die Bitte natürlich, wenn es ihnen gefallen hat, weitergeben, den Hinweis auf diesen Podcast.
Und, wenn es Rückmeldungen gibt…
Alex, wie kann man dich erreichen?
Mich kann man erreichen auf alex.lichtenberger at ponthein.ch
oder auch auf Twitter, also wenn ihr da einfach nach a-lichtenberger sucht.
Ich bin da recht aktiv auf Twitter.
Und ich würde mich freuen über Feedback.
Also ganz im Sinn.
Im Sinne von Continuous Improvement, also wir versuchen auch diesen Podcast natürlich zu verbessern.
Dirk und ich würden uns auf Feedback freuen.
Wie kann man dich erreichen, Dirk?
Ja, mich kann man ähnlich erreichen.
Bei Twitter bin ich genauso erreichbar, at Söllner Dirk.
Beziehungsweise natürlich auch über meine E-Mail-Adresse dirk.söllner.de.
Ganz richtig, dirk.söllner at de.söllner.de.
Aber ich glaube…
Die meisten, die diesen Podcast hören, diesen ersten Podcast hören, kennen dich oder kennen mich.
Also insofern würde ich mich freuen, würden wir uns freuen, wenn wir Rückmeldungen bekommen.
Sei es, dass es uns gefallen hat, sei es, dass wir ein paar Dinge verändern können.
Und insofern freuen wir uns auf den nächsten Podcast und auf die Rückmeldungen unserer Hörer.
Vielen Dank, sagt Dirk Söllner und…
Vielen Dank, sagt Alex Lichtenberger.
Vielen Dank, Dirk Söllner.