Transcript: Devops Redux

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Paisen-Podcast. Heute Episode 56 und wir reden über der Forbes. Hallo Jochen.

Hallihallo Dominik.

Herzlich Willkommen.

Hi.

Hallo.

Ja, also wir haben wieder einen Gast dabei und wir fangen aber tatsächlich heute wieder an mit News, wie ihr es 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 nur noch Pandas Release vor kurzem, 2.2.2, da ist jetzt auch irgendwie, also seit 2.2 glaube ich irgendwie Arrow unten drunter und haben ein paar jetzt 2.0 und so.

Speed und Performance und sowas?

Genau und ja.

Ein paar Breaking Changes?

Gar nicht so viel.

Ne, ist glaube ich diesmal gar nicht so schlimm mit Pandas 3.0, das kommt dann irgendwann im nächsten, da wird glaube ich umgestellt.

Das Default-Message.

Dass sich dann immer Copy und Write verwendet wird und nicht mehr, also momentan ist es ja immer so eine Sache, manchmal sind Operationen halt irgendwie, verändern die Daten direkt und manchmal hat man halt irgendwie, kriegt man eine Kopie und ist ein bisschen unklar und die Zukunft soll eher so sein, dass halt immer Copy und Write halt quasi, dass das halt so umgesetzt wird.

Ja 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 Vectail 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, ist halt auch schon vorher funktioniert, aber jetzt ist halt offizieller Support drin.

Es ist schon reichlich, dauert immer so ein bisschen, wenn man Vectail nutzen 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.

Ja fast, genau und das ist das Hauptproblem, was ich mache.

Was ich auch hatte, war tatsächlich, dass so die Pipelines auch dann oft kaputt waren oder Sachen nicht gingen.

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

Also ich habe tatsächlich, der Grund, warum ich Vectail rausgeschmissen habe, war tatsächlich, dass sie so lange gebraucht haben umzustellen, weil ich gerne auf das neuere Django fahren wollte, aber.

Ja, ja, also das ist immer so ein Problem, also ich fahre eigentlich immer aktuelles Django und halt auch immer aktuelles Vectail und ich habe jetzt schon seit einiger Zeit eigentlich keine Probleme mehr, aber ja, das ist immer so ein bisschen.

Du nutzt immer deine eigenen Monkey Patches und deine eigenen Forks.

Nein, nein, nein, nein, nein, nein.

Genau, ansonsten, ja, was ist noch passiert? Gar nicht direkt Python, aber.

Äh, na, nah dran.

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

Nein, natürlich nicht.

Das Django, äh, das, das Django-Dreckten, das da eingebaut wurde, Support für Redis.

Ah, stimmt.

Ah, so, Moment, Redis, auch noch so eine News, Redis ist closed, ähm, die haben sich von der Open-Source-Community ein bisschen verabschiedet, war es nicht?

Ja.

Was für eine coole Nachricht ist eigentlich.

Ja, gut.

Aber es gibt einen Fork.

Ja, es gibt ganz viele Forks, da ist was Gutes daran.

Ja, ich weiß nicht, gibt es einen Besonderer? Ich fand jetzt Valkyrie.

Ne, es gibt da.

Es gibt da ganz unterschiedliche, äh, Philosophien, da manche, also, ich weiß nicht, ob es sich da lohnt, schon auf irgendeinen, äh, irgendeinen zu nennen, weil das wird sich dann herausstellen, wer da, äh, wer da irgendwie interessant bleibt.

Ich glaub Valkyrie.

Aber, ja, kann schon sein, ich, aber es gibt da noch eine Menge andere.

Und, ähm, ja, das, das, das, äh, ist halt ein Problem.

Ach, witziger Name, unterstatt Key-Value-Store, Valkyrie, kommt natürlich von Valkyrie, ähm, ja.

Ja, also, ähm, ist halt ein, ist halt ein Problem, aber ich finde, das ist halt so ein bisschen exemplarisch, äh, irgendwie, was, was.

Was halt das Problem dann ist, wenn man halt irgendwie gezwungen ist, ein Geschäftsmodell draus zu machen, ne, also.

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

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

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 ist irgendwie besonders schlimme Konsequenzen für irgendwen, hat dann halt irgendwie ein 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, äh, Dinge hat, auf die man Rücksicht nehmen muss und so.

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

Ich würde einfach 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, hm.

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

Also, die Frage ist, brauchst du da halt, natürlich hat Redis Vorteile, aber die Frage ist, brauchst du diese Vorteile wirklich?

Oder ist es, äh, brauchst du das gar nicht, denkst du bloß, dass du es brauchst und deployst?

Ja, aber der Read muss halt dann vorher, damit es irgendwie ordentlich.

Wenn es ordentlich schnell ist, dann schon irgendwie doch im Speicher liegen von der Datenbank dann immer, 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 Hauptspeicher 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 mehr Redis braucht, weiß ich nicht.

Ja.

Ein Abgesang auf eine der tollen Technologien.

Nein, das ist, ja, ich meine, das hat schon natürlich auch coole, man kann damit coole Sachen machen, aber.

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

Ist auch schon ganz nett.

Ja, klar.

Ja, kannst du in der Datenbank aber auch machen, also.

Mhm.

Du meinst Jason Fields?

Ja.

Hm, okay.

Muss ich mal drüber nachdenken.

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

Ja, pickeln, ja.

Ja, genau.

Dann, äh, vielleicht sagen wir was zu diesem, äh, XZ, äh, LZMA-Debakel, das uns über Ostern ereilt hat.

Ja, sag mal was.

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

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

Äh, ja, da gab's jetzt tatsächlich so einen, äh, von relativ langer Hand geplanten, so eine Supply Chain, Chain-Attacke.

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

Keine Ahnung, wer das war, weiß man nicht, aber ja.

Gut.

Könnte gut sein, ja.

Ja.

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

Ja, aber es war gar nicht im, es war in einer, 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, äh, Sicherheitslücke bei SSH aufgetreten wäre.

Nein, nein, ja, 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, sonst keiner.

Ja.

Also was dann?

Nach Geheimdiensten, es riecht ehrlicherweise, ähm.

Ja, vielleicht.

Ja.

Aber, ähm, wie es halt gemacht war, es war halt Open-Source-Bibliothek, aber das war nicht im Source versteckt tatsächlich, das heißt, man konnte das gar nicht sehen.

Ja.

Sondern in den Tar-Balls, die da mit rumlagen irgendwie.

Nein, in den Testdaten.

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

Mhm.

Und, ähm, ja, äh, das, das war ein Ding, wo da was, aber da gab's diverse Geschichten, ne, also überhaupt, dass, ähm, dass man SSH, das SSH quasi, dass man in SSH

Eine Backdoor bringt.

wie Dinge, äh, austauschen kann, dadurch, dass man, äh, irgendwie eine Backdoor in, in, in den Extratools hat, das hätten wahrscheinlich schon viele gar nicht für möglich gehalten.

Ja.

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, ähm, irgendwie so, äh, System-D irgendwie, äh, gepatcht haben, dass, äh, das irgendwie da mit reingelinkt wird.

Mhm.

Äh, und damit irgendwie so eine indirekte Abhängigkeit von Open-SSH zu, äh, der Kompressionsbibliothek.

Also, das heißt, du, äh, bist jetzt gerade auf der, äh, gegen System-D-Seite von diesen Seiten.

Nein, nein, gar nicht. Also, ich fand, ich fand auch, äh, äh, also, äh, äh, Landa Pöttering hat dann halt auf Mastodon auch quasi geschrieben, so, naja, also, wir sagen ja schon seit, ja,

seit Jahren, dass man das nicht so machen soll.

Mhm.

Und, ähm, wie man, das ist dokumentiert, wie es richtig geht.

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

Ja.

Und da hat er natürlich irgendwie einen Punkt.

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

Ja.

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

Aber, ähm, ja, dadurch, dass die Distributoren halt das so angepasst haben, ist es halt, äh, möglich gewesen, da war es.

Und das muss man erst mal wissen, dass das, äh, dass man da so Sachen reinschmuggeln kann, das ist nicht so offensichtlich.

Ja.

