Transkript: Devops Redux

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim PIS Podcast.

Heute Episode 56 und wir reden über DevOps.

Hallo Jochen.

Halli, hallo, Dominik.

Hallo.

Hi.

Hallo.

Ja, also wir haben wieder einen Gast dabei und wir fangen aber tatsächlich heute wieder an mit News, wie ihr schon kennt.

Ja, genau.

Was gibt es denn für News noch?

Es gab wahrscheinlich ganz viele.

Ich habe mir nicht so viel aufgeschrieben, sondern nur so, ja, es gab jetzt eine Pandas-Release vor kurzem 222.

Da ist jetzt auch irgendwie, also seit 2.2 glaube ich, irgendwie Arrow unten drunter und NumPy 2.0 und so.

Also Speed und Performance und sowas.

Genau, und ja.

Ein paar Breaking Changes.

Gar nicht so viel.

Nee, ist, glaube ich, diesmal gar nicht so schlimm mit Pandas 3.0, das kommt dann irgendwann im nächsten, wird, wenn da wird, glaube ich, umgestellt, dass default-mäßig dann immer Copy und Write verwendet wird und nicht mehr.

Also momentan ist es ja immer so eine Sache.

Manchmal sind Operationen halt irgendwie verhalten dann die Daten direkt und manchmal hat man halt irgendwie eine Kopie und ist ein bisschen unklar.

Und die Zukunft soll eher so sein, dass halt immer Copy und Write, halt quasi halt so umgesetzt wird.

Und das ist aber jetzt noch nicht passiert.

Also insofern ist noch, glaube ich, noch nicht so viel Inkompatibilität dabei.

Aber ehrlich gesagt, ich weiß auch nicht, weil ich das auch schon eine ganze Zeit lang nicht mehr so richtig verfolge.

Ansonsten war noch Wactail 6-Release.

Da ist irgendwie so ein neues Interface für Filtern und Suche und so drin.

Und ja, Support, offizieller Support für Django 5.

Es hat auch schon vorher funktioniert, aber jetzt ist halt offizieller Support drin.

Schon reichlich, dauert immer so ein bisschen, ne?

Wenn man Wecktile lassen möchte, dann muss man mit Django oft ein bisschen warten.

Ja, wobei es meistens dann, also inzwischen geht es eigentlich fast immer.

Es ist halt nur so, dass halt manchmal.

Genau, und das ist das Hauptproblem, was ich mal hatte, war tatsächlich, dass so die Pipelines auch dann oft kaputt fahren oder Sachen nicht gingen.

Ja, aber das ist schon seit einiger Zeit passiert, dass.

Also ich habe tatsächlich der Grund, warum ich Wactail rausgeschmissen habe, war tatsächlich, dass sie so lange gebraucht habt, um zu stellen, weil ich gerne auf das neuere Django fahren wollte.

Ja, ja, das ist immer so ein Problem.

Also ich fahre eigentlich immer aktuelles Django und da halt auch immer aktuelles Wectail und ich habe jetzt schon seit einiger Zeit eigentlich keine Probleme mehr, aber ja, das ist immer so ein bisschen.

Du nutzen mit deinen eigenen Monkey-Patches und deine eigenen Django.

Nein, nein,

nein, nein, nein.

Genau, ansonsten, ja, was ist noch passiert?

Gar nicht direkt Python, aber na, nah dran.

Jetzt wo vor kurzem, ich weiß nicht, wann das war, das war aber auch noch nicht so lange her.

Das Django direkt, das da eingebaut wurde, Support für Redis.

Ah, stimmt.

Oh Moment, Redis auch noch so eine News Redis ist.

Die haben sich von der Open Source Community ein bisschen verabschiedet.

Was nicht so eine coole Nachricht ist eigentlich.

Aber es gibt ganz viele Forks.

Das ist das Gute daran.

Ja, ich weiß nicht, es gibt einen besonderen.

Ich fand jetzt While-Key.

Nee, es gibt da ganz unterschiedliche Philosophien da mancher.

Also ich weiß nicht, ob es sich da lohnt, schon auf irgendeinen zu nennen, weil das wird sich dann herausstellen, wer da irgendwie interessant bleibt.

Ich glaube, Walkie.

Ja, kann schon sein.

Aber es gibt da noch eine Menge andere.

Und ja, das ist

die ganze Zeit oder schon Key Value Store, While Key.

Kommt natürlich von Valkyrie.

Ja, also ist halt ein Problem, aber ich finde, das ist halt so ein bisschen exemplarisch, irgendwie, was halt das Problem dann ist, wenn man halt irgendwie gezwungen ist, ein Geschäftsmodell draus zu machen.

Ja, Open Source hat ein Riesenproblem, glaube ich, ja.

Naja, also das generelle Problem ist halt an der Stelle, dass die ganzen Hyperscaler halt dann irgendwie quasi das nehmen, dann selber ein Geschäftsmodell draus machen.

Und aber auch zu wenig zurückgeben dann davon, ne?

Ja, da ist halt noch nicht so richtig klar, wie man damit umgeht.

Ja, muss man mal schauen.

Aber gut, also ich würde jetzt nicht denken, dass das irgendwie besonders schlimme Konsequenzen für irgendwen hat, dann halt irgendwie einen Fork.

Oder man versucht, das irgendwie anders zu machen, weil ob das immer so eine gute Idee ist, da Redis zu verwenden, ist sowieso, ich finde, das wird ein bisschen zu viel verwendet.

Was magst du an Redis denn nicht?

Das ist halt ein zusätzliches Ding, was man mitdeployen muss.

Und das halt irgendwie spezielle Dinge hat, auf die man Rücksicht nehmen muss und so.

Und wie würdest du sonst sowas lösen?

Direkt die Datenbank nehmen?

Datenbank immer direkt, auch für Caching?

Ja, warum nicht?

Und auch für alles Serialisierte von den ganzen.

Naja, also du kannst ja auch einfach quasi das, was du sozusagen in Redis reinschreibst, auch in deine Datenbank reinschreiben.

Ja.

Aber das.

Also muss man natürlich ausprobieren oder ins Fallsystem oder wie auch immer.

Also die Frage ist, brauchst du da halt.

Natürlich hat Redis-Vorteile, wenn du, aber die Frage ist, brauchst du diese Vorteile wirklich oder brauchst du das gar nicht, denkst du bloß, dass du es brauchst und deployst dann im Schwab.

Ja, aber der Read muss halt dann vorher, damit es irgendwie ordentlich schnell ist, dann schon irgendwie doch im Speicher liegen von der Datenbank dann immer dann, oder nicht?

Ja, aber das sollte es ja eh so.

Sollte bei der Datenbank ja eh meistens so sein, dass du da halt dein Working-Set hauptsächlich im Hauptsprecher hast.

Wenn das nicht so ist, dann hast du eh ein Problem.

Also ja, muss man ausprobieren, aber ich meine nur, es gibt da auch noch andere Sachen, die man machen kann.

Und ob man immer Reddis braucht, weiß ich nicht.

Ein Abgesang auf eine der tollen Technologien.

Nein, das ist.

Ja, ich meine, es hat schon natürlich auch coole, man kann damit coole Sachen machen, aber ja.

Ja, vor allem kannst du halt immer alles reinschreiben, muss nicht irgendwas migrieren, irgendein Schema eingeben und so.

Ja, klar.

Kannst du in der Datenbank aber auch machen.

Du meinst Jason Feature.

Ja.

Okay.

Muss ich mal drüber nachdenken.

Du kannst auch pickeln und das in die Datenbank reinschreiben, aber es ist halt ein bisschen.

Ja.

Ja.

Genau.

Ansonsten vielleicht sagen wir was zu diesem XZ LZMA Debacel, das uns über Ostern Aehlt hat.

Ja, sagt mal was dazu.

Müssen wir wahrscheinlich einfach, weil das jeder muss dazu was sagen, jedenfalls habe ich das Gefühl, dass das jeder...

Ja, dann sag doch mal, was hat uns denn für einen Debackel überhaupt ereilt?

Ja, da gab es jetzt tatsächlich so ein von relativ langer Hand geplanten so eine Supply Chain-Attacke.

Du meinst, das waren wahrscheinlich die ausländischen Geheimdienste, die versuchen.

Weiß man nicht, aber ja, könnte gut sein, ja.

Und die Frage ist halt, und es war wirklich relativ perfide und hat halt einige Dinge.

Ja, aber es war gar nicht im Code, es war in der, also vielleicht nochmal ganz kurz zusammengefasst, was passiert ist.

Also es war in einer Open-Source-Bibliothek ein Angriff, der tatsächlich massiv dazu geführt hätte, dass Sicherheitslücke bei SSH aufgetreten wäre.

Nein, nein.

Die Sicherheitslücke, das ist halt so eine Backdoor und zwar eine Nobody but us, also sozusagen eine, wo nur die Leute mit dem richtigen Private Key reinkommen und sonst keiner.

Also was nach Gereimdienst riecht ehrlicherweise?

Ja, vielleicht.

Ja, aber wie es halt gemacht war, es war halt Open Source-Bibliothek, aber das war nicht im Source-Versteck tatsächlich.

Das heißt, man konnte es gar nicht sehen.

Sondern in den Tarballs, die da mit rumlagen irgendwie?

Ne, in den Testdaten.

Also der Trick war, es war sozusagen für, ne, also man kann ja jetzt gültige und nicht gültige irgendwie Binaries haben, die irgendwie komprimiert sind und der Testfall für das ungültige Binary enthielt halt auch noch andere Dinge.

Und ja, das war ein Ding, wo da was, aber da gab es diverse Geschichten.

Also überhaupt das, dass man SSH, das SSH quasi, dass man in SSH Dinge austauschen kann, dadurch, dass man irgendwie eine Backdoor in den XZ-Tools hat, das hätten wahrscheinlich schon viele gar nicht für möglich gehalten.

Und das liegt auch nur daran, das liegt nicht an den beteiligten Projekten, das liegt nicht an Open SSH, das liegt nicht an, das liegt da an einer Kombination davon, weil die Distributoren halt irgendwie so System D irgendwie gepatcht haben, dass das irgendwie da mit reingelingt wird.

Und damit irgendwie so eine indirekte Abhängigkeit von Open SSH zu der Kompressionsbewegung.

Also, das heißt, du bist jetzt gerade auf der Gegen-System-D-Seite von diesem System.

Nein, nein, gar nicht.

Also ich fand, ich fand auch, also Landard Pöttering hat dann halt auf Masodon auch quasi geschrieben: so, naja, also wir sagen ja schon seit Jahren, dass man das nicht so machen soll.

Und wie man, es ist dokumentiert, wie es richtig geht.

Und ja, wir haben das, wir sagen das seit Jahren, ist es nie umgesetzt worden, ja, was wollen wir denn machen?

Und da hat er natürlich irgendwie einen Punkt.

Und es ist auch, die Geschichte, die System die macht, ist ja schon viel besser, als wie es vorher war, mit Cis5-Init und den Shell-Skripten, das ist ja alles noch viel furchtbarer.

Dann wäre es noch einfacher gewesen, irgendwie Dinge zu verstecken.

Aber ja, dadurch, dass die Distributoren halt das so angepasst haben, ist es halt möglich gewesen, da was, und das muss man erstmal wissen, dass man da so Sachen reinschmuggeln kann, das ist nicht so offensichtlich.

Und jetzt ist natürlich auch alles geändert worden.

Das war halt tatsächlich auch so eine Social Engineering-Attacke.

Also man hat halt den einen Maintainer, der dann irgendwie da alleine gekämpft hat, um das Ding da so ein bisschen weiter zu machen, weiterhin unter Druck gesetzt, also auch mit so vielen Nachrichten und sich da in dem Repo als Co-Maintainer irgendwie eingeschlichen und dann halt die ganze Zeit so getan, als macht man irgendwas und dann von außen mit anderen Accounts Druck erzeugt.

Nicht so getan.

Nein, nein, man hat von außen hat auch Druck erzeugt.

Also ja, man hat irgendwas gemacht, aber ich meine, man hat da aktiv dran entwickelt, auch gute Sachen quasi und dann auch Qualität beigetragen quasi, aber man hat diesen einen Maintainer, der halt auch nicht unter Druck gesetzt hat, das war halt.

Das waren viele Commits.

Also es waren nicht irgendwie wenige, das waren richtig viele, es waren, ich weiß nicht, insgesamt, keine Ahnung, geht in die Hunderte und die waren alle sehr gut.

Also irgendwie jemand hat dann mal so ein Beispiel gefunden, meistens, so guckt ihr diesen Commit an, der ist, wie war der Ausdruck Pitch Perfect, der ist halt wirklich das auch die ganze Terminologie war richtig.

Da kannte sich jemand wirklich gut damit aus, wie diese ganze Entwicklung da funktioniert, welche Fachbegriffe es da gibt.

Aber was sie halt auch gemacht haben, sie haben ja psychisch unter Druck gesetzt, sie haben halt in den Issues und so, wurden sie aggressiv und haben angefangen, also ihn persönlich anzugreifen und so weiter, dass er halt dann wirklich so ein bisschen Kontrolle verloren hat und auch gar nicht mehr, also wirklich wollte, glaube ich.

Nein, nein, nein, nein, nein, nein, nein, nein, der wollte vorher schon.

Also der hatte sowieso ein Problem.

Also dass sie sich denen ausgeguckt haben, ist halt auch kein Zufall.

Sondern der hatte irgendwie immer schon irgendwie so ein bisschen Struggle und der wollte das eigentlich, musste halt immer mal wieder Auszeiten nehmen, konnte das nicht so richtig machen.

Und dann haben sie halt gesagt, so brauchst du nicht.

Und er hat ja um Hilfe gefragt.

Er hat gesagt, ich hätte gerne Hilfe, will mir nicht irgendjemand helfen, weil ich kann es nicht so richtig machen, wie es eigentlich gemacht werden müsste.

Ja, und dann hat sich der eine wieder gemeldet.

Ja, es war eine clevere Strategie eigentlich, ja.

Und ja, dann, genau, diese, dass dann noch andere ins Spiel kamen, wo es ging es dann darum, das in die Distributoren reinzu, die Distributionen reinzukriegen und dann halt auch, um halt in einen man da platziert hatte, als Maintainer zu etablieren und so.

Also ja, also es war eine hässliche, also sag mal so, wenn man sich das so anguckt, ich kann mir nicht vorstellen, wie man das irgendwie quasi, wie man da so, wie man da da sozusagen sofort Lund riecht, sondern das kann jedem passieren.

Ja, also ich würde auch sagen, da kann man das schlecht verschützen, dass es halt nur das vier Augenprinzip, was hilft.

Und es gibt halt jetzt hier so Schreihälte, die sagen so, nein, Open Source verbieten, weil es ja total gefährlich, da sind ja Sachen Leute beteiligt, die gar nicht da reingehören.

Wo ich sagen würde, hey, das kann man wahrscheinlich aber auch nicht bei Closed Source verbieten, weil das könnte mit einer anderen Firma auch so passieren.

Oder Open Source wäre da eigentlich besser für.

Ja, also es hat ja dann funktioniert, wo man weiß nicht, ob es an vielen Stellen vielleicht dann, wo man Sachen nicht gefunden hat.

Aber ja, an der Stelle hat man es gefunden, auch wenn es, wenn viel Glück dabei waren.

Aber genau, demgegenüber Closed Source, hast du das mitgekriegt?

Das kam jetzt auch letztens raus, da gab es irgendwie einen offiziellen Abschlussbericht.

Microsoft hat ja irgendwie dieses Problem gehabt mit dem Master Key, der ihnen irgendwie abhanden gekommen ist, wo sie dann gesagt haben: so, oh ja, wir haben hier irgendwie Postmortem-Gedings gemacht und ein langes Ding veröffentlicht, wo sie dann gesagt haben, ja, wahrscheinlich ist es wieso, oder wir denken, es ist halt durch irgendeinen Crashlock irgendwie dann da rausgelegt und keine Ahnung.

Und ja, da hat irgendeine Behörde aber sozusagen einen Bericht auch angefordert und dann haben sie ihnen das geschickt und dann waren die nicht einverstanden und dann haben sie nochmal nachgeprüft und jetzt in dem offiziellen Bericht, der approved ist, steht halt drin, wir wissen nicht, wie uns dieser Schlüssel angekommen ist.

Also ein Ding, mit dem sie, mit dem man Sessions signieren kann, mit dem man in jedem Outlook-Konto reingekommen ist, in jeden Azure-Kram.

Und sie wissen nicht, wie das Ding rausgelegt ist.

Tja.

Das ist nicht so gut, ja.

Und Microsoft hatte auch LibArchive, wo halt die gleichen Leute, die halt da irgendwie dieses Excel-Tools-Dings gemacht haben, auch aktiv waren.

Das haben sie auch integriert mit den Änderungen.

Und ja, also ich glaube nicht, dass Closed Source da irgendwie.

Ich würde auch sagen, also Open Source ist dann wahrscheinlich doch besser, wenn mehr Leute drauf gucken und die dann wirklich so.

Also wie es raufgeflogen ist, da hat irgendwie wirklich jemand Messungen angestellt, ne?

Andres Freund war das.

Microsoft Mitarbeiter arbeitet an Postgres und hat halt so Micro-Benchmarks gemacht.

Ja, aber das ist also Hobby-Nerdism quasi, ne?

Also es ist voll gut, dass es so Menschen gibt, die es so tief mit so Themen aufsetzen, aber ohne so einen Enthusiasmus da an der Stelle, wäre das einfach runter, ja.

Ja.

Na gut, jetzt werden ein paar Sachen zugemacht und es wird wahrscheinlich jetzt ein bisschen schwieriger, aber letztlich ist es schwer, dagegen was zu tun.

Ich habe auch schon irgendwie, also ich meine, es gibt da natürlich das Netz gerade voll davon, was man da also machen könnte und was irgendwie sinnvoll wäre.

Und es gibt aber ehrlich gesagt nicht so viel, was man tun kann.

Also außer ja, die Distributoren könnten vielleicht ein bisschen was machen.

Dass man halt aufpasst, dass halt sowas wie Open SSH, dass man wirklich weiß, was alles, was die Abhängigkeiten dafür sind und dass man da halt dann ein Auge drauf hat, dass da, dass man die Dinger ganz besonders genau anguckt.

Aber ja, letztlich ist es, glaube ich, schwierig, sich dagegen zu verteidigen.

Einen interessanten Ansatz fand ich von einem von Michal Zalewski, hat er dann zu einem Artikel geschrieben, der meinte, so, naja, also gerade auch dieser technisch ist halt die Frage, kriegt man das technisch überhaupt im Griff?

Wahrscheinlich eher nicht, weil eigentlich ist ja der Kern dieser Attacke ein Social Engineering gewesen.

Und ja, da kannst du mit Technik nur begrenzt was gegennehmen.

Ich würde auch sagen, wir können ja auch Mitarbeiter einschleusen und einen Geheimagenten in der Firma, der dann Entwickler ist und dann irgendwie Co-Mit-Rechte sich gehauen hat, indem man da gut arbeitet und dann sowas, ne?

Das kann man wahrscheinlich gar nicht ausschließen.

Tatsächlich ist da das Mehraugenprinzip gar nicht so schlecht.

Ja, und also dessen Fazit war dann quasi mehr oder weniger zu sagen.

Naja, also eigentlich ist das auch nichts, womit sich Open Source Mantener oder auch überhaupt Softwareentwickler letztlich beschäftigen.

Also darin gut sein sollten, weil das ist halt eigentlich, ist das halt eher Spionageabwehr, weil du fängst Spione nicht unbedingt mit Programmierern, sondern dann nimmst du halt andere Spione, die das halt sehen, wie das funktioniert.

Und dann ja, also das fand ich okay, das ist ein Punkt.

Aber ansonsten war immer so eher.

Ja, es halt wird sträflich vernachlässigt und kostet halt alles wieder Geld, ne?

Ja, gut, jetzt gab es mal halt einen Barnschuss irgendwie.

Besser du Internet einfach abstellen, ne?

Naja.

Genau.

Aber war auf jeden Fall aufregendes Ost.

Ja, war spannend.

In Python gab es ja auch wieder so ein paar Tag, ne?

So jede Menge Typhof-Botringen und so.

Gibt's gerade, wobei das eher eine, das sind eher so handelsübliche Kriminelle, würde ich jetzt mal sagen.

