Folge 64: Peter Lange zu DevOps im Infrastruktur-Betrieb 2/2

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

Inhalt laden

Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps Coach bei der PROFI Engineering Systems AG.
Mit ihm sprechen wir über DevOps aus der Sicht des „Endes der Nahrungskette“: dem Infrastruktur-Betrieb.

In dieser Folge des Podcasts werden die verschiedenen Aspekte von DevOps im Kontext des Infrastrukturbetriebs vertieft. Der Gast Peter Lange teilt seine Einsichten über die Bedeutung von Visionen und sinnstiftenden Momenten in der DevOps-Transformation, die Herausforderungen in der Zusammenarbeit zwischen verschiedenen IT-Bereichen und die Notwendigkeit einer kulturellen Veränderung. Es wird die Rolle neuer Technologien wie Kubernetes und Cloud-Infrastrukturen diskutiert, wie sie die IT-Landschaft transformieren und den Weg für eine zukünftige Entwicklung ebnen, die einen stärkeren Fokus auf Automatisierung, Plattformdenken und Produktdenken legt.

Inhalt

  • Einführung und Vorstellung der Teilnehmer
  • DevOps im Infrastrukturbetrieb: Grundkonzepte und Bedeutung
  • Herausforderungen bei der Implementierung von DevOps in Unternehmen
  • Die Rolle von Vision und sinnstiftenden Momenten in DevOps-Projekten
  • Technologische Aspekte: Kubernetes, Cloud-Technologien und deren Einfluss
  • Kulturelle und organisatorische Veränderungen in der IT durch DevOps
  • Zukünftige Trends und Entwicklungen im Bereich DevOps
  • Abschlussdiskussion und Ausblick

Shownotes