Und jetzt ist natürlich auch alles geändert worden, ne, und jetzt machen sie es richtig.

Das war tatsächlich auch so eine Social-Engineering-Attacke, ne, also man hat halt den einen Maintainer, der dann irgendwie da alleine gekämpft hat, um das Ding da so ein bisschen weiter zu, weiterhin unter Druck gesetzt, also auch mit so vielen Nachrichten und sich da in dem Repo als Co-Maintainer irgendwie eingeschlichen.

Ja.

Und dann halt die ganze Zeit so getan hat, jetzt macht man irgendwas und dann von außen noch mit anderen Accounts Druck erzeugt.

Nicht so getan.

Nein, nein, man hat von außen halt noch Druck erzeugt, also, ja, man hat was gemacht.

Nicht so getan.

Aber ich meine, also, man hat da aktiv dran entwickelt, auch gut getan quasi und dann auch Qualität beigetragen quasi, aber man hat diesen einen Maintainer, der halt auch, äh, kann das nicht unter Druck gesetzt werden?

Das waren viele, das waren viele Commits, also es waren nicht irgendwie wenige, das waren richtig viele, es waren, ich weiß nicht, insgesamt, keine Ahnung, so, geht in die hunderte und die waren alle sehr gut, also irgendwie, man hat dann mal so ein Beispiel gefunden, du guckst dir 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, welche Fachbegriffe es da gibt.

Ja, aber was sie halt auch gemacht haben, sie haben ja psychisch unter Druck gesetzt, ne, 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, ne, das war tatsächlich so.

Nein, nein, nein, nein, nein, nee, nee, nee, der wollte vorher schon nicht, also, der hatte sowieso ein Problem, also, dass sie sich den ausgeguckt haben, ist halt auch kein Zufall, sondern der hatte irgendwie immer schon irgendwie so ein bisschen Struggle und der wollte das eigentlich, äh, musste halt immer mal wieder auszeiten.

Nehmen konnte das nicht so richtig machen und dann haben sie halt, äh, gesagt so, brauchst du nicht, und dann, er hat ja um Hilfe gefragt, er hat gesagt, ich hätte gerne Hilfe, will nicht, mir nicht irgendjemand helfen, weil ich kann's nicht so richtig machen, wie es eigentlich gemacht werden müsste, ja, und dann hat sich der eine da gemeldet.

Ja, das war eine cleverere Strategie eigentlich, ja.

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

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

Ja, also, ich würde auch sagen, da kann man sich schlecht verschützen, das ist halt nur das Vier-Augen-Prinzip, was hilft. Und es gibt halt jetzt hier so Schreihälter, die sagen so, nein, oben so was verbieten, weil es ja total gefährlich, da sind ja Sachen und 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 Form her auch so passieren. Und Closed Source wäre da eigentlich besser für.

Ja, also, es hat ja da funktioniert, 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 war. Aber, ähm, genau, demgegenüber Closed Source, ähm, ich weiß nicht, hast du das mitgekriegt? Das gab, kam jetzt auch letztens raus, da gab es irgendwie einen offiziellen, äh, Abschlussbericht, äh, Microsoft hat ja irgendwie dieses Problem gehabt mit dem Master Key, der ihnen irgendwie abhandengekommen ist, wo sie dann gesagt haben,

so, oh, ja, wir haben hier irgendwie, äh, ein Postmortem-Gedings gemacht und ein langes Ding veröffentlicht, wo sie dann gesagt haben, ja, wahrscheinlich ist das irgendwie so, oder wir denken, es ist halt durch irgendeinen Crashlog irgendwie dann da rausgelegt und keine Ahnung. Und, ähm, ja, da hat irgendeine Behörde aber, äh, 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 abhandengekommen ist.

Also ein Ding, mit dem sie, mit dem man Sessions signieren kann, mit dem man in jeden, in jeden, in jedes Outlook-Konto reingekommen ist, in jeden, in jeden Azure-Kram und sie wissen nicht, wie das Ding rausgelegt ist.

Tja, das ist nicht so gut, ja. Und, äh, Microsoft hatte auch LibArchive, wo halt die gleichen, äh, Leute, die halt da, äh, irgendwie dieses XZ-Tools-Dings gemacht haben, auch aktiv waren. Das haben sie auch integriert mit den Änderungen.

Ja.

Und, ähm, ja, also, ich glaub nicht, dass...

Das Closed-Source da irgendwie...

Ich würde auch sagen, also, Open-Source ist dann wahrscheinlich doch besser, wenn mehr Leute draufgucken und die dann wirklich so... Also, wie das raufgeflogen ist, ne, da hat irgendwie wirklich jemand, also, Messungen angestellt, ne?

Andres Freund war das, genau.

Microsoft-Mitarbeiter.

Ja.

Arbeite an Postgres und hat halt so Micro-Benchmarks gemacht und dann...

Ja, aber das ist ja so Hobby-Nerdism quasi, ne? Also, es ist voll gut, dass es so Menschen gibt, die sich so tief mit so Themen aufsetzen, aber ohne so ein Enthusiasmus da an der Stelle wäre das einfach untergegangen, ja.

Ja.

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

Ich hab auch schon, äh, irgendwie... Also, ich mein, es gibt da natürlich das Netz grad voll davon, äh, was man also machen könnte und was, äh, 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...

Mhm.

Was die Abhängigkeiten dafür sind und dass man da, äh, äh...

Halt dann ein Auge drauf hat, dass da, äh, dass man die Dinger ganz besonders, äh, genau anguckt, aber, ähm, ja, ähm, letztlich, äh, ist, ist es, glaub ich, schwierig, sich dagegen zu verteidigen.

Äh, einen interessanten Ansatz fand ich, ähm, von, äh, von einem, von Michael Zaleski, hat dann zu, zu einem Artikel geschrieben, der meinte so, naja, also, grad auch dieser, den, technisch ist halt die Frage, kriegt man das technisch überhaupt in den Griff? Wahrscheinlich eher nicht.

Weil eigentlich ist ja der Kern dieser Attacke ein Social Engineering-Angriff gewesen.

Und, ähm...

Ja, da kannst du mit Technik nur begrenzt was gegen machen.

Ich würde auch sagen, du kannst ja auch Mitarbeiter einschleusen und einen Geheimagenten in der Firma, der dann Entwickler ist und dann irgendwie Commit-Rechte sich ergaunert, indem er da gut arbeitet und dann sowas, ne?

Das kann man wahrscheinlich gar nicht ausschließen. Tatsächlich ist dann das Mehraugen-Prinzip gar nicht so schlecht.

Ja, und, äh, also, und dessen Fazit war dann quasi mehr oder weniger, äh, zu sagen, naja, also, eigentlich ist das auch nicht so, mit sich Open-Source-Maintenner oder auch überhaupt Software-Entwickler letztlich beschäftigen, also darin gut sein sollten, weil das ist halt eigentlich, äh, ist das halt, äh, eher Spiel.

Spionage-Abwehr, weil, äh, äh, du fängst, äh, Spione nicht unbedingt mit, äh, mit Programmierern, sondern dann nimmst du halt andere Spione, die das halt, wissen, 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 alles wieder Geld, ne?

Ja, aber gut, jetzt, jetzt gab's mal halt einen Warnschuss, äh, irgendwie und...

Besser du Internet einfach abstellen, ne?

Naja, äh, genau, aber war auf jeden Fall aufregendes...

Ja, war spannend.

Bei Python gab's ja auch wieder so ein paar Tag, ne? So jede Menge Typo-Squatting und so.

Oh, gibt's grad, äh, gibt's grad, äh, äh, wobei das eher, äh, das sind, das sind eher so, äh, handelsübliche Kriminelle, würde ich jetzt mal sagen, Kleinkriminelle, grad, äh, PyPI hat, äh, Anmeldungen von neuen Benutzern abgeschaltet und, äh, auch nimmt's auch grad, äh, vor ein paar Tagen, ich weiß nicht, es kann auch sein, dass es schon wieder vorbei ist, äh, keine, keine neuen Pakete entgegen, weil halt da irgendwelche, ja, maliziösen, äh, Python-Pakete eingestellt wurden, so auch Typo-Squatting-mäßig und, ähm...