Pipe I hat Anmeldungen von neuen Benutzern abgeschaltet und nimmt es auch gerade vor ein paar Tagen, ich weiß, es kann auch sein, dass es schon wieder vorbei ist, keine neuen Pakete entgegen, weil halt da irgendwelche maliziösen Python-Pakete eingestellt wurden, so auch Typosquetting-mäßig und

einfach jedes tolle Paket, was man kennt, ganz viele Namen von GPT generieren lassen, die endlich klingen und so Valette seinen Code wahrscheinlich.

Und die machen einfach so schnöde Dinge wie Session-Cookies von Bankenclown und irgendwie Krypto-Wallets irgendwie sammeln und solche Sachen.

Ist aber auch natürlich auch unerfreulich, wenn man das irgendwie von betroffen wird.

Ja, also wenn ihr Pakete zufügt, guckt drauf, dass ihr die ordentlich eingibt.

Dann ist so ein bisschen.

Ja, genau.

Ansonsten.

Mehr News.

Ja.

Serr Boyce, das Django Fellow.

Ja, die hier die Django-User Group Köln mit organisiert.

Genau, das ist natürlich irgendwie herzlichen Glückwunsch von hier.

Gehen wir morgen vielleicht auch mal hin wieder zum Treffen.

Ja.

Wenn ihr es hört, bestimmt schon gestern oder vorgestern.

Ja, überhaupt, das habe ich gar nicht so erzählt, aber da passiert relativ viel.

Ich meine, leider ist ja die Djungle-User Group Köln, ist halt so die letzte verbliebene Jungle-User-Group in Deutschland, glaube ich.

Aber dafür passieren dann wieder interessante Dinge.

Im Januar war jetzt auch ein Treffen, wo halt irgendwie da von der Django Software Foundation Leute da waren, so Tipo Coulard von auch Wagtail ganz viel macht.

Und Sarah Taramane, ich weiß nicht, aus der Django-User Gruppe Paris.

Und haben da interessante Sachen erzählt und halt auch so ein Brainstorming gemacht, quasi Richtung, was sollte man denn jetzt irgendwie da noch machen an Django, was sein da für gute Ideen.

Ja, und auch an Aufforderung, alle Leute, die Bock haben sind, kennen herzlich eingeladen auch, ja.

Ja, und da zeichnet er sich so ab, es geht wohl in die Richtung, also ich finde eigentlich ist gerade Django in einer sehr, sehr interessanten Position.

Einfach deswegen, weil jahrelang vorher gab es keine gute Frontend-Story für Django.

Und das hat sich halt irgendwie gerade geändert.

Also mit Edge Mix.

Ja.

Oh, da wollten wir auch gleich noch mit.

Da kann man vielleicht auch nochmal kurz was zu sagen.

Daher, ja, wir haben jetzt da jetzt im Grunde, und ja, da kommen jetzt oft Sachen noch Features in die Browser, wo das halt auch nochmal interessant wird.

Also gerade diese View Transition APIs zum Beispiel, die in Chrome sind die schon länger, aber jetzt in der Tech-Preview für Safari ist gerade auch mit drin.

Firefox muss sich so ein bisschen mal irgendwie, was heißt das auch mal hinkriegen?

Ist ja ganz gut, weil dann kann man halt irgendwie traditionelle Webseiten halt auch irgendwie aussehen lassen wie SPAs, mit relativ wenig Aufwand.

Und ja, das ist natürlich, das ist natürlich interessant.

Das wäre für die meisten Backend-Leute wie uns halt super.

Weil man halt kein komisches JavaScript-Framework vorne und dran verwenden muss.

Und ja, mit Django hat man halt ein Ding, was halt 15 Jahre alt ist.

Langweilige Technologie funktioniert, ist sehr stabil, keine großen Änderungen mehr, eigentlich im Grunde tut es das, was es soll.

Das ist natürlich super, weil dann kann man sich darauf konzentrieren, damit irgendwie interessante Dinge zu tun.

Genau, also Admin-Frontend ist so eine der Sachen, da ist das Admin-Backend, ich weiß nicht.

Ja, das Admin-Backend-Backend soll dann auch was gemacht werden und das wäre dann auch schön, wenn das so Richtung HGMX gehen würde.

Das Problem beim Admin-Backend ist halt, äh, das Backend, also Admin.

Ja, Frontend eigentlich ist das.

Ist halt, dass es halt riesig ist und das, also neu zu schreiben ist halt sehr schwierig.

Vielleicht kann man das irgendwie so ein bisschen mit HGMX und so.

Es soll auch, also das war auf jeden Fall auch ein Ding, wo viele Leute sagen, na, da kann man auch mal was dran machen, das wirkt so ein bisschen altbacken und das muss man ein bisschen moderner.

Das neu zu schreiben, wäre sehr, sehr teuer, aber vielleicht kann man es ja irgendwie so ein bisschen nur im Frontend irgendwie besser aussehen lassen oder so.

Das wäre natürlich auch.

Also da passiert auf jeden Fall was, aber überhaupt generell Richtung irgendwie diese ganzen HGMX und so Sachen besser integrieren.

In die Richtung geht es auch auf jeden Fall.

Und das ist eigentlich super interessant.

Also eigentlich gerade eine sehr, sehr gute Zeit, um sowas mit so einem klassischen Web-Framework irgendwie was zu machen.

Ja, also unter HTMX, wir hatten ja schon eine Episode dafür und ein paar Mal irgendwie auch dann eine Lanze für gebrochen.

Inzwischen hat

das auch schon häufig verwendet in Super.

Du hast auch mehr, genau.

Also Hyper Media Systems, das ist ja das Buch, das ja auch relativ frei rauf und rum liegt oder sowas.

Ja, kann man sich auch auf jeden Fall mal angucken, wenn man sich dafür interessiert.

Also ich finde eigentlich immer ein bisschen, es hat auch gehabt jetzt, es ist jetzt so erfolgreich, dass es auch Kritik gibt, weil es offenbar die Wahrnehmungschwelle irgendwie überschritten hat bei manchen Leuten und dann gibt es die Kritik, die es da bisher gewartet hat.

Ich finde es aber so ein bisschen schade, wenn dann halt irgendwie, ich das Gefühl habe, dass er nicht so richtig verstanden ist, warum das so cool ist.

Oder vielleicht gar nicht verstanden ist, warum, warum man, warum was daran, und das kann ich vielleicht auch noch versuchen, nochmal in zwei Sätzen zu sagen, weil das wäre mir schon wichtig, wenn man das irgendwie verstehen würde.

Also eigentlich coole ist halt aus meiner Sicht, dass es halt eine Geschichte ermöglicht, die halt mit so SPS nicht so gut geht.

Bei SPS hast du halt eigentlich immer, jedenfalls soweit ich das kenne, eine enge Kopplung zwischen Client und Server.

Du musst halt immer, wenn du das eine änderst, musst du das andere mit ändern.

Also wenn du halt irgendwie ein API?

Ja, also API-Versionierung, oh mein Gott, ja.

Nein, aber allein schon, wenn du halt so einfach nur, wenn du änderst dein irgendein Formular oder so, dann musst du das halt einmal am Server ändern und du musst es halt auf dem Client ändern.

Und das heißt, die Dinger sind voneinander abhängig.

Wenn du da halt irgendwie viel mehr in dein Formular reinschreiben möchtest, dann musst du halt im Backend das halt auch alles validieren.

Also im Worst Case brauchst du halt sogar zwei Entwicklungsteams, ne?

Einen, die das Server Type-Strip machen und einen, der da macht.

Das ist der Normalfall, dass du da mehrere Entwicklungsteams hast.

Das heißt, du hast ein System, das ist eng gekoppelt an der Schnittstelle, wo du dann, wo du über eine Teamgrenze hinweg kommunizieren musst.

Also das ist halt einfach.

Ah!

Aber gut.

Aber möglichst den komischen Backend-Leuten diese ganzen schönen Design-Sachen noch dranbinden.

Ja, naja, ich meine, das ist halt einfach, manche Leute mögen halt lieber JavaScript, andere lieber was anderes und dann werden das irgendwie automatisch unterschiedliche Teams oft.

Und ja, aber wenn man jetzt halt ein System hat, das halt, wo man eine harte Abhängigkeit hat, wenn man das eine ändert, dass man das andere auch mit ändern muss und das hast du halt über eine Teamgrenze hinweg.

Das ist halt, ich kann mir nicht vorstellen, wie das keine Probleme machen kann.

Das macht immer Probleme, sowas.

Und das ist eigentlich das Schöne, wenn man jetzt quasi nicht so eine JSON-API dazwischen hat, sondern wenn man einfach HTML ausliefert, dann hast du halt als Server irgendwie klassischen Web-Server mit HTML.

Ja, also tatsächlich REST quasi, so was die JSON-APIs normalerweise halt eben nicht wirklich sind.

Und der Client ist halt der Browser und dann hast du eine lose Kupplung.

Nämlich sozusagen, ich kann den Server ändern und dann muss ich nicht aber einen neuen Browser chippen, sondern das geht halt auch mit allen Browsern, geht auch mit alten Browsern oder geht auch mit neueren Browsern.

Und genau, ich muss nicht beides ändern.

Ich muss nur die eine Seite ändern.

Und das ist halt dann natürlich eigentlich viel angenehmer.

Aber es ist glaube ich relativ schwer zu verstehen für jemanden, der das nicht kennt oder das nicht kann, was das überhaupt heißt.

Ja, ja gut, aber also ich meine, ich würde einfach mal sagen, so wenn du halt ein Formular hast und ich habe halt so eine klassische Web-Applikation, wenn ich da jetzt zwei, drei Formularfelder zusätzlich mache, dann muss ich halt nur an einer Stelle den Code ändern und nicht Client und Server anfassen.

Die meisten modernen Django REST-Framework-Backend-JSON-API-Bereitsteller wollen ja gar kein Formular in der Hand haben, sondern nur eine JSON-Liste rausschreiben oder ein Objekt oder so.

Ja, aber dann musst du halt, du musst ja dafür sorgen, dass das Formular dann irgendwie da ist.

Dann musst du halt immer noch das ändern und du musst halt dann dein Formular ändern in der Client-Applikation.

Ja, meistens nehmen die immer alles.

Nicht so wirklich Datenfall an.

Ja, so Graph-AP-Style oder sowas, du kannst ja einfach nach einem Fragen, kriegst du einfach das, nachdem du nicht gefragt hast und.

GraphQL, ja, das ist auch so eine Sache, aber das macht es ja eher noch schlimmer.

Ja, genau, also das meine ich ja, ja.

Okay, also genau, wo ist das Problem, wenn du halt einfach sagst, okay, wir machen die Datenabfrage einfach so fein granular, dass es im Grunde mehr oder weniger wie SQL ist.

Könnte man ja sagen, ah super, dann ist das Problem ja erledigt, ja.

Das ist ja dann so wie SQL, kann ich ja dann die ganze Logik im Client machen und habe dann nur noch dumme Datenschnittstelle sozusagen.

Das Problem dabei ist, dass ich dann natürlich die Business-Logik im Client habe.

Und die habe ich dann halt in allen Clients, die es gibt.

Die habe ich dann einmal in der SPA, aber halt, die habe ich dann auch in einer mobilen Applikation und in allen Swap-Party-Applikationen.

Wenn ich irgendwo was ändern muss, muss ich das in allen ändern.

Das halt auch irgendwie ein Architekturpertal ist, wo ich mir da geht so, wie kommt man auf die Idee, sowas zu machen.

Ich habe den Client auch überlassen, was für Anfragen gestellt und so, und das ist auch ziemlich gefährlich.

Aber naja.

Ja, gut, dass das Ganze noch so ein Problem hat, ist auch richtig, aber allein schon, dass das halt dazu führt, dass man halt die gleichen Geschichten immer wieder schreibt in unterschiedlicher Form, dabei über Teamgrenzen hinwegkommunizieren muss.

Ja, gut.

Also ist schon, würde ich denken, ist halt auf jeden Fall keine sehr schöne Architektur aus meiner Sicht.

Ja, und genau, das ist halt so, das sind halt so die beiden Hauptprobleme, die ich sehen würde.

Also irgendwie lose Kopplungen und halt irgendwie Business-Logik bitte nur an einer Stelle haben, die halt sehr viel einfacher werden, wenn man halt HTML ausliefert und nicht JSON.

Ja.

Genau, das wollte ich nur mal so erwähnt haben, weil das ja immer so ein bisschen.

Ja, ich glaube, das Hauptproblem sind da auch die People.

Da werden wir gleich wahrscheinlich nochmal reinkommen, weil die Menschen, die man auf den unterschiedlichen Konferenzen zum Beispiel sieht, zu den unterschiedlichen Frontends, Backends, Sprachen und so, sind schon sehr unterschiedlich auch.

Was auch interessant ist.

Die muss man halt dann, ja, muss man sich drauf klar sein.

Wann das dann die Newsjochen?

Ja.

Ja.

Switch, hast du noch News mitgebracht?

Äh, nee.

Du hast aber auch einen Podcast, hast du gesagt.

Genau, ich habe auch einen Podcast.

Erzähl doch mal.

Du darfst doch gleich noch was über dich sagen, erstmal über deinen Podcast.

Ja, ich mache mit meinem Kollegen Dirk den Podcast namens TillPot.

Title für Today I Learned oder Things I Learned.

Wo wir auch immer mal wieder Punkte angehen aus IT, Karriere, Bubble so ein bisschen zu betrachten, welche Sachen wir mal zuletzt gelernt haben.

Oder vielleicht auch nicht gelernt haben.

Manchmal offensichtlicher ist, manchmal auch weniger offensichtlich ist.

Spannend.

Genau.

Was war das letzte Titel?

Schon ein paar Wochen her, das habe ich heute schon wieder vergessen.

Dann müssen wir es in den Show Notes nach jeden Fall nachreichen.

Ja, ich kann ja verlinken das.

Genau, und dann ja.

Also, wir hatten ja schon lange keine gesponserte Episode mehr, aber dieses Mal haben wir es tatsächlich geschafft, eine Episode von uns wieder zu sponsern und wir haben einen schönen Partner dafür gefunden.

Und zwar ist das datascientest.com.

Data Scientists?

Datascientest.com.

Ja, das ist ein Unternehmen, das bietet Schulungen an.

Oh.

Zum Beispiel zum Bereich DevOps oder Python generell oder SQL.

Machine Learning,

LLMs, Deep Learning, Power BI auch sowas, AWS.

Genau, und die kann man remote alle machen.

Also ist gar nicht so schlecht für euch, wenn ihr Familie habt, vielleicht.

Du wolltest nicht irgendwo zum Schluss dort hinfahren.

Flexibler sein, ja.

Also genau, die arbeiten aber auch mit der Sorbon, glaube ich, da irgendwie zusammen.

Ja, die brauffische Zertifikate von einer Pariser Universität.

Ja, und genau.

Man kann halt sich dabei so ein bisschen das Tempo raussuchen, das man gerne dabei hätte.

Also wenn ihr da Interesse dran habt, dann haut doch mal rein, ob da für euch die richtige Schulung bei ist.

Ja.

Guckt ein bisschen durch.

Meldet euch einfach für den virtuellen Takte auf eine Tür an, den haben sie nämlich einen.

Und entdeckt dort die Möglichkeiten, die ihr habt.

Also besucht die Webseite auf www.datascientist.com und schaut euch das ein bisschen an.

Okay, cool.

Ja, ist auch einfach, oder?

Und also vielen Dank an den Sponsor dieser Episode.

Da wir auch gerade von dieser DevOps-Schulung gesprochen haben, würde ich jetzt auch tatsächlich gerne zu unserem Thema der Episode übergehen, wo endlich Switch mein auch ein bisschen mehr zum Wort kommen soll.

Den haben wir nämlich heute eingeladen, weil er sich über DevOps sehr viel weiß.

Und auch ein tolles Buch dazu geschrieben hat.

Soll ich kurz sagen, wieso ich, wie ich darauf aufmerksam habe?

Ja, bitte.

Weil ich habe auf Masodon gesehen, dass Frederik Hemberger, glaube ich, hatte irgendwie geteilt, dass es jetzt ein neues Buch über DevOps gibt.

Und ich dachte so, oh, das ist ja interessant.

Finde ich auch gut, das Zimmer.

Gleich mal gucken.

Und genau.

Ja, und dann habe ich gesehen, oh, da gibt es ja auch noch einen Podcast und dann muss ich direkt direkt eine Mail schreiben und

sofort die Lage sein.

Jetzt musst du dich aber mal vorstellen, erstmal selber, bitte.

Was soll ich denn sagen?

Ja, wie du, deinen Vordamen kennen wir ja schon.

Und was du so machst vielleicht und wie du dazu gekommen bist, was du findest, wie DevOps irgendwie uns begleitet oder.

Genau, also ich fange mal von Vordernamen, sag ich mal, würde ich mal sagen.

Genau, Sushwan ist mein Name.

Ich hab halt, wie ihr schon gesagt habt, ein Buch über DevOps geschrieben, vorher schon mal was über Git geschrieben.

Und da ist mir halt vor allem wichtig, Git über die Kultur zu sprechen.

Und dann die Git-Prozesse und dann die Tools.

Ich arbeite, also meine normale Anstellung ist bei GitLab, wo ich Solutions-Architekt bin.

Also letztendlich eine Presales-Rolle, wo ich mit den verschiedensten großen deutschen Konzernen vor allem zusammenarbeite, beziehungsweise denen dann halt auch erklären muss, wie dies oder jenes funktioniert.

Also versuchst den so Wege aufzuzeigen, wie die DevOps integrieren oder

ja, ich meine, Sinn und Zweck ist halt schon, dass die GitLab kaufen, also die Enterprise-Lizenz beziehen.

Und da finde ich es immer spannend halt zu sehen, wenn ich mit den Firmen rede, so, und ich bin hier ja jetzt privat, was die halt falsch machen teilweise.

Ja, das ist natürlich interessant, ja.

Okay, weil da darfst du gerne auch so ein Nährkästchen plaudern.

Ja, also ich habe ein Beispiel, was ich eigentlich ganz gut finde.

Und zwar hatte ich mal mit, also ich rede halt wie gesagt tagtäglich mit diversen Kunden und die kommen halt immer mal wieder mit, ah, dies oder jenes funktioniert nicht, ich hätte noch einen Feature-Request, so das übliche, was man halt so kennt.

So, und da kamen die halt zu uns und das ist halt erstmal das Erste, worauf ich mich da kümmert, also erstmal anhören, was wollen die überhaupt.

Und die hatten dann so gesagt, so ja, wir möchten, dass die, dass eine bestimmte User-Gruppe nicht den Source-Code sehen darf.

Und das könnt ihr ja nicht, könnt ihr das nicht irgendwie einbauen.

Also ich weiß auch, das Management soll nicht sehen, was man da schreibt.

Oder sind so externe Businesspartner oder sowas, die dann ab und zu mal sehen können oder so, aber ja, okay, den Code nicht.

Ja, genau, das fand ich aber irritieren.

Naja, wenn du nicht einen Code sehen willst, dann mach doch dein ganze Projekt halt privat oder nur die Leute, die es halt sehen sollen, dürfen.

Also ich kann mir auch, ich kenne auch so ein paar Rollen, wo ich das verstehe, ja.

Genau, aber da ging es halt mehr darum, so, nee, die sollen ja Issues und sowas bearbeiten können, aber die sollen den Code nicht lesen können.

Genau.

Das ist auch so mein Gedanke.

Moment mal, da muss ich jetzt noch näher nachfragen, warum?

Warum?

Wie ist ein kleines Kind?

Warum?

Ja, weil das, da kommen jetzt gleich drei, vier Schienen von Warum hinterher.

Nämlich, weil das erste Mal war, sie meinten dann so, ja, die können dann ja irgendwas im Code kaputt machen und sonst was.

Warum?

Ja, ich meine, dann haben sie ja einen Moment, da gibt es doch so Push-Rules und Branch-Protection-Rules und so weiter.

Das sollte man so oder so machen.

So dass man nur mit Code Review und sonst was da den Code einschleusen kann, letztendlich.

Nicht so wie bei XZ.

Auch wenn es ein Maintainer ist.

Und dann dann so, ja, okay, stimmt, das ist nicht das Problem, bla bla.

Ja, okay, aber was ist denn jetzt euer Problem?

Ja, da ist ein Passwort im Quellcode drin.

Oh, okay, ja.

Gut.

Warum?

Ja, genau, warum?

Beziehungsweise dann so, ja, naja, die solltet ihr halt eher ausbauen und warum baut ihr das denn nicht?

