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.
Ä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
wie Source Code Management und die ICD geht,
was halt wirklich jeder braucht.
Ja, klar, so ein eigenes Git schreiben ist vielleicht nicht drüber.
Oder die eigene IDE 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 hat 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 Lock4J-Thematik,
dann fangen sie erst mal an zu gucken,
dann sagen sie, oh.
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 Monitoring, wie wir es vorhin halt hatten.
Und dann wenn man nur 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, das ist doch ein heftiges Modell.
Lass uns doch mal bitte den Katsch 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 Kunden,
zu irgendwie Wert für die Eigentümer,
also die noch Eigentümer.
Wenn sich das sagt,
dass man sich da eingehend ä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, das ist generell so, was das anstrengend ist.
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 schrottig 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 dahingesetzt haben,
wie es früher so war.
Das ist halt auch super nervig, ne?
Weißt du?
Pain.
Also Kulturprobleme, DevOps,
also eine Kommunikationsrolle, ja?
Oder war das da 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,
das Bewusstsein zu schärfen und so.
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 reinen Techies 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 da, so, oder?
Ja.
Und es muss halt trotzdem noch Leute geben,
die das betreiben.
Und das sind ja nicht unbedingt die gleichen.
Ich hatte ja jetzt letzte Woche
erstmal mit einem das Gespräch gehabt,
der meinte dann so,
ah, DevOps findet er irgendwie doof.
Und ich so, ja, warum denn?
Dann so, naja, so wie es bei...
Und dann kam der Zweitsatz,
ja, so wie es bei uns umgesetzt wird,
das finde ich doof.
Und dann so, ja,
wie wird es denn?
Dann so, ja, also es ist ein Großkonzern,
den jeder kennt.
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.
Das habe 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 ihr so,
okay, und 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.
Ja.
Schwierig, ja.
Genau, weil du musst ja die Anwendung entwickeln.
Du musst es dann auch wissen,
wie man das auf dem Kubernetes zum Beispiel deployt
oder 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 ein Object-Source anbinden
oder selbst hosten vielleicht noch ganz schlimmer.
Und dann musst du ja noch das Host-Code-Management
und das CI-CD-Tool noch bedienen.
Also mehr aus der Entwicklungstooling sitzen.
Dann hast du noch mal ein ganz anderes Tool
so aus Richtung Security vielleicht noch,
wo dann noch mal diverse Reporting ist.
Dann 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 Redis 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, ja.
Und wenn es dann so ein bisschen geshared ist,
dann geht das dann ja noch.
Aber wenn es wirklich so rein,
rein, rein entwickelt ist,
dann ist es halt schwierig.
Ja, ja, wobei ich,
ich glaube auch, das ist 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, ne?
Also Leute, die halt alles können,
wenn man eine,
wenn man eine sehr komplexe Umgebung hat,
das ist 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, ich, ich hätte,
ich hätte eine Lösung dafür,
einfach nicht so groß werden.
Das ist blöd.
Das ist ganz doof.
Weil,
Du meinst Microservices?
Nein, nee, ich,
Microservices?
Ja, ja.
Microcompanies.
Ja, Microcompanies.
Wissen wir jetzt,
Microcompanies.
Microsoft.
Namen haben wir dann schon mal.
Ja.
Jetzt brauchen wir nur noch ein Betriebssystem.
Ja, ist auch nicht mehr so micro inzwischen,
aber naja,
machen,
machen inzwischen auch andere Dinge.
Machen die noch Betriebssysteme?
Ja.
Ja, echt?
Ich weiß nicht so genau.
Ich meine, kein Betriebssystem.
Ja, wird das so kraftet?
Naja, gut.
Keine Ahnung, aber,
ja, also ich,
weil,
wenn man, wenn man,
wenn man halt klein ist,
dann kann man ja diese ganze Komplizität herausnehmen.
Dann macht man halt irgendwie kein Kubernetes,
ja, und macht man halt,
man braucht es eigentlich auch,
ehrlich gesagt,
dann wahrscheinlich nicht.
Ja, ein kleines Wort,
so wahrscheinlich auch nicht
die ganze Skalierungsthematik.
Genau, kann man 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 das nicht delegieren,
du kannst das nicht weg.
Quatsch, das wird denen aber erst dann auffallen,
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 Backup-Strategie anders sein muss,
weil da irgendwelche Sequels hin und her
gestauscht werden müssen,
weil irgendwas mit den Vaults passiert,
weil irgendwelche Versionsänderungen
beim Entfernen von irgendwelchen Migrationen
irgendwelche Probleme machen,
weil die Datenbank irgendwie trotzdem SLA hat,
der nicht,
dann,
oh,
ups,
man muss halt doch irgendwas von wissen halt,
ne,
das ist irgendwie blöd.
Ja.
Ja, ich meine,
das ist halt die Frage,
wo man die Abstraktion macht, ne?
Ja.
Ja, also der Konzern möchte jetzt ja immer gerne
so weit wie weg,
womö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 dann 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 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 hab genau einen,
ich weiß nicht genau,
was für eine Rolle der hat,
relativ hoch bei einer alten Bank ist,
wo du dann denkst,
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 erst mal drei Wochen warten,
bis er für irgendwas Zugänge hat.
Dem 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 ja auch dann,
wo ihr dann so,
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,
durchautomatisiert ist,
so von wegen so,
dass du, naja,
Zugang zu den entsprechenden Projekten brauchst
und bekommst,
die du halt brauchst,
dass dann 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 IDE ü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 dann auch,
wenn du lokal jetzt nicht nochmal gucken musst,
wie installiere ich jetzt überhaupt meine Entwicklungsumgebung?
Ja, aber was heißt ja,
wenn ein Problem ist,
dann muss ich ja mit einem 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
Codespaces
und da kannst du ja direkt in die Container reinfribbeln.
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 es abgeht.
Klar, das lernst du dann ja.
Aber du musst jetzt nicht jeden einzelnen Teil so richtig verstehen,
weil idealerweise kann man ja so gucken,
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?
Und wenn das sehr lange ist, ist es schlecht.
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 das, also einfach zu erklären zumindest.
Weil wenn ich jetzt irgendeine völlig veraltete
Python-Abhängigkeit habe,
muss ich erstmal wissen, dass sie da 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 ein spezielles Team,
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, wenn die das überhaupt wissen,
also ich meine, dann wollen die,
also ich kenne das so,
dann wollen die nachgucken,
welche Dependencies es denn gibt,
also so ein JavaScript-Thing oder sowas.
Dann schickst du ihnen halt 200.000 Pakete
und dann sagen die so, äh, uff.
Ja, genau.
Und dann gibt es halt zwei Optionen.
Entweder sagen die, ja, okay, dürft ihr machen
oder die sagen halt so, nee, 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 dem 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.
Also willst du deinen 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, das ist das Projekt gebaut, getestet
und irgendwo hin deployen.
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 nutzen 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,
weil du sprachst ja davon,
naja, wie kann man das jetzt machen,
das mal komplett durchautomatisiert zu machen hier.
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.
Und dann so, warum ist das das Beste?
Warum?
Und dann kommt halt so,
ja, das findet die meisten True-Positives
und sonst war es kein Comfort-Positives und so weiter.
Klingt erstmal gut.
Wo ist das denn eingebunden?
Ja, kurz vor dem Deployment.
Und dann haben wir halt wieder das Problem,
die Entwickler sehen nix.
Und da wollen wir ja wieder,
dass das DevSecOps dann entsprechend, ne,
DevSec und Ops gleichzeitig drauf gucken können.
Und das bringt halt nix,
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 ein Security,
wie der Security-Stand in dem Projekt ist,
zum Beispiel für den Main-Development-Bond,
den du dann da hast.
Das ist ja das Erste.
So, und dann siehst du zumindest schon mal so,
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 Merge-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 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, 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,
naja, du kannst das jetzt nur mergen,
wenn du auch wirklich keine neuen Vulnerabilities einführst.
Womit du halt schon so ein Quality-Gate mit reinmachst,
genauso wie du ein Quality-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 machst,
und ein Review 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,
wenn sie es dann halt schon sehen.
Und als Entwickler ist es dann so,
oh shit, ich brauche jetzt noch ein Approval,
eigentlich willst du das ja auch nicht.
Also du guckst 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 so manche Policies,
kann man ja dann setzen,
genauso wie man Approval-Policies halt eben setzt.
Aber die Frage ist dann,
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.
Test-Tag 4 auskampieren.
Genau.
Und das willst du dann mit Security-Scannern
ja zum Beispiel nicht machen.
Weil wenn da eine Meldung kommt,
dann kannst du fangen wegen,
so, ja, du hast jetzt hier so viele, so viele
Security-Voluntar-Policies 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 Team eingebunden wird,
das schaue ich jetzt mal einfach raus.
Ja, aber es gibt so Situationen.
Keine Ahnung, die Anwendung ist gebrochen,
weil ein Platte ist vorgedorfen oder irgendwas.
Das heißt, du musst sie redeployen,
weil ohne irgendwie anders konnte man das nicht fixen.
Nur ein Redeployment fixt das Problem.
Genau.
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-Agreement
und musst 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-Branche 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 du ja eh schon da,
auch wenn nichts reingemerged wurde.
Aber du willst ja, wenn neuer Code dazukommt,
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 das ja schon an der Stelle,
wo es gemerged wird, eingreifen können.
Ein anderes Beispiel sind zum Beispiel Software-Lizenzen.
So, weil ich hatte mal einen Kunden,
der hat dann ja gesagt,
so, ja, 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 geheißt,
die hätten das halt Open-Source machen müssen
oder sowas in die Richtung.
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 erst mal
ein halbes Jahr da rumentwickelt haben.
Und da sind wir dann halt wieder so,
naja, das muss halt jemand.
Ups, hat ja keiner gemerkt.
Ja, genau.
Und 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.
Und da sind wir dann wieder so aus dem Problem,
wo wir dann halt zum einen
die Kultur haben,
die Tools haben,
die das dann auch
das Ganze auch unterstützen müssen,
dass man bestimmte Sachen
auch entforcen kann,
zum Beispiel Approval Rules.
Weil wenn wir uns diese
Ex-Set-Lücke nochmal anschauen,
da hatten wir zum Beispiel
ja auch nochmal den Punkt,
dass ja in dem Fall
einfach Maintainer einfach rein,
oder der, der zum Maintainer
dann ernannt wurde,
dann ja da direkt reinkommittet hat
und keiner reviewt 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 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 nachdem,
wie viele du hast,
geht halt nicht alles durch.
Aber dadurch verminderst du
natürlich auch
natürlich die Risiken,
so wie es bei Security-Art ist.
Defense in Depth quasi.
Ja, ein paar Sachen fangen ja schon an,
dass du in dem Tooling
Zweifakt-Authentifizierung aktivierst
für Source-Code-Management.
Ja, ja.
So, das ist 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
oder zertifizierte Commits.
Ja, du kannst auch Commit-Signing 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 Code-Review.
Hast du nochmal, also erzwungen halt.
Ja, klar, klar.
Und das kannst du dann auf der technischen Ebene
ja auch erzwingen,
auch in kleineren Teams.
So, 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,
das ist ja Klassiker, ne?
Weil ich habe jetzt irgendwie seit,
die ganze Zeit sage ich mir,
hey, wir brauchen Reboost,
wir brauchen Reboost,
wir brauchen Reboost.
So, ja, ja.
Dann gibt es halt irgendwie so eine Kann-Bahn,
was Pipeline, Driver, Unsinn.
Und da bleibt es halt dann in QA stehen.
Also geht natürlich auf dann,
weil es halt dazu dann,
okay, weil hat noch niemand drüber geguckt.
Ja, ich habe es halt gebaut,
aber guckt mal jemand drüber.
Aber macht halt keiner.
Und dann bleibt es halt die ganze Zeit in QA stehen.
Das sind jetzt irgendwie so,
das ist halt Jahrarbeit.
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 dich nicht.
Das hält dich nicht das Deployment auf.
Aber es wird auch nicht Deployed.
Das wird aber auch nicht,
nein, es wird Deployed,
aber es wird nicht Reviewed, ever.
Und dann steht das halt die ganze Zeit im View.
Und irgendwann sagen Leute,
die Spalte QA ist aber so voll.
Schiebt das doch einfach auf dann.
Da hat er lange,
ja gut, so, zack.
Ist ja 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 die 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 ja 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 jetzt hält das mal den anderen Leuten
mit dem Zimmer mit.
Nein, nein, aber ich meine,
wie kann das 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.
Ich meine nicht das Budget,
sondern ich meine,
wo schlägt denn das,
auch wenn das schief geht.
Ja, bei dem Budgetknappding,
oh, das ist aber teuer.
Da kriege ich mir ein Ärger für, ja.
Ja, aber ich glaube,
das ist gerade ein guter Zeitpunkt,
über die DORA-Metriken zu sprechen.
Kennt ihr DORA-Metriken?
Bitte erklär uns das.
Ich habe es gehört,
aber gerne nochmal erklären.
Die DORA-Metriken sind ursprünglich vier,
mittlerweile fünf Metriken,
um DevOps quasi
auf technischer Prozessebene zu messen.
Metriken halt, ne.
Also die erste ist Deployment Frequency,
also wie oft deploye ich überhaupt
die Änderungen, die ich mache.
Und da gilt natürlich,
je höher die Frequenz,
ne Moment,
jetzt bin ich an die Idee.
Je häufiger du deployst,
desto besser.
Desto besser, ja, ja, klar.
Continuous wäre das dann, ja.
Genau, aber da ist natürlich auch die Frage,
na ja, nur weil du oft deployst,
hast du ja nicht unbedingt,
dass du gut deployst.
Ich habe ja nochmal ein Leerzeichen entfernt,
deploy.
Ja, das würde halt theoretisch
dann nach oben ziehen, oder?
Aber du kannst ja auch
schlechten Code, schlechte Qualität deployen.
Also ich würde zum Beispiel sagen,
es gibt einen Aspekt,
wo Continuous dieses Deployment gar nicht
so gut ist.
Das wäre zum Beispiel Sustainability
oder Green Development oder sowas,
weil es halt auch einfach viel mehr Strom frisst,
wenn die ganze Zeit deine Pipelines laufen.
Just saying.
Ja.
Naja, also wenn die Pipeline statt 10 Mal
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
Stromsverbrauch für den Run einer Pipeline.
Und wenn das so alle Leute machen würden
bei Amazon,
dann wäre schon einiges an Strom,
was da rausfällt.
Also ich weiß nicht,
wenn du beim Arbeiten ein Glas Milch trinkst,
dann kannst du...
Dann kannst du die Pipeline oft laufen lassen.
Warum ist die ineffizient?
Genau, also gucken,
wie lange dauert es überhaupt,
die Pipeline auszuführen?
Weil bei einigen dauert das ja drei Stunden.
Ja.
Genau, und das sollte idealerweise
nicht drei Stunden dauern,
sonst hast du ein Architekturproblem.
Ja, oder ja.
Aber ich glaube,
die Idee hinter den Deployment-Frequenzen
ist klar.
Wenn du häufig Änderungen deployst
und durchkriegst,
aber das heißt 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 du kannst ja auch die Änderungen
von vor zwei Wochen
nacheinander deployen.
Ja.
So, und deswegen hast du da noch
nochmal die zweite...
Lead oder...
Lead-Time, genau.
Lead-Time-to-Production quasi.
Also wie lange brauchst du jetzt
für die Änderungen,
die du jetzt gemacht hast,
damit die tatsächlich ausgerollt wird.
Und das geht aber mehr auf den Speed,
aber dann hast du halt auch nochmal
deine Was-was-und-mal-Fehlern.
Ja.
Und...
Meantime-to-recover...
Genau, genau.
Und die willst du dann ja auch
möglichst klein haben.
Also wenn...
Hotfixes, ja.
Genau, weil das ist halt so ein Beispiel,
du hast ein Security-Issue
und ich finde diese Lock4J-Thematik,
gut, wir sind im Python-Podcast,
aber das fand ich halt spannend,
weil es halt in der Tagesschau drin war.
So, ne?
Und dann siehst du,
da steht,
und die ganzen Teams
in den verschiedenen Firmen
fangen jetzt an,
irgendwelche zu gucken,
wo haben wir das denn jetzt irgendwo drin.
Und das ist schon mal gut und wichtig,
aber es hilft halt nichts,
wenn du...
Also diese Abhängigkeit,
die du dann halt hast
und auch vielleicht aktualisiert hast,
wenn das erst mal drei Wochen
oder drei Monate dauert,
bis es überhaupt ausgerollt ist.
Ja.
Und es ist,
egal welches Vulnerability,
es ist schön
und dann werden
komische Sachen gemacht
und 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.
Ja.
Und aus der Sicht
muss man das halt auch betrachten,
dass das möglich effizient ist.
Also wieder mit der Management-Sicht.
So, also...
So, ne?
Und da kommt dann halt
ganz viele Sachen rein
und jetzt fällt man natürlich
die vierte Dora-Metrik nicht ein.
Das eine war...
Ich will mal 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 kann auch.
Also Dora selbst
ist halt so eine Research-Organisation,
die mittlerweile zu Google gehört
und die haben jetzt dann halt auch
entsprechend den,
jedes Jahr diesen DevOps,
State-of-Devops-Report,
den sie rausbringen
und da,
da ist es dann auch entsprechend spannend,
auch mal reinzugucken,
wo das denn genau funktioniert oder nicht.
Genau.
Change-Failure-Rate.
Das ist mir entfallen.
Genau.
Danke schön.
Genau.
Wie oft das überhaupt zu Fehlern kommt.
Weil wenn keine Fehler passieren,
dann ist es natürlich gut.
Und deswegen muss man eigentlich
alle gleichzeitig betrachten.
Das hilft also nichts,
wenn du ständig
eine hohe Deployment-Frequenzierst,
aber ständig zu Fehlern kommt
und du ganz schön lange brauchst,
bis die Fehler kommen.
Und wenn die Services
wieder recovered sind,
dann ist das nicht so toll.
Dann willst du lieber
mit der Deployment-Frequenz
nicht runtergehen
und dann gucken,
dass du die anderen Metriken
auch richtig beziehst.
Und weswegen ich das jetzt
zusätzlich nochmal erwähne,
ist,
ich habe von einer Firma gehört,
die haben das für die Teams
dann als Zielvorgabe gemacht,
um deren variablen Bonus zu...
Und ich höre mal,
ich höre mal,
man muss das nicht unbedingt gut finden.
Man kann das noch 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 ja trotzdem
zumindest auf diese Metriken schauen,
so auch als Definitiven dann halt.
Aber da muss dann halt auch
von einer Firmenkultur
das auch irgendwie gemacht werden.
Aber da fängt es halt
bei deutschen Firmen,
finde ich, schon sehr stark drauf an,
also kommt das sehr stark drauf an,
wie überhaupt die Fehlerkultur überhaupt ist.
Darfst du auch Fehler machen.
Ja, ja, ja.
Weil das ist ja das Hauptproblem.
Immer wenn ich bei dir
auf die Mädchen gucke,
ist immer alles kaputt.
Ja, wenn da was gehen würde,
würdest du das gar nicht mehr sehen.
Nee, aber das finde ich auch interessant.
Du hast hauptsächlich quasi
deutsche Kunden sozusagen.
Oder hast du auch mal...
Siehst du da Unterschiede?
Weil ich glaube,
das gibt da wahrscheinlich
einige spezielle Probleme hier.
Ja, na ja, ich rede ja meistens nur mit...
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 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.
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 auch ein bisschen drauf rum.
So von wegen so,
viele Firmen haben überhaupt
noch nichtmals verstanden,
dass sie schon eine Software-Firma sind.
Auch wenn sie nicht mehr produzieren.
Ja, ja.
So und...
Das Einzige, was dir digital ist,
hat man nicht gelten.
Hat jemand gerade Autokonzern gesagt?
Ich sage jetzt keine Namen.
Ja, aber ja,
das ist ein großes Problem, ja.
Und da fängst du halt schon an.
So von wegen so,
ja, wir sind ja eine Hardware-Firma
und bla, bla.
Und dann so,
ja, so sieht eure Software auch aus.
Ja.
Also,
ich weiß nicht,
ich habe zu Hause
einen Wechselrichter für meine Software.
Ich habe eine Solaranlage
und wenn ich da auf die Software gucke,
dann denke ich,
ach so,
das sieht sehr nach Elektrotechniker-Firma.
Haben jetzt 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 noch natürlich,
haben wir jetzt einen Wert
in der Software,
innerhalb der Firma.
Also die Software-Entwicklungsteams
sind ja häufig auch
Inhouse-Sachen,
die ja nur für die,
innerhalb der Konzerne.
Und sie sind häufig
auf der falschen Seite
der Bilanz auch.
Ja, sie haben Kostzenter,
keine Kostzenter.
Genau.
Und wenn es halt intern ist,
dann ist halt erst recht
dann mehr Kostzenter.
Und wenn es dann Kunden ist,
ist es ja nochmal
ein bisschen was anderes.
Aber da siehst du ja manchmal,
manchmal sagen dann Kunden
irgendwie was.
Und das ist ja,
das und das ist total wichtig
bei uns.
Und bla, bla.
Und dann google ich das
und dann so,
weil es dann ja manchmal
so Headlines sind,
weil es ein großer Konzern ist,
den 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 typisches internes Tool.
Kurz Firmennamen
und Corona eingetippt.
So, hm,
Massenausbruch bei bla, bla.
Halbes Jahr,
nachdem Corona schon lief.
Und dann so, hm,
ja, vielleicht kam das danach.
Nicht vielleicht,
nicht 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 müssen,
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,
in einer Fabrik halt bist,
zum Beispiel,
dann ist es halt total wichtig,
dass die Software
schnell entwickelt wird
und schnell auch irgendwelche
Fehler entwickelt wird.
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, hm.
Aber, ne,
das ist auch nur so ein Beispiel.
Deswegen fand ich es auch
irgendwie so spannend zu sehen,
als dann diese
temporäre
Mehrwertsteueränderung war.
Da lag ja zwischen
den Beschluss
und der eigentlichen
Implementierung
oder der,
den,
ja,
der Umsetzung
lang irgendwie
drei oder vier Wochen.
Klar, es wurde vorher schon
irgendwie diskutiert
oder sowas.
Aber im Endeffekt
lag es zwischen Beschluss
und,
und dem 1. Juli,
glaube ich,
war das 20,
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.
Ja.
So,
und das haben die
ja 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 weiter.
Und dann halt,
deswegen muss das halt
wieder ganz oben rein.
Genauso,
9-Euro-Ticket
hat super funktioniert,
wenn man es denn möchte.
So.
Und dann kam
Deutschland-Ticket,
das hat dann wieder
ganz lange gedauert.
Du meinst das Management,
ja.
Deswegen,
wenn man es wirklich möchte,
dann geht es das schon.
Ja,
wenn man Durchsetzungskompetenz
hat auch, ne?
Ja, genau.
Du hast eben nochmal
den CTO gesagt
und ich glaube,
hauptsächlich deswegen
habe ich gesagt,
vielleicht nicht immer
nur das CTO ist,
Durchsetzungskompetenz
bei den CTOs
im Vergleich
zu ihrem Vorstand,
zu ihren 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 Konzerten,
wie viele davon haben denn
ein CTO bitte?
Oder,
die sehen sich ja gar nicht.
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 wir schon dabei sind.
Ja,
wie sind die auch intern,
also haben die von an sich,
ne?
Also,
der CEO denkt das also so,
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.
Also,
es ist halt oft das Problem,
wenn das Kerngeschäft
eigentlich gut lief,
ne?
Dann hat 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 bis dahin,
du brauchst ja eine gewisse Zeit,
um halt so hoch zu babbeln
in einem Konzern,
und dann bist du dann halt da
irgendwie,
und du überlegst dir jetzt,
okay,
wenn ich das tue,
was nötig wäre,
dann werden mich alle hassen
und vielleicht werde ich gefeuert
und mein goldener Handschlag
wird nicht ganz so golden,
sondern in Silber,
oder ich überlebe die nächsten
fünf Jahre,
das mache ich in Rente
und dann ist alles super
und alle lieben mich
und mein Nachfolger
hat das Problem,
ja,
dann ist relativ klar,
was man macht,
also ich meine,
ja,
und du machst ja auch
die mächtigsten Leute,
die auf dem Geld sitzen,
zum Feind intern,
also,
das sieht man auch übrigens
an Staaten sowas,
das ist leider nicht
so ein Konzern,
wie man halt so,
ja,
ich finde das witzig,
weil ich musste gerade
an einen Kunden denken,
weil da war es auch so,
mit dem hatte ich vor zwei,
drei Jahren
so am ersten Mal gesprochen,
da war ein Typ da,
der total blockiert hat,
der hat gesagt,
nee,
das ist zu viel Auffahren
und Migration
und überhaupt,
also so von
Bitbucker Jenkins
und nochmal Jenkins
und sonst was
aufgekloppt zu migrieren halt,
ah,
und das ist so teuer
und bla bla bla
und dann passiert der Nächste
ein halbes Jahr später,
der war in Rente.
Plötzlich passiert was.
Ja,
ich fand,
wo du denkst,
warum blockiert er das Ganze,
kann das völlig egal sein
und die ganzen Entwickler
sind dann so,
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,
also da gab es dann
ja klar,
der hat dann auch
ein Interesse daran,
das.
Ja,
genau,
aber das ist dann halt
irgendwie so spannend.
Ja,
aber es ist halt die Frage,
ob dann auch nur Buzzwords
durch das nächste Dorf
getrieben werden
oder dann,
wo halt dieser
Transformationskrise steckt,
ne,
nach Transformation,
nach Transformation.
Also 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,
weil,
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
Surf ü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 das kann
halt auch sein, du baust jetzt was Neues auf und
da schiebst du alle nach und nach rüber.
Was wolltest du sagen, es wäre dein
Kultur,
deine Kulturempfehlung?
Management-Schlag.
Das ist halt wieder
die Frage, wen stellt man diese Frage?
So, ne? Also
wer hört hier gerade zu und wer denkt,
also ich glaube, viele, die werden hier zuhören,
denken so, ja, ich meine, das hatten wir ja jetzt schon
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 Over-Engineering
und weniger zu KISS.
Du meinst, das
NIH-Syndrom ist Over-Engineering
und das, na?
Ja, weil wenn ich selbst für mich gucke, so,
ich habe früher in meinem ersten Job
habe ich ganz viel Jenkins-Krams
gemacht, weil halt total viel, total struppelig
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
draufkommst, 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 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 sich irgendwas an den Paketnamen
geändert hat. Aber dann hat es halt gebaut.
Und dann war es halt gut.
Und ich musste nicht, und ich konnte direkt
nachvollziehen, auch für alle anderen
Entwicklerkisten quasi, was sind die
Abhängigkeiten, die ich zum Beispiel installieren muss, damit ich
den Build-Prozess da erstatten 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 reingeschickt haben.
Genau. Und eigentlich war ich ja Entwickler. Das heißt,
ich wollte ja eigentlich,
sollte eigentlich Software entwickeln, so in die Richtung.
Dafür hatte ich aber keine Zeit gehabt, weil
ich eigentlich nur daran war, die ganzen
Entwicklungs-, ja, den Ops
aus den DevOps-Tooling-Krams zu machen.
Ja. Und wenn ich
manchmal dann sehe, was für komplexe Strukturen
dann mit Riesenteams, mit Jenkins
zum Beispiel, gebraucht werden. Ja. Das ist halt
damals, vor so zehn Jahren,
oder vielleicht so sieben, acht Jahren,
sechs, sieben Jahren vielleicht noch sinnvoll gewesen,
das mal alles skalierbar irgendwie
zu machen. Aber mittlerweile gibt es halt andere Tools, die es halt
einfacher machen. Und das ist halt auch mal die Frage,
wie viel brauchst du da jetzt von
wirklich? Ja, also die Gefahr,
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, premature
optimization is the root of all evil
Ding. Was aber manchmal halt doch Sinn
macht, das doch zu durchdenken und daran zu
denken, dass es Fälle geben kann, wo ich
vielleicht reinwachsen möchte und vielleicht dann einigen Stellen...
Das ist ja immer noch so die Quick-In-20-Anlass.
Ja, ich meine letztendlich auch eine Frage von
Build versus Buy dann ja auch, ne?
Was willst du? Weil
deswegen gehen auch viele zur Cloud.
So, 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 für eine Empfehlung
ist halt echt schwierig.
Ja, aber du hast jetzt aber eigentlich nur über Technologie
geredet und über, da vielleicht ein anderes, aber
über so diese Kulturempfehlung.
Also hat das was mit Open-Mindset
zu tun, mit Gross-Mindset zu tun, mit
Customer-Centric-Mindset zu tun?
Ding, ding, ding, ding, ding.
Keinen dieser Begriffe
jemals gehört.
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.
Wenn man den gar nicht hat, aus welchem
Grund 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 normal
die ganzen Leute da sitzen.
Aber ich glaube, das wäre eine HR-Management
strategische Entscheidung, würde ich sagen, würde important
und auch das ist so ein Transformations-Change,
den man machen kann, wenn man sich das traut,
der hart ist, aber das muss man halt, gibt es dafür
Matrix, I don't know, ich würde sagen ja.
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 Gesamtenfekt für die ganze
Firma ausmacht, keine Ahnung. Ich hatte
keine Ahnung, wie das hindeployed 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 ganz so
funktioniert. Und
so visionsmäßig.
Okay, aber sind wir vielleicht, also ich würde sagen,
also für mich, wenn es jetzt so zwei
Sachen, also eins der wichtigen Sachen ist halt so,
ich glaube, du meinst was dasselbe ist,
why, also warum, value?
Yeah, genau. Also warum mache ich den ganzen Scheiß hier,
überhaupt, hat das irgendeinen? Also
dann gibt es halt dieses Problem, dieses
Programming for Pleasure,
bei den Devs, weil warum man das dann, wenn man da
keinen externen Value drin findet, so,
also weil die Kundenvalue einem überhaupt nicht interessiert
oder so, dann macht man es halt um der Sache
willen, was also aus Management-Perspektive
dann eine blöde Entscheidung ist. Und das Zweite ist
natürlich Monetary Incentives, ne?
Genau. Ja, und
kann man das balancen?
Naja, irgendwie
ist das 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 ich angesprochen werde,
wenn ich so einen Pulli hab, wo ein GitLab-Logon
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 unbedingt bei allem 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,
ein US-Cloud-Provider zu sein, wo ich halt auch ein paar Leute kenne,
wo der Sinn und Zweck
deren Jobs ist, also meines
äquivalentes Jobs eigentlich nur ist,
mehr Workload, den Kunden dazu zu treiben,
mehr Workload in die Cloud zu schieben.
Und 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 Business-Modell ist halt einfach
ein bisschen anders und dann, ja.
Ja, genau, genau. Und das finde ich dann aber auch
persönlich 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 er es laufen lassen möchte, ne?
Ja. Also, weil mich fragen dann auch so Leute,
naja, willst du, wie wenn
GitLab selbst betreiben? Dann sage ich, okay, dann
mach halt selbst. Und, ja, oder wir wollen
einen Managed-Service, dann 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, SaaS-only,
US-only oder sonst was.
Ja, aber ich bin immer so,
irgendwie, 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,
es gibt zum Beispiel Dinge, wo ich
nicht mit Kunden, also nie
mit Kunden spreche, nicht mehr weiß,
wer die sind. Das finde ich total
schwierig, also
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
in anderen Bereichen nicht mehr so sein, dass man
gar nicht weiß, was man da eigentlich tut.
Und das ist...
Also es gibt ja mehrere Probleme, glaube ich,
auf einmal. Also ich glaube, du hast gerade noch mal
von den Cloud-Anbietern zum Beispiel gesprochen, also ein
Beispiel jetzt, man kann sich ja auch
relativ viel damit kaputt machen, also diese
...
Beientscheidung zu treffen. Du sagst,
sie ist wichtig. Beispiel jetzt, ich weiß nicht,
VMware oder sowas, die auf einmal jetzt ihre
Lizenzkosten irgendwie...
Alle Leute kriegen Herzrasse
und dann alle Maschinen laufen auf, wir können ja nichts machen.
Ja, verdammt, müssen wir jetzt schlucken für die nächsten drei, vier
Jahre und...
Ja, aber da ist auch wieder irgendwie selber Schuld
so ein bisschen, ne? Und ich meine,
dieses Böse, also wer jetzt
irgendwie
große Schmerzen hatte mit dieser Geschichte, der sollte sich gut
überlegen, ob er all in Cloud-Native, weiß ich nicht,
reflektiert, weil das kann
ganz genauso wieder sehr, sehr schmerzhaft
werden. Also auch LLMs,
ne, wenn man sich beinbindet mit seiner
neuen, wie nennt man
das, Analytics
Dings-Infrastruktur
Insights, lalala, keine Ahnung, ich wollte die ganzen
Produktnamen jetzt nicht aufzählen.
Egal, aber ja, natürlich, also das
ist, ja,
das ist ein Problem.
Aber um noch mal auf deine Frage zu
kommen, bezüglich was man da, was meine
Empfehlung ist, ein Punkt, den
worüber man DevOps ja auch anders betrachten
kann, außer die Doro-Metriken, ist ja auch noch das
CALMS-Modell.
Hast du auch in deinem Buch direkt am Anfang, glaube ich,
erwähnt. Ja, genau, weil
das ist dann ja die Buchstaben
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
es das halt ist, was man halt in der Technik... 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 sind aber wenigstens automatisiert.
So, wenn
dadurch Fehler passieren, du aber
eine schlechte
Kultur in dem Sinne hast, dass du gar keine Fehler machen darfst,
was alles sehr, sehr gefährlich ist.
Wenn du so einen Prozess-Wald hast, wie willst du den überhaupt erst verstehen?
Weil du kannst den ja quasi nur optimieren,
ja, also so ein Prozess, der kacke ist,
wenn du den durchdrungen hast. Und ich glaube,
das alleine, 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 Kunden-Perspektive.
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 drüber sind.
Ja, ich meine, wenn wir über Kultur sprechen,
das 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 Postmortems
zum Beispiel, was,
dass wir überhaupt mal aufschreiben, was ist
überhaupt ein Fehler passiert, was war da eine
Rotkurs-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 übertreiben,
der, der, 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 wie möchten wir
und viele machen das ja auch,
US-Firmen zum Beispiel
machen das ja auch öffentlich, aber
wenn Fehler passieren
und darüber kann man
immer noch viel lernen. Also mein Lieblings-
Beispiel ist, das war noch lange, bevor
ich bei GitLab angefangen habe,
kennen vielleicht die einen oder anderen noch,
da hatte 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 Promo-Way 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 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 halt zum Beispiel auch ein Problem, dass die Backup
verschiedene Backups-Methoden
gab, die aber alle nicht funktioniert haben,
weil die nie jemand getestet hat.
Ja, klar, genau.
Viel aus meinem Umfeld, die ich dann
also kannte, die haben dann erstmal angefangen im Unternehmen
zu gucken, ich glaube, ich teste mal
meine Backups.
Ja, sollte man tatsächlich machen, also
ja. So, und das sind
halt so Sachen, wo du dann ja auch von anderen Firmen lernen
kannst, so, ne? Genauso wie
du von der XZ-Lüge lernen kannst, so was
kann ich davon vielleicht in der Firma adaptieren oder so was
dann halt, ne? Und
und das trauen sich ja schon viele nicht,
wenn Fehler passieren.
Wie, wie, 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
NIST-2-Direktive oder sowas gibt,
wo ja auch
das Management
verantwortlich gemacht wird,
wenn du,
als Firma
einkletterndes Sicherheitsrücken hast oder
sowas. So, das heißt, das 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 als Automotiv-Sache, da gibt es
nochmal bestimmte Regularien, wo eingehalten werden müssen.
Aber auch das, das ist ja
eher schlimm. Aber das ist ja meistens nur, ja,
vor allem ist das halt schlimm im Sinne von,
und das hatte ich auch von,
von einem Autokonzern gehört, so von wegen, da hatte
ein, ein, und Compliance-Regel haben wir
eigentlich schon so einen Sinn, warum es diese gibt. Und häufig
sind es halt irgendwelche Excel-Listen, wo du einen Haken machen kannst
oder so eine Conference-Liste oder sowas.
Und einer hatte überhaupt nicht das Problem
gesehen, den Haken
zu machen, habe ich getestet. Ohne irgendwie
den Nachweis zu haben, dass er es wirklich getan hat.
Und viele Sachen kannst du ja schon automatisieren
und so ein Reporting machen,
was vor allem bei dem so Banken-Finanzumfeld
kommt, kam nämlich
bei mir die Frage nämlich ganz oft auf, so wie kann
ich dokumentieren, dass es auch
wirklich ein Change, den gemacht wurde,
dass es auch wirklich zwei Leute
reviewt haben, zum Beispiel.
Wer reviewt denn? Der eine von den anderen will da
niemanden in den Schienbein treten, weil man Ärger
kriegt, wenn man irgendjemandem was aufhält.
Also da, wenn du, wenn du das
reviewst, dann bist du ja auch betroffen. Also sozusagen
da hast du schon ein Interesse auch,
würde ich jetzt mal so vermuten,
dass, dass da, dass dir auffällt,
wenn das wirklich ganz kaputt ist.
Naja, aber wenn das Schlimmste ist, dass 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 zusammen,
hängen muss, dann ist auch wieder die Frage.
Ja, ich meine, aber, ich meine,
mein Blickwinkel jetzt ist
jetzt mehr so, naja, ich hab jetzt
einen, ich hab jetzt bestimmte
Regeln, die müsste ich auch umsetzen, die müssen
dann auch gemacht werden und die muss ich 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 dann gar nicht wissen,
wer da was committed hat oder sonst was,
oder welche sichern Sachen im, also Audit-Trail
Thematiken, wer hatte wo Zugriff
oder sonst was. Ja.
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 folgendes, 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, das tendiert
dann auch, also ein
Modus, in dem das dann schief geht, ist halt,
dass man das Ganze zu so einem
Theater verkauft, was halt
tatsächlich die Sachen, die eigentlich die Security noch schlechter
macht. Genau, du hast halt Sachen, die auf der Bühne
als Exit-Tabelle vorgestellt werden, wo irgendwelche Leute
irgendwelche Haken dran machen, wo dann
halt gar nicht klar ist, was da drin ist. Und das Beispiel
mit dieser Paketliste, 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 irgendjemandem
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
Klos machst, geht's halt auch nicht. Oder du bist halt auf irgendwelchen
ganz Legacy-Geschichten, wo
dann auch eigentlich die CVEs dann alle offen sind,
weil du nicht hinterherkommst, damit die Sachen zu patchen.
Du musst halt irgendeinen Tod dann da sterben.
Ja, ja, irgendwas hast du immer, ne?
Aber worauf ich noch hinaus wollte,
ist, dadurch, dass
du ja die, also weil
ich ja meinte, so naja, für einiges ist es ja einfach
nur was abhaken, ohne was wirklich zu testen.
Da gibt es halt Leute, auch Führungstreffe, 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 vom Auto
Firmen kommt, wo du dann denkst, so, hm,
also ich möchte schon wissen, dass wenn ich die Bremse
drücke, dass du auch wirklich bremst.
So, das soll auch, und
dafür gibt es ja Regulation. Systemfehler, Systemfehler,
Systemfehler. Ja, genau, oder
Bootloop oder sowas sonst was.
Weil das soll ja schon funktionieren, das soll ja auch
getestet werden, so.
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 ja immer darauf an, glaube ich, welche Änderungen,
von welchen Ä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. Ja, ja. Oder für
wo auch immer du da was tanken kannst,
laden kannst. Ja.
Das macht halt schon einen deutlichen Unterschied.
Ja, genau. Oder? 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 Chaos-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 halt
machen.
Aber, ja. Also ich würde
sagen, nein. Ich würde sagen, Prozess hilft
nicht. Naja, die Prozesse sind doch gut sein.
Ja, genau. Also ein guter Prozess
hilft also nicht irgendein.
Aber woher weiß man denn
überhaupt, wenn man selber nur eine
begrenzte Ahnung von den Dingen hat, was ein guter
Prozess ist? Ja, schwierig. Weil diese
Informationsaspekte, die, also du,
gerade wenn du bei unbekannten 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 du gelöst hast. Das heißt, du musst irgendwie rum
experimentieren, ja. Und du kannst ja, also
tolles Beispiel jetzt in der Ökonomie.
Du überlegst dir irgendwie so eine Policy für
so ein Land, wie es aus irgendeiner Schuldenfalle rauskommt.
Entschuldigung, ich muss das falsch nicht gerade nehmen.
Und dann fängst du halt an, mit so einem
Erfolg rumzuexperimentieren, was denn eigentlich
alles funktionieren könnte. Und dann hast du vielleicht so ein paar
Spielbälle. Das dauert dann halt zehn Jahre, bis du den Effekt siehst.
Dann merkst du dann zehn Jahre später so, ups.
Keine Ahnung, BIP ging runter.
Lebenserwartung ging
runter.
Dumme Idee.
Mein Punkt war ja auch mehr, dass diese
Compliance-Thematik, die es ja schon in der
Finanzbranche gibt,
dass diese halt eingehalten, da hat ja schon
jemand drüber nachgedacht. Ich weiß jetzt nicht alle
Details dazu. Ja gut, aber mein
Punkt ist, über Dinge, die du
noch nicht weißt, kannst du ja gar nicht so gut
nachdenken, dass du die eingrenzen kannst.
Das ist ja nochmal ein weiteres Problem. Und die Frage ist halt,
was dein Ziel ist,
auf was optimierst du dann?
Willst du überhaupt ein Auto haben, das fährt, in dem Beispiel, ja?
Ja.
Oder möchtest du halt dann die
Veränderungen beschränken? Und das ist, glaube ich,
das ist halt ein Dreieck,
in dem du keine
Sicherheit durch Prozesse kriegst, oder durch gute
Prozesse kriegst, weil die Prozesse gar nicht gut...
Das ist ein stetiger Prozess. Ja, genau.
Das ist dynamisch. Ein bisschen
Schwund ist immer, sagt man manchmal. Wie ist das?
Und du musst halt irgendwie ein Risiko
eingehen. Und du musst halt eigentlich hingehen und eigentlich,
finde ich, diesen
Continuous Improvement-Prozess
berücksichtigen. Was auch wieder so Neugier-
Tour-Ding ist.
Wo wir jetzt dabei 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.
Und das Problem ist auch, Discounts halt Leute haben,
die einfach total neugierig sind, aber die keinen Bock mehr haben,
weil der Rest irgendwie von
Values oder sowas, die immer wieder gegen
jemand fahren ist. Und das wäre halt auch blöd.
Ja, also, ich meine,
ich finde es auch generell schwierig zu erklären,
wie DevOps als Transformation gelingen kann.
Weil es halt sehr, sehr, sehr individuell
ist. Weil ich hab dann,
also, ich saß dann vor diesem Kapitel in dem Buch,
als ich das schreiben wollte, und da dachte ich so,
ja, ich könnte jetzt ganz viele verschiedene Sachen erzählen.
Aber wie das jetzt richtig geht,
keine Ahnung. Dafür gibt es halt so viele
Ja-Aber-Sachen, weil es sehr stark
von abgehängt, was ist das für eine Firma, wie wurde
schon bisher gearbeitet, was sind
das für Führungskräfte,
wie sind da die Silos,
wie sind da die Prozesse,
und... Das ist spannend, weil
diese Parallele zur tatsächlichen Ökonomie
da relativ ähnlich ist. Weil auch
DevOps so eine Art Prozessstruktur
ist, die man auf ein Ökosystem
mit ganz vielen Stakeholdern quetschen
möchte, um so Durchlauf-
Dinge zu, ja,
ich meine, optimieren, Incentives an der richtigen Stelle zu
setzen, ja, also um das Ergebnis
zu verbessern.
Und die
Königsdisziplin in der Ökonomie wäre jetzt so was
wie tatsächlich zu versuchen, alle
Faktoren, die es gibt, selbst wenn es 295
sind, zu identifizieren
und auf jeden einzelnen
Kosmos, was dann
keine Ahnung, ein Stadtbild sein kann
oder halt eine kleine Software
runterzubrechen. Die Frage ist halt,
das ist halt teuer und aufwendig.
Und an welchen Stellen hört man damit halt auf, das
da reinzustecken, das Geld, die Zeit?
Ja.
Ja, und letztens wäre, ja,
warum ist es wirklich so teuer?
Ja.
Also, sag mal so,
ich glaube,
das, also, auch, also, wenn man
jetzt guckt, wie sieht es denn im Alltag oft aus,
dann ist das, glaube ich, nicht so schwer,
der Optimierungspotenzial zu finden. Es ist jetzt nicht so,
dass das irgendwie ein totales Mysterium
wäre, was man da verbessern könnte, sondern es ist
eher so, häufig
habe ich das Gefühl, dass es irgendwie
springt einem schon eher ins Gesicht, was da nicht so gut
läuft. Und dann
ist das eigentlich auch nicht so, dann kannst du auf jeden Fall
lokal Änderungen, wie man es global
macht, keine Ahnung, aber lokal lassen sich
relativ leicht Dinge verbessern. Ich glaube, das ist aber nur
dann halt, wenn das Chefsache ist und wenn du
halt diese Durchsetzung halt von oben
kriegst, um diesen Prozess zu ändern.
Ja, ich meine, wenn ich in einer kleineren Firma bin,
sagen wir mal so 50, 100 Leute oder sonst was
und ich bin da zuständig für so
Entwicklungstooling oder sonst was drumherum,
dann kann man schon mal gucken, okay, brauche ich jetzt überhaupt
diese hunderte Tools, die ich da so drin habe.
Weil dann gibt es dann tatsächlich so, ich meine,
das hatten wir ja gerade kurz ja auch schon angerissen, dass man
halt zwischen den ganzen Tools springt und die sind
alle nicht miteinander verknüpft oder
man ist immer nur daran, irgendwie die Plugins zwischen
den verschiedenen Tools dann zu fixen.
Was dann auch super anstrengend sein kann. Klar, ist nicht
alles perfekt, aber wenn man halt schon
mal, wenn ich manchmal so sehe, wie viele
Tools da sind, also
was ich gerade ja noch
ignoriert hatte, war ja sowas wie Package Registry,
Container Registry und
Dependency Proxy
und dann haben eigentlich ja für alles
wirklich ein eigenes Ding und
was zwangsläufig
manchmal auch nötig ist und
dann gibt es noch für CD ein eigenes Tool und dann gibt es
noch ein Feature Flex Service.
Das ist manchmal schon sehr, sehr, sehr komplex und
dann wundert mich dann nicht, dass einige kapitulieren
und sagen so, ich kann jetzt nicht alle
Tools, die sich auch alle drei Tage
ändern. Da kannst du halt nicht am
Ball bleiben, wenn du nur fünf, sechs Leute im Team hast
und das alles betreiben musst.
Und für einiges gibt es auch keine Lösung.
Es gibt ja nicht unbedingt, also GitLab
wird halt schon zum Beispiel vieles abgedeckt,
GitHub wird auch vieles abgedeckt, aber du hast ja
trotzdem nicht alles da drin, weil in einigen
Use Cases brauchst du dann halt irgendwie was.
Weil du brauchst ja immer noch, keine Ahnung,
Terraform und Infrastrukturen
und sowas
in die Richtung.
Aber
ja,
meine Empfehlung ist mal gucken, dass man das Tooling
drumherum halt möglichst so einfach gestaltet,
dass man nicht
zu sehr abgelenkt
wird von dem Tooling. Also lieber
mit den Werkzeugen arbeiten, nicht
an den Werkzeugen arbeiten, als
reiner Entwickler jetzt.
Weil das ist, glaube ich, so mit das Hauptding,
was sich, wenn man DevOps als
Rolle bezeichnet, DevOps-Engineer-Rolle,
da sind ja häufig,
na gut, darüber können wir jetzt auch noch mal eine Stunde
reden, was ist ein
DevOps-Engineer? Auch wenn man jetzt mal
von, es sind ja häufig ja die Leute, die dann
irgendwie von allem etwas können, aber nichts ordentlich.
So ein bisschen wie ein Full-Stack-Entwickler.
Wo dann halt auch mal die Frage ist, okay,
was,
wie ist da die Teamstruktur? Idealerweise ist
ein DevOps-Engineer halt der
Mensch, der halt in die Teams geht und
das die, die
DevOps zusammenbringt.
Und halt sowohl auf kulturell
als auch die Tools dann noch ein bisschen
verdrahtet miteinander.
Das ist ein
Schweißer, der die Sachen zusammenschweißt,
oder ist das jemand, der nur die Knoten macht, oder
dann, naja, man lernt da verschiedene mit.
Und dann, wenn sie fertig ist, ist er fertig, dann
kann er halt wieder raus. Soll da keine eigene Rolle
halt in einem Team sein, so, ne, grundsätzlich.
Aber es macht schon Sinn, dass es ein
Team gibt, die dann halt Pipeline-Bausteine
baut, wie,
weil eben
Deployments auf Kubernetes gemacht werden sollen,
zum Beispiel, ne. Und das halt
unternehmensspezifisch
oder sowas ist dann.
Also, deswegen, da kann man schon
schon vieles machen, aber es ist halt sehr
abhängig von der Firma,
Organisation, wie es da so mit
reinspielt.
Also, Python muss man auch deployen.
Ja, man muss nicht so viel bilden, zum Glück.
Oder, naja, kommt drauf an. Es gibt natürlich
Sachen, die man auch bauen muss,
aber das ist eher...
Ja, bauen, testen, Security-Checks
drüberlaufen lassen.
Das gibt's halt auch alles so, ne. Auf der
Tooling-Ebene muss halt auch irgendwie deployed werden,
aber es ist halt, aber darum geht's mir ja auch,
ne. Der Toolstack sollte
möglichst einfach gehalten sein, dass man eben
nicht so viel drüber reden muss.
Das ist bei Python oft nicht ganz so. Also, wenn du halt
zum Beispiel dieses ganze Linting drumherum
definieren musst und das Ganze, wo kommen die Pakete
alle her, definieren musst, das ist das schon nicht
unkomplex für jemanden, der damit
anfangen möchte. Das ist was anderes,
als ob du hier so eine voll typisierte Sache hast,
die einfach beim Compilen dann auf die Schnauze
fällt.
Ja, weiß ich nicht.
Aber so aus DevOps-Sicht ist es erstmal egal, oder?
Ja, ist das was?
Ja, also,
Unterschiede gibt's ja eh immer, so, ne.
Also, dafür hat Python halt
eine relativ schnelle Zeit, ne, weil du kannst halt
irgendwas bauen, das funktioniert halt schnell. Fällt halt auch schnell
auf die Nase.
Ja, fällt da so viel
auf die Nase? Wenn man's falsch macht?
Ja, gut. Das kannst du bei allen
sagen. Ja, gut, aber kann man bei
so einem voll typisierten Ding viel falsch machen? Das ist halt die Frage, ne?
Ja, na gut.
Na, gut.
Ich mein, ja, ich weiß nicht.
Überrascht natürlich immer so ein bisschen, wenn es
kompiliert, dann ist es auch okay, aber ich
weiß nicht so genau. Es kann auch immer noch
das Falsche tun. Unsafe, unsafe.
Nee, gar nicht
unsafe, sondern einfach so, ja.
Ich weiß es nicht. Also,
ja.
Naja, ich glaub, man fällt sonst auch nicht mehr
so viel ein.
Ja, ich bin gespannt. Aber die kulturelle
Sache haben wir, glaub ich, schon festgestellt. Es ist ja relativ offen,
ne, und es ist noch nicht so ganz klar, was das überhaupt
heißt, und es gibt da kein so ein Leuchtturm.
Oder das würde mich mal interessieren, ist das ein,
gibt's etwas Spezifisches, was jetzt
halt irgendwie DevOps betrifft, oder ist das halt,
irgendwie, könnte man das, was wir über Kultur gesagt
haben, ganz genau so
sagen, wenn es um Agile-Geschichten
geht, oder wenn es überhaupt darum geht,
irgendwie zu
verstehen, dass Software irgendwie
ein interessantes
Thema ist überhaupt, oder
ja, also
ist das nicht immer das Gleiche?
Ich glaub, es ist tatsächlich ein Problem.
Also Kultur überhaupt zu verstehen
und das zu harmonisieren und
das zu implementieren in den Firmen.
Kommunikation ist eine wichtige Rolle.
Also wenn man, natürlich, es können einen Sachen
halt aus so einer gewissen
botanischen, aus so einem botanischen
Interesse halt irgendwie
beschäftigen, ja, dass man halt die Dinge klassifiziert
und aufmalt, was so unterschiedliche
Kulturformen es gibt, aber die Frage ist,
ist das jetzt rein deskriptiv?
Also ich würde sagen, das Problem ist, dass du voll viel
voraussetzt, dass du immer davon ausgehst, dass
das so selbstverständlich ist, was es aber nicht ist,
und dass ganz oft halt ist eine
Kommunikationsmöglichkeit fehlt
zwischen den Leuten, um diese Harmonisierung
oder das Verständnis oder überhaupt so
die Dinge, um die es dann geht,
klarzustellen
in so einem, auch...
Ja, ich glaub schon.
Genau, ich würde sagen, man kann das jetzt alles, man könnte jetzt aufschreiben
und macht dann halt irgendwie, keine Ahnung,
die, die beschreibt halt,
was Leute so für da Probleme haben,
aber die Frage ist, folgt daraus
irgendwann, kann man das irgendwie ändern?
Wenn man es nicht ändern kann, dann braucht man...
Also ich lasse Leute schreiben darüber, also über so
Dinge für sich selber und dann ist halt so
eine Art Quiz, wo man halt durch muss
und ich glaube, das erhöht das Verständnis,
das gegenseitige Verständnis für
so bestimmte Prozessschritte, warum die wie so sind
und ich glaube, dass das sowas...
Nur mal so als Beispiel, ich meine, diese Agile-Geschichte
mache ich jetzt so ungefähr 20 Jahre.
Habe ich das Gefühl, dass das jetzt heute
wesentlich besser ist als vor 20 Jahren?
Wir haben viel drüber geredet, wirklich.
Und ich habe auch viel mit Leuten drüber geredet,
ich habe versucht viel, hat das Dinge
wirklich verbessert, da wäre ich mir, wäre ich nicht so sicher.
Also, sag mal so, ich würde sagen, das Verhältnis
zwischen Aufwand, den man reinsteckt und Ergebnisse
rauskriegt, ist halt eigentlich gar
nicht so gut bei diesen
Geschichten oft. Ah, also das heißt,
du würdest sagen, viel zu teuer, einfach
mach mich früher. Nee, das nicht,
sondern vielleicht auf Dinge irgendwie
gucken, wo man Sachen verändern kann.
Aber ich meine, gut, das ist jetzt etwas
defetistisch, aber...
Okay, ich glaube,
das ist das Schlusswort. Nein, nein,
das muss auch jemand was Optimistisches
sagen.
Ich finde das gut.
Habt ihr einen Pick euch da ausgesucht?
Ich habe tatsächlich heute keinen.
Nein? Nein, heute nicht.
DefOps, ich
strecke die Fühler.
Gut, doch, ich hätte
einen.
Und zwar
habe ich
jetzt seit einigen, ich habe irgendwann mal
angefangen, weil es Vorgabe war,
irgendwie so IDEs, ich habe eigentlich nie
irgendwie eine IDE verwendet,
bis irgendwie das mal dann halt zur Pflicht
wurde in irgendeinem Projekt.
Und
dann
habe ich eine ganze Zeit lang einen Pipe
Charme verwendet und dann halt irgendwann
auch mal VS Code auch mal eine Zeit lang
und so. Und inzwischen habe ich mich
so ein bisschen daran gewöhnt und
habe dann halt
meine
Default Editor
WIM halt ein bisschen vernachlässigt.
jetzt wollte ich in letzter Zeit mal wieder ein bisschen
was mehr mit WIM machen und dann
habe ich festgestellt, oh mein Gott, irgendwie
das alles zu konfigurieren mit den Language Servern
und keine Ahnung und das ganze Zeug ist ja doch...
Das ist ja total kompliziert geworden.
Und dann habe ich
irgendwann mal so ein bisschen angefangen und dann wieder abgebrochen
und dann dachte ich mir so, oh Gott, das ist alles so...
Zeitintensiv.
Jetzt habe ich was gefunden,
wie man damit
wieder anfangen kann, ohne so viel Zeit
da reinzustecken und das ist Lazy WIM.
Und
ja, das macht dann einen Großteil
der Konfiguration. Also es hat bei mir dazu
geführt, dass ich jetzt wieder mehr WIM
verwende, beziehungsweise Neo WIM, aber
ja.
Lazy WIM. Das macht die ganzen Language Server Kram
so, wie man es nicht möchte.
Das meiste davon. Also ohne Konfiguration
kommt man damit auch nicht aus
und man muss eine ganze Menge Zeugs installieren
und so. Ja, ich habe das letzte Mal damit, weiß ich nicht,
vorletzten Mai
oder so kurz aufgehört und seitdem auch keine Zeit
mehr gehabt. Ja, aber
man kommt, also es ist deutlich
einfacher, als wenn man das jetzt
irgendwie von Grund auf selber machen wollte.
Tag ist bitte nicht schonend. Ich würde das ja auch gerne noch mal in Angriff nehmen.
Aha.
Ja.
Hast du einen Pick?
Hast du ein Tool vielleicht
im DevOps-Bereich, der ja das irgendwie
voll interessant wäre, wo man
was drüber erfahren könnte?
Da gibt es viele.
Ne, tatsächlich jetzt gerade
aus dem Stehgreif jetzt nicht. Habe auch nicht vorher drüber
nachgedacht.
Aber ja.
Hatte ich das letzte Mal eigentlich UV gepickt? Ich weiß gar nicht.
Das weiß ich nicht, aber wir hatten es
auf jeden Fall erwähnt, das letzte Mal, glaube ich.
Ja, dann
vielleicht noch M-Voice oder so.
Was ist das?
Das macht, das singt für dich.
Ist aber Musik.
Ja, ich habe damit letztens
so ein bisschen rumgespielt. Fand ich interessant.
Kannte ich nicht. Ist aber leider
commercial, kostet Geld und du kannst dir Stimmen
kaufen. Und dann gibst du denen
eine Tonleiter und dann singen
alle ein paar Sätze und sie singen für dich.
Ich meine.
War das das Ding, was neulich die MIT
Lizenztext vorgesungen hat?
Weiß ich nicht. Ich hatte neulich
irgendwo gesehen auf Mastodon, glaube ich, hat
irgendjemand verlinkt, das hat da irgendjemand
mit irgendeinem AI-Tool
dazu gebracht,
die MIT-Lizenz-Infotext
quasi vorzusingen.
Von so einer AI-Frau.
Könnte sein. Gibt's lustige
Ranges von
keine Ahnung, Oktaven, in die man die
jeweiligen Stimmen singen lassen kann. Und wenn man das dann kombiniert
mit irgendwelchen coolen Sachen wie Vokuda, ein bisschen
Reverb, ein bisschen Echo, ein bisschen...
Ja, egal.
Ja, dann
wundervoll, dass ihr uns wieder zugehört habt.
Und bleibt uns gewogen.
Hallo at peißenpodcast.de für jedes Feedback,
Anmerkungen, Anregungen und so weiter.
Vielen Dank an dich, dass du heute da warst.
Ja, vielen Dank. Danke, dass ich da sein konnte.
Spaß gemacht. Und dann
hört uns wieder rein und
bis zum nächsten Mal.
Tschüss.