Jedes tolle Paket, was man kennt, äh, einfach ganz viele Namen von GPT generieren lassen, die endlich klingen und von hinter seinen Codes verstecken.

Genau, und, und die, die machen einfach so, so schnöde Dinge wie, äh, Session-Cookies von Banken klauen und, äh, irgendwie Crypto-Wallets, äh, irgendwie sammeln und solche Sachen.

Ja.

Ist aber auch unnatürlich, unerfreulich, wenn man davon betroffen wird, aber...

Ja, also wenn ihr Pakete dazu fügt, guckt drauf, dass ihr die ordentlich eingibt, dann ist so ein bisschen, ja.

Ja, äh, genau. Ansonsten...

Mehr News?

Ja, ähm...

Sir Boyce, das Jungle Fellow.

Wir haben hier die, äh, äh, Jungle User Group Köln mit organisiert.

Ähm, genau, das ist natürlich irgendwie, herzlichen Glückwunsch von hier, äh, irgendwie gehen wir morgen vielleicht auch mal hin, wieder zu einem Treffen.

Ja.

Na, das war dann, wenn ihr es hört, bestimmt schon gestern oder vorgestern.

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

Ich meine, leider ist ja die, äh, die Jungle User Group Köln, das ist also 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, äh, irgendwie da von der Jungle Software Foundation Leute,

da waren, so ein Typ Okular von, auch, Wagtail ganz viel macht.

Mhm.

Und, ähm, Sarah Taramane, ich weiß nicht, äh, aus, aus der Jungle User Group Paris.

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

Ja, und auch eine Aufforderung, ne? Alle Leute, die Bock haben, sind gerne herzlich eingeladen auch, ja.

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

Ähm, einfach deswegen, weil ja, jahrelang vorher, äh, äh, gab es keine gute Frontend-Story für Jungle.

Mhm.

Und das hat sich halt irgendwie gerade geändert, also mit HTMX.

Ja.

Und, da kann man vielleicht auch nochmal kurz was zu sagen.

Und daher, ja, wir haben jetzt da jetzt im Grunde, und, ja, da kommen jetzt auch so 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, äh, ist gerade, äh, auch mit drin.

Ähm, Firefox muss sich so ein bisschen mal, äh, irgendwie, was weiß ich, auch mal hinkriegen.

Ja.

Das wäre ganz gut, weil dann kann man halt irgendwie traditionelle, äh, Webseiten halt auch irgendwie aussehen lassen wie SPAs mit relativ wenig Aufwand.

Und, ähm, ja, äh, das ist natürlich, das ist natürlich interessant.

Also das wäre für die meisten Backend-Leute wie uns, äh, relativ.

Wäre das halt super, ne, weil man da kein komisches JavaScript, äh, Framework vorne dran verwenden muss.

Und, ähm, ja, äh, mit Jungle hat man halt ein Ding, was halt 15 Jahre alt ist.

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 drauf konzentrieren, damit irgendwie interessante Dinge zu tun.

Genau, also Admin-Fontent ist so eine der Sachen, oder ist Admin-Backend, ich weiß nicht.

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

Das Problem beim Admin-Backend ist halt, äh, was Backend, also Admin-Fontent eigentlich ist, ja, genau, ähm, ist halt, dass es halt riesig ist und, äh, das, also neu zu schreiben,

ist halt sehr schwierig, vielleicht kann man das irgendwie so ein bisschen mit HTMLX und so, es soll auch, also das war auf jeden Fall auch ein Ding, wo viele Leute, äh, 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, äh, irgendwie besser aussehen lassen oder so, das wäre natürlich auch, also da passiert auf jeden Fall was, aber überhaupt generell Richtung irgendwie, äh, äh, äh, diese ganzen HTMLX und so Sachen besser integrieren, das, da in die Richtung geht's auch auf jeden Fall und das ist eigentlich super wichtig.

Super interessant, also eigentlich gerade eine sehr, sehr gute Zeit, um sowas mit so einem klassischen, äh, Web-Framework, äh, irgendwie was zu machen.

Ja, also HTMLX, wir hatten ja schon eine Episode dafür und ein paar Mal irgendwie auch da eine Lanze für gebrochen und, ähm.

Inzwischen hat man das auch schon häufig verwendet.

Ja, nicht super, aber das ist auch mehr, genau, also Hypermedia Systems, das ist ja das Buch, das da auch relativ frei rauf und rum liegt oder sowas.

Ja, kann man sich auch auf jeden Fall mal angucken, wenn man, äh, wenn man sich dafür interessiert, also ich finde eigentlich immer ein bisschen, es hat auch gehabt jetzt, es ist jetzt

so erfolgreich, dass, äh, es auch Kritik gibt, weil es offenbar die Wahrnehmungsschwelle irgendwie überschritten hat.

Ja.

Bei manchen Leuten und dann gibt's, äh, die, die Kritik, die es da bisher immer gewahrt hat, ich, ich finde immer so ein bisschen schade, wenn dann halt, äh, irgendwie ich das Gefühl hab, dass da nicht so richtig verstanden ist, warum das so cool ist.

Oder vielleicht gar nicht verstanden ist, warum, warum, äh, was daran, äh, und das, äh, kann ich vielleicht auch mal versuchen, nochmal in zwei Sätzen zu sagen, weil das ist, äh, wäre mir schon wichtig, wenn man das irgendwie verstehen würde, also das eigentlich Coole ist halt, äh, aus meiner Sicht,

dass es halt eine Geschichte, äh, ermöglicht, äh, die, äh, halt mit so SPS nicht so gut geht, ne, bei SPS hast du halt eigentlich, äh, immer, äh, so, jedenfalls soweit ich das, äh, kenne, eine enge Kopplung zwischen Client und Server.

Du musst halt immer, wenn du das eine änderst, musst du das andere mit ändern, ne, also wenn du halt, äh, irgendwie, äh, in Form, ja, so, äh, API-Versionierung, oh mein Gott, ja, das, äh, nein, aber allein schon, wenn du halt so einfach nur, du änderst dann irgendein Formular oder so.

Dann musst du das halt einmal am, am Server ändern und du musst es halt auf dem Client ändern.

Hm.

Und, äh, das heißt, die Dinger sind voneinander abhängig, ne, wenn du da halt irgendwie viel mehr in dein, 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-Trip machen und einen, die das Backend machen.

Aber gut, irgendwie.

Aber möchtest du denn den, den komischen Backend-Leuten diese ganzen schönen Design-Sachen noch dranbinden?

Ja, na ja, ich meine, das ist halt einfach, äh, manche Leute mögen halt lieber JavaScript, andere lieber was anderes und dann sind das, werden das irgendwie automatisch unterschiedliche Teams oft und, ähm, 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, äh, ich kann mir nicht vorstellen, wie das, äh, wie das keine Probleme machen kann, das macht immer Probleme, sowas.

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

REST.

Ja, also tatsächlich REST quasi, ne, so was die JSON-APIs normalerweise halt eben nicht wirklich sind und, äh, der Client ist halt der Browser und dann bist du, hast du eine lose Kupplung, nämlich, äh, sozusagen ich kann den Server ändern und dann muss ich nicht aber einen neuen Browser shippen,

sondern das geht halt auch, ähm, ja, geht mit allen Browsern, geht auch mit alten Browsern oder geht auch mit neueren Browsern und, ähm, genau, ich muss nicht beides ändern, ich muss nur die eine Seite ändern und das ist halt dann natürlich eigentlich viel angenehmer.

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

Ja, äh, ja gut, aber, also, ich meine, ich würde einfach mal sagen, so, wenn du halt ein Formular hast und, äh, 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.

Ähm, 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 ja, du musst ja immer noch, 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 dein Formular ändern in der Client-Applikation.

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 feingranular, dass es im Grunde mehr oder weniger wie SQL ist?

Mhm.

Ja, könnte man ja sagen, ah, super, dann ist das Problem ja erledigt, ja, das ist ja dann so wie SQL, äh, kann ich ja dann die ganze Logik im Client machen und habe dann nur noch dumme Datenschnittstelle, sozusagen.