Egal, wer das Zugriff hat, sollte da keine Passworte drin stehen, ne?

Ja, sondern ausbauen, also ändern und nicht mehr.

Ändern, ausbauen und dann halt durch sowas wie Hashiker Walt oder irgendwie sonst was, irgendein richtiges Tool halt mit reinsetzen, dann halt, ne?

Und dann so, ja, aber da hat man nur in bestimmten Netzwerken Zugriff drauf, also eigentlich auch kein Problem.

Und dann dachte ich so, naja, okay, aber was ist jetzt euer Problem?

Es war eine Policy.

Also die Policy in der Firma hat irgendwie gesagt, bestimmte Leute, die nur Projektmanagement machen, sollen nicht den Source-Code sehen.

Das verstehe ich sogar, also weil es ja teilweise Interessen gibt in Konzernen beispielsweise, ne, oder großen Firmen, die in unterschiedliche Richtungen zielen, also die zum Beispiel nicht die gleiche Interessen sind, obwohl sich das eigentlich komisch antwortet, wenn man in einer Firma ist, wie die des Entwicklungsteams, die daran arbeiten.

Also weil sie dann zum Beispiel Fragen stellen, die in die falsche Richtung gehen, wie nach dem Motto, die versuchen irgendwelche KPIs zu messen, ja, und zu sagen, hey, warum macht ihr das denn nicht?

Und Steam hat sich entschieden, hey, wir wollen nicht an diesen KPIs gemessen werden, sondern lieber Kreativität oder Test-Driven machen oder sowas.

Und diese internen Kunden, die wollen halt was anderes.

Das ist dann aber ein Management-Problem, meistens auch nicht das Problem der Devs, sondern halt von dem Manager der Devs, der dann mit dem anderen Manager darüber reden muss, wie die das verstückeln.

Aber wenn dieser andere Manager halt diese Volltransparenz hat, dann ist die Verhandlungslösung schlechter.

Das ist so ein bisschen vielleicht der Grund, warum man bei Politik hinter verschlossenen Türen Ergebnisse macht, wo die Öffentlichkeit eigentlich ein Interesse daran hatte, dass man das nicht tut.

Aber wenn man dann halt wirklich so Verhandlungen hat, die komplett transparent und offen sind, dann dürfen die ganzen Leute gar nicht mehr richtig verhandeln, sondern müssen immer so sehr, also die Wahrheit sagen für die Position, für die sie eigentlich stehen und dann kommen die sich nie näher.

Und deswegen ist so diese Verhandlungslösung immer schlechter zu erreichen und immer mit größeren Kosten verbunden.

Vielleicht ist es so eine Art von politischem Problem.

Ja, interessant ansatz.

In dem Fall war es aber halt nur so, naja, das war ja das gleiche Team.

Ja, okay.

Über die Leute, die das Projektmanagement gemacht haben.

Also Blickwinkel kann ich das ja noch nachvollziehen, wenn man es jetzt, wenn man in einem Großkonzern ist, dass das nicht wirklich komplett, komplett alles offen ist, sondern das vielleicht nur auf Abteilungen vielleicht offen ist oder sowas.

Das kann ich auch grundsätzlich irgendwie nachvollziehen.

Aber wenn das halt für das gleiche Team ist.

Ja, das macht irgendwie keinen Sinn.

Das macht halt keinen Sinn.

Und eines Aspekte von DevOps ist ja zum Beispiel ja auch Visibilität in aller Sachen.

Also, das so als, weil ich meine, im Ende ist im Endeffekt geht es auch viel um Silos zwischen den verschiedenen Rollen.

Dev, Ops, QA, Security, Finance letztendlich auch, wenn du in der Public Cloud zum Beispiel bist oder sonst was.

Und wenn alle auf die gleichen Daten gucken können, ist das ja zumindest schon mal hilfreich.

So, wenn ein Projektmanagement ja dann sieht, da muss er ja nicht jedes Mal nachfragen, bist du schon fertig, bist du schon fertig, sondern er sieht vielleicht so, ah, das ist ein Merch-Request dran, da läuft gerade eine Option.

Erwartest du vom Projektmanager schon ganz schön viel.

Ja.

Also in der Tech-Firma vielleicht, ja, aber wenn du in einer Nicht-Tech-Firma bist, dass irgendwie ein Projektmanager überhaupt weißt, was ein Merch-Request wirst, die Wahrscheinlichkeit ist nicht so hoch, wie man vielleicht denkt.

Ja, naja, aber das ist ja.

Naja, du musst ja nicht alles verstehen.

Du musst ja nur wissen, dass es da ist und dass du sehen kannst, da wird gerade daran gearbeitet, da sind irgendwelche Kommentare dran sind.

Das heißt ja nicht unbedingt, dass du den Source-Code verstehen und ein Review machen musst als Projektmanager.

Aber du hast gerade interessante Sachen gesagt, die ich gerne so ein bisschen von hinten aufrollen würde, weil wir sind ja super cool in der Geschichte drin und wir haben jetzt drei, warums, glaube ich.

Ja.

Da kommen noch zwei?

Nee, nee, das war es im Wesentlichen.

Okay, dann würde ich gerne diese Definition von DevOps mit den Silos-Kennen nochmal besprechen.

Also welche Sachen da so ineinandergreifen, weil ich glaube, das ist ja das Zentrum unserer Folge.

Vielleicht müssen wir dazu eine kurze Einführung noch hören.

Ja, also ich finde es immer sehr schwierig, DevOps in ein paar Sätzen zu erklären.

Wir haben ein paar Sätze mehr.

Ganz schlimm ist es übrigens, wenn es komplett random Leute sind, die nichts mit IT zu tun haben, auch fragen, worüber ich ein Buch geschrieben habe.

Ganz anstrengend.

Aber ich versuche immer, das so zusammen zu fassen, wenn ich das jetzt ganz kurz sagen würde.

Naja, es geht halt im Wesentlichen um eine Zusammenarbeitskultur in Unternehmen, um gemeinsam an einem Projekt zu arbeiten.

Wo halt dann auch eine Software mit dran hängt.

Die Peoplesicht, ne?

Und nicht die technologische und auch nicht die Prozesssicht, ja.

Genau.

So, und dazu gehört halt eben People over Processes over Tools.

Also erst die Menschen, dann eben die Prozesse und danach die Tools.

Also so in der Wichtigkeit der Reihenfolge.

Du kannst immer noch DevOps richtig beschissen machen, wenn du zwar die richtigen Personen hast oder richtige Arbeitskultur hast und auch die richtigen Prozesse hast.

Wenn aber der technologische Tool-Stack halt bescheiden ist, dann hilft das hier irgendwie auch alles irgendwie nicht.

So, oder?

Ich habe das Beispiel, was du gemacht hast, ist super dafür.

Und zwar das mit dem Auto, dem Fahrer und der Straße.

Genau, also, weil wenn ich jetzt auf meiner Arbeitsblickwickel da drauf schaue, dann positioniert sich vor allem GitLab dann halt mehr, so, naja, wir machen mit, also DevOps wird schneller, besser, einfacher, im Wesentlichen, wenn man GitLab einsetzt.

Durch weniger Tools und so weiter.

Das ist im ersten, im ersten Blick sehe ich das natürlich auch so, aber wenn ich halt mit den Kunden dann rede und gucke, so, naja, was habt ihr denn, wie arbeitet ihr denn überhaupt, dann merkt man halt häufig, so, naja, ihr habt jetzt irgendwelche Probleme, die sind jetzt nicht technologischer Natur.

Das ist halt ungefähr so, als wenn man mir ein Formel 1-Auto geben würde.

Das ist dann halt das Tool.

Der Prozess wäre dann quasi die Straße und ich würde halt auf einer durch die Innenstadt von, keine Ahnung, Düsseldorf fahren.

Oh, das, äh, ich weiß nicht, auf der Köhe, da sieht man manchmal, also oben rum.

Die Formel 1-Autos aber.

Genau, aber da kommst du ja trotzdem nicht so schnell rum.

Nein, nein, nein.

Dann ist es natürlich schön, dass du ein tolles, schnelles Auto hast.

Du bist aber nur, du kannst aber auf der Köhe in Düsseldorf jetzt nicht so schnell fahren.

Gleichzeitig, also brauchst du auch eine gewisse Rennstrecke zum Beispiel dann halt auch.

Und das andere Ding ist, naja, du kannst das Ding überhaupt nicht fahren.

Ja, oder wenn es nachfällig betrieben ist, ist ständig gegen den zweiten Baum fährt, das auch blöd, ja.

Ja, genau.

Und so finde ich, kann man das gleich ganz gut, das typisch deutscher, der typisch deutsche Autovergleich, dann eben anbringen, so von wegen seiner, naja, es bringt halt nichts, wenn du das beste Tool, ein tolles Auto hast, wenn aber die Straße total bescheiden ist und wenn du überhaupt gar kein Auto, gar keinen Führerschein hast, oder gar kein Auto und nicht in ein Auto gefahren bist, dann kann es halt nicht funktionieren.

Sind doch natürlich auch nicht, wenn dein, und jetzt habe ich ja gerade mit dem Frauen-1-Wagen und da sitzt man ja noch alleine drin.

Wenn du aber eigentlich in den Urlaub fahren willst und fünf Leute hast und einen Camper haben willst, eigentlich, da zählt das ja auch irgendwie noch dazu, ne?

Was ist überhaupt die Frage?

Ja, wenn die gerne Kinder die ganze Zeit auf dem Rucksitz klängeln, wenn du bist ja endlich da und du hast das Essen vergessen und so, das wird immer schwierig.

Ja, viele Stakeholder.

Ja, genau.

Okay, also du sagst, der Forps ist ein Kulturbegriff und der halt, wo es darum geht, diese ganzen Siedlungs zusammenzubringen und halt die einzelnen Abteilungen, die es ja früher mal waren, irgendwie miteinander in einen Tisch zu bringen.

Ja, ich kann das ja vielleicht, also wie es früher war, ich bin unerfreulicherweise schon so alt, dass ich weiß, wie es vorher war.

Daher, da hatte man halt irgendwie eine Entwicklungsabteilung und halt dann irgendwie sozusagen die Admins oder halt irgendwie, ja, und also ja, und dann, wenn halt irgendwas produktiv gehen sollte, dann hat man sich halt mit den Entwicklern zusammengesetzt und dann halt das Ganze irgendwie deployed und dann betrieben.

Und ja, aber das waren unterschiedliche Leute.

Also das ist jetzt der Operations-Teil, der Admin-Teil, wenn ich das richtig verstehe.

Ja, der Devs das ist der Software-Entwicklungsteil, aber wir hatten jetzt ja noch viel mehr drin, also zum Beispiel das Security-Ding, das Projekt-Management-Ding.

Welche Silos waren noch drin?

Naja, QR letztendlich halt auch, weil häufig, wenn man nach dem Wasserfallmodell guckt, halt eher nachgelagert, wie man es früher guckt.

Wenn man die reine Agilisierung ist ja eigentlich schon lange durch, sage ich jetzt mal so als Thema.

Da redet man ja kaum noch drüber.

Also dass man das machen müsste oder so.

Aber da wird halt häufig halt auch nur nichts ausgeliefert oder in Betrieb genommen, sondern halt immer über die über die Song geworfen, genau.

Ja, genau.

Und also das Problem dabei ist halt, denke ich, also vor allen Dingen, es gibt zwei große Probleme.

Das eine Problem ist halt, ich würde eigentlich DevOps im Grunde als, als ein Trend in einer ganzen, in einem ganzen Oberbegriff von einem Trend.

Wie auch immer.

Industrie, ich weiß nicht, ja, also begreifen, also dass man versucht, irgendwie, wenn, wenn man jetzt halt sozusagen sich diese ganze Strecke anguckt, von man möchte irgendwas machen zu es ist in Betrieb und die einzelnen Schritte, die dafür nötig sind, dann versucht man halt immer mehr irgendwie Richtung Anfang zu verlagern.

Also ich glaube, das läuft dann irgendwie so unter dem Stichwort Shift-Left oder so und davon ist es halt ein Teil davon, weil es halt darum geht, quasi sozusagen den Teil halt näher an die Entwicklung ranzubringen, der halt irgendwie dafür sorgt, dass das Ganze deployed ist.

Naja, aber jetzt sind wir bei Qualitätskontrolle tatsächlich beim Code schreiben auch dann?

Qualitätskontrolle, ja gut, das ist was ähnliches, dass man das halt auch versucht, da, genau, das konnte man halt bei Qualitätssicherung macht man das sicherlich genauso.

Ja, also Linting, Testing, Testing.

Genau, man versucht das auch immer weiter quasi an den Entwicklungsprozess ranzubringen, beziehungsweise dann halt in die Pipeline, wie auch immer dann, vielleicht in die Idee eigentlich noch besser, weil dann hast du noch einen kürzeren Zyklus von irgendwie, ich mache irgendwie Unsinn zu, mir sagt jemand, dass ich Unsinn mache.

Aber es geht im Grunde darum, zu versuchen, zu verhindern, dass halt ein Fehler irgendwann sehr viel später auftritt, wenn man jetzt eigentlich schon gar nicht mehr dran ist.

Wenn ja zwei Wochen, nachdem man an irgendwas gearbeitet hat, dann das Feedback kommt, ja, das war jetzt irgendwie kaputt, dann ist es halt total blöd, weil dann ist man eigentlich schon an was völlig anderem dran und dann weiß man auch gar nicht, was man jetzt noch tun kann, oft.

Ja, wenn ein halbes Jahr später eine rote Lampe angeht, dann sind die Leute, die dich da eingebaut haben, auch gar nicht mehr da.

Und das überhaupt zu finden, ist das manchmal schon eine.

Ja, und wenn du zwei Abteilungen hast, dann hast du automatisch da halt so ein Ding, wo das ist.

Machen wir erstmal einen Workshop.

Nee, wo du halt diese Trennung hast und wo du es halt, wo es halt sehr schwer ist.

Das macht es halt einfach langsam.

Also das, denke ich, ein wichtiger Punkt.

Ein anderer wichtiger Punkt ist halt, oder das war halt jedenfalls früher immer so ein Problem, wenn man das halt in unterschiedlichen Abteilungen hat, dass man unterschiedliche Interessen hat.

Das halt, ähm genau, ja, also die Entwickler werden halt daran gemessen, was sie halt an quasi Storypoints oder was auch immer irgendwie aus der Tür kriegen, ja, so an Features rausbringen.

Also wie viele Tickets man dann auf irgendeinem Board irgendwie auf die andere Seite.

Ja, genau.

Und die Admins werden daran gemessen, sozusagen, dass halt, wie verfügbar das Gesamtsystem ist.

Und diese Interessen sind halt unterschiedlich.

Also sozusagen eine sehr einfache Strategie, um zu gewährleisten, dass halt quasi nichts schief geht, ist zu versuchen, alle Änderungen zu verhindern.

Und es auf halt einfach.

Ja, und dann kommt da noch das QR-Team rein, die gemessen werden mit, ja, wenn du schon einen Fehler findest, so und das Entwicklungsteam soll ja Features entwickeln.

Das QR-Team.

Idealerweise, genau.

Ein QR-Team wird halt irgendwann immer Fehler finden, selbst wenn es die perfekte Software ist.

Und dann gibt es noch das Betriebsteam und dann haben ja alle andere Ziele und dann passiert halt eher so ein Gegeneinander.

Und im Endeffekt, wenn man halt nochmal einen Schritt zurück geht und dann aufs große Ganze guckt, ist ja der Kerngedanke eigentlich, man will ja irgendein Value, irgendeinen Wert an die Endnutzer bringen.

Ach, jemand hat Kunde gesagt, ach, herzlich.

Deswegen habe ich Endnutzer gesagt, nicht Kunde.

Ja, ja, nein, aber doch schon, also ja.

Ja, ich meine, Kunden ist.

Ebenenwert willst du dann ja haben, dann ja auch, ne?

Und das bringt halt nichts, ich meine, das hast du bei Open Source-Projekten ja auch so, wenn du, da bist ja auch Kunde in dem Sinne.

Ja, genau, Nutzer, danke Nutzer.

Genau.

Wo du dann halt ja auch irgendwie die neuesten Features von, keine Ahnung, Django zum Beispiel nutzen willst.

Wenn die aber nur alle drei Jahre irgendwie veröffentlichen, ist das für dich auch irgendwie blöd.

Weil dann denkst du, eigentlich will ich das, was ich schon entwickelt habe, und dann auch nutzen.

Und das hat jetzt erstmal nichts mit Obs zu tun, oder DevOps so im Direkten zu tun, aber es ist halt auch so ein Aspekt, der damit.

Das ist natürlich ein Produkt Lebenszyklusmanagement.

Ja, das sind so ganz viele Aspekte, die da mit reinkommen.

Und wo ich nochmal einen Schritt zurückgehen würde, ist, weswegen ich auch das Beispiel genannt habe mit diesen Passwörtern und sonst was in dem Source-Code, wo die bestimmten Leute nicht drauf reingucken dürfen, das war am Ende ja nur eine Policy.

Die hat halt keinen Sinn gemacht.

Da muss man halt mal fragen, naja, warum gibt es überhaupt diese Policy?

Naja, die hat irgendjemand festgelegt.

Warum hat diese jemand festgelegt?

Und das ist dann halt wieder so ein bisschen.

Ja, und dann mit der EU.

Uh, aber das jetzt kommst du wieder in so Konzernen und Dingen, ja, das war auf einem anderen Kontinent und die haben sich das so überlegt, weil wissen wir auch nicht so genau.

Und bis wir jemanden gefunden haben, den wir darüber fragen können, sind Monate und Jahre ins Land gegangen und genau,

und du gehst schon auf die richtige Spur, nämlich drauf, wo ich hin will, weil eigentlich muss das Thema ganz weit oben hängen.

Weil wenn man so, weiß ich nicht, schief Technology Officer oder sonst was in einem Großkonzern oder generell in Firmen, denen muss es ja eigentlich von Interesse sein.

Also eigentlich allen in der Führungszitate, dass die, weil ja eigentlich fast überall Software entwickelt wird.

DevSecOps als Priority Number One für unsere Cloud Next Strategy.

Nee, naja, so unabhängig von dem Namen, DevOps oder wie auch immer man das, oder Plattform Engineering oder was auch immer da alles da genannt wird, soll ja schon der, der ist ja schon der Grundgedanke, dass man möglichst ein Value schneller an den Kunden bringt oder überhaupt in den Kunden bringt.

Mach ja voll cool.

Und dass möglichst effizient läuft.

Ja.

So, und da gibt es halt so viele Aspekte und ein Teil davon ist halt eben DevOps.

Ja, okay.

Jetzt muss aber doch nochmal kurz erklären, was denn diese Platform Integration-Strategie und sowas, was das alles ist.

Vielleicht einmal so ganz kurz für alle Leute, die es noch nicht.

Ja, ja.

Das ist eigentlich schon wieder, das ist.

Ja, Bassworth-Reiterei, aber vielleicht nicht mehr für alle Leute, die es gar nicht kennen, das einmal kurz.

Achso ich kann es nicht.

Ja, wenn wir von DevOps sprechen, dann reden wir ja mehr von dieser Anwendung.

Als Entwickler schreibe ich, also Entwicklungsteam schreibe ich dann irgendwie eine Anwendung, die dann ja auch betrieben werden soll.

Und idealerweise aus in einem Team eben, wie wir jetzt auch gerade hatten.

Aber wenn wir jetzt vor allem in größeren Firmen gucken, dann haben wir ja viele Tools, Prozesse, Techniken, die dann auch mit rein spielen, die irgendwer bereitstellen muss.

Zum Beispiel irgendwelche Compliance-Regeln wie wer darf was reviewen oder wo soll was hin deployed werden.

Weil wenn jeder irgendwo auf irgendeiner Public Cloud deployt, da willst du auch ein gewisses Monitoring hinterhaben.

Von den Kosten zum Beispiel, aber auch ein Monitoring von den Diensten, die laufen.

Was aber dann ja von eigenen Teams bereitgestellt wird, weil die sich halt damit auskennen.

Weil wenn du jetzt in einem, keine Ahnung, 20.000 Menschen-Konzern bist und du bist da dein Sechs-Personen-Team oder sowas oder 10-Personen-Team, kennst du sich ja nicht mit dem ganzen Stack aus, um die Anwendung zu betreiben.