Peter hat zwei Buchtipps für uns:
The Other Side of Innovation
Team Topologies

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und letztes Mal haben wir uns mit so viel Spaß mit Peter Lange unterhalten
über verschiedenste kulturelle, organisatorische und technische Aspekte von DevOps im Infrastrukturbetrieb,
dass wir gesagt haben, wir machen einen zweiten Teil dieses Gesprächs daraus.
Und insofern ist auch heute wieder unser Gast Peter Lange. Willkommen zurück, Peter.
Hallo, auch willkommen. Vielen Dank für die erneute Einladung.
Sehr schön. Nachdem es uns ja etwas unsanft, das Netz uns etwas unsanft aus dem Gespräch des ersten Teiles gerissen hat.
Womit wachen wir denn weiter, Peter?
Mir ist im Nachgang, ist mir aufgefallen, auf deine Frage, wie das denn so abläuft.
Das war zwar richtig, aber ein bisschen inkomplett. Das würde ich gerne noch ein bisschen ergänzen.
Das letzte Mal haben wir davon, habe ich davon gesprochen, dass wir sinnvollerweise einen Sinnstifter finden,
wo die unterschiedlichen Teams sozusagen zusammenlaufen, der da auch eine Verantwortung hat.
Und dass es sehr wichtig und wirkungsvoll ist, wenn der die Vision für so ein DevOps-Projekt formuliert.
Damit ist es natürlich nicht zu Ende.
Also zum einen hat man dann natürlich die Herausforderung, einen Wertstrom auszuwählen.
Tatsächlich gibt es natürlich Produkte, die sind geeigneter, andere sind weniger geeignet.
Das ist wichtig. Dann ist es wichtig, ein Team zusammenzustellen, das man gegebenenfalls auch ergänzen kann.
Aber auch da, das Produkt, der Wertstrom und das Team müssen einfach sehr gut zusammenpassen.
Ja, nachdem man dann den Wertstrom schon mal hat und vielleicht auch ein erstes Mal visualisiert hat,
wenn es ihn schon gibt oder wenn es ihn noch nicht gibt, also ein Zollwertstrom,
dann geht es natürlich darum, über Architektur zu sprechen.
Eine Architektur zu definieren oder zu erarbeiten, was natürlich auch ein ganz wichtiger Part ist.
Zum einen ermöglicht es allen, mal über den Tellerrand hinwegzuschauen und das Gesamtgebilde zu verstehen
und ein gemeinsames Verständnis zu schaffen.
Ja, und dann geht es natürlich in Richtung, was wollen wir eigentlich für uns?
Welche Prinzipien brauchen wir? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Ja, das ist natürlich auch ein ganz wichtiger Part.
Und wo müssen wir eigentlich für uns? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Ja, und wo müssen wir eigentlich für uns? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Und wo müssen wir Dinge vielleicht auch schon anders machen als bisher?
Genau, das sind so wichtige Anfangsbausteine, mit denen es typischerweise losgeht in einer Startphase von vier bis sechs Wochen.
Das wollte ich noch ergänzen.
Okay, also die Startphase ist aus deiner Sicht wirklich erstmal so ein bisschen eine Bestandsaufnahme, ein Klarstellen irgendwie?
Ja, das ist zu schaffen und tatsächlich auch zu schauen.
Dass das Produkt beziehungsweise der Wertstrom und das Team zusammenpasst.
Dass wir uns dann anschauen, was gibt es eigentlich für Architektur, Bausteine?
Vielleicht gibt es ja schon was.
Und auch den ganzen Kontext zu beleuchten.
Haben wir regulatorische Anforderungen?
Wie schaut eigentlich das Business aus?
Welche Akteure gibt es?
Eben nicht nur Menschen, vielleicht gibt es ja auch Computer als Akteure.
Welche APIs brauchen wir nach außen?
All dies in einer frühen…
In einer frühen Phase zu erarbeiten und auch für alle klarzumachen.
Das ist super hilfreich.
Und naja, ich plaudere mal so ein bisschen aus dem Nähkästchen.
Das Feedback der Teams ist, mein Gott, Peter, ist das trocken.
Und es ist zum Teil vielleicht auch schmerzhaft für die Leute.
Im Nachgang, manchmal Jahre danach, bekomme ich dennoch zu hören Mensch, Peter, es war zwar super trocken.
Und ich habe wirklich mit mir kämpfen müssen, aber es ist hilfreich bis heute.
Ja, es ist nervt, wenn man nicht endlich ins Machen kommen darf.
Jetzt reden sich alle irgendwie heiß über Kubernetes und was es so alles gibt und möchten gerne mal tüfteln.
Und dann kommst du und redest über, ich weiß auch nicht, Projektstrukturen oder so.
Ja, über Projekte, über Teamstrukturen, über regulatorische Anforderungen.
Softwarekomponenten, Hardwarekomponenten.
Alles, was man so…
In dem Werkzeugkasten, Togaf und andere Architektur-Frameworks halt hat.
Das kann bis runter zum Glossar, den wir in der letzten Folge angesprochen haben, gehen, wo man halt sagt,
okay, wie sieht denn jetzt wirklich unsere Sicht auf Begriffe wie Deployment oder Server oder was auch immer alles aus?
Und das kann natürlich echt trocken sein.
Ein bisschen interaktiver wird es, glaube ich, an den Stellen, wenn man dann in Richtung Wertstrom,
Wertstromanalyse, ist Wertstrom, wo können wir dann optimieren und so kommt.
Und ja, wenn man dann…
Wenn man dann echt in die Umsetzung geht, dann ist natürlich Bewegung drin.
Aber ohne das Fundament zu haben, ist es häufig nicht ratsam, gleich in die Umsetzung zu gehen, weil sonst macht man es halt drei- oder viermal.
Genau.
Und das ist halt auch einfach eine hervorragende Gelegenheit, für dieses gemeinsame Verständnis zu schaffen.
Also ich vergleiche das dann gern mit einem Architekten, der Häuser baut.
Es ist natürlich schon gut zu wissen, bauen wir ein Büro?
Ja.
Ein Haus oder ein Parkhaus oder ein Einfamilienhaus.
Und je früher man das gemeinsam festlegt, desto besser ist dann nachher auch das gemeinsame Verständnis.
Und desto besser kann man auch gemeinsam an dem Wert arbeiten.
Und dann kann man ja iterativ gut vorgehen, ne?
Ja, ganz genau.
Ja, ich finde, das ist eigentlich ein ganz tolles Bild.
So habe ich das noch gar nicht gesehen.
Aber es kommt nicht darauf an, wo die Steckdosen sind oder sowas.
Aber wir müssen uns wenigstens mal darüber im Klaren sein.
Brauchen wir einen Kuhstall oder brauchen wir keinen?
Wäre zumindest hilfreich, wenn man darüber ein gemeinsames Verständnis hat.
Und meine Erfahrung über die, ja jetzt ja schon Jahrzehnte ist, dass das manchmal in manchen Projekten, war das eben nicht klar.
Und dann gibt es Konfusion, babylonisches Sprachgewirr.
Und man wundert sich, warum Dinge nicht so funktionieren, wie sie eigentlich funktionieren sollen.
Weißt du, was ich glaube, Peter?
Ich glaube, es ist sogar genau umgekehrt, sondern es ist der Normalfall, dass diese Verwirrung besteht.
Und eigentlich ist es die bessere Situation, wenn das den Leuten wenigstens bewusst ist, dass sie dann auch keine gemeinsame Sprache haben.
Viel schlimmer ist es, wenn die Leute denselben Begriff für ganz verschiedene Sachen verwenden, so wie wir es im ersten Teil haben.
Was ist denn mit einem Server gemeint?
Ist das eine Softwarekomponente oder ist das ein Stück Blech im Keller?
Beides gleichermaßen legitim, aber wir müssen schon wissen, wovon wir eigentlich reden.
Da ist mir auch so wahnsinnig in Erinnerung.
Ich habe mal etwas, was ein Freund von mir mal erzählt hat, der, was war denn, ein CTO oder sowas von einem Hosting-Unternehmen.
Und der hat mal seine Teams gebeten, ihm ein Architektur-Diagramm zu malen von dem, was die da so machen.
Und kein Team konnte ein vollständiges und korrektes Architektur-Diagramm dessen malen, womit sie sich tagtäglich befassen.
Keiner von denen.
Interessanterweise die, die es am besten hingekriegt haben, waren zufällig die UXler.
Die wie?
User Experience.
Oder was heißt UX an deiner Stelle?
Genau.
Das ist, glaube ich, der Normalfall, dass es da ein gewisses Maß an Grundmissverständnis gibt.
Genau.
Und dann hilft es natürlich, da sind wir wieder bei Sprachaufhänden und Zusammenarbeit und Co.,
die Leute in ein Boot zu setzen, in einen Raum zu sperren und zu sagen, okay, jetzt mach das mal zusammen.
Dann können nämlich auch alle verschiedenen Sichten zusammenkommen.
Und nicht nur die Spezialisten im Diagrammezeichen, die UXler,
bringen ihren Anteil, sondern auch diejenigen, die letztendlich aus ihrer, keine Ahnung,
teilweise wahrscheinlich Silo-Sicht heraus auf das Gesamtprodukt schauen.
Das ist natürlich spannend.
Klar?
Absolut.
Und ich sage mal, so ein Kontext-Diagramm ist natürlich auch extrem hilfreich.
Wir haben das letzte Mal davon geredet, dass sich Teams auch verändern.
Es kommen neue Leute rein.
Da ist natürlich eine Architektur-Dokumentation, in der man beschrieben ist, um was geht es hier,
was ist der Kern, was ist außerhalb, was ist der Kontext, aus welchem Baustein besteht,
besteht das Ganze extrem hilfreich.
Und etwas, was ja typischerweise auch nicht jeden Tag angepasst werden muss
und damit auch vom Aufwand her überschaubar ist.
Du hast vorhin am Anfang des Podcasts, wie geht es dann so in so einem DevOps-Projekt los,
über einen Sinnstifter gesprochen.
Was kann ich mir da unter vorstellen?
Was ist so ein Sinnstifter?
Ja, das Thema Sinnstifter wird immer wieder nachgefragt.
Ich sage mal, wenn ich Menschen motivieren, zu einer Veränderung motivieren will,
dann ist der Sinn, also der Sinn der Veränderung extrem wichtig.
Also das haben wir auch, im Moment wird das auch allen halben kolportiert.
Wir brauchen einen Sinn, Purpose.
Das ist einfach nicht zu unterschätzen.
Und wer ist denn der gemeinsame Sinnstifter von Dev und Ops?
Irgendwo läuft es ja zusammen.
Wenn ich die Gräben nicht größer machen will, dann ist es tatsächlich hilfreich,
ich suche den, wo die Dinge zusammenlaufen und lasse den mal die Vision kommunizieren,
warum es jetzt hilfreich ist, anders zusammenarbeiten als zuvor.
Das ist dann aus Erfahrung jemand, der in einer Hierarchie im Unternehmen recht weit oben sitzt,
weil Entwicklung häufig aus anderen Budgettöpfen bedient wird
und in anderer Verantwortung liegt, als das beim Betrieb der Fall ist.
Kannst du das bestätigen oder hast du da andere Erfahrungen gemacht?
Oft ist es so, kommt auch auf den Kontext an, manchmal ist es auch ein Gesamtprojektleiter.
Ist ja auch möglich.
Also wenn es im Projektkontext ist, ist es manchmal auch ein Projektleiter.
Das ist sehr unterschiedlich.
Das kann auch ein Inhaber sein.
Im operativen Geschäft überhaupt nichts zu tun hat.
Den gilt es halt zu finden oder jemanden finden, der diese Rolle gut ausfüllen kann.
Und was sind so Beispiele für den Sinn einer DevOps-Transformation, DevOps-Projekt?
Beispiel, das mir noch einfällt, konkret war ein Projekt.
Da ging es eigentlich um ein Großprojekt, wo klar war,
dass die anfallenden Arbeiten auch infrastrukturseitig, manuell überhaupt nicht zu stemmen sind.
Und wir ein hohes Maß an Automatisierung brauchen, eigentlich diese 100%-Automatisierung.
Genau. Und dann war halt die Ansage, wir brauchen 100%-Automatisierung.
Wir haben sehr viele Entwickler, die müssen ad hoc Systeme,
ganze Applikationslandschaften bereitgestellt bekommen.
Und dafür brauchen wir die Infrastruktur.
Und eure Aufgabe ist 100%-Automatisierung und im besten Fall schon in einem Vierteljahr.
Wie lange hat es gedauert?
Deutlich länger. Nach einem Vierteljahr war es ausreichend gut.
Aber ich sage mal, wir reden hier über DevOps.
Das ist eine Reise, die hört nie auf.
Ich vergleiche das gerne mit Automobilherstellern.
Wann haben die angefangen?
Mit Toyota Production Systems?
Ich glaube, Ende der 40er des letzten Jahrhunderts.
Und die verbessern heute noch.
Nach 70 Jahren sind die immer noch dabei, Dinge besser zu machen.
Und so wird es auch dort sein.
Aber es ist natürlich wichtig.
Ja, der wichtigste Schritt auf dem Gipfel ist der erste, nicht der letzte.
Ja, die sind sehr weit gekommen.
Jetzt sind wir sehr, sehr weit gekommen und es geht kontinuierlich weiter.
Manchmal ist das sinnstiftende Moment, wir brauchen mehr Kundenzufriedenheit.
Wir wollen mehr Qualität.
Mhm.
Ja, das kann ja auch.
Das kann auch ein sinnstiftender Moment sein, all die Werte, die man mit DevOps erreichen
kann oder will.
Aber das klingt jetzt irgendwie, muss ich schon mal sagen, nach einem ganz schön dicken
Brett.
Und ich frage mich, Stolperfallen gibt es mit Sicherheit zuhauf, aber was sind denn
so die gemeinsten oder die verbreitetsten, wenn man sowas tatsächlich ernsthaft anfangen
möchte?
Ich denke mal, die wichtigste, die haben wir letztes Mal schon angesprochen, es ist
einfach die Manpower.
Ich glaube, der Betriebsaufwand, also das gemeinste ist eigentlich, dass der Betriebsaufwand
so hoch ist, dass ich mich um die Verbesserung von Arbeit nicht kümmern kann.
Ja, so dieses berühmte Beispiel von der stumpfen Säge, der keine Zeit hat, weil er Bäume fällen
muss oder derjenige, der ein Auto an der Tankstelle vorbeischiebt und keine Zeit zum Tanken hat.
Das hört sich blöd an, ja, ist aber so.
Und der Weg dort raus ist meiner Meinung nach, ja.
Ich muss natürlich temporär.
Ich muss da Zeit zur Verfügung stellen und dafür ist es halt hilfreich, auch mit extern
zu arbeiten oder so man sich dann bekommt, neue Leute einzustellen.
An der Stelle ist aber, finde ich, auch wichtig, also ich sage mal, Externe bringen halt nicht
nur, ich sage es jetzt mal, Ressourcen mit rein, sondern halt auch andere Sichtweisen.
Die Gefahr ist, und das ist, denke ich, auch ein wichtiger Aspekt, dass, wenn ich nur mit
intern arbeite, dass die mir das Gleiche nochmal in klein aufbauen, dass die wirklich,
dass die wirklich innovativen Dinge nicht passieren, dass nicht aus dem eigenen Kasten
herausgeschaut wird, ja, weil das haben wir schon immer so gemacht und dann sind die Ideen
vielleicht nur, nur halb so gut, wie wenn ich ein gerüttelt Maß externe Sichtweise
habe.
Das ist dann vielleicht auch eine Berechtigung für externe Berater oder Coaches.
Ja, also es kann schon echt hilfreich sein.
Ja, das stimmt, aus meiner eigenen Sicht als tatsächlich eben externer Berater ist es dann
auch einfach häufig so, gar nicht mal so sehr, dass man eine andere Sicht bringt, sondern
vielleicht auch einfach nur mal Mut machen muss und sagen muss, ja, ich habe das anderswo
schon gesehen und die haben das gekonnt und ihr könnt das auch.
Und dann hat man natürlich auch einen Kristallisationspunkt, wenn ein Externer da ist, dann auch zu sagen,
okay, der Externe.
Ich möchte jetzt mit jemandem aus einem Infrastruktur- oder Applikationsbetrieb sprechen, ich möchte
mit euch über Architektur reden, wir brauchen auch ein paar Entwickler am Tisch und dann
vielleicht auch die Karte, naja, das kostet ja sowieso Geld, ich bin ja jetzt nicht umsonst
hier, dann lasst mal alle, die eh da Kosten produzieren, mal ruhig mit mir zusammen an
einem Tisch sitzen.
Gibt es andere Wege, so eine positive, wohlwollende Atmosphäre zu schaffen, damit man auch in
Richtung Erfolg kommt?
Also was Luca schon angesprochen hat, ist auch einfach davon erzählen, wie es bei anderen
ist.
Also ich sag mal, das ist eigentlich der Klassiker, dass ich am Anfang gesagt bekomme, typischerweise
aus der Mannschaft heraus, manchmal aber auch aus dem Führungskreis heraus, ja, das mag
woanders funktionieren, aber bei uns funktioniert das nicht.
Ist ja so der Klassiker.
Und dann ist natürlich gut, wenn man vielleicht sogar aus der Branche kommt.
Ja.
Und dann kann man dann auch, wenn man im Führungsbereich noch Fragen hat, dann kann man halt auch da
nach dem Führungsprogramm, da kann man dann auch auf die Beispiele kommen, da kann man
mal sagen, ja, das wurde mir dort auch gesagt, und heute stehen wir aber an einer ganz anderen
Stelle.
Die sind nicht zu Ende mit der Reise, aber sie haben schon diese und jene Ziele erreicht.
Und ich kann euch sagen, wie wir da vorgegangen sind, wir können das auch hier mit dem oder
einem ähnlichen Weg versuchen.
Das bringt dann Vertrauen, das bringt dann ein bisschen Selbstsicherheit auch, um den,
ähm, den Wunsch zu erreichen.
Ja, klar.
Und das ist auch ein sehr guter Schritt.
Ja, klar.
Ja, klar.
Ich hoffe, das ist ein sehr guter Schritt.
Ja, klar.
den doch recht langen und häufig auch steinigen Weg der Transformation dann anzutreten.
Also den ersten Schritt, den du vorhin erwähnt hattest, auf dem Weg zum Gipfel auch wirklich zu gehen.
Ganz genau. Und ich sage mal, wenn wir jetzt schon bei der Metapher sind vom ersten Schritt,
hilfreich ist natürlich auch mal das Erreichen des ersten Basislagers sozusagen.
Also früh erste Erfolge zu zeitigen und die dann auch zu kommunizieren.
Und wenn denn erste Erfolge da sind, die kommuniziert sind und die dann auch angenommen werden,
dann wird es oft sogar ein Selbstläufer.
Übrigens auch nicht nur Erfolge, ich weiß nicht, zu kommunizieren, sondern überhaupt erst mal als Erfolge zu erkennen.
Das ist etwas, was ich ganz häufig habe, wenn es darum geht, zum Beispiel Testautomatisierung einzuführen.
Dann sagen die Leute, oh Mann, wir haben erst einen automatisierten Test.
Und dann sage ich, merkt ihr eigentlich, was ihr da geleistet habt?
Das war der schwerste.
Ihr habt eine Testinfrastruktur aufgesetzt, ihr habt euch Gedanken über Tests an sich gemacht.
Ihr wisst jetzt, wie man automatisierte Tests einerseits schreibt, andererseits ausführt.
Und wahrscheinlich sogar 90 Prozent des Weges sind geschafft.
Und die anderen 10 Prozent macht dann sowieso nebenbei, nämlich kontinuierlich den Testset aufbauen.
Klar kommt irgendwann nochmal so eine Phase, wo vielleicht nochmal ein Refactoring oder so notwendig ist,
wo man vielleicht nochmal die Regressionstests oder andere,
Testsets ein bisschen zusammenstutzt oder ähnliches.
Aber ja, das ist auf jeden Fall ein extrem wertvoller Punkt.
Und ich denke, Basislager 1 auf jeden Fall an der Stelle.
Ja, und das ist, denke ich, auch ein ganz wichtiger Punkt von zum Beispiel einem DevOps-Coach,
dass er in Retrospektiven das immer wieder hervorzieht, immer wieder die Leute darauf fokussiert,
was sie denn schon alles getan haben.
Genau.
Jetzt gibt es ein Architektur-Diagramm.
Wir brauchen jetzt einen neuen, der kann sich leichter einarbeiten.
Das sind ja alles auch echte Werte, die dort geschaffen werden.
Also sogar bevor es in die Umsetzung geht, werden ja Werte geschaffen.
Und das zu fokussieren und da immer wieder darauf hinzuweisen, ist, glaube ich, auch ein ganz wichtiger Erfolgsfaktor.
Ja, wir hatten ja zusammen in einem Projekt gearbeitet.
Und was mich so ein bisschen…
Was mich so ein bisschen überrascht hat, ist, dass häufig in den ersten Retros dieses
Wir haben uns zusammengesetzt und ausgetauscht über die Silo-Grenze hinweg.
Und wir haben ein besseres Verständnis geschaffen.
Wirklich die treibenden Erfolgserlebnisse der Teilnehmer waren, wo man sagt,
Okay, das ist ja jetzt eigentlich nicht wirklich ein Hexenwerk.
Also das macht doch mal ein Meeting und ladet mal jemanden aus Dev und Ops zusammen ein.
Ist häufig wirklich ein guter erster Schritt auf dem Weg zu
Wir haben einen gewissen Erfolg erreicht.
Und man wundert sich, aber miteinander reden hilft.
Ja, tatsächlich.
Also ich sage mal, am Anfang fängt man an, miteinander zu reden.
Und irgendwann arbeitet man sogar zusammen.
Das ist halt der erste Schritt.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Weil es ja offensichtlich im Alltag gar nicht so einfach ist, zusammenzuarbeiten.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Weil es ja offensichtlich im Alltag gar nicht so einfach ist, zusammenzuarbeiten.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Okay, für uns warst du gerade kurz weg.
Aber nichtsdestotrotz, wir waren gerade bei dem erfolgreichen ersten Schritt.
Was sind denn die größten Herausforderungen auf dem Weg zum Basislager 1?
Oder vielleicht, wenn das zu kleine sind, die größten Herausforderungen auf dem Weg zum Gipfel?
Also was ich als eine große Herausforderung sehe, ist,
wir haben ja oft fragmentierte Organisationen, die sogenannten Silos,
wir haben ja oft fragmentierte Organisationen, die sogenannten Silos,
mit sehr unterschiedlichen Zielvorgaben und die Veränderung der Inzentivierung der Ziele.
Und das ist eine große Herausforderung, weil da brauche ich eben das Management.
Ich brauche das Management bei Ihnen, das erfordert auch Mut.
Ja, das ist eine der großen Herausforderungen.
Und dann die Entwicklung tatsächlich einer gemeinsamen Verantwortung.
Für die Beteiligten.
Auch ein großer Schritt, der halt aufgeteilt werden muss in viele kleine.
Und da ist es auch einfach sicherlich hilfreich, das auch mal transparent zu machen.
Also mal transparent zu machen, wo liegt Verantwortung, wo werden Entscheidungen getroffen
und an welcher Stelle ist es hilfreich, Entscheidungen abzugeben oder gemeinsam zu treffen.
Meiner Meinung nach auch ganz wichtige.
Ganz wichtige Aspekte, denn diese unterschiedlichen Ziele führen natürlich zu diesem Silo-Denken ganz stark.
Also mein Storage ist okay, der ist grün, also kümmert mich die Performance der Anwendung nicht.
Um es jetzt mal ganz platt zu sagen.
Ja gut, aber wenn man solche Messdaten, Messwerte erhebt, sind die natürlich dann, wie du sagst, Silo-bezogen.
Hilft das dann kundenfokussierte?
Kennzahlen zu erheben, also Kundenzufriedenheit wäre so ein Thema.
Oder andere, vielleicht auch unternehmensspezifische Richtung, keine Ahnung, Umsatz oder Gewinn oder Marge oder ähnliches?
Ja, natürlich. Das ist absolut hilfreich, ist aber gleichzeitig auch so ein Stück weit die Königsdisziplin.
Ich denke, da sollte man auf jeden Fall hinkommen.
Am Anfang steht, denke ich mal, die Silo-übergreifende, die cross-funktionale Sicht auf,
zum Beispiel Messdaten, aber mit Gipfeln sollte das natürlich in Business-relevanten Rundmeldungen, Feedbacks letztlich.
Weil am Ende sind es ja die wenigsten Firmen, die das Geschäftsfeld darin besteht, Storage zur Verfügung zu stellen, Server zur Verfügung zu stellen.
Die allermeisten Organisationen wollen etwas anderes.
Die Versicherung will Versicherung verkaufen.
Die Bank will Geld verwalten.
Der Maschinenbauer will Teile verkaufen.
teilen, produzieren.
Dann sind wir wieder bei dem, was du
einleitend als deine DevOps-Definition
genannt hast, diesen Wertfokus,
wie auch immer er sich dann konkret
darstellt.
Ja, natürlich, da muss es
hingehen und das ist schon auch,
weil ihr das vorher gefragt habt, ist schon
auch etwas, was nicht
von heute passiert, diese
Fokussierung der Leute
auf den eigentlichen Wert fürs
Unternehmen. Da kommen viele
Ideen und wenn du dann fragst,
okay, inwiefern
trägt das zu einem Mehrwert
bei? Das muss ja nicht
immer direkt ins Business gehen.
Manchmal ist es auch ein Mehrwert, wenn ich
regulatorische Anforderungen erfüllen kann.
Das kann durchaus
auch ein Mehrwert sein, aber
diese Fokussierung auf
Mehrwert, das ist
etwas, was nicht von
heute auf morgen geht und sicherlich
einer der spieglerischen
Komponenten
Tätigkeiten.
Und gleichzeitig
einer der wirkungsvollsten.
Vielleicht wollen wir ein bisschen die Richtung
ändern des Gespräches,
denn jetzt haben wir uns sehr viel auf
der kulturellen Ebene
aufgehalten, oder ich nenne es mal
pur kulturellen Ebene aufgehalten.
Solche Themen wie Wertfokus beispielsweise,
wie wertschöpfende
Kommunikation miteinander und so.
Und wir nennen es ja auch
DevOps im Infrastrukturbetrieb, das ist die
Überschrift über diese Folge.
Aber trotzdem frage ich mich,
wie kommen da jetzt eigentlich
neue Technologien, all das, was
auch viele Leute unter DevOps verstehen,
in diesem Thema
vor? Was ist denn mit
Kubernetes, sagen wir mal, oder mit
Docker oder mit Cloud
und all diesen Dingen? Wie hängt das
denn damit zusammen?
Das sind natürlich
viele der Dinge, die du
angesprochen hast, können
hilfreiche
Bausteine sein, ob sie es denn tatsächlich
sind, liegt natürlich,
liegt natürlich mal wieder
am Kontext. Also,
sag mal, sowas wie Containerisierung,
ja, ich weiß noch,
wie das damals mit, losging
mit der Hardware-Virtualisierung,
ja, also früher die
Emulation vom Betriebssystem,
wirklich Wine, etc.,
das war ja wirklich schmerzhaft.
Dann kam auf einmal Frau M. Währungs-Eck und hat
gesagt, wir machen alles anders und wir
virtualisieren die Hardware.
Auch da habe ich,
damals war ich sehr aktiv in diesem Bereich,
und habe sehr viele Widerstände.
So, jetzt haben
wir aktuell mit der
mit der Containerisierung,
legen wir die Abstraktion
wieder eins höher,
zu dem Anwendungsprozess,
und das ist natürlich
ein wichtiger und
hilfreicher Schritt.
Ich sag mal, ein Großteil,
ein großer, nicht zu unterschätzender Teil
der Betriebsaufwände liegt einfach
darin, Betriebssysteme
zu managen, zu patchen,
Sicherheitspatches, etc.
Leider Gottes auch
viel Produktionssysteme
anzupassen, ja, und dann zu hoffen,
dass es danach so gut funktioniert
wie zuvor. Also, insofern,
ja, diese Technologien sind
hilfreich, aber
nicht jede Technologie
passt in jeden Kontext,
und Technologie
allein schafft halt keine
Fähigkeiten.
Ich brauche die Prozesse dazu,
ich brauche die Menschen dazu,
mit den entsprechenden Skills,
wenn die Technologie allein
hilft halt nicht. Also, ich kenne
Situationen, da wurden Container,
Plattformen aufgebaut,
und die wurden halt einfach nicht angenommen.
Ja, und dann, also
der Mehrwert war praktisch null.
Ja, im Gegenteil.
Es wurde Geld ausgegeben,
ja, und
das war pure Verschwendung.
Ja, und da sind wir wieder
bei dem Teil,
wer ist eigentlich der Kunde?
Und dann können solche
Technologien natürlich total hilfreich sein.
An der Stelle, wir
haben September
2022, wir haben
ein Energiethema,
natürlich sind mit solchen
Technologien auch solche
Herausforderungen vielleicht besser zu stemmen.
Natürlich, wenn ich
Anwendungsinstanzen, die ich aktuell
nicht brauche, problemlos runterfahren kann
und problemlos wieder hochfahren kann,
dann kann ich natürlich auch
unglaublich viel Energie sparen.
Also, man glaubt ja nicht, wie viel
im Rechenzentrum im Kreis rumdreht
und Strom
in heiße Luft verwandelt,
ohne dass es benutzt wird.
Also, da sehr viel
Potenzial mit dem Hinweis,
die Technologie allein macht es nicht.
Und ob eine Ressource
bei mir im Rechenzentrum idelt oder
beim Cloud-Betreiber,
spielt an der Stelle
natürlich auch keine Rolle.
Ja, das stimmt. Ja, ich, ähm,
ich verwende da immer ganz gerne so ein Bild,
so wie,
wie wenn ich was anpflanze oder sowas.
Es geht mir nicht ums Substrat,
es geht mir nicht um die Erde, aber es ist halt nur mal notwendig,
dass die Tomaten wachsen können. Und ich glaube,
so ähnlich ist das auch mit all diesen
Plattform-Dingen, nicht wahr? Die sind
nicht hinreichend, aber durchaus notwendig,
damit ich die Früchte ernten kann, um die es mir
eigentlich geht.
Absolut. Absolut.
Mir fallen da andere Dinge ein, die vielleicht
noch notwendiger oder früher
notwendig sind, wie zum Beispiel
gemeinsames, gemeinsames Git.
So,
da,
da gäbe es schon, oder eine gemeinsame
Wissensplattform,
da gäbe es schon Dinge, die mir noch vorher
einfallen, ja, und die ich für
mindestens so, so wichtig
empfinde. Aber
du hast natürlich Recht, diese Plattformen
sind äußerst hilfreich
und in vielen Kontexten
auch das Mittel der Wahl.
Ich sag mal, Cloud wird da oft
insbesondere von den Anbietern als
Heilmittel dargestellt und
immer wieder werde ich
noch gefragt, ja, was ist denn jetzt eigentlich
Cloud und ist das denn immer Public
und da gibt es erschreckend
wenig Wissen eigentlich.
Ja, und
die Idee, dass es am Ende ein
Bereitstellungsmodell ist,
ist erstaunlich
wenig verbreitet. Ich ziehe dann oft
die Analogie zum Strom, also von der Erfindung
des Stroms bis zu dem
Zeitpunkt, zu dem er aus der Steckdose
kam. Ich glaube, das waren
20 Jahre, wenn überhaupt.
Beim Compute
hat es 100 Jahre gedauert.
Tatsächlich wird es
nach wie vor schlechter adaptiert.
Wer würde schon,
es gibt nur wenige,
die Strom produzieren, um ihn zu
nutzen. Tatsächlich
produzieren aber ganz viele
Compute, um es zu nutzen.
Aber es ist ein Bereitstellungsmodell und
das kann natürlich hilfreich sein,
muss es auch nicht und manchmal ist es so,
sogar gar nicht möglich aufgrund von
regulatorischen Vorgaben.
Das bedeutet ja nicht, dass ich
keine Cloud mache, sondern dass ich
vielleicht eine Cloud selber mache.
Das ist aber,
das ist etwas, das muss man sich halt
im Einzelfall anschauen,
aber es sind super hilfreiche,
super hilfreiche
Technologien oder im
Fall der Cloud Bereitstellungsmodelle
für solche Herausforderungen,
wie wir sie im DevOps-Umfeld erleben.
Mhm.
Dann ist das jetzt vielleicht ein guter
Zeitpunkt, um auch mal ein bisschen
aus der Vergangenheit oder der Gegenwart
sich zu lösen und mal ein bisschen in
Richtung Zukunft zu denken.
Wenn du jetzt mal so
extrapolierst die Reise, die du
und deine Kunden gemacht haben
über die vergangenen Jahre und Jahrzehnte,
was denkst du denn, wohin diese Reise
weiterhin gehen wird und wo siehst du denn
die aktuell größten Herausforderungen
oder die spannendsten Spielfelder?
Also
ich glaube, die Reise
geht gerade im Bereich
der Infrastruktur,
des Betriebs, noch
sehr viel mehr in Richtung
Plattform und Produktdenken.
Also die Zeiten,
in denen IT produziert
wird, wie in einer Manufaktur,
ich glaube, die werden
immer schwieriger.
Es wird mehr und mehr ein
Plattformdenken geben. Personen
werden sich auch umorientieren,
also nicht nur vom
reinen Denken, sondern auch von den
Skills. Die
Rechenzentren sind eher API
driven. Es wird immer weniger mit
der Maus am Arm
umgesetzt. Genau, das
ist einer der Dinge,
die ich sehe.
Die Art und Weise der Zusammenarbeit,
die wir heute
teilweise
schon sehen zwischen Entwicklern
und Anwendungsbetrieb,
das wird auch mehr und mehr
nach unten wandern in Richtung
Infrastruktur.
Die Methoden,
mit der wir arbeiten, die Werkzeuge,
mit denen gearbeitet wird,
das wird sich meiner Meinung nach
mehr und mehr angleichen.
Schon in vielen
Organisationen auf dem Weg,
aber mehr Unternehmen
noch nicht auf dem Weg und
das wird sicherlich ein
Teil des
Wandels.
Das ist dann das, was man
landläufig GitOps nennt, oder?
Ja, ich bin
gespannt, was nach GitOps kommt.
Was mich immer so ein bisschen fasziniert,
weil ich hätte irgendwie gedacht, dass das
schon immer gelebte Praxis war.
Ich möchte
wetten, dass zum Beispiel die Mainframe-Jungs
das vor 40 Jahren auch schon
von den Ansätzen her ganz ähnlich gelebt haben.
Vor 40 Jahren war ich
noch nicht in der IT, aber ich gebe dir natürlich
Recht.
Die haben das früher viel deutlicher
gelebt. Es gibt ja
neben dem Mainframe auch noch so
Midrange-Systeme, damals
hieß es AS400, heute glaube ich
i-Series. Dort waren
viele
Kompetenzen gebündelt.
Man hat sich eben nicht nur um die
Hardware gekümmert, sondern natürlich auch um den
damals Direct Attached Storage,
was wir heute teilweise auch wieder sehen,
über die Datenbank, die drauf ist,
bis zu den Anwendungen.
Das war alles in einem
Team. Und ja,
damals waren wir aus heutiger
Sicht weiter.
Lustig, oder? Ich finde,
das muss irgendwie so
sein in der IT. Das Pendel schwingt immer so ein bisschen
hin und her. Zuerst hatte man
Zentralisierung, dann hatte man Dezentralisierung,
jetzt hat man wieder Zentralisierung in Richtung
Cloud, jetzt kommt dann vielleicht wieder eine Dezentralisierung.
Und so ist es mit vielen anderen
Sachen auch, oder? Ja, mir fällt
dazu ein Geschäftsführer ein,
der tatsächlich einen IT-Hintergrund
hatte, neben seinem kaufmännischen Hintergrund.
Und der hat mir genau das
gesagt. Damals ging es
um Terminal Server,
und dann hat er gesagt so, ah, nee,
Herr Lange, ich beobachte
das jetzt schon seit langer Zeit,
seit 40 Jahren, das geht immer hin
und geht immer, und geht dann
wieder her. Und diesmal
setze ich einen Zyklus aus.
Kann man eben eigentlich nur
gratulieren zu dieser
Einsicht, wobei
was ich ganz klar sehe,
ist, dass DevOps
und DevOps
Vorgehen meiner Meinung nach
das IT-Produktions-
Modell der Zukunft darstellen. Davon
bin ich fest überzeugt.
Ja, es gibt ja auch nicht wenige, die sagen,
das ist die
Professionalisierung
letzten Endes endlich mal der IT,
dass man mehr
in Richtung nicht mehr Handarbeit
geht, wie du vorhin gesagt hast,
mit der Maus irgendwie in den Betriebssystemen
rumfuhrwerken, sondern in Richtung
einer Automatisierung,
einer Industrialisierung im weiteren Sinne,
dass das jetzt
die industrielle Revolution der IT ist irgendwie.
Ja, natürlich auch
der Digitalisierung. Mein Geschäftsfeld
heißt ja Digitalisierung und agile
Methoden, wie ich vorstehe und das ich
verantworte. DevOps ist natürlich
auch ein Stück weit die Digitalisierung
der IT-Produktion.
Und wenn wir uns
das anschauen… Was so lustig widersprüchlich
klingt, ne?
Ja, sollte man meinen. Und wenn man genau hinschaut,
dann ist es gar nicht so widersprüchlich.
Also, wenn wir uns anschauen,
die IT-Abteilungen dieser Welt
haben in der
Produktion, also die letzten
Jahrzehnte, den
produzierenden
Abteilungen enorm geholfen
weiterzukommen im Bereich der
Digitalisierung, im Bereich von
Lean-Production.
Diese ganzen Vorteile
und wenn man sich dann anschaut,
wie viel davon sie für sich selber
adaptiert haben, kann man ja
schon auch demütig werden.
Viele Erfahrungen, die
es in Organisationen gibt,
mit dem Thema, insbesondere
mit dem Thema Lean, kann man jetzt
natürlich auch für die
IT mitnutzen.
Wir fangen da ja nicht von…
Wir müssen das nicht
von Neuem erfinden.
Ja, und ich finde, das ist auch eine ganz gute
Nachricht, weil es
zeigt halt auch irgendwie, schlussendlich geht’s
ja um nichts Neues, um nichts anderes.
Wenn man ehrlich ist, zum Schluss geht’s
wahrscheinlich um Menschen, ne? Und Menschen
sind halt irgendwie immer Menschen.
Ja, das stimmt.
Wobei ich würde es ergänzen, es geht nicht
nur um Menschen, es geht natürlich auch um Prozesse,
es geht auch um Technologie,
neue Technologien zu adaptieren.
Aber der Mensch ist
natürlich ein ganz, ganz wichtiger
Player in dem Spiel.
Und der, der es
ermöglicht oder entmöglicht.
Genau.
Das klingt fast wie ein tolles Schlusswort für
eine Folge,
die sich ja nennt, DevOps im Infrastrukturbetrieb,
dass wir es auf diese Weise wieder
den Bogen zurückspannen.
Gibt’s noch was Wichtiges, was du loswerden
möchtest? Haben wir was vergessen?
Gibt’s was, was du noch genauer beleuchten
möchtest?
Ich weiß gar nicht, ob ich’s
ob ich was vergessen hab. Man kann
natürlich über DevOps, kann man ja reden,
Tage und Wochen lang.
Aber was ich schon nochmal
adressieren möchte, ist
die Veränderungen, wie sie
DevOps mit sich bringen, sind
ohne sinnstiftendes Moment
schwer umsetzbar.
Das ist wichtig.
Und ich hab’s schon
angesprochen, so eine Vision
und ein klares Commitment vom Sinnstifter
sind nicht zu unterschätzende,
äußerst kraftvolle Werkzeuge,
die Enormes
bewirken können und die man nutzen sollte.
Naja, und der Rest ist
harte Arbeit, Schweiß,
Tränen und sehr viel Lernen.
Und an der Stelle möchte ich auch
alle Zuhörer motivieren,
das ist es wert, weil
Arbeit wird dadurch eben nicht nur besser,
sondern auch schöner.
Ja, ich glaube, das hast du schön gesagt.
Das ist etwas, was ich auch als sehr wichtig empfinde.
Ich finde, Peter, das war ein tolles
Schlusswort und
wir haben ja jetzt auch schon wieder
mit Fug und Recht eine neue Folge
draus gemacht. Insofern danke
ich dir an dieser Stelle nochmal
vielmals dafür, dass du uns so viel von deiner
Zeit und von deinen Erfahrungen geschenkt hast.
Falls Leute noch Fragen haben,
dann können sie mit Sicherheit
einen Blick in die Shownotes werfen
und dort Wege finden, um mit dir
in Verbindung zu treten, um mit der profi AG in Verbindung
zu treten. Das Buch, das du erwähnt hast,
das packen wir natürlich auch in die Shownotes rein.
Und alles, was uns jetzt vielleicht auch im Nachgang
noch einfällt an Dingen, die wir als
Wichtige erachten für euch
liebe Hörerinnen und Hörer. Auch im Namen
von Falko, der jetzt irgendwie schon weghechten
musste, möchte ich mich
also nochmal ganz herzlich bei dir bedanken, Peter.
Und ich wünsche dir einen ganz tollen Tag.
Sehr gerne, gleichfalls. Vielen Dank
für die Einladung.
Vielen Dank.
Vielen Dank.
Vielen Dank.