Ja.

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

Die habe ich dann halt in allen Clients, die es gibt, die habe ich dann einmal in der SPA, aber halt, äh, die habe ich dann auch in einer mobilen Applikation.

Ja.

Und in allen Third-Party-Integrationen.

Und es wird halt dann nicht lang.

Und wenn ich irgendwo was ändern muss, muss ich das in allen ändern.

Das ist halt auch irgendwie ein Architektur-Pattern ist, wo ich mir denke, wie kommt man auf die Idee, sowas zu machen?

Natürlich, ich kann 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, ist auch richtig, aber, äh, allein schon, dass das halt dazu führt, dass man halt die gleichen Geschichten immer wieder schreibt in unterschiedlichen.

Verschiedlicher Formen, dabei über Teamgrinsen hinweg kommunizieren muss.

Ja, gut.

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

Ähm, ja, und, äh, genau, das ist halt so, das sind halt so die beiden Hauptprobleme, die ich sehen würde, ne?

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

Mhm.

Ja.

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

Das ist ja immer so ein bisschen...

Ja, obwohl, also, ich glaube, das Hauptproblem sind da auch die People, da werden wir gleich wahrscheinlich nochmal einkommen, 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, äh, luberklar sein.

Ähm, ja.

Waren das deine News, Jochen?

Ja.

Ja.

Äh, hast du noch News mitgebracht?

Äh, nee.

Du hast aber auch einen Podcast, hast du gesagt.

Genau.

Du hast aber auch einen Podcast.

Erzähl doch mal.

Ähm.

Du darfst doch gleich noch was über dich sagen.

Erst mal über deinen Podcast.

Ja, ich mache mit meinem, äh, mit einem Kollegen, äh, Dirk, äh, Podcast namens TillPod.

Till 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, äh, Sachen wir mal zuletzt gelernt haben.

Mhm.

Oder vielleicht auch nicht gelernt haben.

So ein Beispiel offensichtlicheres, manchmal auch weniger offensichtliches.

Mhm, spannend.

Ähm, genau.

Was war das Letzte, Till?

Oh, das ist schon ein paar Wochen her.

Das habe ich heute schon wieder vergessen.

Okay, dann müssen wir jetzt den Schonungsnachrichten nachreichen.

Ja, ich kann ja verlinken das.

Ja.

Genau.

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 sponsoren.

Und wir haben einen schönen Partner dafür gefunden.

Und zwar ist das datasigntest.com.

Datasigntest?

Datasigntest.com, genau.

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

Oh, okay.

Zum Beispiel zum Bereich DevOps oder Python generell oder SQL.

Machine Learning.

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

Genau, und die kann man remote alle machen.

Also es ist gar nicht so schlecht für euch,

wenn ihr Familie habt vielleicht.

Du wolltet nicht irgendwo zum Fußball dorthin fahren.

Ja, so ein bisschen flexibler sein, ja.

Also genau, die arbeiten aber auch mit der Sorbonne, glaube ich,

da irgendwie zusammen.

Ja, es gibt offizielle Zertifikate von einer Pariser Universität.

Ja, und genau, man kann halt sich dabei so ein bisschen das Tempo raussuchen,

was man gerne dabei hätte.

Also wenn ihr da Interesse dran habt, dann schaut 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 Tag der offenen Tür an,

den haben sie nämlich ein.

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

Also sucht die Webseite auf www.

www.datascientist.com

Genau, und schaut euch das ein bisschen an.

Okay, cool.

Ja, wunderbar.

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, ich meine, auch ein bisschen mehr zum Wort kommen soll.

Den haben wir nämlich heute eingeladen,

weil er nämlich über DevOps sehr viel weiß

und auch ein tolles Buch dazu geschrieben hat.

Soll ich kurz sagen,

wie ich darauf aufmerksam geworden bin?

Ja, bitte.

Weil ich habe oftmals so gesehen,

dass Frederik Hemberger, glaube ich,

hat 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 Thema.

Gleich mal gucken.

Und genau.

Ja, dann habe ich gesehen,

oh, da gibt es ja auch noch einen Podcast.

Und dann muss ich direkt eine Mail schreiben und fragen.

Sofort ja gesagt.

Ja, jetzt musst du dich aber mal vorstellen,

erst mal selber.

Bitte.

Was soll ich denn sagen?

Ja, wie du deinen Vornamen kennst.

Und was du so machst vielleicht,

wie du dazu gekommen bist,

was du findest,

wie DevOps irgendwie uns begleitet.

Genau.

Also ich fange mal von vorne an.

Würde ich mal sagen.

Genau.

Sushivan ist mein Name.

Ich habe 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,

über die Kultur zu sprechen.

Und dann die Prozesse.

Und dann die Tools.

Ich arbeite, so meine normale Anstellung ist bei GitLab,

wo ich Solutions-Architekt bin.

Also letztendlich eine Push-Sales-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 du versuchst denen so Wege aufzuzeigen,

wie die DevOps integrieren?

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 zu sehen,

wenn ich mit den Firmen rede.

Ja.

Und ich bin hier ja jetzt privat.

Was die halt falsch machen teilweise.

Ja, das ist natürlich interessant.

Da darfst du gerne auch so ein Nähkä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 ein Feature-Request.

So das Übliche, was man halt so kennt.

So, und da kamen die halt,

die halt zu uns.

Und das ist halt erst mal das Erste,

worauf ich mich dann kümmere.

Also erst mal anhören,

was wollen die überhaupt?

Und die hatten dann so gesagt so,

ja, wir möchten,

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ß,

warum er das Management sollte sehen,

was man da schreibt.

Oder es sind so externe Business-Partner 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 richtig.

Naja, wenn du nicht einen Code sehen willst,

dann mach doch dann das ganze Projekt halt privat

oder nur die Leute,

die es halt sehen sollen, dürfen.

Ja, 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.

Hä?

Genau.

Okay.

Das ist auch so mein Gedanke.

Moment mal,

da muss ich jetzt noch näher nachfragen.

Warum?

Ich mach ja sehr gern ein Warum,

wie so ein kleines Kind.

Warum?

Ja, ja, voll gut.

Und 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,

da ist ja ein Moment,

da gibt es doch so, ne,

Push Rules und Branch Protection Rules und so weiter.

Das sollte man so oder so machen,

sodass man nur mit Code Review und sonst was

da den Code einschleusen kann letztendlich, ne?

Nicht so wie bei XZ.

Ja.

Auch wenn es ein Main Trainer ist.

Und dann so,

ja, okay, stimmt,

das ist nicht das Problem,

bla, 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 eh ausbauen

und warum baut ihr das denn nicht?

Egal, wer das Zugriff hat,

sollte keine Passworte drinstehen, ne?

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

Ändern, ausbauen und dann halt, ne,

durch sowas wie Hashtag of World

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.

Dann dachte ich so,

naja, okay, aber was ist jetzt euer Problem?

Dann, es war eine Policy.

Ja, mhm.

Also die Policy in der Firma hat irgendwie gesagt,

bestimmte Leute, die nur Projektmanagement machen,

sollen nicht den Source Code sehen.

Mhm.

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 gleichen Interessen sind,

obwohl sich das eigentlich komisch antwortet,

wenn man eine Firma ist,

wie die Desentwicklungsteams, 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 das Team hat sich entschieden, hey, wir wollen nicht,

an diesen KPIs gemessen werden,

sondern lieber Kreativität oder Testdriven machen

oder sowas.

Und diese internen Kunden, die wollen halt was anderes.

Das ist dann aber ein Managementproblem,

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 verhackstückeln.

Aber wenn dieser andere Manager halt diese volle Transparenz 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 das so eine Art von politischem Problem.

Ja, interessanter Ansatz.

In dem Fall war es aber halt nur so,

naja, das war ja das gleiche Team.

Ja, okay.

Nur die Leute, die das Projektmanagement gemacht haben.

Blickwinkel kann ich das ja noch nachvollziehen,

wenn man jetzt 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 noch grundsätzlich irgendwie nachvollziehen.

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

Ja, das macht irgendwie keinen Sinn.

Das macht dann keinen Sinn.