Also du kannst zwar die Anwendung betreiben, aber nicht unbedingt noch.

Ich hätte jetzt so ein Gegenbeispiel.

Ja.

Ja.

Also ein bisschen mehr noch, also eher so 200 als 20.

Und ja, doch die kleinen Teams-Team komplett End-to-Hand alles selber.

Also das Problem ist halt, dass dieses Monster, was also sonst an Bürokratie und Prozessorfonthintersteckt, wenig mit den People zu tun hat.

Oder vielleicht doch gerade.

Also es sind halt einfach ganz viele Leute involviert, die alle gefragt werden wollen, die alle irgendeinen Schlüssel, irgendeine Türe in der Hand haben, durch die du durchgehen musst, was diesen ganzen DevOps-Prozess insgesamt sehr, sehr anstrengend und nervtötend und aufwendig macht.

Genau, und der Plattform-Engineering-Ansatz sieht jetzt halt mehr, ist halt an sich nichts Neues, der Begriff halt eher neuer, würde ich sagen.

Oder zumindest so, wie da jetzt durch die durch die IT-Landschaft gezogen wird.

Es ist halt mehr darum, dass du das als Service bereitstellst, innerhalb der Firma zum Beispiel.

Um sagst so, hier ist jetzt mein Monitoring zum Beispiel.

So, das kann zum Beispiel eine erstmal ganz einfach eine Wiki-Seite sein, wo drin steht, so kannst du dich in das zentrale Monitoring-System einklinken, ohne dass du ein eigenes Monitoring-System selbst hosten musst, als Team von zehn Leuten zum Beispiel.

Was ja Sinn macht.

Und du hast ja ganz viele Sachen, weil du willst ja eigentlich auch kein Source Go-Manag selbst machen, CICD selbst machen.

Das soll ja schon da sein, das soll ja jemand machen.

Und das ist dann halt mehr diese, das sehe ich mehr so, als auf der Ops-Seite von DevOps betrachtet, weil man dann halt Dienste für die Entwicklung zur Verfügung stellt.

Du möchtest aber eine Kommunikationsrolle da an der Stelle aktive Kommunikation nach außen haben.

Beides, ja.

Also letztendlich sowohl die technologische, dass es aber auch sinnvoll ist.

So, weil, ich meine, letztendlich macht die AWS oder GCP oder sonst was, die machen ja auch nichts anderes als Dienste bereitstellen und die kannst du dann nutzen.

Und das willst du ja innerhalb der Firma auch haben, nur halt eine Etage tiefer vielleicht so.

So ein Steward.

Ja, ja, ich verstehe.

Ja, weil, wo dann halt auch die unternehmenspezifischen Sachen mit drinstehen.

Und man sieht ja häufig dann ja auch in vielen Konzernen, ich weiß nicht, ob das heute immer noch so ist, aber ich glaube schon, so diese Self-Signed-Certificates, die dann irgendwo mit eingebunden werden müssen, wie die sind, dann Services, die dann jeder braucht oder sonst was.

Idealerweise ist es ja so einfach wie möglich, das irgendwo einzubinden, was an einer Stelle auch dann das entsprechende Team dann umzwischen kann, was dann von allen angezogen wird.

Also es gibt ja Sachen durch Services, die dann sowas wie APIs bereitstellen, dann gibt es Firmen, die das gut machen, es gibt Leute, da muss man lange Tickets schreiben, auf die man dann wochenlang warten muss.

Genau, und da fehlt dann wieder die Visibilität, weil du keine Ahnung hast.

Aber schöner wäre es ja dann wiederum, wenn du dann weißt, okay, dieses eine Team macht irgendwie, manage das Prometheus zum Beispiel für die ganze Firma, wo du dann weißt, die braucht eine Änderung, ich gehe da jetzt mal als normaler Entwickler hin, ich weiß, was sie ändern muss.

Ich führe da jetzt als Merge-Request dann oder Pull-Request die Änderung bei, die ich jetzt machen möchte.

Und das Team soll das reviewieren, weil die sind ja die Experten, die betreiben das.

Aber ich mache direkt die Änderung, schlage was vor und kann dann mit denen diskutieren, statt dass ich eine E-Mail schreibe oder ein Ticket aufmache und dann liegt das irgendwo im Nirvana und ich weiß als Entwickler selbst vielleicht nicht, wo das drin geht, obwohl ich vielleicht auch

noch hätte.

Ja, dann gibt es aber manchmal auch gar nicht so Teams, die das machen, sondern das sind dann einzelne Menschen, die sich hinter Menschen versteckt haben, die sich hinter Menschen versteckt haben oder die schon gar nicht mehr da sind und so.

Und ja.

Deswegen sind wir wieder bei einem People- und Management-Problem.

Das muss halt von oben erkannt werden.

Und ich sehe ja die ganzen Firmen, wenn ich mit denen rede, wie ineffizient die eigentlich arbeiten.

Ja, aber was macht man denn?

Abpreis und Neubauen?

Die richtige Lösung haben wir jetzt auch nicht so, aber erstmal muss das Verständnis da sein.

Das finde ich immer so erschreckend, weil, naja, bisher hat es ja immer funktioniert, das ist das Tür.

Also ich sehe das tatsächlich, so wenn es schon so in den tief in den Boden gefallen ist und so verzahnt ist und so verknotet und so weiter.

Ja, also People, ich habe da Probleme mit das lösbar zu machen, weil diese Interessen sich halt nicht harmonisieren lassen.

Und das, also ich finde das schwierig, also ich würde Parallelorganisationen in modern, in neu, in gut aufbauen, die guten Leute dafür finden und das umziehen.

Ja, das ist jetzt mehr so die Transformations-Migrationsfrage dann, ne?

Aber erstmal muss ja das Verständnis da sein.

Das Problem ist auch bei so ganz großen Konzernen, dann hast du eine Transformation angefangen, bist du am halben Jahr stecken geblieben, bist du doch mal ein Tempel irgendwie rausgeflogen.

Dann machst du die nächste Transformation auf der Transformation der Transformation und so wird das Ganze einen sich ewig in ein schwarz beißendes Monster und ja.

Ja, ich meine, was man schon sieht, ist, finde ich, dass, also, oder mir fällt gerade noch ein anderes lustiges Beispiel ein.

Da hatte ich nämlich auch bei der anderen Firma dann mit drüber unterhalten, die hatten dann ganz viele Firewall-Regeln zwischen irgendwelchen Diensten und das Entwicklungsstyle.

Muster musste dann irgendwo eine E-Mail hinschreiben, wo dann nochmal drin steht, warum, wieso, weshalb.

Mussten sie ganz am Anfang schon machen.

Und ein Validierungsdokument dazu einreichen.

Genau.

Ganz viele verschiedene Sachen, die dann noch mit reinspielen.

Und das ist dann halt irgendwie sehr, sehr schwierig, dann auch entsprechend zu sehen, wenn dann noch per E-Mail ganz viel kommuniziert wird.

Oh, ich habe so tolle E-Mail-Ketten erlebt, wie ein Dreivierteljahr eine Kette von 280 E-Mails an irgendwie unterschiedliche Leute zwischendurch mit Eskalation an verschiedene Management-Layer und dann irgendwie war dann ein Passwort dann verfügbar für einen Zugriff auf ein SharePoint-Laufwerk.

Ja.

Toll, ne?

Das nächste so, hä, im Moment, ich drücke jetzt zum Knopf und dann kommt das Passwort heraus, ich gebe es dir weiter und wo ist das Problem?

Aber gut.

Genau, das ist dann zum Beispiel, und wenn man das dann halt ordentlich umsetzt und dann kommen wir zum Beispiel wieder auf der technischen Ebene zustande, wenn man jetzt halt ein ordentliches, ein ordentliches Team hat für Firewall-Regeln, ist ja gut erstmal die Frage, wie weit man Firewall-Regeln generell braucht, in welcher Form.

Oder ob man das als Code zur Verfügung stellt, sodass die Leute dann einfach dann Merch-Requests, Pull-Requests oder sonst was aufmachen, so von wegen, und da die Diskussion machen, weil das dann nicht in E-Mails hängt.

Und man dann, wenn das approved ist, dann auch direkt gemerkt und ausgerollt wird und nicht erst dann, wenn es irgendwer dann zehn Jahre später dann implementiert.

Also ich glaube, das wird halt dann komplex und kompliziert, wenn du halt kein Unternehmen hast, was jetzt organisch gewachsen ist, sondern wenn du so Murder-Aquisition-Modelle hast, wo du halt einzelne Firmenteile kaufst und verkaufst und die wild rumschmeißt und die alle auf unterschiedlichen Stacks und Kulturen und Architekturen sitzen und du dann halt das irgendwie beherrschen willst, dass das schon...

Ah, ich meine, kommt auch mal darauf an, wo man hinschaut, ne?

Also wie weit man das spannen möchte.

Manchmal reicht es ja schon, wenn es dann innerhalb von, wenn es, keine Ahnung, eine große Firma ist, wo fünf verschiedene Sachen sind oder aufgekauft worden sind und mit völlig verschiedenen Stacks sind, aber irgendwie zusammengekloppelt sind, dann reicht es ja schon, wenn man fünf verschiedene Sachen hat für Firewall-Sachen statt 20 oder 200 oder sowas.

Ja, schon besser, vielleicht.

Oder gar keine Kontrolle drüber hat.

So, oder?

Ja, und genau, das ist auch wieder.

Also meine Erfahrung ist aber, dass auch da das Verständnis oft dann fehlt, wofür sowas.

Was ist denn eigentlich eine Firewall?

Das ist immer sehr enttäuschend.

Firewall oder ist er sicher?

Die große Leute überhaupt gar nicht verstehen, was sie da tun.

Ja, der ganze Verkehr geht alles so bei einen Knoten und dann an dem Knotenpunkt wird geguckt und genau entschieden, was durch darf und was nicht.

In die eine oder in die andere Richtung.

Naja, aber was ist das denn?

Ist das ein Hardware-Gerät?

Das ist ja eine gute Frage.

Ja, also aus der theoretischen Sicht würde ich sagen, ja, das ist halt ein Konzept zur Umsetzung einer Policy am übergang zwischen den Richtung.

Ja, aber ich finde, das geht ja schon mal wieder nochmal der Tiefe, äh, eine Stufe tiefer.

Weil, weil mein Punkt ist ja mehr so, die Ineffizienten erstmal wissen, dass man Ineffizienzen hat und diese dann auch auflösen kann.

Und das kannst du auf verschiedenen Ebenen machen.

Weil mit anderen Kunden mal gesprochen, die sind, die machen mehr halt in Fabriken und deren Hauptprodukt ist, irgendwas auszudrucken.

Und die gucken dann halt sehr stark drauf, wie die Leute gehen innerhalb der Fabrik oder sonst was, damit das alles effizient ist.

Weil da siehst du ja, wenn jemand fünfmal um den Block läuft oder um den Drucker läuft, dass

das ineffizient ist.

Aber vielleicht mit den ganzen Leuten auch geredet.

Und wenn es gerade um People's Management ging, dann siehst du drumlaufen durch das ganze Gebäude vielleicht gar nicht so schlecht.

Genau, und da kann ja schon mal hilfreich sein, wenn du mal mit anderen Leuten redest, genau.

Ja, aber das würde zum Beispiel, wenn du rein die Route optimieren würdest, würde sowas unter den Tisch fallen, weil du hast von einem kulturellen Aspekt gesprochen und von sowas wie der Fisch stinkt vom Kopf her.

Und das fand ich beides super wichtig.

Ja, genau.

Und aber ja, also auch jetzt Beispiel, es gibt einen hypothetischen Konzern, der eine Kultur hat, die, ich sag jetzt mal, relativ konservativ ist.

Und da hast du jemanden, der aber eigentlich so ein modernes, plattform-driven-Mindset hat, den er irgendwie versteht, dass diese Sachen so ein bisschen, ja, mehr Synergieeffekte haben könnten, wenn man so eine Harmonisierung von dieser Kultur auch hinkriegt und mit den Menschen, wenn man die besser einbindet, der kommt mit der Kultur ja vielleicht gar nicht klar.

Das heißt, wenn das so theoretisch möglich ist, also ist es auch für jemanden, der als CTO, whatever, versucht, in vielleicht eine richtige Richtung zu gehen, wenn er intern halt vor diesen Blockaden steckt, kommt er da gar nicht durch und verbrennt sich und kommt dann in Diskussionen über Effektivität oder über Finanzen oder wie dauert das denn so lange und wie teuer ist das denn?

Und du hast halt auch so da so, die richtige Form finde ich jetzt schwer zu beschreiben, aber wenn ein Projekt am Anfang viel Geld kostet und am Ende irgendwas bringen, ist es schwer, trotzdem die vielleicht durchzukriegen, als wenn du so eine Salamitaktik mit so Häppchenweisen Veränderungsprozessen machen kannst.

Was es halt auch für solche Manager dann unheimlich schwer machen kann, in so Konzernen mit einer festen Kultur Veränderungen reinzubekommen.

Einer der Gründe, warum ich sagen würde, ist das eigentlich überhaupt keine gute Idee, mach es einfach in neu im Guten und versuch dann deine Sachen anzubinden.

Also in gut mit den, also du hast recht, eine Kultur, die richtigen Leute an der richtigen Stelle und die richtige Plattformarchitektur zu finden, wie man überhaupt Services deployt, das einmal in gut aufzubauen und dann die Äste nach unten zu schlagen.

Aber jetzt sind wir in dem Problem, ist dieser Transformationsprozess, wird dem vertraut, kann ja durchgehen.

Deswegen glaube ich gar nicht, dass der CTO der richtige Ansprechpartner wäre, sondern es müsste tatsächlich dann, je nach, keine Ahnung, Business-Modell, der ganze Aufsichtsrat oder der ganze Vorstand zu machen.

Nee, genau.

Naja, gut.

Aber da hast du halt das Problem, ich meine, gerade wenn jetzt ein Konzern was anderes macht, dann.

Ja, also die verstehen überhaupt nicht, wovon du redest.

Genau, eben.

Also das grennst du darum, ist die Frage, was es erwarten, dass sie mit Mitarmitteln beschäftigen wollen.

Vielleicht kriegen die Menschen noch hin zu unterscheiden zwischen irgendwie dem Admin, der da im Keller rumsitzt und auf den Knopf auf den Servern rumdregt und dem Entwickler, der zu Hause auf seiner Kiste versucht, irgendwas an Software zu bauen, was man irgendwie braucht, aber das Ganze dazwischen, diese heute hochkomplexe Geschichte, warum man Cloud braucht alles, die ganzen Passwort-Sachen, das wird gar nicht so offensichtlich klar.

Also die meisten Leute ist auch gar nicht klar, dass Cloud nur der Rechner von jemand anderem ist irgendwie.

Ja.

Das ist auch irgendwie komisch zu verstehen.

Und wo das Netzwerk halt hingeht und warum man das überhaupt alles machen muss, klar, da gibt es auch Leute, die sagen, ja, warum steht das nicht bei uns im Keller, wo ich auch sagen muss, ja, auch vielleicht gar nicht so immer die doofe Idee, vielleicht kann man das ja auch da so verteilt hinstellen, dass es gute Renaissancen ist.

Aber das ist, ja, das ist keine allgemeingültige Antwort auf diese Frage.

Ja, also ich meine, ich kann ja nochmal eine andere Story erzählen von den vorherigen Arbeitgeber, wo ich war.

Da war ich aber extern an einer anderen Firma verkauft, so konsultant-mäßig.

Und das fand ich auch spannend, weil da war ich quasi in so einem Ops-Team und um Firewall-Regeln zu managen, das war halt total identifiziert.

Weil da war es dann halt auch so, naja, ein Team müsste von A nach B irgendwie Firewall-Freischaltung haben.

Dann wurde halt irgendwie ein Ticket aufgemacht in einem der 5000 Jira-Instanzen, die es also gab.

Und dann lag das erstmal eine Woche rum.

Dann hat das irgendwie, das Zielsystem hat dann irgendwann auf Approof gedrückt und dann lag das nochmal ein paar Tage rum und dann hat es irgendjemand implementiert.

Das hat halt ewig gedauert.

Und manchmal kamen da irgendwelche Projektmanager mit Schokolade an und so von wegen so, mach mal schneller hier.

Ja, ja.

Wieder bei der People-Komponente.

Aber eigentlich wäre es ja schon viel schöner, wenn die Teams halt einfach selbst den eben, ne, wie vorhin gesagt, den Merch-Requests quasi stellen, dass sie sagen, so, ja, ich muss jetzt von A nach B hin und dann, wenn der Zielsystem das approved oder die Person halt das approved, dass es dann automatisch gemerkt wird und beziehungsweise in der Zwischenzeit halt reviewed wurde.

Und dann kriegst du es halt theoretisch halt von einem Tag durch.

Also ich bin auch, also ich brauche zum Beispiel sowas häufiger mal und ich hatte auch überhaupt keinen Bock auf so einen Prozess.

Und ich habe dann einfach angefangen, mir so Requests auszudenken.

Also echte Requests braucht halt immer viel, ich habe viel entwickelt und dann unterschiedlich auch Sachen umgehängt, also in Anführungszeichen, so Fehler produziert, weil es muss ja doch anders sein, als ich dachte.

Und ich habe einfach so viele Anfragen produziert, dass meine Privileged Escalation quasi gestiegen ist und ich mehr Verantwortung bekomme, um die Sachen selber zu riegeln.

Was vielleicht nicht der ganz richtige Weg ist, aber das ist tatsächlich so ein Problem, ja, weil die Leute, wenn du die Leute dazu bringst, dass sie arbeiten müssen, irgendwann passiert was.

Ja, und das muss halt idealerweise von oben dann halt auch gestellt werden.

Genau, das ist der Grund, warum ich das gemacht habe, weil halt irgendwann halt klar wird, hey, okay, da eskaliert was nach oben und dann gibt es halt dieses Kommunikationsproblem und man muss halt einen neuen Prozess vielleicht finden oder den Prozess verbessern, um halt irgendwie die Kommunikation und die Kosten, die dadurch entstehen, so ein bisschen runterzukriegen.

Aber das ist halt krass, weil in so festgefahrenen Strukturen das wenige, das sind dann politisch-taktische Dinge, ja, um da irgendwie weiterzukommen.

Es ist fürchterlich, ehrlicherweise.

Ja, vor allem da gab es ja noch ganz viele andere Sachen und da muss ich jedes Mal drüber denken, wenn ich über nämlich über DevOps rede, weil da gab es halt Entwicklungsteam, die haben das halt entwickelt.

Dann gab es ein App-Ops-Team, die haben nur die Anwendung irgendwie betrieben.

Und dann gab es nochmal das Team, in dem ich war.

Da ging es dann mehr um das Betriebssystem und das, was gebraucht wird, damit das App-Ops-Team da irgendwas hingeployen kann.

Dann gab es aber auch nochmal irgendwie so einen, ich kriege jetzt nicht mal ganz auf die Reihe, dann gab es aber auch nochmal ein QR-Team, was nachgelagert war, die auch nochmal einen eigenen Jenkins irgendwo laufen hatten mit eigenen Tests und die aber nur so Enduser-Oberflächen-Selenium-Tests gemacht haben.

Die aber keinen Zugang zu dem Source-Code hatten von dem eigentlichen Job.

Das heißt, sie sind bei der Änderung immer hinterhergelaufen.

Ja, und der Enderung unsere Tests sind kaputt.

Also oh Mist, was macht das?

Das waren doch nur so zwei Leute in diesem Team oder was?

Ja, super.

Und der war total demotiviert eigentlich die ganze Zeit, weil er ihnen immer nur hinter irgendwelchen Änderungen hergelaufen ist.

Der konnte ja nichts anderes tun.

So, und eigentlich macht es halt nicht Sinn, das nachgelagert zu machen, sondern wie du vorhin ja auch meintest, Shift-Left, möglichst frühzeitig das hat es auch zu machen, damit das Teil des Prozesses wird.

So, wenn das aber schon irgendwie so von einer Organisationsstruktur so aufgebaut ist, dass man gar nicht mit den Teamen oder Teams redet, dann macht das irgendwie nicht so viel Sinn.

Ja, auch Security, ne?

Diese ganzen Regeln, diese Policies, wo kommen denn eigentlich her?

Warum gibt es die denn?

Ja, genau.

Irgendjemand hat da irgendwann gesagt, das muss so sein.

Der schon Rente.

