Folge 9: DevOps Missverständnisse

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

Inhalt laden

In dieser Episode von „DevOps auf die Ohren und ins Hirn“ diskutieren Alex Lichtenberger und Dierk Söllner sechs häufige Missverständnisse über DevOps. Sie erklären, dass DevOps weder ein neues Framework ist noch die agile Produktentwicklung ersetzt, sondern diese ergänzt und sich gut in das IT-Service-Management einfügt. Die Rolle des IT-Betriebs wird durch DevOps verändert, aber nicht überflüssig gemacht, und obwohl Automation ein wesentlicher Bestandteil von DevOps ist, geht es dabei um mehr als nur „Everything as Code“. Zudem klären sie, dass Entwickler keinen direkten Zugriff auf Produktionsumgebungen haben, sondern der Prozess hochautomatisiert und kontrolliert abläuft.

Inhalt

  • DevOps als Philosophie, nicht als Framework
  • Verhältnis von DevOps zur agilen Produktentwicklung
  • Kompatibilität von DevOps mit IT-Service-Management
  • Die Rolle von Operations in DevOps und das Konzept von NoOps und NewOps
  • Bedeutung der Automation in DevOps und darüber hinausgehende Aspekte
  • Missverständnis über Entwickler mit direktem Zugriff auf die Produktion
  • Verschiedene DevOps-Praktiken und -Prinzipien