Und eines der Aspekte von DevOps ist ja zum Beispiel

ja auch Visibilität in aller Sachen.

So, das so als, weil, ich meine, im Endeffekt geht es auch viel

um Silos zwischen den verschiedenen Rollen.

Ops, QR, 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 Projektmanagement

ja dann sieht, da muss man 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 Diskussion.

Aber jetzt erwartest du vom Projektmanagement ja 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ß,

was ein Merch-Request ist, 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 dran gearbeitet, da sind irgendwelche Kommentare

dran zu finden. Das heißt ja nicht unbedingt,

dass du den Source-Code verstehen und

ein Review machen musst als Projektmanager.

Mhm. Okay, 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 dieser 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

gerne nochmal besprechen. Also welche Sachen da so ineinander

greifen, 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 ruhende Leute

sind, die nichts mit IT zu tun haben, auch Fragen, worüber ich

ein Buch geschrieben habe. Das ist ganz anstrengend.

Ähm,

aber ich versuche immer, das so

zusammenzufassen, 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 auch eine Software

mit dran hängt. People-Sicht, ne? Und nicht

die technologische und auch nicht die Prozess-Sicht, 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.

Also, du kannst immer

noch DevOps richtig beschissen machen,

wenn du, ähm, zwar die

richtigen Personen hast oder die richtige Arbeitskultur

hast und auch die richtigen Prozesse hast,

äh, wenn aber der technologische

Tool-Stack halt, äh, bescheiden ist,

dann hilft das ja irgendwie auch alles irgendwie nicht.

So, ne? Aber deswegen muss man...

Ich fand das Beispiel, was du da gebracht hast, das ist, äh, super dafür.

Und zwar das mit dem Auto, dem Fahrer und der

Straße. Genau, also, weil wenn ich jetzt

aus meiner Arbeitsblickwinkel da drauf schaue,

dann, ähm, positioniert sich

vor allem GitLab dann halt mehr so, naja, wir machen, äh,

äh, mit, äh,

also DevOps wird schneller, besser, einfacher

im Wesentlichen, äh, wenn man GitLab

einsetzt. Mhm. 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

technologische Natur. Das ist halt

ungefähr so, als wenn man mir

ein Formel-1-Auto geben würde.

Mhm. Ähm, das ist

dann halt das Tool. Äh, der Prozess

wäre dann quasi die Straße und

ich würde halt auf einer,

auf, äh, durch die Innenstadt von,

keine Ahnung, Düsseldorf fahren.

Oh, das, äh, ich weiß nicht, auf der Köhe, da

sieht man manchmal, also, nicht gerade rum,

die Formel-1-Autos, aber. Genau, aber

da kommst du ja trotzdem nicht so schnell rum. Nein, nein,

nein, nein. Dann ist es natürlich schön, dass du ein tolles,

schnelles, äh, Auto hast. Ja.

Du bist aber nur, äh,

du kannst aber auf der, auf der Köhe in Düsseldorf jetzt nicht

so schnell fahren. Nö. Gleichzeitig,

äh, also brauchst du auch eine gewisse

Rennstrecke zum Beispiel dann halt auch, ne?

Und das andere Ding ist, naja, du kannst

das Ding überhaupt nicht fahren. Ja, oder

wenn, oder wenn der Fahrer völlig betrunken ist, ständig gegen den

zweiten Baum fährt, ist auch blöd, ja. Ja, genau.

Und, äh, und so finde ich,

kann man das eigentlich ganz gut, das typisch

deutscher, der typisch deutsche Autovergleich,

dann eben anbringen, so von wegen so, naja, das bringt halt

nichts, wenn du das beste Tool, ein tolles Auto hast,

äh, wenn aber die Straße total

bescheiden ist und wenn du überhaupt gar kein Auto,

gar keinen Führerschein hast zum Beispiel, oder gar kein Auto,

oder nie ein Auto gefahren bist, dann kann's halt nicht funktionieren.

Das hilft dann natürlich auch nicht,

wenn dein, äh,

und jetzt hab ich ja gerade mit dem Form 1

Wagen und da sitzt man ja nur 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? Ja.

Was sind überhaupt, was ist überhaupt die Frage, das warum?

Ja, ja. Ja, wenn die Kinder die ganze

Zeit auf dem Rücksitz quengeln, weil du bist ja endlich da und du hast das

Essen vergessen und so, das wird irgendwann schwierig.

Ja. Viele Stakeholder.

Ja. Genau.

Okay, also du sagst, der Forbes

ist ein Kulturbegriff und der halt,

wo es darum geht, diese ganzen Silos zusammenzubringen

und halt, ähm,

ja, die einzelnen Abteilungen, die es ja früher mal waren,

irgendwie miteinander an 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, ja, eine

Entwicklungsabteilung und halt dann irgendwie

sozusagen die, 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, äh, ja, aber das waren unterschiedliche

Leute, also. Also das ist jetzt der

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

Ja. Und der Dev-Teil ist der Software-Entwicklungsteil,

aber wir hatten jetzt ja noch viel mehr drin, also zum Beispiel das Security-Ding,

das Projektmanagement-Ding,

ähm, welche Silos waren noch drin?

Na ja, QA

letztendlich halt auch, weil häufig, also wenn man

auf dem Wasserfallmodell guckt, halt eher nachgelagert,

ganz früher guckt, weil man jetzt die

reine Agilisierung ist ja eigentlich schon lange

durch, sag ich jetzt mal so als Thema, da redet man

ja kaum noch drüber. Also, dass man das machen

müsste. Ja. Aber

da wird halt häufig halt auch nur nix ausgeliefert

oder in Betrieb genommen, wie so, ne, sondern halt

nur über die, über die, äh. Über den Zorn geschmissen.

Über den Zorn geworfen, genau. Ja, ja.

Ja.

Genau, und, ähm, also das Problem

dabei ist halt, äh, denke ich, also

vor allen Dingen, es gibt zwei große Probleme, das

eine Problem ist halt, äh,

ähm, ich würde eigentlich

DevOps, äh, im Grunde, äh,

äh, als, als ein, ein Trend

in der ganzen, in der ganzen,

äh, äh, in einem, ja,

äh, ja, wie, was ist das?

Oberbegriff von einem Trend?

Äh, ne, ja, ja,

wie, wie auch immer. Industrie, äh,

ja, äh, äh, also,

äh, äh, begreifen,

also, dass man versucht, äh,

irgendwie, wenn, äh, wenn man jetzt

halt sozusagen sich diese ganze Strecke anguckt

von, man möchte irgendwas machen zu

ist es im Betrieb und die einzelnen Schritte,

die dafür nötig sind, dann versucht man halt immer

mehr, irgendwie Richtung

anfangen zu verlagern, also ich glaube, das läuft

dann irgendwie so unter dem Stichwort Shift-Left oder so

und DevOps ist halt ein Teil davon, weil

es halt darum geht, quasi,

äh, äh, sozusagen den,

den Teil halt näher an die

Entwicklung ranzubringen, der halt irgendwie dafür

sorgt, dass das Ganze deployed, äh, ist, weil

Naja, aber jetzt sind wir bei Qualitätskontrolle

tatsächlich beim Codeschreiben auch dann?

Qualitätskontrolle, ja, gut,

das ist, was ähnlich ist, dass man das halt auch

versucht da, äh, genau, das konnte man halt bei,

bei, bei Qualitätssicherung macht man

das sicherlich, äh, genauso. Ja, so

Linting, Testing, Testing. Genau, man versucht das

auch immer weiter quasi an den Entwicklungsprozess

ranzubringen, beziehungsweise dann halt in die Pipeline,

äh, wie auch immer, dann vielleicht, äh,

in die IDE, eigentlich noch besser,

weil, äh, dann hast du noch einen kürzeren Zyklus,

äh, von irgendwie, ich mach irgendwie

Unsinn zu, mir sagt jemand, dass ich Unsinn mache,

äh, aber

es geht im, im, im Grunde darum, äh,

äh, zu versuchen, zu verhindern, dass

halt, äh, ein Fehler irgendwann

sehr viel später auftritt, wenn man jetzt eigentlich