Ja, aber was auch noch spannend war, ist dann halt das Team, in dem ich dann war, hat, hat halt mehr so diese Mittelbeer dann da betreut.

Und da fand ich es halt spannend, da ist dann fast jedes Mal jemand, der dann nachts aufgeweckt worden, weil irgendwas im Monitoring gemeckert hat.

Was hat da gemeckert?

Voll oft, weil da irgendwie eine Festplatte vollgelaufen ist.

So, und da kommen wir jetzt wieder auf den Punkt von wegen verschiedene Ziele.

Weil wenn ich als Entwickler nachts aufgeweckt werde, dann will ich eigentlich nur, dass dieser verdammte Warnung weggeht und ich mich wieder hinlegen kann.

Ja, Loggen abstellen.

Zum Beispiel, ne?

Oder halt das Log-File deaktivieren, weil halt irgendwie Loks total vollgeschrieben hat.

Ja, und was passiert?

Am nächsten Tag passiert es halt nochmal.

Und nochmal.

Aber es gab halt keinen richtigen Feedback-Channel zu das eigentliche Team, um das eigentliche, um den eigentlichen, weil das ist halt eine Anwendung, ne?

Also ich habe auch schon so Sachen gesehen, also Security-Regeln total wichtig und alles zugemacht und so weiter, aber dann brauchte halt jemand irgendein Monitoring, irgendein Login-Tool.

Was hat er halt gemacht?

Also nicht das Login konfiguriert und dann irgendwie den Port-Stecker richtig reingesteckt, sondern einfach alle Ports aufgemacht, weil er mit seinem Tool da drauf wollte.

Zack.

Ja, und da merkt man halt wieder so, naja, wenn die jetzt in einem Team wären, Dev, QA und Ops, dann würdest du alleine, weil man sich ja schon kennt, würdest du ja schon so und du würdest dann ja auch als Dev dann ja auch Bereitschaft oder sowas dann machen.

Was viele vergessen, ja, muss man.

Oder sollte man, wenn man Shared Responsibilities hat.

Da bist du ja im eigentlichen Interesse, im eigenen Interesse, dass du eben nicht jede Nacht wach wirst.

Und wenn du dann aber auch die Person tatsächlich kennst, die jede Nacht aufgeweckt wirst, dann fragst du halt ja eher mal nach, warum eigentlich wirst du aufgeweckt und erzählt dir ja dann halt was.

Wenn das aber so weit in der Organisationsstruktur auseinanderhängt, dass du gar nicht dazu kommst, mit denen zu reden, weil du nur über irgendwelche E-Mails und irgendwelche Ticketsystemen redest, dann ist es halt schon sehr, sehr schön.

Ich hatte das auch gedacht, dass ich irgendwie im Urlaub irgendwie so Zeugs machen musste oder sowas.

Weil einfach aber die Kollegen, die in meiner eigenen Abteilung sind, irgendwie keinen Bock hatten, sich darüber Gedanken zu machen.

Und das ist ja noch weiterhin völlig egal.

Sei denn, die müssen es selber machen.

Und dann müsste ich damit auskähnen.

Aber wenn man halt, wenn sie sich halt damit auskennt, dann sagen wir so, oh, da weiß ich ja gar nichts von, das ist schon schwierig.

Ja, gut, also solche Probleme gibt es natürlich auch immer noch, aber das ist dann halt schwer zu lösen mit irgendwie.

Ja, genau, ja, aber jetzt sind wir bei demselben Problem.

Jetzt fängt das an, ja.

Nee, du wirst dann, man wird ja auch nicht alle Probleme damit los, klar.

Also ich glaube, dieses Kapital.

Dass du die Leute zum Beispiel gar nicht kennst, mit denen du reden müsstest.

Das auch, wenn du dann bei

deinem gleichen Team bist, dann hat man das schon mal nicht mehr.

Ja, das kannst du ja, du kannst ja auch nicht alle kennen.

Genau, also gerade wenn du ganz viele verschiedene Teams hast, wir tun wir ja so, als haben wir irgendwie 100 Projekte gleichzeitig oder sowas, wie würde man denn da mit den ganzen Leuten, wie will man die alle kennen?

Nee, klar.

Über Jahre vielleicht, ne?

Genau.

Nee, genau deswegen ist es ja auch wichtig, möglichst den Dienst so einfach wie nur, also wenn man das irgendwas als Dienst innerhalb der Firma betreibt, um jetzt wieder auf den Punkt wie Monitoring oder Firewall-Regeln oder Source Code Management CICD oder sowas angeht, dann will man ja auch nur eins davon haben und will endlich jedes Team das Rad neu erfinden und alles selbst betreiben.

Das Tooling drumherum.

Und das willst du ja eigentlich ja auch ein bisschen zentralisieren.

Ja.

Ja, aber das ist auch wieder eine interessante Frage.

Ich meine, wir hatten ja jetzt eben diese ganzen Probleme, die man halt, wenn man so sehr, sehr groß ist.

Aber kann es nicht sein, dass man das anders machen würde, wenn man jetzt nicht so groß ist zu machen?

Ja, da zum Beispiel würde ich da sagen, okay, alles auf einer Kiste, alles drauf, alles läuft und jeder weiß, wie es geht und ganz gut.

Ich würde auch denken, dass zum Beispiel dieses alles selber machen, ist eigentlich vielleicht.

Und die Frage ist, wie macht man das jetzt eigentlich?

Also macht das Sinn?

Also klar, wenn du halt einen großen Konzern hast und du hast halt Monitoring, dass halt ein Team das Monitoring macht, okay.

Ja, das ist irgendwie schon ein Nachvollzug.

Entschuldigung, bin ich nicht gar einbrecher, aber warum nicht einfach sagen, hey, wir haben hier so ein Monitor und bitte sorgt doch dafür, dass eure Anwendung hier drin hinkommuniziert.

Also sowas wie Eventstreaming oder sowas.

Naja, gut, aber sondern so, du brauchst dann halt irgendwie jemanden, der sich damit beschäftigt.

Und wenn das halt hinreichend groß wird, dann kann das nicht mehr irgendwie jeder machen für sich, sondern dann muss das halt irgendwie.

Nee, aber vielleicht habe ich irgendwie dann irgendwann so eine Liste von Sachen, die ich halt erfüllen muss.

Ich muss halt irgendwie Blue Head dann was geben.

Aber ich kann die Sachen trotzdem ja alle noch selber machen.

Das verstehe ich nicht.

Also wenn zum Beispiel jemand sagt, hey, ich habe hier so einen Endpunkt, bitte poste doch dahin deine Loks.

Für diese und diese Fälle, dann, wenn ich das machen müsste, dann würde denen auffallen, wenn ich A keine Loks poste.

Und auch wenn in den Loks irgendwas durch, was da nicht drinstehen soll.

Und dann hätten die immer noch die damit machen, was sie wollen.

Ja, dann wäre das wäre ja so diese Monitoring-Abteilung, die könnte da Inzident.

Genau, das meine ich.

Genau das meine ich ja.

Das muss ja jemand trotzdem zur Verfügung stellen.

Bei größeren Firmen halt eher als bei Kleinen.

Wenn du 50 Leute Firma ist, das ist ja, da kannst du ja einfach rüberlaufen, so gesehen, wenn du im Office sitzt oder jemandem ping.

Das ist jetzt nicht das Ding.

Aber es muss ja trotzdem mehr betreiben und machen.

Genau, aber wenn man jetzt kleiner macht, also mein Ding wäre jetzt eher so, wenn man jetzt sehr viel kleiner ist, kann es nicht sein, dass dann vielleicht eine interessantere Strategie ist, statt irgendwie Tools für all das zu haben, das halt alles einfach selber zu machen.

Also, ich meine, ist natürlich auch vielleicht ein bisschen extrem, aber ich mache das ja tatsächlich auch häufiger.

Und manchmal fühle ich mich mir so ein bisschen schlecht, weil ich denke, naja gut, vielleicht sollte ich das nicht tun.

Aber auf der anderen Seite denke ich mir so, naja, wo ist eigentlich meine Kernkompetenz?

Was ist das, was ich gut kann?

Und mein Ding ist halt einfach, ich kann halt zum Beispiel ziemlich gut Crut-Apps, Web-Geschichten machen.

Das kann ich halt einfach, weil ich das einfach total häufig mache.

Und die Frage wäre jetzt halt, macht es für mich Sinn, irgendwie so ein Tool wie Prometheus zu verwenden oder Kubernetes oder keine Ahnung.

Oder ich kann mir auch einfach mein eigenes Ding schreiben, was das halt, was meinen Anwendungsfall erfüllt und sonst nichts, dann ist es vielleicht so, dass ich dann besser das halt selber baue.

Würde ich auch so sehen.

Und ich würde sagen, das ist mein Ansatz wäre auch zu sagen, okay, dann bauen wir das halt klein selber in gut für das, was man braucht.

Und wächst dann halt organisch.

Dann hat man halt tatsächlich verschiedene Monolithen, die genau exakt darauf zugeschnitten sind, was man will.

Man muss halt gucken, dass der Knowledge-Transfer da gut ist.

Aber man wird diese ganzen Tools eigentlich alle los.

Ja, also wo zieht man die Grenze?

Das ist das Schwierige.

Also irgendwann, also bei einigen Sachen muss man dann halt selbst machen, weil wenn man jetzt halt über, keine Ahnung, Redes spricht, dann ist halt auch immer die Frage, so, naja, entweder betreibe ich das jetzt einfach selbst, weil ich das einfach nur brauche, dann ist das okay.

Oder man macht das mehr so als Managed Service bei einer eher größeren Firma.

Nur bei eher kleineren, aber das ist ja halt nicht eben etwas, was jede Firma braucht.

Und dann kannst du es halt überall selbst betreiben.

Aber wenn es halt so um was Elementares wie Source Code Management und CICD geht, was halt wirklich jeder braucht.

Ja klar, so ein eigenes Git-Schreiben ist vielleicht nicht.

Oder die eigene Idee schreiben will man auch nicht.

Ja, aber ich meine, das ist ja das Ding, ich habe schon so oft gesehen, wo es dann halt, ich glaube, ich habe mal eine Firma gesehen, die hatten dann gezählt, wie viele GitLab-Instanzen sie in der Firma hatten und das waren irgendwie über 200 Stück.

Oh, okay, ja.

Das ist sportlich.

Und wenn dann halt irgendwie so eine Supply Chain-Thematik wieder aufkommt, wie bei der Log4J-Thematik, dann fangen sie erstmal an zu gucken, dann so, oh, äh.

Du musst ja dann alles finden.

Richtig.

Und das ist dann wieder schwierig.

Und dann hast du lieber wieder was Zentrales.

Und genauso macht es natürlich dann auch bei anderen Monitoren, wie wir es vorhin halt hatten, so, damit man nur noch an einer Stelle gucken muss, auch für kleinere Firmen.

Je weniger standardisierte Lösungen du verwendest, desto schwieriger wird es natürlich auch, dich zu akquirieren und dich dann einzubinden.

Ja, und das ist

auch ein Schätzungsmodell, das lass uns doch mal bitte den Cut verkaufen.

Ja, das habe ich auch schon tatsächlich am eigenen Leib.

Das ist auch sehr frustrierend, wenn man das nicht weiß.

Also wenn tatsächlich zum Beispiel sich das strategische Ziel der Firma ändert von irgendwie Wert an unten zu irgendwie Wert für die Eigentümer, also die noch-Eigentümer, wenn sich das dahingehend ändert und man dann so ein bisschen in so ein Dual Diligence-getriebenes Entwicklungsmodell verfällt, aber nicht weiß, worum es eigentlich geht, das kann sehr frustrierend sein.

Ja, es ist

generell so, was das anfängt.

Also auch von mehreren Perspektiven, ja.

Also auch wenn ich jetzt was Tolles gebaut habe, dann das abgenommen zu bekommen und das standardisieren zu müssen und das alles wegzuschmeißen, was cool ist, ist blöd.

Aber auch wenn ich halt irgendwas übernehmen muss, was total trottig ist und irgendwelche Leute gebaut haben, die weiß nicht, auch seit zehn Jahren keine Lust mehr hatten, sich den neuen Scheiß anzugucken und das einfach irgendwie da hingesetzt haben, wie es früher so war, ist halt auch super nervig.

Also Kulturprobleme, DevOps, also eine Kommunikationsrolle, ja?

Oder alles schwierig.

Ich meine, wir haben irgendwie so über ganz vieles gesprochen, aber irgendwie, aber das ist ja genau das, was ich spannend finde dann halt auch.

Und genau deswegen dann überhaupt das Bewusstsein zu schärfen.

Naja, als normaler Entwickler kann man da ja gar nicht so viel machen, weil wenn die Struktur, Teamstruktur, wenn man jetzt den reinen Techie anhört, und ich würde jetzt mal sagen, wahrscheinlich hören viele reine Techis jetzt erstmal zu, die können halt nicht so viel tun, so, weil wenn es halt.

Ja, du musst ja deine Flight-Level-Kompetenz ein bisschen raisen.

Weil wenn ich halt, und ich meine, im Endeffekt sind der Entwickler halt zum Entwickeln, ja.

So, oder?

Ja.

Und es muss halt trotzdem noch Leute geben, die das betreiben.

Und das sind ja nicht unbedingt die gleichen.

Ich hatte jetzt letzte Woche erstmal mit einem das Gespräch gehabt, der meinte dann so, ah, DevOps findet er irgendwie doof.

Nächstes Jahr, warum denn?

Dann so, naja, so wie es bei, und dann kam der zweite Satz, ja, so wie es bei uns umgesetzt wird, finde ich es so.

Also ja, wie wird es den umgesetzt?

Dann so, ja, also es ist ein Großkonzern, den jeder kennt, äh, den nenne ich jetzt mal nicht.

Und der meinte dann halt so, naja, der hat, da sind dann so Entwicklungsteams, sind dann so fünf, sechs, sieben Leute.

Und dann gibt es dann halt viele einzelne Teams, die dann so einzelne Services bereitstellen, also wie ich vorhin auch schon ein bisschen erzählt, und als beratend quasi tätig sind.

Aber die Teams selbst sind für sich einzeln verantwortlich für alle ihre Microservices oder sonst was.

So.

Und dann fragt die so, okay, um was funktioniert nicht?

Dann so, naja, das sind halt von diesen sechs Leuten sind sechs Entwickler.

So, und da sitzt halt keiner drin, der überhaupt mal so ein bisschen Ahnung hat, so von wegen, wie man irgendwas betreibt, wie man Monitoring, wie man Backup oder sonst was betreiben muss.

Da gibt es zwar hier und da vielleicht mal ein paar Ressourcen, aber halt überhaupt nicht der Fokus, der es eigentlich sein sollte.

Ja, das ist natürlich schlecht.

Da braucht man auch, wenn man halt irgendwie alles machen soll, dann muss man halt auch die entsprechenden Kompetenzen auch alle da haben eigentlich.

Ansonsten wird es halt schwierig.

Genau, weil du musst ja die Anwendung entwickeln, du musst es dann auch wissen, wie man das auf dem Kubernetes zum Beispiel deployt oder auf dem OpenShift oder was auch immer.

Oder wohin auch immer man deployt.

Wenn es halt ein Kubernetes ist, dann ist es halt von der Lernkurve halt deutlich höher.

Und wenn es dann, dann brauchst du noch das Monitoring-Tool, dann musst du noch gucken, wo du die Backups hinschiebst vielleicht.

Oder vielleicht musst du einen Object Storator anbinden oder selbst hosten, vielleicht noch ganz schlimmer.

Und dann musst du ja noch das Source Code Management und das CICD-Tool noch bedienen.

So mehr aus Entwicklungstoolings ist, dann hast du nochmal ein ganz anderes Tool, so aus Richtung Security vielleicht noch.

Wo dann nochmal diverse Reporting sind.

Da hast du noch ein Projektmanagement-Tool.

Die musst du jetzt nicht alle selbst betreiben, aber manchmal schon.

Und halt noch die ganzen Nebendienste, eben wie vorhin gemeint, wie Redes zum Beispiel dann, ne?

Die dann auch eben irgendwo laufen müssen.

So, und da muss man halt so viele verschiedene Sachen können.

Das kann halt nicht fünf Personen machen, die nur entwickeln.

Ja, ja gut, klar.

Das ist halt, ja, das, äh, ja.

Und wenn es dann so ein bisschen geschert ist, dann geht das dann ja noch.

Aber wenn es wirklich so rein entwicklert ist, dann ist es halt schwierig.

Ja, wobei ich glaube auch, dass es halt, ja, wenn die, wenn die, also dieses, dieses, wenn es halt groß wird, dann ist es immer problematisch, weil ich weiß auch nicht, wie will man das lösen.

Also Leute, die halt alles können, wenn man eine sehr komplexe Umgebung hat, dass es halt dann wird halt immer weniger.

Und das Problem ist aber auch, irgendwie kann man es halt nicht einfacher machen, weil, ja, man will ja davon profitieren, dass man Dinge zentralisiert und halt irgendwie, ja, sehr schwierig.

Ich hätte eine Lösung dafür.

Einfach nicht so groß werden, das ist blöd.

Das ist ganz doof.

Du meinst Microservices.

Nein, nein, ich will.

Microcompanies.

Wenn wir es Microsoft.

Namen haben wir dann schon mal.

Ja, das brauchen wir nur noch Betriebssysteme.

Ja, ist auch nicht mehr so Mike Ho inzwischen, aber naja, machen inzwischen auch andere Dinge.

Machen die noch Betriebssysteme?

Ja?

Ja, echt?

Ich weiß nicht so genau.

Wird das doch gehabt hat?

Naja, gut.

Keine Ahnung, aber ja, also ich, weil wenn man halt klein ist, dann kann man ja diese ganze Komplexität herausnehmen.

Dann machen wir halt irgendwie kein Kubernetes.

Und dann machen wir halt, man braucht es eigentlich auch, ehrlich gesagt, dann wahrscheinlich nicht.

Ja, also kleines

auch so dann auch nicht die ganze Skalierungsthematiken verkupfen.

Genau, haben wir auch nicht.

Also ich habe tatsächlich, der Hauptgrund, warum Leute, die ich kenne, dann so Kubernetes unbedingt haben wollen, ist, weil sich dann andere Teams darum kümmern, was da passiert.

Ja, aber genau, ich glaube, das ist ein.

Du kannst es nicht delegieren.

Quatsch, das wird den aber erst dann auch mal, wenn es halt dann die Probleme gibt, weil die hoffen dann immer darauf, dass das irgendwie glatt geht, weil, also das Problem ist halt ja, wenn es irgendwelche Änderungen gibt und die Entwickler gar nicht wissen, wie man halt so eine Pipeline anpasst, weil da irgendwelche kleinen Änderungen sein müssen, weil die Backer-Strategie anders sein muss, weil da irgendwelche Sequels hin und her gestauscht werden müssen, weil irgendwas mit den Volts passiert, weil irgendwelche Versionsänderungen beim Entfernen von irgendwelchen Migrationen irgendwelche Probleme machen, weil die Datenbank irgendwie trotzdem einen SLA hat, der nicht.

Dann, oh, obs.

Da muss man halt doch irgendwas von wissen halt, ne?

Das ist irgendwie blöd.

Ja, ich meine, das ist halt die Frage, wo man die Abstraktion macht, noch?

Ja, also der Konzern möchte jetzt ja immer gerne so weit wie weg wie möglich von allen Leuten, die irgendwas kaputt machen können, machen und gerne die ganze Kontrolle haben, was halt dazu führt, dass irgendwie keine Innovation mehr passiert.

Und dann ist halt die Frage, kann man so eine, also kann man eine Konzerninfrastruktur bereitstellen, die so automatisiert ist, jetzt sind wir aber halt nur beim Tuning beim Prozess und bei nicht mehr bei diesen Menschen, ne, dass alles einfach so funktioniert und man unabhängige Teams voneinander haben, die irgendwelche Anwendungen einfach so bauen können und dass der Konzern, die Krake schluckt das einfach und packt das so hin, dass es für alle immer regelkonform läuft.

Also ich hab, und jetzt komme ich wieder zurück auf die Management-Ebene.

Ich habe genau einen, ich weiß nicht genau, was für eine Rolle der hat, relativ hoch bei einer alten Bank ist.

Oder denkst du, naja, alte Bank, da ist alles langsam oder sonst was.

Und der war ganz klar, lag vielleicht auch daran, dass er ein Ami ist, der ganz klar dann gesagt hat, so, naja, ich will das hier zu einem Tech-Konzern umbauen.