Shownotes

  1. DevOps Days: devopsdays.org
  2. ITIL (IT Infrastructure Library) für IT-Service-Management: ITIL
  3. Scrum als agiles Framework: Scrum Guide
  4. Scaled Agile Framework (SAFe): Scaled Agile Framework

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 zu einer neuen Folge des Podcasts
DevOps – auf die Ohren und ins Hirn.
Mein Name ist Alex Lichtenberger.
Ich begrüsse die Zuhörer und Abonnenten auch im Namen von Dirk Söllner.
Der sich dann gleich vorstellen wird.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir sprechen alle DevOps-Interessierten an, die mit dem Medium Podcast etwas anfangen können
und gerne etwas dazu hören, sei es beim Autofahren, im Zug oder abends im Hotel oder zu Hause.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern.
Die in DevOps enthalten sind.
Mit diesem Podcast sollen die Hörer und Hörerinnen das vielleicht etwas schwammige Thema DevOps besser verstehen und auch erklären können.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern,
damit sie persönlich durchblicken und ihr Unternehmen erfolgreicher machen können.
Heute machen wir wieder mal einen Podcast zu zweit, ohne externen Gast.
Das heisst dieses Mal nur Dirk und ich.
Nun zum Thema vom heutigen Podcast, das ist inzwischen der neunte Podcast, DevOps-Missverständnisse.
DevOps ist ja schon seit fünf bis sechs Jahren geprägt, dass ja kein Framework ist, kodifiziert.
Jeder versteht ja auch ein bisschen was anderes darunter und entsprechend gibt es ja sehr viele Missverständnisse.
Als Beispiel.
DevOps ersetzt die agile Produktentwicklung oder DevOps macht den IT-Betrieb überflüssig.
NoOps oder DevOps ist ein neues Framework.
Das sind so Punkte, die der Dirk und ich, wir haben uns das mal aufgelistet, auch aus unserer Praxis, aus Beratung und Schulung, was wir so aufschnappen.
Ja, und wir wollen diese Missverständnisse mal durchgehen und auch vielleicht einen oder anderen missverständlich.
Ja, bevor wir da jetzt mit mal one-by-one durchgehen, vielleicht noch kurz Dirk, willst du auch noch was kurz sagen?
Ja, Alex, vielen Dank für die Einleitung. Ich will kurz was sagen, vielleicht auch ein bisschen länger nachher zu den fachlichen Themen.
Ja, Dirk Sönder ist mein Name. Ich stelle mich jetzt auch ruhig auch nochmal vor, weil wir ja doch mehr Zuhörer bekommen und auch Zuhörer bekommen, die uns, die mich und dich, Alex, auch noch gar nicht so aus der Praxis kennen.
Also insofern.
Dirk Sönder. Ich betreibe verschiedene Webseiten. Eine unter anderem die Webseite devops.de, also mit zwei Dees, wo auch dieser Podcast dann verfügbar ist.
Mittlerweile haben wir ihn ja auch bei iTunes platzieren können. Also auch die hohen Weihen der bekannten Podcast-Portale haben wir ja dann geschafft.
Und insofern kriegen wir auch Rückmeldungen und ich wollte die Chance heute mal nutzen, mich auch bei den verschiedenen Rückmeldungen zu bedanken.
Bei den Hinweisen, wo Leute aufhören.
Wo wir etwas verbessert haben, wo wir also schon Dinge verändert haben und mit den kleinen oder auch größeren Tipps, sodass wir den Podcast immer mehr auch an die Wünsche und Anforderungen der Zuhörer anpassen können.
Also insofern einen vielen Dank oder einen herzlichen Dank an die Zuhörer und an die Abonnenten.
Gut, vielen Dank, Dirk. Dann legen wir mal los, deine unsere wunderbaren Liste.
Da haben wir als erstes, sehe ich, DevOps ist ein neues Framework. Dirk, was meinst du?
Ja, ist ja wirklich ein interessantes Missverständnis aus meiner Sicht.
Ich könnte mir vorstellen, dass das von dem einen oder anderen Hersteller oder Anbieter von Schulungen unter diesem Stichwort quasi verkauft wird.
Aber für mich ist das eben kein neues Framework.
Das macht es für mich auch so interessant, diese Sichtweise, dass es eben kein neues Framework ist, weil ich glaube, dass wir schon genug Frameworks haben.
Die muss ich jetzt nicht alle aufzählen. Wir wollen auch die Namen nicht alle nennen.
Also ich glaube, dass wir genug Frameworks haben. Wir haben genug Wissen.
Wir haben genug Wissen aufgeschrieben. Wir haben genug Wissen in der Praxis.
Wir müssten jetzt nur einfach mal drangehen, das in der Praxis umzusetzen, das, was an Wissen da ist, was an beschriebenen Frameworks da ist.
Und deswegen glaube ich, dass es eben kein neues Framework ist.
Ich sehe es jedenfalls nicht als ein Framework. Ich sehe es als etwas, was so Best Practice ist, dass die Unternehmen ihr eigenes Best Practice ermitteln.
Die Welt wird immer komplexer. Das heißt, aus meiner Sicht könnte auch überhaupt, wenn wir ein Framework hätten,
ein Framework allein kann meiner Meinung nach die Komplexität, die wir haben und die ja stetig zunimmt, gar nicht mehr abdecken.
Das heißt, wenn ich sage, es ist für mich kein neues Framework, heißt es für mich, ich kombiniere verschiedene Dinge.
Ich glaube, das haben wir auch immer schon mal wieder dargestellt. Das zeigt sich auch bei unseren Gästen.
Wir haben ein bisschen IT-Service-Management drin, repräsentiert durch ITIL.
Wir haben ein bisschen Agilität drin, durch Scrum unter anderem repräsentiert.
Und wir haben Lean-Management drin mit Kaizen.
Das heißt, die verschiedenen Frameworks und Ansätze, die es gibt, die kombinieren wir einfach nur.
Und vielleicht noch der letzte Punkt aus meiner Sicht jetzt für diesen ersten Einstieg in dieses Missverständnis.
Ich denke auch, dass DevOps etwas ist, was man in der Praxis umsetzen muss, was man erfahren und erlernen muss.
Es hilft nicht, irgendeinen Best-Practice-Ansatz zu haben und den sozusagen nur zu kopieren.
Ich glaube, das ist zum Beispiel etwas, wo…
Wo ITIL auch Schwierigkeiten hervorgerufen hat, wenn ein Unternehmen nur auf die Idee kommt, das zu kopieren.
Es spricht nichts dagegen, von Best-Practice-Ansätzen zu lernen, genauso wie ich von anderen Unternehmen lernen kann.
Also lernen ja als Best-Practice, aber eben das Wichtigste ist, man darf nicht kopieren, meiner Meinung nach.
Und deswegen halte ich es eben nicht für ein Framework, sondern einfach eine Philosophie.
Ja, also da sehe ich eigentlich genau gleich wie du.
Und das ist ja auch eben das Problem.
Mit dem Wort Framework oder auch Best-Practices.
Ich würde DevOps auch eher als Bewegung ansehen und als Emerging-Practices.
Sehr stark wird das ja geprägt durch die verschiedenen DevOps-Events, sei es die DevOps-Days, DevOps-Meetups, die ja inzwischen auf der ganzen Welt stattfinden.
Und wo halt wirklich, wie du sagst, auch aus der Praxis heraus neue Ideen…
Das sind eher so Emerging-Practices.
Ja, die kommen, die dann die Philosophie von DevOps unterstützen.
Und schlussendlich bewährt sich auch das, was Erfolg hat.
Und dann eben das Schöne, wie dann die verschiedenen Dinge dann zusammengebracht werden.
Elemente aus Agile, Lean und Service-Management und anderen.
Und in zwei Jahren schaut dann DevOps wahrscheinlich wieder anders aus, wie es heute ausschaut.
Das macht für mich persönlich jetzt auch den Reiz aus.
Ja, wahrscheinlich ist auch die Frage…
Ob man es überhaupt jemals mit einem Snapshot beschreiben kann.
Wenn es immer in Bewegung ist, dann ändert es sich ja auch.
Und ich glaube auch, das zeigen so meine Diskussionen, dass jedes Unternehmen das ein bisschen anders für sich sieht.
Ich habe in meinen Schulungen, da legen wir ja Wert auf der einen Seite auf Kultur, aber auch auf Automation.
Also zwei grundsätzlich unterschiedliche Bereiche.
Und dann gibt es Schulungsteilnehmer, die beschweren sich, dass wir viel zu viel über Kultur sprechen.
Das Ganze wäre ja…
Da gibt es sehr viel Automation.
Und dann gibt es welche, die genau das Gegenteil sagen.
Die also sagen, hey, ihr habt super toll die Kultur drin.
Hebt hervor, was Kultur bedeutet.
Automation, das kann ja im Prinzip jeder.
Da rede ich über irgendwelche Tools.
Also auch die Sichtweise der Teilnehmer, der Schulungsteilnehmer in diesem Falle, ist total unterschiedlich.
Und das finde ich eben schön, wenn man damit umzugehen weiß.
Ich weiß natürlich auch, dass es schwierig ist, im Unternehmen eine Richtung vorzugeben,
wenn man quasi kein klares Ziel hat.
Ich glaube, es wäre ein schlechter Rat, das Ziel quasi, das fehlende Ziel zu ersetzen,
indem man einfach blind eben ein Framework kopiert, was auf ganz vielen Seiten beschrieben ist.
Man muss einfach probieren, man muss immer wieder anpassen.
Und wie gesagt, die aktuelle Zeit ist heute so komplex.
Die Herausforderungen sind so unterschiedlich, dass ich eben auch im Unternehmen mich immer wieder anpassen muss.
Ja, dann wollen wir uns mal den nächsten auf der Liste anschauen.
Was denkst du?
Können wir machen.
Ich bin bereit.
Aber du bist ja dran, ne?
Ja, genau, ich bin dran.
Dann schaue ich mal da.
DevOps ersetzt agile Produktentwicklung.
Ja, auch ein weit verbreitetes Missverständnis.
Ja, das Problem ist wahrscheinlich mit dem Wort ersetzt.
Ich würde eher sagen, DevOps erweitert oder ergänzt die agile Produktentwicklung.
Weil agile Produktentwicklung ursprünglich natürlich aus dem Dev, aus dem Development raus,
inzwischen auch nicht schon in die Jahre gekommen, kann man sagen.
Agiles Manifest 2001, Scrum, Kanban, eigentlich noch älter.
Und wenn man so die Entwicklung anschaut, also die 90er Jahre, da hat man ja typischerweise noch wasserfallmässig Projekte abgewickelt.
So Projekte sind dann gut und gerne zwei, drei Jahre.
Und dann sind eben die Entwickler, die haben dann zuerst den Move gemacht, haben gesagt, ja, wir müssen da, wenn jetzt mal die Konkurrenz das gleiche in einem halben Jahr macht, da haben sie angefangen auf agil umzustellen.
Aber eben agil selber, beispielsweise auch in der Umsetzung dann mit Scrum, ist ja nicht ausreichend, wenn das ganze System ja nicht erlaubt,
dass man beispielsweise alle zwei.
Wochen oder häufiger effektiv mit dem Produkt und mit dem Service live gehen kann.
Und aus dem raus hat sich ja dann ganz natürlich hat sich eigentlich DevOps entwickelt.
DevOps als natürliche Weiterentwicklung von agil, dass man zum Beispiel sagt, ja, man versucht zu mehr zu automatisieren, auch so die Qualität zu steigen, indem man beispielsweise Tests automatisiert,
indem.
Man früher auch Operations im im Zyklus reinholt dann und das hat schlussendlich hat das die ganze agile Entwicklung bereichert, indem dann halt auch die Qualität gestiegen ist.
Also auch wenn man, denke ich, mit Leuten aus der agilen Welt, die schon seit seit langer Zeit im agilen Umfeld arbeiten, die sagen, ich hab’s wahrscheinlich auch letztes Mal eine Daten Startup gegründet, schon vor x Jahren über DevOps.
Ja.
Ja.
Ja.
Ja.
Und da hat er gesagt, ja, okay, DevOps sagt ihr dem.
Ja, wir machen das schon seit 15 Jahren.
Das ist jetzt natürlich so die die Sicht der agilen.
Na und jetzt gibt natürlich aus Operations Sicht auch oder, dass sich die dann ich denke sich dann Richtung Agilität entwickeln können und was auch noch dazu.
Ich denke auch klassische Phasen, wenn man jetzt Phasen mäßig, Wasserfall mässig vor geht.
Kann man ja auch von automatisieren,
und von dem kulturellen Change von DevOps profitieren.
Was deshalb ersetzen, denke ich, ist das falsche Wort.
Es ist eher, würde ich sagen, es bereichert, ergänzt die agile Produktentwicklung.
Ja, da würde ich dir zustimmen.
Dieses Wort ersetzen ist wahrscheinlich das, was so am meisten stört
oder was einem sofort ins Auge springt.
Ich würde es auch sehen.
Es ist eine Art Fortsetzung, es ist eine Erweiterung,
dass ich die agilen Teams eben erweitere, dass ich die agile Arbeit erweitere.
Und natürlich ist viel Agilität in DevOps drin, aber eben nicht alles.
Und das finde ich eben auch wichtig, immer wieder zu betonen.
Sonst könnte man ja sagen, okay, ich nehme irgendein agiles Produktentwicklungsteam,
packe da so ein, zwei Betriebsleute mit dazu und dann habe ich ja schon DevOps.
Das wäre ja eben auch etwas zu kurz gesprungen.
Also insofern ist für mich eben auch wichtig, nochmal zu sagen,
dass wir da auch schon viel IT-Service-Management drin haben.
Das hören vielleicht die agilen Entwickler nicht so gerne.
Und wir haben auch wirklich viel Lieblingsarbeit.
Lean drin, Lean-Management.
Und auch da, denke ich, sind viele wichtige Aspekte,
die einfach das Ganze ergänzen an der Stelle.
Also insofern habe ich immer wieder gesagt,
agil, Lean und IT-Service-Management.
Und vor allen Dingen, es ersetzt eben dann nicht die Produktentwicklung,
sondern es bereichert das.
Ja, der Gene Kim hat ja mal schön gesagt,
es braucht Entwickler, die so denken können wie Operation-Leute
und Operation-Leute, die so denken können wie Entwickler.
Es bereichert dann auf beide Seiten.
Ja, und wenn man jetzt mal überlegt, die agile Produktentwicklung,
also wenn wir das mit Scrum mal gleichsetzen,
ist schon interessant, wie ich finde, in dem aktuellen Scrum-Guide 2017,
da wird schon mehr auf DevOps und auf Automation und andere Themen hingewiesen.
Das heißt also, da haben Jeff und Ken schon so ein bisschen mehr den Blick
auch auf das, was aktuell sich quasi am Markt tut,
mit Ansätzen, eben nicht mit Frameworks, aber mit Ansätzen.
Genau.
Und insofern,
denke ich, gibt es auch ganz wichtige Dinge, die aus der Agilität kommen,
die aus dem Scrum kommen.
Wenn wir einfach mal schauen, bei Scrum haben wir ja potenziell auslieferbare Produktinkremente.
Ein richtig schön sperriger Begriff, der auch nicht immer einfach zu erklären ist.
Aber aus Sicht von DevOps ist es für mich ganz einfach.
Das, was die Scrum-Teams liefern, das liefern sie jetzt eben nicht in irgendeine Testumgebung,
sondern sie liefern es in die Produktivumgebung.
Also, ich sage mal, verbal gesehen nur ein kleiner Schritt,
aber inhaltlich ist es natürlich dann viel.
Ich bin mit dabei, um quasi bis in die Produktivumgebung zu liefern als Team an der Stelle.
Also, das ist, was du auch sagtest, es ist die Fortsetzung.
Wir erweitern die Aufgaben der agiligen Teams einfach, um auch ein bisschen Produktivsetzung.
Software is always in a releasable state.
Das ist eine der Definitionen von continuous delivery.
Und wenn man sich das mal so auf die Zunge zergehen lässt,
was heißt in a releasable state, kann man sogar so interpretieren und sagen,
ja, es ist sogar betragen.
Also, ich arbeite so, auch wenn ich zum Beispiel agil arbeite,
dass ich jederzeit live gehen könnte.
Und zwar auch so, dass es dann im Sinne jetzt von Service Management
halt nicht funktionale Anforderungen wie Security, Performance etc. das erfüllt.
Ja, ich habe in meinen Schulungsunterlagen so einen Satz drin stehen,
dass wir eben, was du sagtest mit dem continuous delivery,
dass wir quasi die Release-Setzung oder den Release,
den Release-Plan, die Produktivsetzung,
dass wir das damit eben in die Hände des Business legen.
Das Business könnte das Release live gehen lassen,
wenn wir das eben erfüllen, was du eben gesagt hast.
Und die gucken immer etwas ungläubig,
was manche können sie sich noch nicht vorstellen,
aber das ist ja genau das Ziel, wo wir hinwollen.
Das stimmt, ja.
Was ich dann häufig mache, auch wenn jetzt Teams,
sagen wir, die mit agil arbeiten, zum Beispiel nach Scrum,
dass wir zusammen antworten,
mit der Definition of Done arbeiten.
Wir machen das jeweils im Rahmen von Retrospektiven
und überlegen uns, was heisst jetzt Done für uns?
Oder Done hat früher vielleicht mal geheissen,
ja, okay, wir haben Acceptance-Kriterien, sind erfüllt,
da haben wir das weiterentwickelt, okay, Peer-Review,
da haben wir gesagt, okay, jetzt tun wir mal,
Done heisst beispielsweise, wir haben auch Performance-Tests durchgeführt,
also die, logischerweise muss man die dann automatisieren,
oder wir haben gesagt, ja, gewisse Security-Anforderungen,
die immer wieder kommen, die werden auch Teil von Done,
und das ist so eine Reise, und irgendwann kann man dann
vielleicht wirklich sagen, ja, unser Done, also jederzeit auch,
wir könnten jederzeit live gehen, oder so ist es eigentlich,
aus dieser Sicht ist es schon eine natürliche Weiterentwicklung
von Agilität, aber wie gesagt, klassische Projekte, denke ich,
die können auch davon profitieren.
Ja.
Zum nächsten, oder?
Drittes Missverständnis, was wir hier für uns so aufgeführt
und aufbereitet haben, DevOps passt nicht zu IT-Service-Management.
Das ist natürlich unsere Hauptdomäne oder unsere historische Domäne,
deine und meine, und auch das, finde ich, ist eben ein Missverständnis.
Das heißt, DevOps-Praktiken, meiner Ansicht nach,
können natürlich kompatibel zu IT-Service-Management gestaltet werden,
weil wir natürlich viele Ziele, die wir mit IT-Service-Management,
verfolgen, mit DevOps auch verfolgen und durch DevOps-Praktiken unterstützen.
Allein schon das Thema Automation, wie viel Aufwand und Ärger
wir uns im IT-Service-Management ersparen können,
wenn wir Dinge automatisieren, finde ich das schon einen ganz wichtigen Punkt.
Also insofern passt DevOps aus dieser Sicht heraus schon mal sehr gut
zu IT-Service-Management.
Und wenn ich mir dann so ein, zwei Teile mal rauspicke vom IT-Service-Management,
dann das ganze Thema.
Also CMDB, CMS, Configuration Management, das sind natürlich alles Dinge,
die Pflege dieser Datenbank, das war immer schon ein Automatisierungsgebiet,
wo man eigentlich nur wirklich sinnvoll arbeiten konnte,
wenn man das automatisieren konnte.
Und dadurch, dass ich jetzt die Entwicklung mit Eime ziehe quasi,
da habe ich ja noch bessere Daten, noch genauere Daten.
Und wenn ich den ganzen Fahrrad Continuous Delivery automatisiere,
dann habe ich auch automatisch eine,
die bessere CMDB.
Also auch da, finde ich, ist es wirklich ein sehr gutes Beispiel dafür,
dass DevOps eben IT-Service-Management sehr gut ergänzen kann, unterstützen kann.
Ja, und da können dann eben auch die Entwickler,
die können, vor allem die können was lernen.
Weil historisch, du hast ja DevOps Wall of Confusion,
jetzt sagen wir, okay, die Operations-Leute müssen lernen,
agiler zu werden, zusammenzuarbeiten mit den Entwicklern.
Aber auf der anderen Seite ist es auch ein Bereich,
in dem die Entwickler sich ja historisch nie für IT-SM interessiert haben.
Aber ich denke schon, also ein Kandidat ist zum Beispiel auch das Problem-Management.
Problem-Management, denke ich, eine der Practices aus dem IT-Service-Management,
die dann hilft, ganz im Sinne jetzt auch vom Second Way, vom Gene-Came-Feedback,
von rechts nach links, wiederkehrende Störungen,
da auch dann…
Proaktiv, oder das an der Wurzel zu fassen
und Probleme zu beheben und Störungen zu verhindern.
Configuration-Management sehe ich auch so.
Andere, denke ich, Gebiete, zum Beispiel das Event-Management,
zum Beispiel das ganze Continuous-Monitoring,
wo, sagen wir, auch wenn man jetzt ITIL als Framework anschaut,
da hat es super Tipps drin, die helfen,
wie man ein Continuous-Management,
Continuous-Monitoring aufbauen kann,
ohne dass man jetzt das Rad neu erfinden muss.
Ja, richtig.
Also, was du auch sagtest beim Thema Störungen,
beim Incident-Management, sehe ich ganz genauso.
Ich habe im DevOps ja das Ziel, schnell Störungen zu erkennen
und auch schnell reagieren zu können.
Und da wird jeder ITIL-Freak sagen,
genau das ist das, was wir auch wollen an der Stelle.
Also, insofern gibt es da wirklich große Übereinstimmungen
und man kann sich gut ergänzen.
Und wenn ich ergänzen nochmal…
Ich finde aber auch im Umkehrschluss,
dass IT-Service-Management auch sehr schön
das Thema Agilität unterstützen kann.
Denn wir haben dort, wie du auch sagtest,
tolle Tipps, tolle Practices zum Thema,
wie gehe ich mit Kunden um?
Was sind Services?
Wie beschreibe ich Services?
Service-Level-Management?
Wie vereinbare ich Services?
Das sind alles Dinge, die man quasi im DevOps
sehr schön aus IT-Service-Management übernehmen kann
und weiterentwickeln kann.
Weil das sind alles Sachen, die in den Bereichen,
z.B. Lean-Management und Agile, eben nicht auftauchen.
Also auch da denke ich, kann IT-Service-Management
auch etwas dazu beitragen, um das ganze Thema rund zu machen.
Also, ich finde auch definitiv, ITSM hilft.
Aber es gibt auch dann viele Aspekte,
wo es bei jedem Framework manchmal hilft, manchmal nicht.
Ich denke, die große Inspiration für DevOps
kommt schon vor allem aus dem Lean,
dann aus dem Agilen und natürlich auch ein bisschen
aus dem IT-Service-Management.
Aber ich würde es genau in der Reihenfolge formulieren.
Aber das ist jetzt so meine persönliche Meinung.
Ja, klar.
Also insofern, aber wir haben ja zu Anfang schon gesagt,
es ist kein neues Framework
und jedes Unternehmen muss die eigenen Erfahrungen machen.
Und je nachdem, wie die Erfahrungen im Unternehmen sind,
also ob es groß ist, ob es klein ist,
ob es viele Provider hat, ob es viel selbst macht,
es gibt sehr viele unterschiedliche Rahmenbedingungen,
und die haben einen Einfluss darauf,
wie gestalte ich denn meine DevOps-Organisation,
wenn ich überhaupt in so eine Richtung gehen möchte an der Stelle.
Ja, also insofern, ich glaube auch schon,
dass man aber auch, da haben wir vielleicht
ein bisschen unterschiedliche Einschätzungen.
Ich glaube schon, dass auch so Themen wie Governance
und das ganze Thema Management, also quasi als Überbau,
dass das auch Dinge sind, die wir aus dem IT-Service-Management
sehr gut übernehmen können, quasi als Rahmen,
in dem die DevOps-Teams dann,
sauber und gut strukturiert arbeiten können.
Das ganze Thema Portfolio, Service, Katalog.
Natürlich kann ich mich hinstellen
und kann die Teams das bestimmen lassen,
bin ich auch mit dabei,
aber die bestehenden Strukturen im Unternehmen,
die sind ja da, und da, denke ich,
hilft es schon noch, solche etablierten Prozesse zu haben
und die auch zu nutzen.
Aber man muss sie sicherlich anpassen
und DevOps-Teams da so reinbringen,
also reinmerchen.
In dem Kontext auch, du hast das Portfolio-Management,
erwähnt, also das Scaled-Agile-Framework.
Ich weiss nicht, wie es in Deutschland ist,
aber in der Schweiz ist es,
also ich glaube jetzt bei grossen Unternehmen,
Enterprise-ITs, wo eigentlich dann auch die Governance
sehr stark geprägt wird durch solche Frameworks.
Also Portfolio, Programm und dann auf Projekt- oder Team-Ebene
ist dann halt Scrum oder Kanban
und dann halt ergänzt durch DevOps-Mechanismen.
Ja, richtig.
Aber auch da wieder, was wir zu Anfang hatten,
eigentlich ist es ja ein Luxus-Problem.
Ich kann mir als Unternehmen überlegen, was nehme ich?
Nehme ich jetzt Governance aus Safe,
nehme ich Governance aus Covid beispielsweise,
haben wir ja nicht nur ITIL.
Also ich kann mich eigentlich bedienen,
das ist natürlich aufwendig
und das ist auch mit viel Arbeit verbunden.
Man muss Gehirnschmalz investieren.
Aber wir waren ja bei dem Missverständnis,
DevOps passt nicht zu IT-Service-Management
und das passt nicht so.
Also das passt sehr gut,
und kann sich sehr gut gegenseitig befruchten.
Ja, da sind wir uns einig, denke ich.
Sehr schön.
Mhm.
DevOps macht den IT-Betrieb überflüssig,
respektive NoOps.
NoOps, da habt ihr vielleicht schon den Begriff schon mal gehört.
Das ist ein ursprünglicher Begriff,
der wurde geprägt vom CEO von Netflix.
Der Name fällt mir jetzt gerade nicht mehr ein.
Aber er hat eigentlich gesagt,
ja, für ihn DevOps,
also er heisst es auch,
er braucht keine Operation mehr.
Das ist so der Begriff auch vom Full-Stack-Developer.
Der hat alles selber im Griff.
Shift, Left,
der kümmert sich auch um die ganzen nicht-funktionalen Dinge.
Und Operation ist eh alles,
das dann Infrastructure as Code,
das kommt alles aus der Cloud raus.
Und ja,
gut, da muss man erstens mal dazu sagen,
heute, wie Netflix funktioniert,
das ist definitiv nicht mehr so.
Auch die haben Operation.
Und Operation ist ja,
man darf das jetzt, denke ich,
weniger als Funktion anschauen,
sondern es gibt, sagen wir,
gewisse traditionelle Aufgaben, oder?
Die müssen auch, sagen wir,
im DevOps-Team oder im DevOps-Konstrukt
wahrgenommen werden.
Ich denke, was sich schon ändert,
ist die Rolle von Operation.
Also Operation,
und das ist übrigens auch interessant,
eine der ursprünglichen Ideen von IT-Service-Management,
Operation muss viel früher im Zyklus,
im Lebenszyklus von Produkten und Servicen
berücksichtigt werden.
Also Shift, Left.
Das kann dann schon de facto bedeuten,
dass halt klassische Operation-Abteilungen schrumpfen.
Also nicht mehr so die Denke,
ja, etwas wird entwickelt,
wird übergeben an jemand anderen,
über Prozesse etc.,
sondern halt die Aufgaben,
die müssen weiterhin wahrgenommen werden.
Aber früher Shift, Left.
Und dann ist auch, ich denke,
im Verständnis von DevOps ist,
oder das sehe ich zumindest oft in der Praxis,
ist Operation,
also im DevOps ist sehr stark auch der Enabling,
sagen wir, Infrastructure Layer.
Also die ganze Infrastruktur zur Verfügung stellen.
Cloud, also das kann dann auch eine private Cloud sein,
oder dann halt Public Cloud,
da braucht es auch die Governance dann dazu.
Und mit Infrastructure as Codes,
den ganzen darunter liegenden Layer,
damit dann die Teams,
you build it, you own it,
da effektiv auch beispielsweise Continuous Delivery machen können.
Ohne diesen Layer ist das nicht möglich.
Also es findet dann,
ich denke in der Zukunft ist es nicht mehr die Aufgabe von Operation,
Code in die Produktion zu nehmen,
das zu betreiben,
sondern das den anderen einfacher zu machen,
damit sie das selber machen können.
Und auch andere,
also wenn jetzt von No Ops,
finde ich deshalb auch einen schlechten Begriff,
weil es wird weiterhin,
es wird Störungen geben,
es wird weiterhin klassische,
Monitoring-Aufgaben.
Die Frage ist einfach, wo wird das dann wahrgenommen?
Es ist dann, denke ich,
nicht mehr ein separates Department,
weil das etwas, was ja DevOps definitiv nicht will,
sondern ich glaube Operation muss sich einfach,
ja, muss sich ein bisschen neu orientieren.
Und ich habe es glaube ich schon mal gebracht,
da ist dann eben nicht No Ops,
sondern New Ops eher.
Aber die müssen dann auch entsprechend offen sein,
sich zu wandeln,
statt wie anhin oft halt dann zu mauern,
zu sagen ja,
immer nein zu sagen und sagen nein,
das kommt jetzt nicht in die Produktion,
sondern auch sich da zu öffnen.
Und wenn das nicht der Fall ist,
dann wird dann eben aus,
dann wirklich No Ops draus,
weil dann,
das sehe ich auch oft,
Entwicklungsabteilungen,
die dann das Zepter selber in die Hand nehmen
und,
und sich dann die Dinge auf dem Markt selber beschaffen,
beispielsweise via Public Cloud etc.
Also deshalb,
DevOps macht,
denke ich,
nein,
macht den IT-Betrieb nicht überflüssig,
aber der IT,
die Rolle des IT-Betriebs wird sich wandeln
oder wandelt sich bereits.
Ja,
ich glaube auch,
dass sie sich schon aktuell schon stark wandelt.
Da ist ja auch ein gewisser Druck da durch,
durch Cloud-Anbieter,
du hast es ja eben schon gesagt.
Das heißt,
eine gewisse Notwendigkeit ist da.
Das, was du eben sagtest mit dem Mauern,
nein, das kommt nicht in die Produktion.
Das kann natürlich sein,
dass man gemauert hat aus Prinzip,
aber es kann ja auch sein,
dass man die Gründe gehabt hat,
warum es nicht in die Produktion geht.
Und das finde ich eben einen weiteren Punkt.
Du hast ja gesagt,
sie müssen sich wandeln und das,
oder die Arbeit muss sich wandeln.
Und das finde ich eben dann nur als Vorteil für Ops,
dass die Erfahrung und die Verantwortung,
das Verantwortungsbewusstsein,
das, was wir einfach viel früher in den Lifecycle einbeziehen
und dass wir das jetzt auch wirklich umsetzen.
Du hast ja gesagt,
das auch schon gefordert.
Ja,
es ist ja auch nichts Besonderes zu sagen,
hey,
viel früher einsteigen.
Aber ich glaube,
dass wir jetzt an dem Punkt sind,
wo wir in den IT-Organisationen feststellen,
die Notwendigkeit ist da
und die Sinnhaftigkeit wird auch so gesehen.
Also insofern,
New Ops,
ja,
New Ops heißt,
sie bringen ihre Erfahrung mit ein,
sie bringen ihre Verantwortung,
ihr Governance-Thema,
ihr Governance-Thema mit ein
und sorgen dafür,
dass wir viel früher diese Dinge beachten
und damit auch mehr Qualität produzieren.
Und,
was ich ja auch nochmal ganz interessant finde,
es gibt ja ganz viele ungeliebte manuelle Tätigkeiten im Operations.
Das sichert zwar Arbeitsplätze,
aber ist nicht unbedingt sinnstiftend an der Stelle.
Also insofern,
auch da wieder das Thema Automation,
dadurch,
dass wir eben quasi über DevOps,
auch ganz stark über Automation reden
und es auch umsetzen,
ändert sich ja auch das Thema Ops.
Sprich,
wir kriegen eben,
wir haben den Entfall von vielen manuellen ungeliebten Tätigkeiten,
einfach weil wir Dinge automatisieren
und dazu muss aber auch Ops die Erfahrung mit einbringen
und muss auch die Anforderungen an die Automatisierung quasi formulieren
und mit in den Teams entsprechend eben formulieren.
Ja,
also da finde ich auch,
ja,
aber das produziert dann auch sehr viele Ängste.
Sagen wir,
Leute,
die halt im Vergangenheit
sehr viele repetitive Aufgaben gemacht haben
und da ist jetzt ein gewisses Automatisierungspotenzial,
da,
dass sich dann die Leute halt die Frage stellen,
ja was,
was,
was passiert mit mir in der Zukunft?
Jetzt kann man das natürlich als Gefahr sehen,
einerseits,
aber auch als Chance.
Also primär würde ich jetzt,
für mich würde ich sagen,
ja auch,
dass der Job spannender wird.
Aber die,
das Problem ist natürlich dann mit den Skills.
Das sieht man auch schön,
zum Beispiel im Testing.
Früher sehr viel,
sagen wir Testausführende,
während heute,
klar die,
weil ja viel Automatisierung,
auch Testautomatisierung,
das heisst,
es braucht wenige Testausführende,
aber Leute,
die dann die Skills haben,
zum Beispiel Tests zu automatisieren
oder in die Richtung.
Und dann ist dann immer die Frage,
ja,
die Leute wollen vielleicht,
aber sie können nicht von den Skills her.
Das ist dann schon,
schon auch problematisch.
Auf der anderen Seite ist ja,
Industrialisierung ist etwas,
das vermutlich schon seit 200 Jahren stattfindet,
aber die Jobs sind ja nicht weniger geworden,
es sind immer mehr geworden.
Und ich glaube,
in der IT ist auch,
obwohl jetzt immer mehr automatisiert wird
oder Komoditisierung durch Cloud,
die Jobs werden mehr,
aber es ist halt mehr,
es wird anspruchsvoller,
denke ich.
Und da ist auch die Frage,
können sich Operationsleute,
die,
sagen wir,
sich in automatisierten Bereichen bewegt haben,
also die jetzt automatisieren,
können sich da weiterentwickeln?
Und wenn nicht,
dann ist es halt für die schon schwieriger.
Ja, das glaube ich auch.
Aber da stelle ich fest,
zumindest bei uns in Deutschland,
dass wir ja schon verantwortungsvolle Firmen haben,
verantwortungsvolle IT-Organisationen,
die sich ihrer Verantwortung eben bewusst sind
und auch dafür sorgen,
dass die Mitarbeiter diesen Weg mitgehen,
wenn sie sich eben öffnen.
Das hast du ja auch schon zu Anfang gesagt.
Sie müssen sich öffnen
und sie müssen das als Chance sehen.
Wer dort mauert,
der hat vielleicht früher die Produktivsitzung gemauert
und jetzt mauert er sich dann seine eigene Sackgasse.
Ja, ich finde,
da gibt es so ein schönes Dreieck.
Dürfen,
wollen und können.
Das eine ist ja,
wir dürfen,
klar,
die Firma sagt doch,
also ihr dürft,
wir wollen das sogar,
dass ihr euch in die Richtung entwickelt.
Und dann ist schon die Frage damit,
aber will er das überhaupt?
Und vielleicht,
ja, okay, will er es,
aber da gibt es auch die Fälle,
wo man aus dem Testausführen,
dann kannst du nicht von morgen auf heute
einen Testautomatisierer machen.
Das sind komplett andere Skills.
Da kann dann eben schon noch der Hund begraben sein.
Weil da finde ich einfach dann auch wichtig,
deswegen haben wir auch diese Missverständnisse,
die wir mal rausgepickt haben,
dass man den Betriebsleuten klar macht,
dass man das Wissen schon noch hat,
was man noch braucht.
Natürlich verändert sich die Arbeit,
aber das Wissen,
die Erfahrung,
die die gesammelt haben,
das sind Schätze,
die kann ich einem Entwickler,
kann ich ihm das gar nicht erklären.
Also die Erfahrung,
die der Betrieb mitbringt,
die braucht man auch bei Übergangsphasen in die Cloud,
wenn man wirklich die Cloud,
also wenn man eine externe Cloud hat
oder wenn man eine eigene,
eine private Cloud aufbaut im Unternehmen.
Das Wissen brauche ich ja auch an der Stelle.
Also insofern,
da sind wir uns eben auch einig,
der DevOps,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
da sind wir uns eben auch einig,
der DevOps macht den IT-Betrieb nicht überflüssig,
sondern verändert die Arbeit
und wir können nur hoffen,
dass sich die Leute mitgenommen fühlen,
dass sie mitgenommen werden
und dass sie sich einbringen können.
Ja,
ist eine Chance schlussendlich.
Ja,
ja Mensch,
das fünfte,
das fünfte Missverständnis,
einen können wir noch
oder zwei.
DevOps ist eigentlich nur Everything as Code.
Das heißt,
wir reden eigentlich bei DevOps nur über Automation.
Also auch das,
das ist ein Missverständnis.
Denn,
das denke ich,
haben wir schon durch die vorherigen Missverständnisse
ein bisschen klar gemacht,
wir reden eben nicht nur über Automation.
Natürlich haben wir bei DevOps oder mit DevOps
einen ganz hohen Automationsanteil,
aber das ist eben nicht alles,
weil wenn ich jetzt beispielsweise über die Prozesse
nicht nachdenke,
dann automatisiere ich ja nur Teilschritte
eines gesamten Prozesses.
Das heißt,
ich brauche einen Gesamtüberblick über alle Prozesse,
über den gesamten Ablauf,
über die gesamte Wertschöpfungskette,
das heißt,
Automation,
sehr schön,
aber ich muss eben die gesamte Wertschöpfungskette im Blick haben,
muss diese drei Wege,
muss den Rückfluss einfach über die gesamte Kette sehen.
Also insofern,
ja,
Automation,
aber es reicht eben nicht,
nur einen Teil zu betrachten.
Ja,
ich denke,
also DevOps ist sicher nicht möglich ohne Automation.
Ja,
da hatten wir auch früher schon mal drüber gesprochen.
People,
Prozesse,
Technologies,
schlussendlich ein Aspekt dann.
Und wir brauchen ja auch Kultur.
Also das ganze Thema,
was wir aus der Agilität kennen mit Experimenten,
mit Fehlerkultur,
mit Dingen mal ausprobieren und so weiter.
Also die vielen Dinge,
die wir aus der Agilität kennen,
die muss ich in eine DevOps-Kultur einbringen,
genauso wie ich auch die Betriebsaspekte in diese Kultur einbringen muss.
Also ich glaube wirklich einen großen Mehrwert
oder das Sahnehäubchen ist zum Beispiel einfach,
eine gemeinsame Kultur zu schaffen,
eine Kultur,
wo sich alle wiederfinden,
wo es dann eben auch wirklich Spaß macht
oder vielleicht wieder Spaß macht,
für die IT zu arbeiten.
Du hast ja immer so schöne Zitate vorhin gebracht
und ich habe da auch ein schönes Zitat gefunden
von dem Christopher Little,
der hat eben gesagt,
bei DevOps geht es nicht um Automatisierung,
genauso wie es in der Astronomie nicht um Teleskope geht.
Also ich brauche das zwar,
aber es gibt ein bisschen mehr an der Stelle.
Also insofern,
ja,
Missverständnis ausgeräumt hoffentlich an der Stelle.
DevOps ist,
DevOps ist mehr als Automation.
Das muss ich jetzt gleich noch toppen,
nochmal mit einem Zitat.
A fool with a tool is still a fool.
Ja stimmt, richtig.
Von wem kommt das eigentlich?
Von Herrn Kupf unbekannt.
Keine Ahnung,
ich glaube das ist so ein bisschen allgemein gut,
aber da gibt es sicher einen,
der das zuerst gesagt hat.
Man muss mal gucken,
wo man den findet.
Also insofern,
Everything as Code,
ja auf jeden Fall,
aber es ist eben nicht alles.
Wollen wir noch einen?
Also Zeit haben wir glaube ich noch.
Der ist ja so von der Reserve list.
Ja, mach mal.
Knapp 40 Minuten.
Ja, der tönt im ersten Moment ein bisschen blöd,
aber ich bin halt ab und zu stoßig auf diese Aussage.
Entwickler haben direkten Zugriff auf die Produktion.
Nein, natürlich nicht.
Aber zuerst einmal,
woher kommt dieses Missverständnis?
Also einerseits,
ist halt wenn man hört,
wie Continuous Delivery, Continuous Deployment,
z.B. Amazon,
die machen 5000 Deployments am Tag.
De facto,
wenn Entwickler Code eingecheckt und das hat alle Tests durchlaufen,
das geht in die Produktion.
Das ist dort so,
bei anderen Firmen auch.
Und dadurch kann ja dann das Missverständnis,
jetzt hat der Entwickler direkt Zugriff auf die Produktion.
Aber wenn man jetzt,
gut, das ist halt ein bisschen jetzt technisch auch,
aber wenn man sich Continuous Delivery anschaut,
die DevOps Pipeline ist ja weiterhin so und muss auch so sein,
auch aus Governance Gründen.
Der Entwickler entwickelt auf einer Entwicklungsumgebung
und was ja weiterhin stattfindet,
ist dann der Transport und die ganze Change Control,
einfach in einem hochautomatisierten Grad.
Das heisst,
wenn das wird dann direkt überführt in eine Testumgebung,
es werden automatisierte Tests durchgeführt,
also alle,
die das V-Modell kennen,
das fängt dann beim Unit Test System Test etc.
Dann aber auch,
was ja früher vergessen gegangen ist,
nicht funktionale Tests wie Performance, Security, Continuity etc.
Und dann,
wenn das alles erfolgt,
dann wird das in eine zum Beispiel Produktionsumgebung überführt.
Vielleicht auch nur für ein paar wenige User,
je nachdem welche Teststrategie das man fährt.
Man kann ja dann sagen,
ja,
dann lässt es mal als Piloten laufen
und dann,
wenn kein negatives Feedback,
wird es dann ausgeweitet auf den Rest.
Aber in dem Sinn ist ja auch ganz im Sinne von DevOps,
dass es wird,
dass es kein direkter Zugriff auf die Produktion,
dass uns das weiterhin separiert,
Change Control,
aber halt einfach im,
wenn wir jetzt technisch oder prozessmässig gesprochen,
einen hohen Grad an Automatisierung.
So, also das ist jetzt so meine Sicht.
Ich weiss nicht wie du Dirk,
bist du auch schon über diese Aussage gestossen,
Entwickler haben direkten Zugriff auf die Produktion.
Das kommt manchmal bei,
wenn wir über das Thema Governance sprechen,
dann kommt das manchmal,
aber so wie du es im Prinzip gesagt hast,
kommt dann immer auch als Erklärung
und ich glaube,
dass die meisten das dann auch an der Stelle auch verstehen.
Ja, genau.
Ja Mensch,
dann haben wir heute sechs Missverständnisse
und ich glaube,
wir sollten die nochmal aufzählen
und zwar eben,
dass wir sie so formulieren,
damit keiner rausgeht aus dem Podcast
und sich quasi das Missverständnis merkt.
Also ich fange mal an mit meinem ersten Missverständnis
und formuliere das mal positiv.
DevOps ist kein neues Framework.
DevOps ist eine Philosophie,
aber kein neues Framework.
Dann versuche ich das im genau gleichen Stil für den nächsten,
nämlich DevOps ergänzt und ersetzt nicht
die agile Produktentwicklung.
Jawohl, dann mache ich weiter mit dem dritten.
DevOps passt zu IT-Service-Management.
DevOps kann gut von IT-Service-Management ausgehen.
Man muss IT-Service-Management lernen und umgekehrt.
Also DevOps passt sehr wohl zu IT-Service-Management.
Dann DevOps macht IT-Betrieb überflüssig aka NoOps.
Nein, die Aufgaben von Operation wird es weiterhin brauchen.
Ist halt einfach das Bild von Operation,
das klassische Operation,
das sich wandeln muss Richtung NewOps.
Jawohl, da bin ich wieder dran.
DevOps ist mehr als Automation.
DevOps ist nicht nur Everything as Code.
DevOps ist mehr als Automation.
Und DevOps besteht zwar zu einem hohen Teil aus Automation,
aber es gibt noch viele andere wichtige Dinge.
Insofern, DevOps ist mehr als Automation.
Dann Entwickler haben direkten Zugriff auf die Produktion.
Nein, natürlich nicht.
Das ist Blödsinn.
Ja.
Jetzt hast du mich aber geschockt.
Ja.
Jawohl, sehr schön.
Ja, dann haben wir doch wieder eine Podcast-Folge hier gemeinsam über den Weg gebracht.
Das ist jetzt die letzte Einstellige.
Also insofern, mir macht es Spaß.
Ich finde es schön.
Es ist ein schöner Austausch.
Und man sieht ja auch und hört an den Feedbacks,
dass es bei den Kunden auch ankommt,
dass es Leute gerne hören.
Gut, dann sind wir jetzt durch, Alex.
Ich habe ja gesagt, mir hat das Spaß gemacht.
Mir macht es immer wieder Spaß.
Beim nächsten Mal.
Beim nächsten Mal haben wir dann wieder einen Gast
oder vielleicht sogar auch mehrere Gäste hier im Podcast.
Wir haben ein Unternehmen.
Und das Unternehmen wird uns ein bisschen was aus der eigenen Praxis berichten.
Insofern verraten wir den Namen mal noch nicht.
Es ist aber ein ganz interessantes Unternehmen.
Der eine oder andere wird es vielleicht kennen.
Aber ja, seien Sie gespannt.
Seid ihr gespannt auf den nächsten Podcast.
Ich verabschiede mich.
Auf Wiederhören, auf Wiedersehen, wo auch immer.
Dir war Dirk Söhner.
Ja, vielen Dank auch von meiner Seite.
Es hat mir auch wieder riesig Spass gemacht.
Und ja, ich freue mich auf den nächsten Podcast.
Dann hört man sich wieder in einem Monat.
Bis dann, auf Wiederhören.
Tschüss.
Tschüss.
Tschüss.
Tschüss.
Tschüss.