schon gar nicht mehr dran ist, wenn er zwei Wochen nach dem

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 mal

an etwas völlig anderem dran und dann, äh,

weiß man auch gar nicht, was man jetzt noch

tun kann, oft, und, äh.

Ja, wenn ein halbes Jahr später irgendeine rote Lampe angeht und

die Leute, die sich das eingebaut haben, auch gar nicht mehr da,

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

Naja, und wenn du zwei Abteilungen hast, dann hast du automatisch

da halt so ein Ding, wo das halt

Ja, müssen wir jetzt mal ein Meeting machen, jetzt machen wir erstmal einen Workshop.

Ne, wo du halt diese Trennung hast und wo du es halt,

äh, wo es halt sehr schwer ist, wo,

das macht es halt einfach langsam, also das, denke ich,

ein wichtiger Punkt, ein anderer wichtiger Punkt ist halt,

äh, oder, das war halt

jedenfalls früher immer so ein Problem, wenn man das

halt in unterschiedlichen Abteilungen hat, dass,

äh, dass man unterschiedliche Interessen hat.

Das halt, ähm, genau, äh, ja,

also, die Entwickler

werden halt dran gemessen, äh, was sie

halt an, äh, quasi

Story Points oder was auch immer irgendwie

aus der Tür kriegen, ja, so an Features

raus, rausbringen. Also wie viele Tickets

man dann auf irgendeinem Board irgendwie auf die andere Seite

Ja, genau, und die,

äh,

äh, Admins werden halt dran gemessen, sozusagen,

äh, das halt, äh,

wie, wie verfügbar das ganze Amtssystem ist und

diese Interessen sind halt unterschiedlich, ja, also

sozusagen eine sehr einfache Strategie eben

zu gewährleisten, dass halt, äh,

äh, quasi nichts schief geht, ist

zu versuchen, alle Änderungen zu verhindern und sagt halt

einfach, nö.

Ja, und dann kommt da noch das, äh, QA-Team

rein, die gemessen werden mit, äh,

ja, wenn du keine Fehler findest,

so, und das, das Entwicklungsteam

soll ja Features entwickeln, das QA-Team

Idealerweise, genau,

ja, und QA-Team wird halt

irgendwann immer Fehler finden, selbst wenn es die perfekte

Software ist, äh, und dann

gibt's noch das Betriebsteam und dann, äh, die haben ja alle

andere Ziele und, äh, dann passiert

halt eher so ein Gegeneinander und im Endeffekt,

wenn man halt nochmal einen Schritt zurückgeht und dann

aufs große Ganze guckt, ist ja der

Kerngedanke eigentlich, man will ja irgendeinen

Value, irgendeinen Wert an die Endnutzer

bringen. Ach, hier, jemand hat Kunde gesagt,

ach, herzlich.

Deswegen hab ich Endnutzer gesagt, nicht Kunde.

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

ja, ich mein, also Kundennutzer, das ist,

äh, User-Value oder, ja. Genau, irgendeinen Wert willst du dann

ja haben, dann ja auch, ne, und das bringt halt

nix, ich mein, das hast du bei Open-Source-Projekten ja auch

so, wenn du, da bist du ja auch Kunde in dem Sinne.

Ja, genau, Nutzer, Sangenutzer.

Genau. Ähm, 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 du denkst, also, eigentlich will ich das,

was ich dann entwickelt hab, und dann,

äh, auch nutzen, und das

hat jetzt erstmal nix mit Ops zu tun,

oder DevOps wird so

im Direkten zu tun, aber es ist halt auch so ein Aspekt, der damit

Es ist natürlich ein Produkt-Lebens-Zyklus-Management.

Ja, das sind so ganz viele Aspekte, die

da mit reinkommen, ne, und

äh, wo ich nochmal einen Schritt zurückgehen

würde, ist, äh, weswegen ich auch das

Beispiel genannt hab mit dem,

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

schien in der Teams. Ja, aber dann, oh, aber das ist, jetzt kommst du wieder

in so Konzernen und denkst, ja, das war auf einem anderen Kontinent,

und die haben sich das überlegt, weil, wissen wir

auch nicht so genau, und bis wir jemanden gefunden haben,

den wir darüber fragen können, äh, sind Monate

und Jahre ins Land gegangen, und, ähm.

Genau, und du, du, du, du gehst schon

auf die richtige Spur, nämlich drauf, wo ich hin will, weil

eigentlich muss das Thema ganz weit oben

hängen. Mhm.

Weil, wenn man so, weiß nicht,

schief Technology-Officer

oder sonst was in Großkonzernen, oder generell

in Firmen,

denen muss das ja eigentlich von Interesse

sein, also eigentlich allen in der

Führungssituation, dass die, weil ja eigentlich

fast überall Software entwickelt wird.

DevSecOps als Priority Number One

für Cloud Next Strategy.

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 einen Value schneller an den Kunden bringt,

oder überhaupt an den Kunden bringt. Ach ja, voll cool.

Und das möglichst effizient läuft. Ja.

So, und da gibt's halt so,

so viele Aspekte, und ein Teil davon ist halt eben

DevOps. Ja, okay.

Jetzt musst du aber doch nochmal kurz erklären, was denn

diese Plattform-Integration-Strategie

und sowas, was das alles ist.

Vielleicht einmal so ganz kurz für alle Leute, die das noch nicht... Du meinst

Plattform Engineering? Ja, ja.

Das ist eigentlich schon wieder, das ist...

Ja, Buzzword-Reiterei, aber vielleicht

für alle Leute, die das gar nicht kennen, lass einmal kurz...

Ach so, ich kann's nicht. Ja, ich meine,

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 auch betrieben werden soll.

Und idealerweise auch 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 reinspielen,

die irgendwer bereitstellen muss.

Zum Beispiel irgendwelche Compliance-Regeln,

wie, wer darf was reviewen, oder

wo soll was hindeployed 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

Menschenkonzern bist,

und du bist da dein 6-Personen-Team

oder sowas, oder 10-Personen-Team,

kennst dich 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.

Bisschen mehr noch, eher so 200 als 20.

Und, ja,

doch, die kleinen Teamsteam waren

komplett end-to-end.

Alles selber. Also,

das Problem ist halt, dass dieses

Monster,

was also sonst an Bürokratie

und Prozessor von hinter steckt,

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

zu irgendeiner 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, es hat an sich nichts Neues,

der Begriff halt eher neuer, würde ich sagen.

Oder zumindest so, wie der jetzt durch die

IT-Landschaft gezogen wird.

Es ist halt mehr darum, dass du das als Service

bereitstellst innerhalb der Firma zum Beispiel.

Und sagst so, hier

ist jetzt mein Monitoring

zum Beispiel.

Das kann zum Beispiel erstmal ganz einfach

eine Wiki-Seite sein, wo drinsteht,

so kannst du dich in das zentrale

Monitoring-System einklinken, ohne dass du

ein eigenes Monitoring-System selbst hosten musst,

als Team von 10 Leuten zum Beispiel.

Was ja Sinn macht.

Und du hast ja ganz viele Sachen, weil du willst ja

eigentlich auch kein Source-Command-Management selbst machen,

CICD selbst machen. Das soll ja schon da sein,

das soll ja jemand machen.

Und das ist dann halt mehr, 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.

Also beides, ja.

Also letztendlich sowohl die technologische, dass das aber auch

sinnvoll ist. Ich meine, letztendlich

macht ja 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 noch die

unternehmensspezifischen 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 diese Internet-Services,

die dann jeder braucht oder sonst was.

Und idealerweise ist das ja so einfach wie möglich, das irgendwo

einzubinden, was an einer Stelle

auch dann das entsprechende Team dann

umswitchen kann, was dann von allen angezogen wird.

Also es gibt ja Sachen, Services, die dann sowas wie

APIs bereitstellen. Dann gibt es Firmen, die das gut machen.

Es gibt Leute, denen 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

Managed Ass

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 ich ändern muss.

Ich führe da jetzt als Merch-Request dann oder

Pull-Request die Änderung bei, die

ich jetzt machen möchte. Und das Team soll das

reviewen, 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 einen Ticket

aufmache. Und dann liegt das irgendwo im Nirwana