Und das ist halt total ineffizient, wenn ein Entwickler anfängt und er muss erstmal drei Wochen warten, bis er für irgendwas Zugänge hat.

Den war halt so wichtig, dass dann, wenn er den Laptop aufklappt.

Und ich meine, ihr seid ja auch freiberuflicher unterwegs.

Das heißt, ihr habt da manche auch dann, wo ihr dann sagt, ja, jetzt warte ich noch auf Zugänge für irgendwelche fünf verschiedene Sachen oder sonst was.

So dass du dann nur noch einen Zugang bekommst und dort dann alles mit komplett idealerweise, idealerweise durchautomatisiert ist, so von wegen so, dass du naja Zugang zu den entsprechenden Projekten brauchst und bekommst, die du halt brauchst, dass dann da auch die alle Security-Richtlinien und sowas schon eingerichtet sind.

Darüber können wir gleich nochmal separat sprechen, dass dann halt auch zum Beispiel eine IDI über den Webbrowser dann zum Beispiel funktioniert, wo dann die ganzen Container, die dann gestartet werden müssen, irgendwo auf dem Kubernetes im Hintergrund laufen, damit du lokal jetzt nicht nochmal gucken musst, wie installiere ich jetzt überhaupt meine Entwicklungsumgebung.

Ja, weil was das ja ein Problem ist, dann muss ich ja mit dem Durchschlüsselloch irgendwie in den Container rein.

Das kannst du dann ja.

Also bei GitLab heißt das Remote Development Workspaces.

Bei GitHub heißt das zum Beispiel Code Spaces.

Und da kannst du ja direkt in die Container reinfriemeln.

Das ist erstmal egal, ob das bei dir lokal ist oder irgendwo anders, der Container läuft.

Aber der Gedanke ist ja halt, dass du halt sofort loslegen kannst, zu entwickeln und nicht erstmal den ganzen Stack, also klar, irgendwie musst du schon verstehen, wie abgeht, klar, das lernst du dann ja, aber du musst jetzt nicht jeder einzelne Teil so richtig verstehen, weil idealerweise kann man ja so gucken, so ich bin jetzt ein neuer Mitarbeiter und ich möchte genau einen String ändern.

Bei der Riesenanwendung zum Beispiel.

Wie lange braucht man dafür, um das hinzukriegen, ja.

Und wenn das sehr lange ist, ist es schlecht, ja.

Genau.

Und dann musst du halt theoretisch nochmal komplett durchgehen und gucken, was kannst du alles automatisieren, um das angenehmer zu machen.

Und da können wir zum Beispiel auch mal über Security sprechen.

Weil wenn wir jetzt mal von Abhängigkeiten zum Beispiel angucken, finde ich immer ein relativ einfaches Thema, weil es, also einfach zu erklären zumindest.

Weil wenn ich jetzt irgendeine völlig veraltete Python-Abhängigkeit habe, muss ich erstmal wissen, dass sie dir drin ist.

Also irgendwie eine Sichtbarkeit haben.

Und häufig sehe ich es dann halt nur so bei den ganzen Firmen so, naja, die haben halt irgend ein spezielles Team, ein spezielles Tool, was ein bestimmtes Team dann betreut, also Security-Team betreut, was komplett nachgelagert ist und die sagen dann kurz vor dem Deployment, nee, also könnt ihr nicht deployen, weil da ist irgendwie eine veraltete Sache drin.

Ja, also wenn die das überhaupt wissen, also ich meine, dann wollen die, dann, also ich kann das so, dann wollen die nachgucken, welche Dependencies es denn gibt, also so ein JavaScript-Ding oder sowas, dann schickst du halt 200.05 und dann sagen die so, äh, uff.

Ja, genau.

Dann gibt es halt zwei Optionen entweder sagen die sehr, okay, dürft ihr machen, oder die sagen halt so, nee, ihr dürft kein JavaScript nutzen.

Oder so.

Und dann, ja.

Ja, genau.

Und da musst du natürlich gucken, wie machst du es dann richtig?

Und da kommen wir wieder zu den Shift-Left zu sprechen, dass du das ja möglichst in der Pipeline schon haben willst.

Die alle nutzen.

Und vielleicht alle nutzen müssen, weil da kommen wir wieder in Richtung Compliance.

So, weil.

Du willst deine eigenen Runner betreiben?

Für so Pipelines und sowas.

Nee, die Pipeline-Definition selbst.

Was ist deine Pipeline-Definition an der Stelle dann?

Naja, wenn du jetzt eine Pipeline geschrieben hast, egal welches Tool jetzt, dann willst du dann ja, naja, dass das Projekt gebaut, getestet und irgendwo hindeployed wird.

Aber du hast dann ja auch zum Beispiel den Security Scanner, den du ausführen musst.

Also deine eigene YAML-Pipeline hat irgendwelche Prozesse, die da sind und es gibt ein Repo, in dem deine eigenen YAML-Pipelines liegen, die alle benutzen müssen.

Naja, erstmal gibt es ja nur die Pipeline.

So.

Und jetzt ist halt die Frage, so, naja, ich möchte jetzt als Firma durchsetzen, dass, weil du sprachst ja davon, naja, wie kann man das jetzt machen, dass man komplett durchautomatisiert so machen wir.

Und das muss man ja gucken, wo man das automatisiert und wo man das dann auch eventuell durchsetzt.

Weil ich habe voll oft schon mit irgendwelchen Kunden gesprochen, die sagten dann so, ja, wir haben hier irgendein bestimmtes Security-Tool, das ist das Beste, was es gibt.

Und dann so, aha, warum ist das das Beste?

Warum?

Und dann kommt halt so, ja, das findet die meisten True Positives und sonst was, kaum False Positives und so weiter.

Klingt erstmal gut.

Wo ist es denn eingebunden?

Ja, kurz vor dem Deployment.

Und dann haben wir halt wieder das Problem, die Entwickler sehen nichts.

Und da wollen wir ja wieder, dass das Dev-Sec-Ops dann entsprechen, ne?

DevSec und Ops gleichzeitig drauf gucken können und das bringt halt nichts, wenn es ganz am Ende ist.

Das ist schon mal das Erste.

So, idealerweise hast du aber diesen Scan-Durchlauf ja schon in der Pipeline drin, sodass du das schon in dem Tool, in dem du eh schon arbeitest, dann halt sehen kannst, was eine Security, wie der Security-Stand in dem Projekt ist, zum Beispiel, wenn du ein Main Development Board stehen oder da hast.

Das ist ja das Erste.

So, dann siehst du zumindest schon mal, oh, ich habe da irgendwelche Abhängigkeiten, die veraltet sind oder sonst was.

Und schöner ist es dann ja noch, wenn du dann eine Merch-Request machst oder eine Pull-Request und dann machst du deine Änderung als Entwickler und dann siehst du dann da ja schon idealerweise, deswegen auch Shift-Left, dass die, dass du da eine völlig veraltete Python-Abhängigkeit mit reingebracht hast, die du vielleicht mal aktualisieren solltest.

So, und jetzt kommen wir dann nämlich auf den Punkt zustande, wo dann halt die Tools Prozesse zusammenspielen, mit der Kultur letztendlich auch.

Weil da kann man halt so schöne Sachen machen wie, äh, das sind jetzt aber wieder häufig, sowohl in GitLab als auch in GitHub, glaube ich, auch irgendwelche Enterprise-Features, wo du dann halt sagen kannst, so, naja, du kannst das jetzt nur mergen, wenn du wirklich keine neuen Vulnerabilities einführst.

Womit du halt schon so Quality Gate mit reinmachst, genauso wie du in einem Qualität Gate drin hast, um überhaupt ein Review zu machen.

Also angenommen, du hast jetzt nur ein Review, ein Review brauchst du normalerweise, aber weil du jetzt ein Critical Vulnerability mit einführen würdest, bräuchtest du jetzt noch ein Review vom Security-Team.

Die können also dann, wenn du es schon einbindest, würden es dann halt schon sehen.

Und als Entwickler ist dann so, ach shit, ich brauche jetzt noch ein Approval, eigentlich willst du das ja auch nicht.

Also Luxe lieber, statt einen Downgrade von irgendeiner Abhängigkeit zu machen, lieber ein Upgrade zu machen und zu gucken, was das eigentliche Problem ist.

Das ist natürlich der Idealzustand.

Wie gut das funktioniert, ist halt die Frage.

Weil das sind halt zum Beispiel so Policies, kann man ja dann setzen, genauso wie im Approval-Policies halt eben besetzt.

Aber die Frage ist dann halt zum Beispiel so, naja, wie entforst du das Ganze jetzt?

Weil ich hatte vor Jahren, als ich mal in einem Uni-Projekt war, da hatte ich dann halt mehr um die Bildinfrastruktur in diesem Projekt gekümmert in so einem Projekt, in dem ich drin war.

Wir waren irgendwie zehn Leute oder so, keiner hatte Ahnung, was sie machen, jeder hat irgendeinen Scheiß gemacht.

Und einer hat dann angefangen, die Tests rauszuwerfen, weil sie fehlgeschlagen sind.

Ja, okay.

Tests auskompieren.

Genau.

Und das willst du dann mit Security-Scannern ja zum Beispiel nicht machen.

So, weil wenn da eine Meldung kommt, so fangen wegen so, ja, du hast jetzt hier so viele, so viele Security-Vulnerabilities drin.

Dann könntest du ja einfach als Team hingehen und sagen, so, ah, dieses Ding in der Pipeline-Definition, wo ein Security-Scanner von einem einen Team eingebunden wird.

Das schaue ich jetzt mal einfach raus.

Ja, aber es gibt so eine Situation, ne?

Keine Ahnung, die Anwendung ist gebrochen, weil ein Plattes vollgelaufen irgendwas.

Das heißt, du musst sie redeployen, weil ohne irgendwie anders konnte man das nicht fixen.

Nur ein Redeployment fix das Problem.

So, jetzt hast du aber in einem Redeployment irgendwie Zeugs drin, was dann den Security-Check nicht passt.

Und du hast aber ein Service-Level-Agrement, muss das Ding halt wieder hochkriegen.

Ja, genau.

Und da kommen wir dann wieder zu dem Punkt, dass das an der richtigen Stelle halt blockieren muss und nicht an den falschen.

Weil wenn du den Main oder Production Branch quasi, je nachdem wie auch immer der heißt, da willst du eigentlich immer komplett durchdeployen können, egal wie der Security-Stand ist.

Weil den Stand hast ja eh schon da, auch wenn nichts reingematcht wurde.

Aber du willst ja, wenn neuer Code dazukommen, willst du eigentlich, dass er möglichst besser ist.

In welcher Form auch immer.

Zum Beispiel Security.

So, und wenn du da aber schon schlechter wirst, dann willst du, dass ja schon an der Stelle, wo es gemerged wird, eingreifen können.

Ein anderes Beispiel sind zum Beispiel Softwarelizenzen.

So, weil ich hatte mal einen Kunden, der hat dann gesagt, so der, wir hatten dann irgendein Team, die hatten dann halt irgendwie, die haben irgendeine App programmiert für irgendein Smartphone, irgendwas.

Und dann hatten die dann irgendeine GPL-lizenzierte Abhängigkeit mit drin als Basiskomponente.

Und das hätte dann Geist, die hätten das halt open source machen müssen oder sowas in Richtung.

Und das wurde aber kurz vor der Freigabe ist das halt aufgefallen.

Das willst du nicht so spät haben, nicht in einem halben Jahr später, weil die haben erstmal ein halbes Jahr da rumentwickelt haben.

Und da sind wir dann halt wieder so, naja, das muss halt jemand.

Das hat ja keine gemerkt.

Ja, genau.

Da fängst du halt wieder von vorne an, weil dann so, okay, diese Abhängigkeit kann ich gar nicht nutzen.

Wir müssen die ganze Anwendung nochmal von vorne schreiben, so in die Richtung, ne?

Und da sind wir dann wieder so aus einem Problem, wo wir dann halt zum einen die die Kultur haben, die Tools haben, die das Ganze auch unterstützen müssen, dass man bestimmte Sachen auch enforcen kann, zum Beispiel Approval Rules.

Weil wenn wir uns diese XZ-Lücke nochmal anschauen, da hatten wir zum Beispiel ja auch nochmal den Punkt, dass ja in dem Fall einfach Maintainer Verein oder der, der zum Maintainer dann ernannt wurde, dann ja da direkt reinkommittet hat und keiner reviewed hat.

Klar, es hätte auch durch ein Review nicht auffallen können.

Wenn es halt, dann hätten die wahrscheinlich eh zwei Leute reingeschleust.

Aber wenn man jetzt als Unternehmen jetzt guckt, dann kannst du ja gucken, naja, wie kann ich solche Sachen, wie vermeide ich als Unternehmen zum Beispiel, dass ich, dass irgendwelche Leute bei mir im Team eine Backdoor mit einbauen.

Ja, also ehrlich

gesagt, ich glaube,

das wird schwierig.

Geht nicht.

Kannst du fast nicht.

Ja, also komplett kannst du es nicht.

Aber du möchtest das ja so ein bisschen so in die Richtung machen, wie die ganzen Schutzmechanismen bei der Corona-Pandemie, wo du ganz viele verschiedene hast und je nach wieder du hast, geht halt nicht alles durch.

Aber dadurch verminderst du natürlich die Risiken.

So wie es bei Security hat.

Defense in Depth quasi.

Ja, ein paar Sachen fangen ja schon an, dass du in dem Tooling Zweifaktor-Authentifizierung aktivierst fürs Source-Code Management.

Ja, ja.

So.

Dass es dann halt, wenn du irgendwie durch Phishing oder sowas, hast du dann halt wirklich oder irgendwie halbwegs sicher sein kann, dass die Person, die da was committet, ja auch die Person ist, die Zugang zu dem Account hat.

Also du

willst zertifizierte Schlüssel haben quasi.

Ja, du kannst auch mal mit Tiging machen zum Beispiel.

So, das kannst du dann auch nochmal machen.

Da hast du schon mal ein paar Probleme weniger.

Dann machst du zum Beispiel nochmal Court Review.

Also nochmal, also erzwungen.

Und das kannst du dann auf der technischen Ebene ja auch erzwingen, auch in kleineren Teams.

So, mit, oder Abteilungen oder sowas.

Weil dann kannst du sagen, naja, es muss halt mindestens ein Reviewer, muss es halt.

Ja, aber das

kostet doch doppelt so viel Geld.

Ja.

Ja, also ich ist Klassiker, ne?

Bei mir, ich habe jetzt irgendwie seit die ganze Zeit sagen wir, hey, wir brauchen Rewus, wir brauchen Reboos, wir haben einen Rewus.

So, ja, ja, dann gibt es halt irgendwie so eine Kanban, irgendwas, Pipeline, Treiber, Unsinn.

Und da bleibt es halt dann in QA stehen.

Also geht natürlich auch dann, weil es halt dazu sagen, okay, wir hatten noch nicht mehr drüber geguckt.

So ja, es ist, ich hab's halt gebaut, aber so guckt mal jemand drüber.

Aber macht halt keiner.

Und dann bleibt es halt die ganze QA stehen, das sind jetzt irgendwie so das Problem,

aber das macht ja, das macht ja, ja, nee, das macht ja überhaupt keinen, also habt ihr schon mal drüber nachgedacht, also was tatsächlich oft, also finde ich, ganz gut funktioniert, ist, dass man sagt, okay, Review ja, aber das sollte nicht irgendwie Deployment aufhalten oder so.

Nein, das hält nicht das Deployment auf.

Aber das wird aber auch nicht, nein, es wird deployed, aber es wird nicht reviewed, ever.

Und dann steht das halt die ganze Zeit reviewed oder irgendwann sagen Leute, die Spalte creates aber so voll, schiebt es doch auf Dunder.

Hat da lange auch

eine Entscheidung, die man eventuell

treffen kann.

Nein, ich verstehe das.

Das Problem ist nur, es gibt halt dieses Review immer nicht, weil keine Zeit, kein Geld.

Zu viel zu tun, dies, das.

Ja, aber da ist halt auch mal die Frage, wie mit Kultur.

Wie die Kultur dann halt auch immer ist.

Ja, ja, wollten wir irgendwann mal schreiben, ja.

Weil wenn du dann wieder als Team eigenverantwortlich bist, dann willst du dir zum Beispiel auch, dass die Qualität halt relativ hoch ist, idealerweise.

Ja, also ich würde auch sagen, darf man keine Kompromisse machen, aber dass man den anderen Leuten mit dem Klammer benutzt.

Nein, nein, aber ich meine, wie kann es denn sein, dass das keine Konsequenzen hat, wenn Leute nicht?

Das ist ja komisch irgendwie.

Das ist ja jetzt etwas, wo ich denken würde so, ja, wo schlägt denn das?

Nein, das meine ich jetzt gar nicht.

Das ist gar nicht das Budget, sondern ich meine, wo schlägt denn das auf, wenn das schief geht?

Ja, bei dem Budget knapp denn.

Oh, das war teuer.

Aber ich glaube, das ist gerade ein guter Zeitpunkt über die Dora-Metriken zu sprechen.

Kennt ihr auch Dora-Metriken?

Bitte erklär uns das.

Die Dora-Metriken sind ursprünglich vier, mittlerweile fünf Metriken, um DevOps quasi auf technischer Prozessebene zu messen.

Metriken halt, ne?

So, die erste ist Deployment Frequency.

Also wie oft deploy ich überhaupt die Änderungen, die ich mache.

Und da gilt natürlich, je höher, desto, also ja, je höher die Frequenz.

Nee, Moment.

Das bin ich gerade die Idee.

Ja, aber je häufiger du deployst, desto besser.

Ja, ja, klar.

Genau.

So continuous wäre das dann, ja.

Genau.

So, aber da ist natürlich auch die Frage, so, naja, nur weil du oft deployst, hast du ja nicht unbedingt, dass du gut deployst.

Nee, ich habe ja nochmal Leerzeichen entfernt, Deploy.

Ja, das wird er halt theoretisch dann nach oben ziehen.

Aber du kannst ja auch schlechtes, schlechten Code, schlechte Qualität deployen.

Also ich würde zum Beispiel sagen, es gibt einen Aspekt, wo Continuous Disdeployment gar nicht so gut ist, das wäre zum Beispiel Sustainability oder Green Development oder sowas, weil es halt auch einfach viel mehr Strom friss, wenn die ganze Zeit deine Pipelines laufen.

Das sehen.

Ja.

Naja, also wenn die Pipelines statt zehnmal am Tag, nur einmal am Tag läuft und das halt für den Kunden keinen Unterschied macht, dann hat man halt nur ein Zehntel des Stromsverbrauch für den Run einer Pipelines.

Und wenn das alle Leute machen würden bei Amazon, wäre ja schon einiges an Strom, was da rausfällt.

Also ich weiß nicht, wenn du beim Arbeitenglasmilch trinkst, dann kannst du die Pipeline offen laufen lassen.

Warum ist sie ineffizient?

Genau, also gucken, wie lange dauert überhaupt die Pipeline auszuführen.

Wobei bei einigen dauert das ja drei Stunden oder eigentlich so.

Ja, genau, und das sollte idealerweise nicht drei Stunden dauern, sonst hast du ein Architekturproblem.

Ja, oder so, ich glaube, die Idee hinter den Deployment-Frequencies ist klar, wenn du häufig Änderungen deployst und durchkriegst, aber das heißt ja immer noch nicht, dass du die, nur weil du häufig deployst, hast du ja nicht unbedingt, dass die Änderungen, die du jetzt gerade machst, schnell durchkommen.

Weil so kannst ja auch die Änderungen von vor zwei Wochen nacheinander deployen.

So, und deswegen hast du da nochmal die zwei Time, genau, Lead Time to Production quasi.

Also wie lange brauchst du jetzt für die Änderung, die du jetzt gemacht hast, damit die tatsächlich ausgerollt wird.

Und das geht aber mehr auf den auf den Speed, aber dann hast du halt auch nochmal, was warst du denn mal Fehlern?

Mean Time to Recovery,

genau, genau.

Und die willst du dann ja auch möglichst klein haben.

Also wenn.

Hotfixes, ja.

Genau, das genau, weil das ist halt so am Beispiel, naja, du hast ein Security Issue und ich finde diese Lock4J-Thematik, ich meine, gut, wir sind in Python-Podcast, aber das fand ich halt spannend, weil es halt in einer Tagesschau drin war.