und ich weiß als Entwickler selbst vielleicht nicht,

wo das drin ist, obwohl ich vielleicht Ahnung hätte.

Ja, und 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. Genau. Ja.

Deswegen sind wir wieder bei einem People-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? Abreißen, neu bauen?

Die richtige Lösung habe ich jetzt auch nicht.

Aber erstmal muss das Verständnis da sein.

Das finde ich immer so erschreckend, weil

bisher hat es ja immer funktioniert.

Also ich sehe das tatsächlich so, wenn es schon so

in den tiefen Boden gefallen ist und so verzahnt ist

und so verknotet und so weiter.

Und 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

modern, neu, gut aufbauen,

die guten Leute dafür finden und das umziehen.

Ja, das ist jetzt

mehr so die Transformations-

Migrationsfrage dann, ne?

Aber erst muss ja das Verständnis da sein. Das Problem ist auch bei so ganz

großen Konzernen, dann hast du eine Transformation angefangen,

bist dann ein halbes Jahr stecken geblieben, bist dann auf einen Termin

rausgeflogen, dann machst du die nächste Transformation,

auf der Transformation, der Transformation, der Transformation

und so wird das Ganze ein sich ewig

in den

schwarzbeiß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 Bestätigten

und das Ermittlungsteam

musste dann

irgendwo eine E-Mail hinschreiben,

wo dann nochmal drin steht, warum, wieso, weshalb

und das mussten sie ganz am Anfang schon machen.

An Validierungsdokumente zu 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

auch 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 verschiedenen Management-Layer

und dann irgendwie war dann

ein Passwort dann verfügbar

für einen Zugriff auf ein Sharepoint-Laufwerk.

Ja. Toll, ne?

Dann denkst du ja so, Moment, ich drücke jetzt so einen Knopf

und dann kommt das Passwort da raus, 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

Team hat für Firewall-Regeln,

ist ja gut, erst mal 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

Word-Requests, Poll-Requests oder sonst was aufmachen,

nur von wegen, und da die Diskussion machen,

weil das dann nicht in E-Mails hängt

und man dann, wenn das geprüft ist,

dann auch direkt gemerged 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

Merger-Acquisition-Modelle hast, wo du halt einzelne

Firmenteile kaufst und verkaufst und die Welt rumschmeißt

und die alle auf unterschiedlichen Stacks

und Kulturen und Architekturen

sitzen und du dann halt das

irgendwie beherrschen willst, dass das schon

Ja, ich meine, kommt auch 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 größere Firma ist, wo fünf verschiedene Sachen sind

oder aufgekauft

wurden, sind mit völlig verschiedenen Stacks

die da aber irgendwie zusammengeklöppelt 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.

Ja, also das

Ja, und

genau das auch wieder, also

meine Erfahrung ist auch, ja, dass auch da

das Verständnis oft dann fehlt, wofür

sowas, was ist denn eigentlich ein Firewall? Das ist immer

sehr

enttäuschend.

Wenn der Firewall ist, dann ist er sicher.

Die große Waffe. Ja, dass Leute überhaupt gar nicht

verstehen, was sie da tun. Ja, der ganze

Verkehr geht alles über einen Knoten und dann

an dem Knotenpunkt wird geguckt und

genau entschieden, was durch darf und was nicht.

In die eine oder die andere Richtung.

Naja, aber was ist das denn?

Ist das ein Hardware-Gerät? Das ist 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 beiden Seiten. Ja, aber ich finde, das geht ja schon mal wieder

nochmal eine Stufe tiefer.

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 ja auf verschiedenen Ebenen

machen. Ja. 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 es ineffizient ist.

Hat er aber vielleicht mit den ganzen Leuten auch geredet.

Und wenn es gerade um Peoples-Management ging, dann

siehst du ein Rumlaufen durch das ganze Gebäude.

Vielleicht gar nicht so schlecht. Genau.

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 optimierst,

würde sowas unter den Tisch fallen.

Weil du hast von dem 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.

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 Platform-Driven

Mindset hat, denn 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. Selbst 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 der da gar

nicht durch und verbrennt sich und kommt dann

in Diskussionen über Effektivität oder

über Finanzen oder wie sehr rum dauert

das denn so lange und wie teuer ist das denn?

Und du hast halt auch da so

die richtige Form finde ich jetzt

schwer zu beschreiben, aber wenn Projekte am Anfang viel Geld

kosten und am Ende irgendwas bringen, ist es schwer

trotzdem die vielleicht durchzukriegen, als wenn du so eine

Salami-Taktik 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änderung reinzubekommen.

Einer der Gründe, warum ich sagen würde, es ist eigentlich überhaupt

keine gute Idee, mach es einfach neu,

in gut und versuch dann die Sachen anzubinden.

Also

du hast recht, eine Kultur, die richtigen

Leute an der richtigen Stelle und die richtige

Plattform-Architektur zu

finden, wie man überhaupt Services deployt,

das einmal 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 die ganze Forschung

Ja, genau. Oder hast du halt

das Problem, ich meine, gerade wenn jetzt

ein Konzern was anderes macht.

Also die verstehen überhaupt nicht, wovon du redest. Genau, eben.

Also das ist die Frage, kannst du das erwarten,

dass sie sich damit beschäftigen wollen?

Vielleicht kriegen die Menschen

noch hin zu unterscheiden zwischen irgendwie

dem Admin, der da im Keller rumsitzt und auf den Knöpfen

auf den Zömern rumdreht 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, also das sind ja die ganzen

Buzzword-Sachen, das wird gar nicht

so offensichtlich klar. Also

die meisten Leute sind auch gar nicht klar, dass Cloud

nur der Rechner von jemand anderem ist, irgendwie.

Ja. So, ne, das ist,

auch irgendwie komisch zu verstehen und wo

das Netzwerk halt hingeht und warum man das überhaupt alles machen

muss. Na klar, da gibt es auch Leute, die sagen,

warum steht das nicht bei uns im Keller, wo ich auch sagen muss,

ja, vielleicht gar nicht so immer die doofe Idee, vielleicht

kann man es ja auch da so verteilt hinstellen,

dass es gute Relevanz ist, aber das ist

ja,

das ist

keine allgemeingütige

Antwort auf diese

Ja, also ich meine, ich kann ja noch mal eine andere

Story erzählen von dem vorherigen Arbeitgeber,

wo ich war, da war ich aber extern in

einer anderen Firma verkauft, so konsultenmäß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

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 einen der 5000 Jira-Instanzen, die es also gab

und dann lag das erstmal eine Woche rum,

dann hat das irgendwie das Zielsystem, hat dann

irgendwer auf Approve gedrückt und dann lag das

nochmal ein paar Tage rum und dann hat es irgendjemand

implementiert.

Das hat halt ewig gedauert und mancher kam da irgendwelche

Projektmanager mit Schokolade an, so von wegen so

mach mal schneller hier.

Wieder bei der People-Komponente.

Aber eigentlich wäre es ja schon viel schöner, wenn die Teams

halt einfach selbst den, wie vorhin gesagt,

den Merch-Requests quasi

stellen, also sagen so, ja, ich muss jetzt von A nach

B hin und dann, wenn der

Zielsystem das approvet

oder die Person halt das approvet, dass es dann

automatisch gemercht wird und beziehungsweise

in der Zwischenzeit halt reviewed wurde und dann kriegst du

das halt theoretisch von einem Tag durch.

Also ich bin auch, also ich brauch zum Beispiel sowas,

häufiger mal und ich hatte auch überhaupt keinen Bock auf so

einen Prozess und ich hab dann einfach angefangen

mir so Requests

auszudenken, also echte Requests, ich brauch

da immer, ich hab da viel entwickelt und dann unterschiedlich

auch Sachen umgehängt, also Anführungszeichen Fehler

produziert, weil es muss ja doch anders sein,

also ich dachte, ich hab einfach so viele Anfragen produziert,

dass meine Privilege-Escalation

quasi gestiegen ist und ich mehr Verantwortung bekomme,

die Sachen selber zu regeln, 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 gesteuert 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's 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,

dass wenige, das sind ja politisch-taktische