Und dann siehst du, steht dann so, und die ganzen Teams in den verschiedenen Firmen fangen jetzt an, irgendwelche zu gucken, so, wo haben wir das denn jetzt irgendwo drin.

Und das ist schon mal gut und wichtig, aber es hilft halt nichts, wenn du diese Abhängigkeit, die dann halt hast, und auch vielleicht aktualisiert hast, wenn das erstmal drei Wochen oder drei Monate dauert, bis du überhaupt ausgerollt ist.

Ja.

Und es ist egal welche Vulnerability.

Es ist schön und dann werden komische Sachen gemacht dann halt, ne?

Oder nur auf die falschen Sachen geguckt.

So, okay, es ist gefixt, aber es wird dann irgendwie in drei Monaten ausgerollt.

Das hilft dann irgendwie auch noch nicht so viel.

Und aus der Sicht muss man das halt auch betrachten, dass das wirklich effizient ist.

Also wieder unter Mensch.

So, ne?

Und da kommen dann halt ganz viele Sachen rein.

Und jetzt fällt man natürlich die vierte Dora-Metrik nicht ein.

Das eine war

unauffällig googeln hier.

Wir gucken einmal kurz schnell auf die digitalen Geräte, die wir in der Tasche haben.

Das ist natürlich peinlich.

Das genau.

Und also Dora selbst ist halt so eine Research-Organisation, die mittlerweile zu Google gehört.

Und die haben jetzt dann halt auch entsprechend jedes Jahr diesen DevOps, State of DevOps Report, den sie rausbringen.

Und da ist es dann auch entsprechend spannend, auch mal reinzugucken, wo das denn genau funktioniert oder nicht.

Genau.

Change Failure Rate, das ist mein Entfallen, genau.

Dankeschön.

Genau, wie oft es überhaupt zu Fehlern kommt.

Weil wenn keine Fehler passieren, dann ist natürlich gut.

Und deswegen musst du eigentlich alle gleichzeitig betrachten.

Das hilft halt nichts, wenn du ständig eine hohe Deployment-Frequenzie hast, aber ständig zu Fehlern kommt und du ganz schön lange brauchst, bis die Services wieder recovered sind, dann ist das nicht so toll.

Dann willst du lieber mit der Deployment-Frequency runtergehen und dann gucken, dass du die anderen Metriken auch richtig beziehst.

Und weswegen ich das ja zusätzlich nochmal erwähne, ist, ich habe von einer Firma gehört, die haben das für die für die Teams dann als Zielvorgabe dann gemacht, um deren variablen Bonus zu.

Man muss das nicht unbedingt gut finden.

Ja, man kann das nicht gamen, dann.

Ja, ja, das kannst du natürlich.

Wenn die Metrik zum Ziel wird, dann ist das natürlich scheiße.

Ja, das ist nicht unbedingt gut.

Aber man kann jetzt trotzdem zumindest auf diese Metriken schauen, so auch als Defektiven dann halt.

Aber da muss dann halt auch von der Firmenkultur das auch irgendwie gemacht werden.

Aber da fängt es halt bei deutschen Firmen, finde ich, schon sehr stark drauf an, also kommt da sehr stark drauf an, wie überhaupt die Fehlerkultur überhaupt ist.

Darfst du überhaupt Fehler machen?

Ja, ja, ja.

Weil das ist ja das Hauptproblem.

Immer, wenn ich bei dir auf den Mädchen gucke, ich nehme alles kaputt.

Ja, wenn nach was gehen würde, wirst du es gar nicht mehr sehen.

Aber das finde ich auch interessant.

Du hast hauptsächlich quasi deutsche Kunden sozusagen.

Oder hast du auch mal und siehst du da Unterschiede?

Weil ich glaube, das, ja, das gibt da wahrscheinlich einige spezielle Probleme hier.

Ja, naja, ich rede ja meistens nur mit den, also ich rede mit Firmen, die den Hauptsitz in Deutschland haben.

Und halt Großkonzerne, die man halt alle so kennt.

Und ich sehe aber halt meistens nur so die Leading-Teams, muss ich dazu sagen.

Ich sehe halt nicht alle und nicht alle, nicht alle, nicht alle tief und ich sehe halt mehr so relativ oberflächlich.

Und man kriegt da so ein bisschen auch mit, was dann in den USA zum Beispiel läuft.

Und da haben die halt ganz andere Probleme.

Also, weil da redet man über diverse Sachen, die ich jetzt hier spreche, muss man halt gar nicht reden.

Und in deutschen Firmen sehe ich halt immer das Problem, deswegen reite ich hier da ein bisschen drauf rum.

So, so von wegen so, die viele Firmen haben überhaupt noch nicht mal verstanden, dass sie schon eine Softwarefirma sind, auch wenn sie nicht mehr produzieren.

Ja, ja.

So und.

Das Einzige, was der digitale Sachen

hat, wäre der Autokonzern gesagt.

Ich sage jetzt keinen Namen.

Ja, aber ja, das ist ein großes Problem, ja.

Und da fängt es halt schon an.

So, von wegen sage, ja, wir sind ja eine Hardwarefirma, bla bla.

Und dann so, ja, so sieht eure Software auch aus.

Also, weil, weiß nicht, ich habe zu Hause einen Wechselrichter für meine Solaranlage und wenn ich da auf die Software gucke, dann denke ich, das sieht sehr nach Elektrotechniker-Firma.

Wir hatten es irgendwie versucht, ein bisschen was zu entwickeln.

Ja.

Und das merkt man dann halt schon so.

Und dann ist überhaupt gar nicht das Verständnis da, dann sind wir wieder zurück bei dem Verständnis, überhaupt bei den Software-Entwicklungsprozessen was zu verbessern.

Und dann musst du mit DevOps gar nicht anfangen.

So in die Richtung.

Und dann ist auch immer der Unterschied natürlich, haben wir jetzt einen Wert innerhalb der Firma, also die Software-Entwicklungsteams sind ja häufig auch von Inhouse-Sachen, die ja nur für die innerhalb der Konzerne entwickeln.

Und sie sind häufig auf der falschen Seite der Bilanz auch.

Ja, sie haben

Post-Center, keine Post-Center.

Genau.

Und wenn es halt intern ist, dann ist halt erst recht dann mehr Costcenter.

Und wenn es dann Kunden ist, ist es ja nochmal ein bisschen was anderes.

Aber da siehst du ja manchmal, manche sagen dann Kunden was.

Und ja, das und das ist total wichtig bei und so bla bla bla.

Und dann google ich das und dann so, weil es dann ja manchmal so Headlines sind, weil es so große Konzerne ist, die man kennt.

So, weil wenn ein Kunde sagt dann so, ja, wir mussten hier ganz am Anfang Corona-Pandemie irgendwie Testmanagement-Software und sonst was, weil wir alle durchtesten mussten bei uns in der Fabrik oder sonst was.

War halt typisches internes Tool.

Kurzfirmnamen, Corona eingetippt.

So, hm, Massenausbruch bei bla bla.

Halbes Jahr nachdem Corona schon lief.

Und so, hm, ja, vielleicht kam das danach, nicht vielleicht ganz am Anfang.

Aber da, aber da, das war dann halt wiederum ein gutes Beispiel, finde ich, weil da muss es halt wieder schnell gehen.

Und da ist es dann wiederum interessant, weil wenn die Firma nicht operieren kann, weil gerade Pandemie ist, und sie müssen alle durchtesten, weil halt das Geschäftsmodell halt so ist, dass du dann halt in einer Fabrik halt bist zum Beispiel, dann ist es halt total wichtig, dass diese Software schnell entwickelt wird und schnell auch irgendwelche Fehler entwickelt wirst.

Und da sind wir halt wieder bei dem Punkt, das muss halt oben auch verstanden werden.

Und ich glaube, an dem Punkt sollte es grundsätzlich schon verstanden werden.

Ob das da der Fall war, weiß ich jetzt nicht.

Ja, aber.

Aber das ist auch nur so ein Beispiel.

Deswegen fand ich es ja auch irgendwie so spannend zu sehen, als dann diese temporäre Mehrwertsteueränderung war.

Da lag ja zwischen dem Beschluss und der eigentlichen Implementierung oder der Umsatzgesetz.

Der Umsetzung.

Lagen irgendwie drei oder vier Wochen.

Klar, es wurde vorher schon irgendwie diskutiert oder sowas.

Aber im Endeffekt lagen zwischen Beschluss und dem 1.

Juli, glaube ich, war das 20?

21.

Muss 2020 eigentlich gewesen sein, weil mich hat es auch noch getroffen.

Genau, da musste ja jeder irgendwie deren Software da umstellen, damit die Rechnungen richtig gestellt werden.

So, und das haben die auch irgendwie hinbekommen.

Aber da mussten dann, aber wenn du dann halt irgendwie wieder nur drei Monate brauchst, um irgendwie eine Änderung herauszubekommen, wenn du aber gleichzeitig ein Mobilfunkprovider bist, der ständig Rechnungen schreibt, dann musst du dann halt das richtig hinbekommen und getestet haben und so.

Und dann halt.

Deswegen muss es halt wieder ganz oben sein.

Genauso ein 9-Euro-Ticket hat super funktioniert, wenn man es dann möchte.

So.

Und dann kam Deutschland-Ticket, das hat er wieder ganz lange gedauert.

Meinst du das Management, ja?

Deswegen, wenn man es wirklich möchte, dann geht es das schon gerne um.

Ja, wenn man Durchsetzungskompetenz hat auch, ne?

Also du hast eben nochmal den CTO gesagt und ich glaube, hauptsächlich, deswegen habe ich gesagt, vielleicht nicht immer nur CTO, ist Durchsetzungskompetenz bei den CTOs im Vergleich zu ihrem Vorstand, zu ihrem anderen C-Levels überhaupt vorhanden.

Also das hängt vielleicht damit zusammen, ist es ein Tech-Driven-Konzern oder nicht.

Wenn du jetzt bei deutschen Konzernen, wie viele davon haben denn ein CTO bitte?

Haben die einen Ding, der keinen hat?

Ja, es gibt schon, glaube ich, viele, aber es ist halt schon eher die Frage, was für eine Kompetenz haben die halt, ne?

Wo man schon dabei sind.

Also, wie sind die auch intern, also haben die für einen Ansicht?

Also der CEO denkt das also, ja, ja, das ist irgendwie der Typ, der macht das dann irgendwie so nebenbei.

Oder wird da ernst genommen, ne?

Auch, das ist auch so ein kulturelles Ding wahrscheinlich.

Ja.

Also es ist halt oft das Problem, wenn das Kerngeschäft eigentlich gut lief, dann hatte man keinen Veränderungsdruck auf solche Strukturen.

Nein, nein, also ich glaube, das ist rational.

Das ist nicht nur so eine, da gibt es keinen Veränderungsdruck, sondern es ist einfach, wenn du Mitte 50 bist oder so, wie so die meisten Leute, die dann bist, dahinten, du brauchst ja eine gewisse Zeit, um halt so hochzubabbeln in einem Konzern.

Und dann bist du dann halt da irgendwie dann, äh, und du überlegst dir jetzt, okay, wenn ich wenn ich das tue, was nötig wäre, dann werden mich alle hassen und vielleicht werde ich gefeuert.

Und mein Gold Handschlagen wird nicht ganz so golden, sondern silbern.

Oder ich überlebe die nächsten fünf Jahre, das habe ich nicht in Rente und dann ist alles super und alle lieben mich.

Und mein Nachfolger hat das Problem.

Dann ist relativ klar, was man macht.

Also ich meine, und du machst ja auch noch die mächtigsten Leute, die auf dem Geld sitzen zum Feind intern.

Das sieht man auch übrigens an Staaten sowas.

Das ist leider nicht schon Konzern rübergreifend so.

Ja, ich finde das witzig, weil ich musste gerade an einen Kunden denken, weil da war es auch so.

Mit denen hatte ich vor zwei, drei Jahren zum ersten Mal gesprochen.

Da war dann ein Typ, der da total blockiert hat, hat sie, nee, das ist zu viel Aufwand und Migration und überhaupt.

Also so von Bitbacker Jenkins und nochmal Jenkins und sonst was auf GitLab zu migrieren halt.

Ah, und das ist so teuer und bla bla bla.

Und dann passiert ja nichts, dann passiert ja nichts.

Halbes Jahr später, der war in Rente.

Plötzlich passiert was.

Ja, ich fand.

Oder denken sie so, warum blockiert er das Ganze?

Kann das völlig egal sein?

Und die ganzen Entwickler sind da so anders.

Das Problem ist halt, genau, wenn er jetzt was macht und es geht irgendwie, dann wird es ihm halt angerechnet.

Und ja, wenn das halt irgendwie dem Nachfolger auf die Füße fällt, dann ist das nicht mehr sein Problem, ja.

Ja, also der Nachfolger wollte dann ja auch was verändern, ne?

Also da gab es dann so.

Der hat auch ein Interesse daran lassen.

Ja, genau.

Aber das ist dann halt irgendwie so spannend.

Ja, aber es halt die Frage, ob dann auch nur Buzzwords durch das nächste Dorf getrieben werden oder dann, wo man halt in der Transformationskrise steckt, ne?

Transformation nach Transformation.

Zu einem gewissen Rahmen ist das ja auch menschlich so, ne?

Weil dann Veränderungen halt eh immer wieder was sind, die du immer anstrengend findest.

Das hat ja scheinbar immer funktioniert vorher.

Ich bin kein großer Fan von, also in irgendeiner Komplexität irgendwann überschritten ist, ja?

Und eine Größe von so einem Schiff überschritten ist.

Kein großer Fan von dem ewigen Transformationsmonster.

Also ich würde sagen, das funktioniert nicht.

Da hast du auch Unsinn.

Ja, ich meine, für mich ist auch Transformation, kann halt auch.

Also ich mache eine Unterscheidung zwischen Transformation und Migration.

Migration ist für mich, wenn du mehr oder weniger eins zu eins von dem einen auf das andere wechselst.

Und Transformation ist, wenn du es wirklich mal komplett neu denkst.

Und es kann halt auch sein, du baust jetzt was Neues auf und da schiebst du alle nach rüber.

Okay, ja, okay.

Was wolltest du sagen, es wäre dein Kultur, ähm, deine Kulturempfehlung?

Managementschlag.

Das ist halt wieder die Frage, wen stellt man diese Frage?

So, ne?

Also wer hört dir gerade zu und wer denkt, also ich glaube, viele, die werden hier zuhören, denken, ja, ja, ich meine, das hatten wir ja jetzt schon nicht wirklich vorher so, ne?

Weil überall das Gleiche mehr oder weniger ist.

Beim Tooling kann man halt als Techie zum Beispiel noch relativ viel machen.

Oder zumindest gucken.

Und da finde ich, neigt man als Techie viel zu oft zu Overengineering und weniger zu KISS.

Also Simple Skill.

Das NIH-Syndrom ist Overengineering und das, na?

Ja, weil wenn ich selbst für mich gucke, so ich habe früher in meinem ersten Job ganz viel Jenkins-Krams gemacht, weil er halt total viel, total strubbelig war.

Das ist jetzt, keine Ahnung, zehn Jahre her ungefähr.

Und für mich hat es Spaß gemacht, das alles irgendwie einmal sauber zu ziehen, alles automatisieren und verschiedene Services damit anzubinden oder sonst was.

Vor zehn Jahren gab es aber auch keine andere Lösung, wo es halt irgendwo sinnvoll war.

So von wegen Reproducible Builds und sowas zu bauen, weil es vorher war so, da ist eine VM, da wird irgendwas gebaut.

Wenn du jetzt aber eine neue Ubuntu Version drauf kam, wofür das Paket gebaut werden sollte, dann musstest du per Hand irgendwo das alles machen, um die Abhängigkeiten zu installieren oder sonst was.

Und ich habe halt hingegangen und das ist komplett durchautomatisiert, sodass wenn eine neue Version rauskommt, von welcher Distribution auch immer, und das musste für verschiedene Distributionen für Windows gebaut werden, dass es dann halt komplett durch, dass ich nur noch eine Zeile hinzufügen musste und dann einmal kurz testen musste, ob die, ob sich irgendwas an den Paketnamen geändert hat.

Aber dann hat es halt gebaut.

Und dann war halt es halt gut und ich musste nicht, und ich konnte direkt nachvollziehen, auch für alle anderen Entwicklerkisten quasi, was dann die Abhängigkeiten nicht zum Beispiel installieren muss, damit ich den Bildprozess da starten kann.

Und da habe ich halt vieles per Hand gemacht.

Und mittlerweile gibt es dann halt eben andere Tools, die halt besser sind, wo es halt.

Wo mehr Leute mehr Zeit reingesteckt haben.

Genau, und eigentlich war ich Entwickler, das heißt, ich wollte ja eigentlich, sollte eigentlich Software entwickeln, so in die Richtung.

Dafür hätte ich aber keine Zeit gehabt, weil ich eigentlich nur daran war, die ganzen Entwicklungs- ja den Obs aus den DevOps-Tooling-Krams zu machen.

Und wenn ich manchmal dann sehe, was für komplexe Strukturen dann mit Riesen-Teams, mit Jenkins zum Beispiel gebraucht werden, das ist halt damals vor so zehn Jahren oder vielleicht so sieben, acht Jahren oder sechs, sieben Jahren vielleicht noch sinnvoll gewesen, das mal alles skalibar irgendwie zu machen, aber mittlerweile gibt es halt andere Tools, die es halt einfacher machen.

Und das ist halt auch mal die Frage, ist, okay, wie viel brauchst du da jetzt von wirklich?

Ja, also deshalb die Gefahr des, ne, ich baue es selber, wie viel optimiere ich schon vorher, wie viel nicht?

Oder mache ich es nur Hands-on?

Wir sind so ein bisschen auf diesem, ne, Pre-mature Optimization ist the root of all evil Ding, was aber manchmal halt doch durch Sinn macht, das doch durch zu durchdenken und daran zu denken, dass es Verleck geben kann, wo ich vielleicht reinwachsen möchte und vielleicht dann einigsteilen, aber auch so die Quick and Dirty anders.

Ja, ich meine letztendlich auch eine Frage von Bild versus Buy dann ja auch.

Was willst du?

Weil deswegen gehen auch viele zur Cloud.

Weil man halt auch viel verkaufen kann und dann ist fertig.

Und ich muss es mir nicht selbst bauen.

Geht ja in die gleiche Richtung.

Und da kannst du dann schon vieles machen.

Aber was so eine Empfehlung ist halt echt schwierig.

Ja, aber du hast jetzt aber eigentlich nur über Technologie geredet und über da vielleicht ein anderes über so diese Kulturempfehlung.

Also hat das was mit Open Mindset zu tun, mit Growth Mindset zu tun, mit Customer-Centric Mindset zu tun?

Dieser Begriff hier jemals gemacht.

Oh Gott.

Ja, ja, ich weiß es nicht.

Aber ich glaube schon, also ich glaube schon, dass es wichtig ist, dass die Leute wenigstens Entwicklungen nicht ganz abgeeignet sind, also dass sie zumindest neugierig sind.

Also ich finde, dass das so der Teil vom Commitment, den man mitbringen sollte.

Und wenn man den gar nicht hat, aus welchen und auch immer, dann wird es schwierig.

Vielleicht ist das noch so ein Problem.

Das habe ich jetzt nicht ganz verstanden.

Also wenn du nicht neugierig bist in deinem Job, dann kannst du eigentlich relativ wenig Neues lernen oder hast da gar keine Lust drauf oder möchtest auch gar nicht irgendwie daran arbeiten, dass du diese neuen Integrationen verstehst oder da reinkommst.

Das kannst du ja nicht ändern, also wie die Leute sind.

Ja doch, du kannst dich gar nicht einstellen.

Ja gut, aber jetzt hast du nochmal diese ganzen Leute, da sitzen.

Aber ich glaube, das ist da, das wäre eine HR ein Management strategische Entscheidung, wurde important.

Und auch das ist so ein Transformationstage, den man machen kann, wenn man sich das traut.

Der hart ist, aber das muss man halt.

Gibt es da für Matrix?

I don't know.

Ich würde sagen, ja.

Ja, also ich meine, ich kann ja von mir aussprechen, was mich motiviert bei der Arbeit.

Für mich und im Vergleich zu den früheren Firmen, wo ich war.

Da war bei den alten Firmen immer das Problem, fand ich.

Ich hatte halt überhaupt keine Ahnung, was ich da überhaupt tue.

Also klar, ich wusste, was ich für mich tue, aber was das im Gesamteffekt für die ganze Firma ausmacht, keine Ahnung.

Ich hatte keine Ahnung, wie das hingeployed wird.

Das ist schon mal das Erste.

Ich hatte keine Ahnung, was für Nutzer das sind.

Ich habe halt irgendwas im Backend da gemacht als Entwickler und dem Entwicklungstooling ein bisschen noch drumherum gemacht.

Aber ich hatte keine Ahnung, wie das jetzt Ganze funktioniert.

Und so visionsmäßig.

Okay, aber vielleicht an die.

Also ich würde sagen, so, also für mich werden es jetzt so zwei Sachen.

Also eins der wichtigen Sachen ist halt so, ich glaube, du meinst du dasselbe ist, why, also warum Value.

Yeah, genau.

Also warum mache ich den ganzen Scheiß hier überhaupt?

Hat das irgendeinen Sinn?

Also dann gibt es halt dieses Problem, ne?

Dieses Programming for Pleasure, ne?

Bei den Devs, weil warum man das dann irgendwie, wenn man da keine externen Value drin findet, so.

Also weil die Kunden, weil die einen überhaupt nicht interessiert oder so, dann macht man es halt um der Sache wühlen.

Was also aus Management-Perspektive dann eine blöde Entscheidung ist.

Und das zweite ist natürlich Monetary Incentives, ne?

So.

Genau.

Ja, und ja, ist da, kann man das balancen?

Ja, irgendwie ist ja für jede Person ja auch ein bisschen individuell, ne?

Du meinst die Values?

Ja, ja, genau.

Und deswegen hatte ich auch nur von mir gesprochen, was für mich dann halt, und ich sehe ja bei mir jetzt durch GitLab dann halt, dass es angesprochen werde, wenn ich so einen Pulli habe, wo ein GitLab Loch drauf ist.

Oder halt die Leute das generell cool finden oder ich dann halt auch weiß, damit helfe ich den Leuten tatsächlich irgendwie.

Zwar nicht um mit Ballem oder sonst was, aber irgendwie haben die ja schon so einen gewissen Mehrwert da draus, ne?

Was ich halt dann besser finde als, keine Ahnung, bei irgendeinem Cloud-Provider zu sein, bei einem US-Cloud-Provider zu sein, wo ich halt auch ein paar Leute kenne, wo der Sinn und Zweck deren Jobs ist, also meines Äquivalenten des Jobs eigentlich nur ist, mehr Workload, den Kunden dazu zu treiben, mehr Workload in die Cloud zu schicken.

Wo ich denke mir so, ah, das würde ich jetzt nicht so gerne machen.

So, obwohl das ungefähr der gleiche Job ist, so, ne?

Ja.

Das Businessmodell ist halt einfach ein bisschen anders und dann.

Ja, genau, genau.

Und das finde ich dann aber auch im persönlichen dann auch irgendwie nicht so, da bin ich dann auch lieber auf der Schiene, so von wegen so, naja, jeder soll selbst für sich entscheiden, wo es offen lassen möchte.

Ja.

Also, weil mich fragen halt auch so Leute, naja, willst du, wir werden hier GitLab selbst betreiben, dann so, okay, dann mach halt selbst.

Und ja, oder wir wollen einen Managed Service und könnt ihr auch.

Ihr könnt entscheiden.

Das finde ich dann halt besser, als wenn es dann halt irgendwie, also rein persönlicher Ebene, als wenn es dann halt so, wir haben nur ein Modell und das ist Cloud-only, SARS-Only, US-Only oder sonst was.

Und ich denke, pff.

Ja.

Ja, aber ich meine, ich bin immer in der so IT-Branche unterwegs, häufig, oder überwiegend.

Und das liegt aber auch, glaube ich, daran, dass einfach ich da halt halbwegs verstehe, was da passiert.

Oder und bei Sachen, wo ich nicht verstehe, wie das funktioniert.

Ich meine, manchmal mache ich auch noch andere Sachen und manchmal mache ich dann, und das finde ich dann auch ganz schwierig, immer oder oft, wenn ich halt mal, es gibt zum Beispiel Dinge, wo ich nicht mit Kunden, also nie mit Kunden spreche.

Nicht mal weiß, wer die sind.

Das finde ich total schwierig.

Also, ähm, und ja, bei diesen IT-Sachen ist es halt häufig nicht so.

Da ist auch die Kultur insofern ein bisschen anders, dass die halt nicht so super, also dass man schon weiß, an welchem Produkt man arbeitet, ja.

Aber es kann ein anderer Bereich natürlich auch sein, dass ich gar nicht weiß, was man da eigentlich tut.

Ja.

Und das ist.

Also es gibt ja mehrere Probleme, glaube ich, auf einmal.

Also ich glaube, du hast gerade nochmal von den Cloud-Abietern zum Beispiel gesprochen.

Also ein Beispiel jetzt, man kann sich ja auch sehr viel damit kaputt machen, also diese Beientscheidung zu treffen.

Du, du sagst, sie ist wichtig.

Beispiel jetzt, ich weiß nicht, VMware oder sowas, die auf einmal ihre Lizenzkosten irgendwie alle Leute kriegen, Herr Trasser, und dann alle Maschinen laufen offen, wir können nichts machen, ja, verdammt, müssen wir jetzt gucken für die nächsten drei, vier Jahre.

Ja, aber da ist auch wieder irgendwie selber schuld so ein bisschen.

Und ich meine, dieses Böse, also wer jetzt, wer jetzt irgendwie große Schmerzen hatte mit dieser Geschichte, der sollte sich gut überlegen, aber all in Cloud Native weiß ich nicht.

Ja, das meine ich, weil das kann ganz genauso wieder sehr, sehr schmerzhaft werden.

Oder auch LNMs, wenn man da einbindet, mit seiner neuen, wie nennt man das?

Analytics Dings-Infrastruktur, Insights, lalala, keine Ahnung, ich wollte die ganzen Produktnachmäßig auch sehen.

Egal.

Aber ja, natürlich.

Also das ist ja.

Das ist ein Problem.

Aber um nochmal auf deine Frage zu kommen bezüglich, was man da, was meine Empfehlung ist, ein Punkt, worüber man DevOps ja auch anders betrachten kann, außer die Bodometriken, ist ja noch das Calms-Modell.

Hast du auch an dein Buch direkt am Anfang, glaube ich, erwähnt es nicht.

Ja, genau, weil das ist dann ja die WUSHAM-C-A-L-M-S, C für Culture, was wir jetzt sehr ausführlich besprochen haben, A für Automation, L für Lean, also möglichst schlank zu halten, M für Measurement-Metriken und S für Sharing.

Und was man halt häufig sieht, ist dann halt, dass man sich nur auf die Automatisierung fokussiert wird.

Ja, weil das halt ist, was man halt nach der Karte.

Das kannst du als Techie, genau, kannst du das nämlich gut machen, aber wenn du halt scheiß Prozesse automatisierst, hast du halt immer noch Scheißprozesse, die aber wenigstens automatisiert.

So, wenn dadurch Fehler passieren, du aber eine schlechte Kultur in dem Sinne hast, dass du gar keine Fehler machen darfst, weil alles sehr, sehr gefährlich ist.

Wenn du so einen Prozess weit hast, wie willst du den überhaupt erst verstehen?

Weil du kannst den ja quasi nur optimieren, ja, also so einen Prozess, der kacke ist, wenn du den durchdrungen hast.

Und ich glaube, das allein, also Architekten zu finden, die das können, sind schon sehr selten, weil du dafür einen relativ guten Einblick haben musst in sowohl die technische als auch die Business-Perspektive dann, ja, also die Kundenperspektive.

Und das ist das Hauptproblem, was du an guten Architekten, auch bei Projektmanagern übrigens hast, ist, dass die meisten Leute weder auf der einen noch der anderen Seite richtig drin sind.

Ja, ich meine, wenn wir über Kultur sprechen, können ja verschiedene Abstufungen sein, ne?

Es reicht ja schon, wenn du Fehler machen kannst, machen darfst.

Wie handhaben wir Fehler?

So in Richtung Blameless Post-Mortems zum Beispiel.

Was dass wir überhaupt mal aufschreiben, was ist überhaupt ein Fehler passiert, was war da eine Root-Cross-Analyse machen, um zu schauen, was für Fehler sind passiert, warum sind die passiert und warum sind die nicht vorher aufgefallen.

Ohne Fingerpointing zu betreiben, der, da, der ist schuld.

Aber trotzdem benennen, was schiefgegangen ist und wie wir das jetzt zukünftig verbessern wollen.

Und das ist dann halt eben die Frage.

So, so wie möchten wir, und viele machen das ja auch, US-VM zum Beispiel, machen das ja auch öffentlich.

Aber wenn Fehler passieren.

Und darüber kann man ja immer noch viel lernen.

Also mein Lieblingsbeispiel ist, das war noch lange, bevor ich bei GitLab angefangen habe, kennen vielleicht die einen oder anderen noch.

Da hat er dann jemand, die Datenbank, irgendwie hatte Datenbank Synchronisierung nicht funktioniert und wollte auf dem, also Synchronisierung auf dem Secondary und wollte dann auf Secondary einfach das Datenverzeichnis wegschmeißen, damit es nochmal von vorne anfängt zu synchronisieren, hat das aber aus Versehen auf dem Primary gemacht.

Und dann war halt GitLab.com damals offline, ich glaube, das war 2016, 17, ewig lange her.

So, und der ganze Fehlerprozess wurde, und ich habe es als ich habe 2020 bei GitLab angefangen, also einige Jahre später.

Und ich habe dann halt den Livestream verfolgt, wie die untereinander diskutiert haben, wie man das jetzt fixen kann.

Und dann war ja halt zum Beispiel auch ein Problem, dass die Backups verschiedene Backups-Methoden gab, die aber alle nicht funktioniert haben.

Die nie jemand getestet hat.

Ja, klar, genau.

Und viele aus meinem Umfeld, die ich dann also kannte, die haben dann erstmal angefangen, in meinem Unternehmen zu gucken, ich glaube, ich teste mal meine Backups.

Ja, sollte man tatsächlich machen.

So, und das sind halt Sachen, wo du dann ja auch von anderen Firmen lernen kannst.

Genauso wie du von der XZ-Lücke lernen kannst, so was kann ich davon vielleicht in der Firma adaptieren oder sowas dann halt, ne?

Und das trauen sich ja schon viele nicht, wenn Fehler passieren.

Oder zuzugeben, so von wegen, da habe ich einen Fehler gemacht.

Ja, Security ist ein Riesenproblem, weil wenn du die Verantwortung für irgendwas trägst und deinen Kopf hinhalten musst, du fängst halt an, die Sachen zuzuschließen, nicht wieder aufzumachen.

Ja, und spannend finde ich das jetzt auch nochmal, dass es ja noch irgendeine Direktive, die NIS 2-Direktive oder sowas, gibt, wo ja auch das Management verantwortlich gemacht wird, wenn du als Firma eigletterndes Sicherheitsrücken hast oder sowas.

Das heißt, es wird dann eigentlich nochmal noch deutlich wichtiger.

Also ich glaube, es wird noch deutlich spannend, weil im Moment ist es ja gefühlt, Softwareentwicklung allgemein, also Softwareentwicklung der Betrieb.

Jeder macht einfach das, was er möchte.

In so Finanzindustrie und vielleicht Automotive-Sachen, da gibt es nochmal bestimmte Regularien, wo eingehalten werden müssen.

Aber auch das, das ist ja egal.

Aber es ist ja meistens nur, ja, vor allem ist es halt schlimm im Sinne von, und das hatte ich auch von einem Autokonzern gehört, so von wegen da hatte einen einen, und Compliance-Regeln haben ja eigentlich schon so einen Sinn, warum es diese gibt.

Und häufig sind es halt irgendwelche Excel-Listen, wo du einen Hacken machen kannst oder eine Conference-Liste oder sowas.

Und einer hatte überhaupt nicht das Problem gesehen, den Hacken zu machen, habe ich getestet.

Ohne irgendwie den Nachweis zu haben, dass das wirklich getan hat.

Und viele Sachen kannst du ja schon automatisieren und so ein Reporting machen.

Was vor allem bei dem so einem Banken- und Finanzumfeld kam nämlich bei mir die Frage nämlich ganz oft auf, so wie kann ich dokumentieren, dass auch wirklich ein Change, den gemacht wurde, dass das auch wirklich zwei Leute reviewt haben, zum Beispiel.

Ich meine, auch das, wer reviewt denn?

Der eine von den anderen will da immer niemanden gegen Schieber eintreten, weil man Ärger kriegt, wenn man irgendwann was aufwendet.

Also da, wenn du, wenn du als Review, wenn du das reviewst, dann bist du ja auch mit dran.

Also sozusagen, da hast du schon ein Interesse auch, würde ich jetzt mal so vermuten, dass sie

aufhört, wenn das wirklich.

Naja, aber wenn das Schlimmste ist, das passieren kann, dass irgendjemand sagt du du du.

Und das andere Problem aber ist, dass dein Kollege keinen Bock auf dich hat mit dem ganzen Tag zusammenhängen muss, dann ist

er auch wieder die Frage.

Ja, ich meine, aber ich meine, mein Blickwinkel jetzt ist jetzt mehr so, naja, ich habe jetzt einen, ich habe jetzt bestimmte Regeln, die müsste ich auch umsetzen, die müssen dann auch gemacht werden und die muss sich eventuell nachträglich auch nochmal anschauen.

Weil wenn ich jetzt gucken möchte, wie bei der XZ-Lücke, wo es jetzt nämlich ja Open Source war, bei Closed Source ist dann halt auch die Frage, so Firmen, die können ja gar nicht wissen, wer da was committed hat oder sonst was.

Oder welche Sicherheitssachen als Audit Trail-Thematiken, wer hatte, wo Zugriff oder sonst was.

Das muss halt auch irgendwo angehakt werden.

Und bisher ist es halt sehr, sehr stark, finde ich, danach getrieben.

Jeder macht halt das, was er möchte.

Und es gibt halt, also generell, ganz, ganz allgemein.

Und ich glaube, das kann zukünftig jetzt nicht mehr so viel so gut weitergehen.

Das Problem ist jetzt folgende, hast du keine Leute, die haben von Security eigentlich gar keine Ahnung, die stehen halt dann da.

Also das Problem mit der Compliance ist halt immer, dass das tendiert dann auch, also ein Modus, in dem das dann schief geht, ist halt auch, dass man das Ganze zu so einem Theater verkommt, was halt tatsächlich die Sachen, die eigentlich die Security noch schlechter macht.

Genau, du hast halt Sachen, die auf der Bühne als Excel-Tabelle vorgestellt werden, wo irgendwelche Leute irgendwelche Haken ran machen, wo dann halt gar nicht klar ist, was da drin steht.

Und das Beispiel mit dieser Paketliste, ne, das ist halt so ein Ding.

Du hast gar keinen praktischen Use Case, wo du die alle einzeln auditen kannst.

Als kleines Team.

Du musst irgendjemand vertrauen, das tut, was eigentlich ein Argument für Open Source wäre, aber wir sehen auch bei Open Source bist du nicht komplett davon befreit.

Aber wenn du das alles mit Clubs machst, geht's halt auch nicht.

Oder du bist halt auf irgendwelchen ganz Legacy-Geschichten, wo dann auch eigentlich die CVEs alle offen sind, weil du nicht hinterherkommst, damit die Sachen zu patchen.

Du musst halt irgendeinen Tod dann da sterben.

Ja, irgendwas hast du immer.

Aber worauf ich noch hinaus wollte, ist, dadurch, dass du ja die, also weil ich ja meinte, so, naja, für einige ist es ja einfach nur was abhaken, ohne was wirklich zu testen, da gibt es halt Leute, auch Führungskreffe, die verstehen dann halt nicht, dass es eigentlich nicht in Ordnung ist, einfach nur zu sagen, so ja, naja, es reicht ja, wenn es abgehakt ist.

Und wenn es dann von Autofirmen kommt, wo du dann denkst, so, hm, also ich möchte schon wissen, dass wenn ich die Bremse drücke, das auch wirklich bremst.

So, das soll, und ich meine, dafür gibt es ja Regulationen.

Systemfehler, Systemfehler.

Systemfehler.

Ja, genau, oder eine Bootloop oder sowas, sonst was, ne?

Weil das soll ja schon funktionieren, das soll ja auch getestet werden.

Ich glaube, da sind manche auch Leute irritiert, wie das bei Tesla oder sowas geht, weil die pushen ja auch viele Änderungen schnell raus.

Aber das kommt immer darauf an, glaube ich, welche Änderung, von welcher Änderungen wir sprechen.

Weil es macht ja schon einen Unterschied, ob es direkt die Auto-Elektronik ist oder ob das Infotainment-System ist für die Navigation.

Oder für wo auch immer du da was tanken kannst, äh, laden kannst.

Das macht halt schon einen deutlichen Unterschied.

Und deswegen muss man auch ein bisschen unterscheiden, was für Software reden wir jetzt hier.

Aber ich meine, man muss ja nur auf den Cars Communication Kongress gucken, wenn du da guckst, welche Security-Lücken da drin sind.

Ein paar Sachen lassen sich ja schon durch den Prozess dann ja schon lösen oder verhindern.

Dann hat man halt die eigentlichen Probleme an anderen Stellen, muss man dann halt machen.

Aber.

Also ich würde sagen, nein.

Ich würde sagen, Prozess hilft nicht.

Naja, die Prozess hätte auch gut sein.

Also, ja, genau, so ein guter Prozess hilft.

Also nicht irgendein, ja, aber.

Aber woher kriegt man, woher weiß man denn überhaupt, wenn man selber nur eine begrenzte Ahnung von denen hat, was ein guter Prozess ist?

Ja, weil diese Informations Dingen arbeitest, dann kennst du den perfekten Prozess dafür nicht, weil du ja eine Lösung machst, die es aber so noch nicht gab.

Du kannst halt noch nicht mal jemanden irgendwie abgucken, was die gelöst ist.

Das heißt, du musst irgendwie rumexperimentieren, ja.

Und du kannst ja, also tolles Beispiel jetzt in der Ökonomie, du überlegst hier irgendwie so eine Policy für so ein Land, wie es auch in so einer Schuldenfalle rauskommt, Entschuldigung.

Ich muss das falsche gerade nehmen.

Und dann fängst halt an, mit so einem Bevölkerung rumzuexperimentieren, was denn nicht alles funktionieren könnte.

Und da hast du vielleicht so ein paar Spielbälle, das dauert dann halt zehn Jahre, bis du den Effekt siehst, wächst dann zehn Jahre später so, ups, keine Ahnung, BP ging runter, Lebenserwartungen ging runter, die ging runter.

Dumme Idee.

Mein Punkt war ja auch mehr, dass diese Compliance-Thematiken, die es ja schon in der Finanzbranche gibt, dass diese halt eingehalten, da hat ja schon jemand drüber nachgedacht.

Weil es jetzt nicht alle Details dazu gibt.

Ja gut, aber mein Punkt ist, über Dinge, die du noch nicht weißt, kannst du ja gar nicht so gut sagen.

Ja, genau,

genau, dass die Eingrenzen.

Das ist ja nochmal ein weiteres Problem.

Und die Frage ist halt, was dein Ziel ist, auf was optimierst du dann?

Also willst du überhaupt ein Auto haben das Pferd in dem Beispiel, ja?

Oder möchtest du halt dann die Veränderungen beschränken?

Und das ist, glaube ich, das ist halt ein Dreieck, an dem du keine Sicherheit durch Prozesse kriegst oder durch gute Prozesse kriegst, weil die Prozesse

gar nicht gut haben.

Ein stetiger Prozess noch?

Ja, genau.

Das ist halt dynamisch.

Ein bisschen schwund ist immer, sagt man manchmal, wie ist das?

Und du musst halt irgendwer ein Risiko eingehen.

Und du musst halt eigentlich hingehen und eigentlich, also finde ich, diesen Continuous Improvement-Prozess berücksichtigen, was auch wieder so ein Neugier-Kulturding ist.

Wo wir jetzt wieder sind, mit welchen Leuten will man das überhaupt machen.

Und da würde ich sagen, das ist vielleicht die Entscheidung, die man am Anfang richtig machen kann.

Das wäre so mein kultureller Tipp.

Such dir halt die Leute aus, danach, wie neugierig die sind, überhaupt die Sachen richtig zu machen.