Dinge, ja, um da irgendwie weiterzukommen,

ist das fürchterlich, ehrlicherweise.

Ja, vor allem, da gab's ja noch ganz viele andere Sachen,

ähm, und da muss ich

jedes Mal drüber denken, äh, denken,

wenn ich über DevOps rede, weil da gab's halt

Entwicklungsteam, die haben das halt entwickelt,

dann gab's ein AppOps-Team,

die haben nur die Anwendung

irgendwie betrieben und dann

gab's nochmal das Team, in dem ich war,

da ging's dann mehr um das

Betriebssystem und das, was gebraucht

wird, damit das AppOps-Team da irgendwas hindeployen

kann, dann gab's aber auch nochmal irgendwie so

einen, äh, ich krieg das nicht mal ganz auf die Reihe,

dann gab's aber auch nochmal ein QA-Team,

was nachgelagert war, die auch nochmal

einen eigenen Jenkins-Signal laufen hatten,

mit eigenen Tests und die aber nur

so End-User-Oberflächen-

Selenium-Tests gemacht haben,

die aber keinen Zugang zu dem

Source-Code hatten von dem eigentlichen Job,

das heißt, die sind bei der Änderung immer hinterhergelaufen.

Ja, okay, ist die Änderung unserer Tests kaputt?

Also, oh Mist, was machen wir jetzt?

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

Und der war, äh, total, äh,

demotiviert eigentlich die ganze Zeit,

weil er immer nur hinter irgendwelchen Änderungen hergelaufen ist.

Der konnte ja nichts anderes tun, so,

und eigentlich macht's halt nicht Sinn, das nachgelagert

zu machen, sondern, wie du vorhin ja auch meintest,

Shift-Left, möglichst frühzeitig das halt auch zu machen,

damit es Teil des Prozesses wird.

Ja. So, wenn das aber schon irgendwie so

von der Organisationsstruktur so

aufgebaut ist, dass man gar nicht mit den Team

oder Teams redet,

dann macht das irgendwie nicht so viel Sinn.

Ja, auch Security, ne, diese ganzen Regeln, diese Policies,

wo kommen die denn eigentlich her und so, warum gibt's die denn?

Ja, genau. Irgendjemand hat ja irgendwann gesagt,

das muss so sein. Der schon rennte.

Ja, und, äh,

aber noch, was auch noch spannend war, ist

dann halt das Team, in dem ich dann war,

war, äh, hat, hat halt mehr so

die, diese Middleware dann da betreut,

und da war, fand ich's halt spannend,

äh, da ist so ein, fast jedes Mal

jemand in der Nacht aufgeweckt worden,

ähm, weil irgendwas im Monitoring gemeckert hat.

Und was hat da gemeckert?

Voll oft, weil da irgendwie eine Festplatte

vorgelaufen ist. Mhm.

So, und da kommen wir jetzt wieder auf den Punkt

mit wegen, von wegen verschiedene Ziele,

weil, wenn ich als Entwickler

nachts aufgeweckt werde, dann will ich ja eigentlich nur, dass dieser

verdammte, äh, Warnung weggeht

und ich mich wieder hinlegen kann. Ja.

Äh, Loggen abstellen?

Zum Beispiel, ne, oder halt, äh, das Log-File,

äh, deaktivieren, weil halt irgendwie

Log, Logs total vollgeschrieben hat.

Ja. Ja, und was passiert am nächsten Tag,

passiert's halt nochmal. Und nochmal. Aber es gab halt

keinen richtigen Feedback-Channel zu das eigentliche Team,

ähm, um

das eigentliche, um den eigentlichen, weil

das ist halt irgendeine Anwendung, ne?

Also, ich hab auch schon so Sachen gesehen, also, Security-Regeln

total wichtig und alles zugemacht und so weiter,

aber dann brauchte halt jemand irgendein Monitoring, irgendein

Logging-Tool. Was hat er halt gemacht? Also,

nicht das Logging konfiguriert und dann irgendwie den Port,

den Portstecker 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.

Ja. Was viele vergessen.

Ja, muss man. Oder sollte man, wenn

man Shared Responsibilities hat, da

ist ja im eigentlichen Interesse, im eigenen

Interesse, dass du eben nicht

jede Nacht wach wirst.

Ja. Und

wenn du dann aber auch die Person tatsächlich

kennst, die jede Nacht aufgeweckt wird, dann

fragst du halt eher mal nach, warum eigentlich

wirst du aufgeweckt und erzähl dir dann ja 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

äh

redest, dann ist es

halt schon sehr, sehr schwierig. Ich hatte das auch gesagt, dass

ich irgendwie im Urlaub irgendwie so Zeugs machen

musste oder sowas, ne? 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 ausgehen. Aber

wenn man halt, wenn die sich halt damit ausgehen, dann sagen die mir so,

oh, da weiß ich gar nichts von. Das war 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. Ja, ja. Fängt halt an, ja.

Nee, du wirst dann, man wird ja auch nicht alle Probleme

damit los, klar. Also ich glaube,

das Problem ist, dass du die Leute zum Beispiel

gar nicht kennst, mit denen du

reden müsstest. Das ist auch ein Problem, ja.

Wenn man im gleichen Team ist, dann hat man das schon mal nicht mehr.

Ja, ja.

Das kannst du ja, du kannst ja auch nicht

alle kennen, so, ne?

Genau, also gerade wenn du ganz viele verschiedene Teams hast,

wir tun ja so, als haben wir irgendwie 100 Projekte gleichzeitig oder

sowas, wie will man denn da mit den ganzen Leuten, wie will man die alle

kennen? Nee, klar. Über Jahre vielleicht,

ne? Ja, genau.

Genau deswegen ist es ja auch wichtig, möglichst

den Dienst so einfach wie, 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, dass man, da 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, aber auch.

Welches? Ja.

Ja, aber das ist auch wieder eine

interessante Frage. Ich meine,

wir hatten 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

zum Beispiel. Ja, zum Beispiel würde ich da sagen, okay,

alles auf einer Kiste, alles drauf, alles läuft und jeder weiß,

wie es geht und dann ist gut.

Ich würde auch denken, dass

zum Beispiel dieses alles selber machen ist eigentlich

vielleicht, oder 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 dann ein Team das Monitoring macht, okay.

Ja, das ist irgendwie schon ein Nachvollziehen.

Also, Entschuldigung, wenn ich nicht gar unterbreche,

aber warum nicht einfach sagen, hey,

wir haben hier so ein Monitoring, bitte sorgt doch dafür, dass eure

Anwendung hier drin hinkommensiert, also

sowas wie Event-Streaming oder sowas.

Naja, gut, aber

sagen wir mal 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

Naja, aber vielleicht habe ich irgendwie dann irgendwann

so eine Liste von Sachen, die ich halt erfüllen muss. Ich muss halt irgendwie

Blue Hat und irgendwie dann das 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 Logs für

diese und diese Fälle, dann

wenn ich das machen müsste, dann würde

denen auffallen, wenn ich a, keine Logs poste

und auch wenn in den Logs irgendwas drinsteht, was da nicht

drinstehen soll. Und dann hätten die immer noch,

könnten die damit machen, was sie wollen, ja, dann wäre das

so diese Monitoring-Abteilung, die könnte da

inzidenz... Genau das meine ich ja.

Genau das meine ich ja. Das muss ja jemand

trotzdem zur Verfügung stellen. Bei größeren

Firmen halt eher als bei kleinen.

Bei kleinen

50-Leute-Firma ist,

das ist ja, da kannst

du ja einfach rüberlaufen, so gesehen, wenn du im Office sitzt

oder jemandem pingen, das ist jetzt nicht das Ding.

Aber es muss ja trotzdem jemand betreiben

und machen.

Genau, aber wenn man jetzt kleiner, 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

Trot-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 klein mein eigenes Ding

schreiben, was das halt, was mein Anwendungsfall

erfüllt und sonst nix.

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

das 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.

Oder bei eher kleineren. Aber das ist ja halt nicht

nicht etwas, was jede Firma braucht.

Und dann kannst du es halt lieber selbst betreiben.

Aber wenn es halt so um was Elementares