Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast. Heute Episode 56 und wir reden über DevOps.
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?
Ja,
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 ein paar 2.0 und so.
Also Speed und Performance
und sowas? Genau und
ein paar Breaking Changes.
Ganz so viel.
Nee, ist glaube ich diesmal gar nicht so schlimm
mit Pandas 3.0, das kommt dann irgendwann
im Nächsten. Da wird, glaube ich,
umgestellt,
dass defaultmäßig dann immer Copy und Write
verwendet wird und nicht mehr. Also momentan ist es ja immer so
eine Sache, manchmal sind Operationen
halt irgendwie, 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.
Und das ist aber jetzt noch nicht passiert.
Also insofern ist noch, glaube ich, noch nicht so viel
und die
eigentlich fast immer. Es ist halt nur so,
dass halt manchmal...
Genau, und das Hauptproblem, was ich mal hatte,
war tatsächlich, dass so die Pipelines auch dann
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 ich so lange
gebraucht habe, umzustellen, weil ich gerne auf das neuere
Dango fahren wollte. Ja, 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. Du nutzt immer deine
eigenen Monkey Patches und deine eigenen Forks.
Genau, ansonsten, ja, was ist noch passiert?
Gar nicht direkt Python, aber
nah, nah dran.
Jetzt wo vor kurzem,
ich weiß nicht, wann das war, das war aber auch noch nicht so lange her.
Das Django
das Django-Drecksen,
das da eingebaut wurde, Support für Redis.
Ah, stimmt.
Oh, Moment, Redis, auch noch so eine News.
Redis ist post.
Die haben sich von der Open-Source-Community ein bisschen verabschiedet.
War es nicht so eine coole Nachricht
eigentlich?
und Python.
Ja, also
ist halt
ein Problem, aber ich finde, das ist halt so ein bisschen
exemplarisch irgendwie, was
halt das Problem dann ist, wenn
man halt irgendwie
gezwungen ist, ein Geschäftsmodell draus zu machen.
Ja, Python Source hat ein Riesenproblem,
glaube ich, ja.
Naja, also das generelle Problem
ist halt an der Stelle, dass die
ganzen Hyperscaler halt
dann irgendwie quasi das nehmen,
dann selber ein Geschäftsmodell draus machen und
ja, das ist halt das.
und auch zu wenig zurückgeben dann davon.
Ja, da ist halt noch nicht so richtig klar, wie man damit umgeht.
Ja, muss man mal schauen.
Aber gut, also ich würde jetzt nicht denken,
dass das irgendwie besonders schlimme Konsequenzen für irgendwen hat.
Dann nimmt man halt irgendwie einen Fork
oder man versucht, das irgendwie anders zu machen,
weil ob das immer so eine gute Idee ist, da Redis zu verwenden,
ist sowieso, ich finde, das wird ein bisschen zu viel verwendet.
Was magst du an Redis denn nicht?
Das ist halt ein zusätzliches Ding, was man mitdeployen muss.
und das halt irgendwie spezielle
Dinge hat,
auf die man Rücksicht nehmen muss und so.
Und wie würdest du sonst sowas lösen?
Ich würde 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 im Redis reinschreibst,
auch in deine Datenbank reinschreiben.
Ja, aber das...
Also muss man natürlich ausprobieren
oder ein 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
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 schnell ist
dann schon irgendwie doch im Speicher liegen von der Datenbank
Ja, aber das sollte es ja eh so
Sollte bei einer Datenbank ja eh meistens so sein
dass du da halt
dein Working Set hauptsächlich im Hauptspeicher hast
und 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 noch Redis braucht, weiß ich nicht.
Ein Abgesang
auf eine der tollen Technologien.
Nein, ich meine, das hat schon
natürlich auch coole, man kann damit coole Sachen machen,
aber, ja.
Man kann 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.
Du meinst Jason Field?
Ja.
Okay.
Muss ich mal drüber nachdenken.
Du kannst auch picklen und das in die Datenbank reinschreiben.
Ja.
Genau. Ansonsten
vielleicht
sagen wir was zu diesem
XZ
XZMA Debakel,
und die Programmiersprache Python.
Ja, aber es war gar nicht im Code, es war in einer, also vielleicht nochmal ganz kurz zusammengefasst, was passiert ist,
es war in einer Open-Source-Bibliothek ein Angriff, der tatsächlich massiv dazu geführt hätte,
dass Sicherheitslücke bei SSH aufgetreten wäre.
Nein, nein, die Sicherheitslücke, das ist halt so eine Backdoor, und zwar eine Nobody-But-Us,
also sozusagen eine, wo nur die Leute mit dem richtigen Private Key reinkommen, sonst keiner.
Also was nach Greinendienst riecht, ehrlicherweise.
Ja, vielleicht.
Ja, aber wie es halt gemacht war, es war halt Open-Source-Bibliothek,
und Jochen unterhalten sich über die Programmiersprache Python
dass man
das SSH quasi
dass man in SSH
Dinge austauschen kann dadurch
dass man irgendwie eine Backdoor
in den XTools
hat, das hätten wahrscheinlich
schon viele gar nicht für möglich gehalten
und das liegt auch nur daran, das liegt nicht an den beteiligten
Projekten, das liegt nicht an OpenSSH
das liegt an einer Kombination
davon, weil
die Distributoren halt
irgendwie so SystemD
irgendwie
gepatcht haben,
dass das irgendwie
da mit reingelinkt wird.
Und damit
irgendwie so eine indirekte Abhängigkeit von
OpenSSH zu der
Kompressionsbibliothek. Also das heißt, du bist jetzt gerade
auf der Gegensystem-D-Seite von
diesen Zeiten. Nein, nein, gar nicht. Also ich fand auch,
also
Landa Pöttering hat dann halt auf Mastodon auch
quasi geschrieben, so, naja, also wir sagen ja schon
seit Jahren, dass man das nicht so machen soll.
Und wie man
es dokumentiert, wie es richtig geht.
und ja, wir haben das, wir sagen das seit Jahren, es ist nie umgesetzt worden, ja was wollen wir denn machen?
Und da hat er natürlich irgendwie einen Punkt.
Und es ist auch, die Geschichte, die System, die macht, ist ja schon viel besser als wie es vorher war,
mit den Scythe-Init und den Schadenskripten, das ist ja alles noch viel furchtbarer,
dann wäre es noch einfacher gewesen, irgendwie Dinge zu verstecken.
Aber ja, dadurch, dass die Distributoren halt das so angepasst haben, ist es halt möglich gewesen,
da war es, und das muss man erstmal wissen, dass man da so Sachen reinschmuggeln kann,
das ist nicht so offensichtlich
und jetzt ist natürlich auch alles geändert worden
Das war halt tatsächlich auch so eine Social Engineering Attacke
also man hat halt den einen Maintainer, der dann
irgendwie da alleine gekämpft hat
um das Ding da so ein bisschen weiter zu machen
weiterhin unter Druck gesetzt, also auch mit so vielen Nachrichten
und sich da in dem Repo als
Co-Maintainer irgendwie eingestichen
und dann halt die ganze Zeit so getan hat, jetzt macht man
irgendwas und dann von außen noch mit
anderen Accounts Druck erzeugt
von außen halt noch Druck erzeugt, also ja man hat
was gemacht, aber ich meine, man hat da
aktiv dran entwickelt auch gute Daten quasi
und dann auch Qualität beigetragen quasi, aber
man hat diesen einen Maintainer, der halt auch
relativ unter Druck gesetzt ist.
Das waren viele Commits.
Also es waren nicht irgendwie wenige, das waren
richtig viele, es waren, ich weiß nicht, insgesamt,
geht in die hunderte
und die waren alle sehr gut. Also irgendwie
jemand hat dann mal so ein Beispiel gefunden,
guck dir diesen Commit an, der ist,
wie war der auch so, pitchperfect, 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 ist da?
Ja, aber was sie halt auch gemacht haben, sie haben ja psychisch unter Druck gesetzt.
Sie haben halt in den Issues und so
wurden sie aggressiv und haben
angefangen, also ihn persönlich anzugreifen
und so weiter, dass er dann wirklich so ein bisschen Kontrolle verloren hat
und auch gar nicht mehr, also wirklich wollte,
glaube ich. Nein, nein, nein, nein,
der wollte vorher schon. Also der hatte sowieso ein Problem.
Also dass sie sich den ausgeguckt haben, ist halt auch kein Zufall.
Sondern der hatte irgendwie immer
schon so ein bisschen Struggle
und der wollte das eigentlich,
musste halt immer mal wieder Auszeiten nehmen,
konnte das nicht so richtig machen und dann haben sie halt
gesagt, brauchst du nicht.
Und er hat ja um Hilfe gefragt. Er hat gesagt, ich hätte
gerne Hilfe, will mir nicht irgendjemand helfen,
weil ich kann es nicht so richtig machen, wie es eigentlich gemacht werden müsste.
Ja, und dann hat sich der eine da gemeldet.
Ja,
das war eine kleinere Strategie eigentlich.
Und ja,
dann, genau, dass dann noch
andere ins Spiel kamen, ging es
dann darum, die Distributionen
reinzukriegen und dann halt auch
um einen, den man da platziert
hatte, als Maintenner zu etablieren und so.
Also ja,
Ja, also es war eine hässliche, also wenn man sich das so anguckt, ich kann mir nicht vorstellen, wie man das irgendwie quasi, wie man da so, wie man da sozusagen sofort lunt riecht, sondern das kann jedem passieren.
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
Nein, Open Source 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 Open Source wäre da eigentlich besser für
Also es hat ja da funktioniert
Man weiß nicht, ob es an vielen Stellen vielleicht
dann, wo man es auch nicht gefunden hat
Aber ja, an der Stelle hat man es gefunden, auch wenn
viel Glück dabei war, aber
genau, demgegenüber Closed Source
Hast du das mitgekriegt?
Das kam jetzt auch letztens raus, da gab es irgendwie einen offiziellen
Abschlussbericht
Microsoft hatte ja irgendwie dieses Problem
gehabt mit dem Masterkey
der ihnen irgendwie abhanden
gekommen ist, wo sie dann gesagt haben, so, oh ja
wir haben hier irgendwie
ein Postmortem-Dings gemacht und
ein langes Ding veröffentlicht, wo sie dann gesagt haben, ja wahrscheinlich
ist es irgendwie so, oder wir denken
es ist halt durch irgendeinen Crashlog irgendwie dann da raus
geleakt und keine Ahnung
und ja, da
hat irgendeine Behörde aber
sozusagen einen Bericht auch
angefordert und dann haben sie ihnen
das geschickt und dann waren die nicht einverstanden
und dann haben sie nochmal nachgeprüft und jetzt in dem offiziellen
Bericht, der approved ist, steht halt drin
wir wissen nicht, wie uns dieser Schlüssel
abhanden gekommen ist. Also ein Ding, mit dem
man Sessions signieren kann, mit dem man
in jedes
Outlook-Konto reingekommen ist,
in jeden
Azure-Kram
und sie wissen nicht, wie das Ding rausgelegt
ist. Tja, das ist wirklich so gut.
Und Microsoft hatte auch LibArchive,
wo halt die gleichen Leute, die halt
da irgendwie dieses
AcceptTools-Dings gemacht haben, auch aktiv
waren. Das haben sie auch integriert
mit den Änderungen.
Und ja, also
ich glaube nicht, dass Closed-Roster irgendwie
Ich würde auch sagen, also Open-Source ist
dann wahrscheinlich doch besser, wenn mehr Leute drauf gucken, die dann
wirklich so, also wie das raufgeflogen ist,
da hat irgendwie wirklich jemand, also Messungen angestellt,
ne? Andres Freund war das,
Microsoft-Mitarbeiter,
bei Delim Poskis
und hat halt so Micro-Benchmarks gemacht.
Ja, aber das ist ja so Hobby-Nerdism
quasi. Also es ist voll gut, dass es so Menschen gibt,
die sich so tief mit so Themen aussetzen, aber
ohne so einen Enthusiasmus da an der
Stelle wäre das einfach untergegangen.
Ja.
Ja gut, jetzt werden ein paar Sachen
zugemacht und es wird wahrscheinlich
jetzt ein bisschen schwieriger,
aber letztlich ist es schwer, dagegen
was zu tun. Ich habe auch schon
irgendwie, also ich meine, es gibt da natürlich das
und das ist gerade voll davon, was man da so machen könnte und was irgendwie sinnvoll wäre
und es gibt aber ehrlich gesagt nicht so viel, was man tun kann.
Also außer ja, die Distributoren könnten vielleicht ein bisschen was machen.
Dass man halt aufpasst, dass halt sowas wie OpenSSH, dass man wirklich weiß,
was die Abhängigkeiten dafür sind und dass man da halt dann ein Auge drauf hat,
dass man die Dinger ganz besonders genau anguckt.
aber
ja, letztlich
ist es glaube ich schwierig, sich
dagegen zu verteidigen. Einen
interessanten Absatz fand ich
von Michael Zaleski,
der hat dann so einen Artikel geschrieben, der meinte so,
naja, also gerade auch dieser
technisch ist halt die Frage, kriegt man das technisch überhaupt
in den Griff? Wahrscheinlich eher nicht,
weil eigentlich ist ja der Kern dieser Attacke
im Social Engineering-Angriff gewesen
und
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. Das kann man wahrscheinlich
gar nicht ausschließen. Tatsächlich ist dann das Mehraugenprinzip
gar nicht so schlecht.
Dessen Fazit war dann
quasi mehr oder weniger 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 eher
Spionageabwehr, weil
du fängst Spionen
nicht unbedingt mit Programmierern, sondern
dann nimmst du halt andere Spione, die das halt, wie das
funktioniert.
Also das fand ich okay,
das ist ein Punkt, aber ansonsten war immer
so eher... Ja, es wird sträflich vernachlässigt
und kostet alles wieder Geld.
Ja, aber gut, jetzt gab es mal halt einen Warnschuss
irgendwie.
Besten so Internet einfach abstellen.
Na ja.
Genau, aber war
auf jeden Fall aufregendes. Ja, war spannend.
Bei Python gab es ja auch wieder so ein paar Tag,
so jede Menge Typos.
und so. Gibt es gerade,
wobei das eher
so handelsübliche Kriminelle
würde ich jetzt mal sagen.
PyPI hat Anmeldungen
von neuen Benutzern abgeschaltet und
nimmt es auch gerade
vor ein paar Tagen, ich weiß nicht, es kann auch sein, dass es schon wieder
vorbei ist, keine neuen Pakete
entgegen, weil halt da irgendwelche
maliziösen
Python-Pakete eingestellt
wurden, so auch typosquatting-mäßig
und einfach jedes tolle Paket,
was man kennt, ganz viele Namen von
GPT generieren lassen, die endlich klingen und von hinter
seinen Code verschicken. Und die machen
einfach so schnöde Dinge wie
Session-Cookies von Banken klauen und
irgendwie Crypto-Wallets irgendwie sammeln
und solche Sachen. Ist aber auch
natürlich unerfreulich, wenn man davon betroffen
wird. Also wenn ihr Pakete dazu fügt, guckt
drauf, dass ihr die ordentlich eingibt.
Das ist so ein bisschen, ja.
Ja, genau.
Ansonsten. Mehr News?
Ja.
Das ist Herr Beuys, das Django-Fellow. Ja, die hier, die
Django User Group Köln mit organisiert.
Genau, das ist natürlich irgendwie herzlichen Glückwunsch
von hier. Gehen wir morgen
vielleicht auch mal hin wieder zu den Treffen.
Das war natürlich, wenn ihr es hört, bestimmt schon
gestern oder vorgestern. Ja, überhaupt,
das habe ich gar nicht so erzählt, aber da
passiert relativ viel. Ich meine, leider ist ja die
Django User Group Köln
die letzte verbliebene Django User Group in Deutschland,
glaube ich. Aber dafür passieren
dann wieder interessante Dinge. Im Januar war jetzt auch ein Treffen, wo
halt irgendwie da von der Django Software Foundation
Leute da waren, also Tipo Kula von Wagtail ganz viel macht und Sarah Taramane aus der Django-Juicy-Group Paris und haben da interessante Sachen erzählt und halt auch so ein Brainstorming gemacht quasi Richtung, was sollte man denn jetzt irgendwie da noch machen an Django, was sind da für gute Ideen.
Ja und auch eine Aufforderung, alle Leute, die Bock haben, sind gerne herzlich eingeladen auch.
Ja, und da zeigte es sich so ab, es geht wohl in die Richtung, also ich finde eigentlich ist gerade Django in einer sehr, sehr interessanten Position, einfach deswegen, weil ja jahrelang vorher gab es keine gute Frontend-Story für Django und das hat sich halt irgendwie gerade geändert, also mit Edge Team X.
Ja, und
da kann man vielleicht auch nochmal kurz was zu sagen
und daher, wir haben jetzt da jetzt
im Grunde und 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 ist gerade
auch mit drin
Firefox muss sich so ein bisschen
mal irgendwie, das muss ich auch mal
hinkriegen, das ist ja ganz gut, weil
dann kann man halt irgendwie traditionelle
Webseiten halt auch irgendwie aussehen lassen
wie SPAs mit relativ wenig Aufwand.
Und ja,
das ist natürlich interessant.
Also das wäre für die meisten Backend-Leute
wie uns super.
Weil man kein komisches JavaScript-
Framework vorne dran verwenden muss.
Und ja,
mit Django hat man halt ein Ding,
was halt 15 Jahre alt ist, langweilige
Technologie funktioniert, ist sehr stabil,
keine großen Änderungen mehr, eigentlich im Grunde
tut es das, was es soll. Das ist natürlich super,
weil dann kann man sich darauf konzentrieren, damit irgendwie interessante
Dinge zu tun. Genau, also Admin-Fontent
ist so eine der Sachen oder ist Admin-Backend, ich weiß nicht.
Ja, 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,
das Backend, also Admin-Fontent eigentlich,
genau, ist halt,
dass es halt riesig ist und
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 sagen, na, kann man
auch mal was dran machen, das wirkt so ein bisschen altbacken
und das muss man ein bisschen moderner. Das neu zu schreiben wäre
sehr, sehr teuer, aber vielleicht kann man es ja
irgendwie so ein bisschen nur im
Frontend irgendwie besser aussehen lassen oder so.
Das wäre natürlich auch, also da passiert auf jeden Fall
was, aber überhaupt generell Richtung
irgendwie
diese ganzen HTMLX und so Sachen besser
integrieren, das, da in die Richtung
geht es auch auf jeden Fall und das ist eigentlich super interessant.
Also eigentlich gerade eine sehr, sehr gute
Zeit, um
sowas mit so einem klassischen
Webframework
irgendwie was zu machen.
Ja, also zu HTML-Mix, wir hatten ja schon eine Episode dafür
und ein paar Mal irgendwie auch da eine Lanze für gebrochen
und... Inzwischen hat man das auch
schon häufig verwendet. Ja, nicht super,
aber es ist auch mehr, genau. Also Hypermedia Systems,
das ist ja das Buch, das ja auch relativ frei rauf und rum liegt
oder sowas. Ja, kann man sich auch auf jeden Fall
mal angucken, wenn man
sich dafür interessiert. Also ich finde
eigentlich immer ein bisschen, es hat auch gehabt,
es ist jetzt so erfolgreich, dass es
auch Kritik gibt, weil es offenbar
die Wahrnehmungsschwelle irgendwie überschritten hat.
bei manchen Leuten und dann gibt es
die Kritik, die es da bisher immer gab,
ich finde das immer so ein bisschen schade, wenn man halt
irgendwie, ich das Gefühl habe, dass
da nicht so richtig verstanden ist, warum das so cool ist
oder vielleicht gar nicht verstanden ist,
warum, was daran
und das kann ich
vielleicht auch mal versuchen, nochmal in zwei Sätzen zu
sagen, weil das wäre mir schon wichtig, wenn
man das irgendwie verstehen würde.
Das eigentlich Coole ist halt, aus meiner
Sicht, dass es halt eine Geschichte
ermöglicht,
die halt mit so
SPS nicht so gut geht. Bei SPS hast du
halt eigentlich immer,
jedenfalls soweit ich das kenne,
eine enge Kopplung zwischen Client und Server.
Du musst halt immer, wenn du das eine
änderst, musst du das andere mit ändern. Also wenn du halt
irgendwie
API-V2,
API-Versionierung, oh mein Gott.
Nein, aber allein schon, wenn du
halt einfach nur, du änderst
irgendein Formular oder so,
dann musst du das halt einmal
am Server ändern und
du musst es halt auf dem Client ändern.
und das heißt, die Dinger sind voneinander abhängig.
Wenn du da halt irgendwie viel mehr in dein
Formular reinschreiben möchtest, dann musst du
halt im Backend das halt auch alles validieren.
Also im Worst Case brauchst du halt sogar zwei Entwicklungsteams.
Einen, die das Server-Teilchrist machen und einen, die das Backend machen.
Ich fürchte, das ist der Normalfall, dass du da mehrere Entwicklungsteams hast.
Das heißt, du hast ein System, das ist eng gekoppelt
an einer Schildstelle, wo du dann
über eine Teamgrenze hinweg kommunizieren musst.
Also das ist halt einfach...
Ah!
Aber gut.
Aber möchtest du denn den komischen Backend-Leuten diese ganzen
schön Design-Sachen noch dran binden.
Ja, naja, ich meine, das ist halt
einfach, manche Leute mögen halt lieber JavaScript,
andere lieber was anderes und dann
werden das irgendwie automatisch unterschiedliche Teams oft
und ja, aber wenn man jetzt
halt ein System hat, das halt, wo man
eine harte Anhängigkeit hat, wenn man das eine
ändert, dass man das andere auch mit ändern muss und das hast du
halt über eine Teamgrenze hinweg, das ist halt, ich kann mir
nicht vorstellen, wie das keine Probleme machen kann,
das macht immer Probleme sowas und
das ist eigentlich das Schöne, wenn man jetzt
quasi nicht so eine JSON-API
dazwischen hat, sondern wenn man einfach
HTML ausliefert,
dann hast du halt als Server
irgendwie, ja, klassischen
Web-Server mit HTML.
REST. Ja, also tatsächlich
REST quasi, so was die JSON-Apps
normalerweise halt eben nicht wirklich sind.
Und der Client ist halt der Browser
und dann hast du eine lose Kupplung.
Nämlich, sozusagen
ich kann den Server ändern und dann muss ich
nicht aber einen neuen Browser shippen, sondern das geht halt auch
mit alten Browsern, geht auch
mit alten Browsern oder geht auch mit neueren Browsern.
Und genau, ich muss nicht beides ändern.
Ich muss nur die eine Seite ändern.
Und das ist halt dann natürlich eigentlich viel angenehmer.
Aber 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 gut, aber ich würde einfach mal sagen,
wenn du halt ein Formular hast und ich habe
halt so eine klassische Web-Applikation, wenn ich da jetzt
zwei, drei Formularfelder zusätzlich mache,
dann muss ich halt nur an einer Stelle den Code ändern
und nicht klein
und unzuerwartend fassen.
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 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, meistens nehmen die immer alles.
Ja, so Graph-API-Style oder sowas, du kannst einfach nach einem fragen, kriegst einfach das, nachdem du dich gefragt hast.
und GraphQL. Ja, das ist auch
so eine Sache, aber das macht es ja eher noch schlimmer.
Ja, genau. Das meine ich 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?
Könnte man ja sagen, ah super, dann ist das Problem ja
erledigt. Das ist ja dann so wie SQL.
Kann ich ja dann die ganze Logik
im Client machen und habe dann nur noch dumme
Datenschnittstelle sozusagen.
Das Problem dabei ist,
dass ich dann natürlich die Business-Logik im Client
habe und die habe ich dann halt in allen Clients, die es
gibt. Die habe ich dann einmal in der SPA, aber halt die habe ich dann auch in einer mobilen
Applikation und in allen Third-Party-Integrationen.
Wenn ich irgendwo was ändern muss, muss ich das in allen ändern.
Das ist halt auch irgendwie ein Architektur-Panel, wo ich mir denke, wie kommt man auf die Idee,
sowas zu machen?
Ich kann den Kleinen auch überlassen, was für Anfragen gestellt und so und das ist auch
ziemlich gefährlich.
Aber naja.
Ja, gut, dass das Ganze noch so ein Problem hat, ist auch richtig, aber allein schon,
dass es halt dazu führt, dass man halt die gleichen Geschichten immer wieder schreibt
in unterschiedlicher Form, dabei über Teamgrinsen
hinweg kommunizieren muss.
Also ist schon, würde ich denken,
auf jeden Fall keine
sehr schöne Architektur aus meiner Sicht.
Ja,
und genau, das sind halt so
die beiden Hauptprobleme, die ich sehen würde.
Also irgendwie lose Kopplungen und halt
ein bisschen Logik bitte nur an einer Stelle haben,
die halt sehr viel einfacher
werden, wenn man halt HTML ausliefert
und nicht JSON.
Ja.
Genau, das wollte ich nur mal so erwähnt haben,
weil das ja immer so ein bisschen...
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, für 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
luberklar sein.
Ja.
Waren das deine News, Jochen? Ja.
Ja.
Hast du noch News mitgebracht?
Nee.
Du hast aber auch einen Podcast,
hast du gesagt. Genau, ich habe auch
einen Podcast. Erzähl doch mal.
Du darfst doch gleich noch was über dich sagen.
Erstmal über deinen Podcast. Ja, ich mache
mit meinem Kollegen Dirk
einen 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
Sachen wir mal zuletzt
gelernt haben oder vielleicht auch
nicht gelernt haben. Zum Beispiel offensichtlicheres,
manchmal auch wenig offensichtliches.
Spannend
Genau
Was war das letzte, Till?
Oh, das ist schon ein paar Wochen her
Das habe ich heute schon wieder vergessen
Dann müssen wir uns das schon nachrechnen
Ja, ich kann das verlieben
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
sponsern und wir haben einen schönen Partner dafür gefunden
und zwar ist das datascientest.com
DataScientist.com
Ja, das ist ein Unternehmen,
das bietet Schulungen an.
Zum Beispiel zum Bereich DevOps oder
Python generell oder SQL.
Machine Learning.
Deep Learning. Power BI auch sowas.
ABS.
Die kann man remote
alle machen. Also ist gar nicht so
schlecht für euch, wenn ihr Familie habt vielleicht.
Du wolltest nicht irgendwo zum Standort hinfahren.
Flexibler sein.
Ja, also genau.
Die arbeiten aber auch mit der
Sorbonne, glaube ich, da irgendwie zusammen.
Ja, es gibt auch 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
Takt 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.datascientist.com und schaut euch das ein bisschen an.
Okay, cool. Ja, ist ja auch eine Nummer, oder?
Und also vielen Dank an den Sponsor dieser Episode.
Da wir auch gerade von dieser DevOps-Schulung gesprochen haben, würde ich jetzt auch tatsächlich gerne zu unserem Thema der Episode übergehen,
wo endlich, ich meine, auch ein bisschen mehr zum Wort kommen soll.
den haben wir nämlich heute eingeladen, weil er
über DevOps sehr viel weiß
und auch ein tolles Buch dazu geschrieben hat
Soll ich kurz sagen, wie ich
darauf aufmerksam war? Ja, bitte
Ich habe auf Amazon gesehen, dass Friedrich Hemberger
glaube ich, hatte irgendwie geteilt
dass es jetzt ein neues Buch über DevOps gibt
und ich dachte so, oh, das ist ja interessant
finde ich auch gut, das Thema
gleich mal gucken und genau
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
Jetzt musst du dich aber mal vorstellen
erstmal selber, bitte
Was soll ich denn sagen?
Deinen Vornamen kenn ich ja schon
und was du so machst vielleicht, wie du dazu gekommen bist
was du findest, wie DevOps
irgendwie uns begleitet oder
Genau, also
ich fange mal vom Vornamen
würde ich mal sagen, genau,
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
bei einer normalen Anstellung, das 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 versuchst du in 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,
und ich bin hier ja jetzt privat,
was die halt falsch machen teilweise.
Ja, das ist natürlich interessant.
Darfst du gerne
aus dem Nähkästchen plaudern?
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
dann kamen die halt zu uns
und das ist halt
erst nochmal das Erste, worauf ich mich dann kümmere,
was wollen die überhaupt?
Und die hatten dann so gesagt,
ja, wir möchten, dass
eine bestimmte User nicht den Source sehen darf und das k ihr ja nicht k ihr das nicht irgendwie einbauen Also ich wei noch das Management sollte ich 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 den Code sehen willst, dann mach doch
das ganze Projekt halt privat oder nur die
Leute, die es halt sehen sollen, dürfen.
Also ich kann mir auch, ich kenne auch so ein paar Rollen,
wo ich das verstehe, ja.
Genau, aber da ging es halt mehr darum,
die sollen ja Issues und sowas
bearbeiten können, aber die sollen den Code
nicht lesen können.
Genau, das ist auch so mein Gedanke.
Moment mal, da muss ich jetzt noch
nachfragen, warum?
Warum? Sie ist ein kleines Kind.
Ja, für gut.
Da kommen jetzt
gleich drei, vier
Schienen von warum
hinterher, nämlich weil das erste Mal,
sie meinten dann so, ja, die können dann
irgendwas im Code kaputt machen und sonst was.
Warum?
Ja, ich meine, da gibt es ja einen Moment,
da gibt es da so 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.
Nicht so wie bei XZ.
Auch wenn es ein
Main-Tainer ist.
Und dann so, ja, okay,
stimmt, das ist nicht das Problem.
Blablabla. Ja, okay, aber was ist
jetzt euer Problem? Ja, das sind
Passwort im Quellcode drin.
Oh, okay.
Warum?
Ja, genau, warum?
Beziehungsweise dann so,
naja, die solltet ihr halt eh ausbauen und
warum baut ihr das denn nicht?
Egal, wer das Zugriff
hat, sollte keine Passworte drinstehen.
Ja, also ausbauen, also ändern
und nicht mehr. Ändern, ausbauen
und dann halt durch sowas wie Hesheker-Vault
oder irgendwie sonst was, irgendein richtiges
Tool halt mit reinsetzen, dann halt.
Und dann so, ja,
aber da hat man nur in bestimmten
Netzwerken Zugriff drauf, also
eigentlich auch kein Problem.
Und dann war sie so, naja, okay,
aber was ist jetzt euer Problem?
Es war eine Policy.
Also die Policy in der Firma hat irgendwie
gesagt, bestimmte Leute, die nur Projektmanagement
machen, sollen nicht den Source-Root sehen.
Das verstehe ich sogar,
also weil es ja teilweise
Interessen gibt in Konzernen
beispielsweise 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
in einer 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 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 Testreferenzen 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 Dev-Stellung, mit dem anderen Manager darüber reden muss, wie sie 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 da kommen die sich nie näher und deswegen
ist so diese Verhandlungslösung immer schlechter
zu erreichen und immer mit größeren Kosten
verbunden. Vielleicht ist es so eine Art von politischem Problem?
Ja, 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 alles offen ist,
sondern das vielleicht nur auf Abteilungen
vielleicht offen ist oder sowas. Das kann ich auch grundsätzlich
irgendwie nachvollziehen.
aber wenn das halt für das
gleiche Team ist, das macht
keinen Sinn
und eines der Aspekte von DevOps ist
zum Beispiel ja auch Visibilität
in aller Sachen
also das so als
weil ich meine
im Endeffekt geht es auch viel um Silos
zwischen den verschiedenen Rollen
DevOps, 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 da sieht vielleicht so,
ah, da ist ein Merch-Request dran,
da läuft gerade
eine Diskussion. Aber jetzt erwartest du vom Projektmanager
schon ganz schön viel.
Ja.
Also in der Tech-Firma vielleicht, ja, aber wenn du in einer
Nicht-Tech-Firma bist, dass irgendwie ein Projektmanager
überhaupt weiß, was ein Merch-Request ist, die Wahrscheinlichkeit ist nicht
so hoch, wie man vielleicht denkt.
Ja, naja, aber das ist ja,
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. Das heißt ja nicht
unbedingt, dass du den Source Code verstehen
und ein Review machen musst als Projektmanager.
Aber du hast
gerade interessante Sachen gesagt, die ich gerne so ein bisschen
von hinten aufrollen würde, weil wir sind ja super
cool in dieser Geschichte drin und wir haben jetzt drei
Warums, glaube ich. Da kommen noch zwei?
Nee, nee, das war das Wesentliche.
Okay, dann würde ich
gerne diese Definition von DevOps mit den
Siloscannen nochmal besprechen, also welche Sachen da so
ineinander greifen, weil ich glaube, dass
als 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
und fragen, worüber ich ein Buch geschrieben habe.
Ganz anstrengend.
Aber ich
versuche immer, das so zusammenzufassen,
wenn ich das jetzt mal ganz kurz sagen würde.
Es geht halt im Wesentlichen um eine
Zusammenarbeitskultur in Unternehmen,
um gemeinsam
an einem Projekt zu arbeiten.
Wo halt auch eine Software
dran hängt. People-Sicht und nicht die technologische
und auch nicht die Prozess-Sicht.
Genau. Und dazu gehört halt eben
People over Processes over Tools.
Also erst
die Menschen, dann eben
die Prozesse und danach die Tools.
Also so in der Wichtigkeit der Reihenfolge.
Du kannst immer noch
DevOps richtig beschissen machen, wenn du
zwar die richtigen Personen
hast oder die richtige Arbeitskultur hast,
und auch die richtigen Prozesse hast.
Wenn aber der technologische Toolstack
halt bescheiden ist, dann hilft das
irgendwie auch alles irgendwie nicht.
Ich fand das Beispiel, was du da gemacht hast,
das ist super dafür. Und zwar das
mit dem Auto, dem Fahrer und der Straße.
Genau, also wenn ich jetzt aus meiner
Arbeitsblickwinkel da drauf schaue, dann
positioniert sich vor allem GitLab
dann halt mehr so, naja, wir machen
mit, also
DevOps jetzt schneller, besser, einfacher
im Wesentlichen, wenn man GitLab einsetzt.
Durch weniger Tools und so weiter.
Das ist im ersten Blick sehe ich das natürlich auch so, aber wenn ich halt mit den Kunden dann rede und gucke, naja, was habt ihr denn, wie arbeitet ihr denn überhaupt, dann merkt man halt häufig, 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
Das ist dann halt das Tool
Der Prozess wäre dann quasi die Straße
und ich würde halt auf einer
durch die Innenstadt
von, keine Ahnung, Düsseldorf fahren
Oh, das, ich weiß nicht, auf der Köhl
da sieht man manchmal, also
wie ich da rum bin, von den Formel 1 Autos
Genau, aber da kommst du ja trotzdem nicht so schnell rum
Nein, nein, nein
Dann ist es natürlich schön, dass du ein tolles, schnelles Auto hast
Du kannst aber
auf der Köhe in Düsseldorf jetzt nicht so schnell fahren
Gleichzeitig
brauchst du auch eine gewisse Rennstrecke
zum Beispiel
Und das andere Ding ist, du kannst das Ding überhaupt nicht fahren
Oder wenn der Fahrer
dich betrunken ist, wenn ich gegen den zweiten Baum fahre, das ist auch gut
Ja genau
Und so finde ich, kann man das
eigentlich ganz gut, der typische
deutsche Autovergleich, dann eben anbringen
von wegen so, naja, es bringt halt nichts, wenn du das beste
Tool, ein tolles Auto hast
wenn aber die Straße total bescheiden ist
und wenn du überhaupt gar kein Auto, gar kein Führerschein
hast zum Beispiel oder gar kein Auto, noch nie ein Auto gefahren bist
dann kann es halt nicht funktionieren
das hilft dann natürlich auch nicht, wenn dein
und jetzt
habe ich ja gerade mit dem Formel 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, dann zählt das ja auch irgendwie
noch dazu, ne?
Was ist überhaupt die Frage?
Ja, wenn die
Kinder die ganze Zeit auf dem Rucksack kängeln, wenn die Menschen endlich
und das Essen vergessen und so, das wird immer schwierig.
Ja, viele
Stakeholder.
Okay, also du sagst,
der Forbes ist ein Kulturbegriff,
wo es darum geht, diese ganzen Silos
zusammenzubringen und halt
die einzelnen Abteilungen, die es ja früher mal
waren, irgendwie miteinander in einen
Tisch zu bringen. Ja, ich kann das ja vielleicht,
also wie es früher war, ich bin unerfreulicherweise
schon so alt, dass ich weiß, wie es vorher war.
Daher, da hatte
man halt irgendwie
eine Entwicklungsabteilung und
dann irgendwie sozusagen
die Admins
und
dann wenn halt irgendwas
produktiv gehen sollte, dann
hat man sich halt mit den Entwicklern zusammengesetzt
und dann halt das Ganze irgendwie deployed
und dann betrieben.
Und ja,
aber das waren unterschiedliche Leute.
Also das ist jetzt der Operations-Teil, der Admin-Teil,
wenn ich das richtig verstehe.
in der Dev-Seite als Softwareentwicklungsteil,
aber wir hatten jetzt ja noch viel mehr drin, also zum Beispiel das Security-Ding,
das Frag-Management-Ding.
Welche Silos waren noch drin?
Na ja, QA letztendlich
halt auch, weil häufig, wenn man
auf ein Wasserfallmodell guckt, halt eher nachgelagert,
wenn man es früher guckt.
Die reine Agilisierung ist ja eigentlich schon lange
durch, sage ich jetzt mal so als Thema,
da redet man ja kaum noch drüber.
Also, dass man das machen müsste.
Aber da wird häufig halt auch nur nichts ausgeliefert
oder in Betrieb genommen,
sondern halt nur über die...
über den Zorn geschmissen.
Über den Zorn gebrochen, genau.
Ja, genau.
Und also das Problem
dabei ist halt, denke ich,
vor allen Dingen, es gibt zwei große Probleme.
Das eine Problem ist halt,
ich würde eigentlich
DevOps im Grunde
als ein Trend
in einer ganzen,
in einem, ja,
was ist das?
Oberbegriff von einem Trend?
Branche.
Wie auch immer.
begreifen,
dass man versucht,
wenn man jetzt
sich diese ganze Strecke anguckt von
man möchte irgendwas machen zu
ist es in Betrieb und die einzelnen Schritte, die dafür
nötig sind, dann versucht man halt immer mehr
Richtung Anfangen
zu verlagern. Also ich glaube, das läuft dann
unter dem Stichwort Shift Left oder so und
der Forms ist halt ein Teil davon, weil es halt
darum geht, quasi
sozusagen den
den Teil halt näher an die Entwicklung
ranzubringen, der halt irgendwie dafür sorgt, dass
das ganze deployed ist.
Naja, aber jetzt sind wir bei Qualitätskontrolle
tatsächlich beim Codeschreiben auch dann?
Qualitätskontrolle, ja gut,
das ist was ähnliches, dass man das halt auch
versucht da, genau, das konnte man halt bei
Qualitätssicherung, macht man das
sicherlich genauso. Ja, so Linting,
Testing, Tests. Genau, man versucht das auch immer
weiter quasi an den Entwicklungsprozess
ranzubringen, beziehungsweise dann halt in die Pipeline,
wie auch immer dann vielleicht
in die IDE, eigentlich noch besser.
weil dann hast du noch einen kürzeren Zyklus
von irgendwie, ich mache irgendwie Unsinn
zu, mir sagt jemand, dass ich Unsinn mache.
Aber es geht
im Grunde darum,
zu versuchen, zu verhindern, dass halt
ein Fehler irgendwann
sehr viel später auftritt, wenn man jetzt eigentlich
schon gar nicht mehr dran ist. Wenn ja zwei Wochen, nachdem man
an irgendwas gearbeitet hat, dann das Feedback kommt,
ja, das war jetzt irgendwie kaputt, dann ist
halt total blöd, weil dann ist man eigentlich schon
völlig anderem dran und dann
weiß man auch gar nicht, was man jetzt noch
tun kann oft.
und... Ja, wenn ein halbes Jahr später irgendeine rote Lampe
angeht, dann sind die Leute, die sich da eingebaut haben,
auch gar nicht mehr da, um das überhaupt zu finden.
Das mache ich da schon. Naja, und wenn du zwei Abteilungen hast,
dann hast du automatisch da halt so ein
Ding, wo das halt... Ja, müssen wir erstmal ein Meeting machen. Jetzt machen wir erstmal
einen Workshop. Ne, wo du halt diese Trennung hast
und wo du es halt, wo es halt sehr schwer
ist, das macht es halt einfach langsam.
Also das, denke ich, ein wichtiger Punkt. Ein anderer wichtiger
Punkt ist halt,
das war halt jedenfalls früher immer so ein Problem,
wenn man das halt in unterschiedlichen Abteilungen hat,
dass man unterschiedliche Interessen hat.
Ja. Das halt, genau,
also die Entwickler werden halt dran gemessen, was sie halt an quasi Story Points oder was auch immer irgendwie aus der Tür kriegen, ja, so an Features rausbringen.
Also wie viele Tickets man dann auf irgendeinem Board irgendwie auf die andere Seite...
Ja, genau. Und die
Admins werden daran gemessen,
wie verfügbar
das Gesamtsystem ist. Und diese
Interessen sind halt unterschiedlich.
Eine sehr einfache Strategie eben zu gewährleisten,
dass halt
quasi nichts schief geht, ist zu versuchen,
alle Änderungen zu verhindern.
Ja, und dann kommt
da noch das QA-Team rein,
die gemessen werden mit,
wenn du einen Wähler findest.
Und das Entwicklungsteam soll ja
Features entwickeln.
und die Fehlerpreisung.
Idealerweise, genau.
Ein QA-Team wird halt irgendwann immer Fehler finden,
selbst wenn es die perfekte Software ist.
Und dann gibt es noch das Betriebs-Team
und die haben ja alle andere Ziele.
Und 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.
Jemand hat Kunde gesagt. Ach, herzlichen Dank.
Deswegen habe ich Endnutzer gesagt,
und nicht Kunden.
Ja, ich meine, Kunden, Nutzer,
irgendeinen Wert
willst du dann ja haben, dann ja auch.
Und das bringt halt nichts, ich meine, das hast du bei
Open-Source-Projekten ja auch so, da bist du ja auch
Kunde in dem Sinne. Ja, genau, Nutzer,
sagen wir Nutzer. Genau.
Wo du dann halt ja auch irgendwie die
neuesten Features von, keine Ahnung, Django zum Beispiel
nutzen willst. Wenn die aber nur alle drei Jahre irgendwie veröffentlichen,
ist das für dich auch irgendwie blöd.
Eigentlich will ich das, was ich schon entwickelt habe,
und dann auch nutzen.
Und das hat jetzt erstmal nichts mit Ops
zu tun oder DevOps
so im Direkten zu tun, aber es ist halt
auch so ein Aspekt, der damit reinkommt.
Das ist ja ein Produkt-Lebenszyklus-Management.
Ja, das sind so ganz
viele Aspekte, die da mit reinkommen.
Und wo ich
nochmal einen Schritt zurückgehen würde, ist,
weswegen ich auch das Beispiel genannt habe,
mit diesen Passwörtern
und sonst was in dem Source-Code, wo die
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?
und die hat irgendjemand festgelegt.
Warum hat diese jemand festgelegt?
Und das ist dann halt wieder...
Aber 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,
sind Monate und Jahre ins Land gegangen.
Genau, und
du gehst schon auf die richtige Spur,
wenn ich darauf hin will, weil eigentlich muss das Thema
ganz weit oben hängen.
Weil wenn man so
schief
Technology Officer oder sonst was
in Großkonzernen oder generell in Firmen,
denen müsste es ja eigentlich
von Interesse sein, also eigentlich
all den Erführungssituationen, 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,
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!
Und da gibt es halt so viele Aspekte und ein Teil davon ist halt eben
DevOps.
Jetzt musst du aber doch nochmal kurz erklären, was
denn diese Platform-Integration-Strategie
und sowas, was das alles ist.
Vielleicht einmal so ganz kurz für alle Leute, die es noch nicht...
Du meinst Platform-Engineering? Ja, ja.
Das ist eigentlich schon wieder...
Ja, Bass wird Reiterei, aber
vielleicht für alle Leute, die es gar nicht kennen,
das einmal kurz... Ich kann es nicht!
Ja, wenn wir von DevOps sprechen, dann reden wir
mehr von dieser Anwendung. Als Entwickler
schreibe ich, also Entwicklungsteam schreibe ich
an Anwendungen, 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 hin deployed
werden, weil wenn jeder irgendwo
auf irgendeiner Public Cloud deployed,
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.
Also ein bisschen mehr noch,
also eher so 200 als 20.
und ja, doch die kleinen Teams, die machen komplett end-to-end alles selber.
Also das Problem ist halt, dass dieses Monster, was da so sonst an Bürokratie und Prozessor von hinter steckt,
wenig mit den Peoples 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 für irgendeine Türe in der Hand haben, durch die du durchgehen musst,
was diesen ganzen DevOps-Prozess
insgesamt 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
da jetzt durch die
IT-Landschaft gezogen wird, es ist halt mehr
darum, dass du das als Service bereitstellst
innerhalb der Firma zum Beispiel, um
sagst, hier ist jetzt
mein Monitoring zum Beispiel
das kann zum Beispiel
erstmal ganz einfach eine Wiki-Seite sein,
wo drin steht, so kannst du dich in das
zentrale Monitoring-System einklinken,
ohne dass du ein eigenes Monitoring-System selbst
hosten musst, als Team von 10 Leuten zum Beispiel.
Was ja Sinn macht.
Und du hast ja ganz viele Sachen, weil
du willst ja eigentlich auch kein
Host-Management selbst machen, CICD selbst machen.
Das soll ja schon da sein, das soll ja jemand machen.
Und das ist dann halt mehr diese,
das sehe ich mehr so als auf der Ops-Seite von
DevOps betrachtet,
weil man dann halt Dienste für die
Entwicklung zur Verfügung stellt.
Du möchtest aber eine Kommunikationsrolle da an der Stelle
aktive
Kommunikation nach außen haben.
Beides, ja. Also letztendlich
sowohl die technologische, dass das aber auch sinnvoll ist.
Ich meine, letztendlich macht die AWS
oder GCP oder sonst was, die machen ja auch nichts anderes
außer Dienstebereitstellungen, die kannst du da 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.
Wo dann halt auch 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,
wie diese Internet-Services, die dann jeder braucht oder sonst was.
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 da Services, die dann sowas wie APIs bereitstellen,
dann gibt es Firmen, die das gut machen, ausgepläutert, da muss man lange Tickets schreiben,
auf die man dann wochenlang warten muss.
Genau, und da fehlt dann wieder die Visibilität, weil du keine Ahnung hast.
Aber schöner wäre es ja dann wiederum, wenn du dann weißt, okay, dieses eine Team macht irgendwie, managt das Prometheus zum Beispiel für die ganze Firma, wo du dann weißt, die braucht eine Änderung, ich gehe da jetzt mal als normaler Entwickler hin, ich weiß, was ich ändern muss, ich führe da jetzt als Merge-Request 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 Nirvana
und ich weiß als Entwickler selbst vielleicht nicht
wo das drin geht, obwohl ich vielleicht Ahnung hätte.
Ja, und es gibt aber dann 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.
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, was macht man denn? Abpreisen,
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.
Ich sehe das tatsächlich so, wenn es schon so in den tiefen
Brunnen gefallen ist und so verzahnt ist und so
verknotet und so weiter.
Ich habe da Probleme
mit das lösbar zu machen,
weil diese Interessen sich halt nicht
harmonisieren lassen.
Ich finde das schwierig.
Ich würde Parallelorganisationen
modern, neu, gut aufbauen,
gute 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 am halben Jahr stecken geblieben,
bist dann auf deinem Termin rausgeflogen,
dann machst du die nächste Transformation, auf der Transformation
jetzt was anderes, Transformation und so wird das
Ganze ein sich ewig
in den Schwanz beißendes Monster
und ja. Ja, ich meine,
was man schon sieht ist,
finde ich, dass, oder mir fällt
gerade noch ein anderes wissiges Beispiel ein,
Da hatte ich mich auch bei der anderen Firma
mit drüber unterhalten. Die hatten ganz viele
Firewall-Regeln zwischen irgendwelchen Bestimmungen.
Und das Ermittlungsteam
musste dann
irgendwo eine E-Mail hinschreiben,
wo dann nochmal drinsteht, warum, wieso, weshalb.
Das mussten sie ganz am Anfang schon machen.
Und ein Validierungsdokument dazu einreichen.
Genau.
Ganz viele verschiedene Sachen, die dann noch mit reinspielen.
Und das ist dann halt irgendwie sehr, sehr
schwierig dann auch entsprechend zu sehen,
wenn dann auch
per E-Mail ganz viel kommuniziert wird.
Oh, ich habe so E-Mail-Ketten erlebt, wie ein Dreivierteljahr eine Kette von 280 E-Mails an unterschiedliche Leute zwischendurch mit Eskalation an verschiedene Management-Layer und dann irgendwie war dann ein Passwort dann verfügbar für einen Zugriff auf ein Sharepoint-Laufwerk.
Ja.
Toll, ne?
Jetzt sehe ich es 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, ist halt 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 auf anderen Merch-Requests, Pull-Requests
oder sonst was aufmachen, so von wegen, und da die
Diskussion machen, weil
das dann nicht in E-Mails hängt, und man
dann, wenn das approved ist, dann auch direkt
ausgerollt wird und nicht erst dann,
wenn es irgendwer dann zehn Jahre
später dann implementiert. Also ich glaube, das wird
halt dann komplex und kompliziert, wenn du halt
kein Unternehmen hast, was jetzt organisch
gewachsen ist, sondern wenn du so Murder-Acquisition-Modelle
hast, wo du halt einzelne Firmen teils
verkaufst und verkaufst und die wild rumschmeißt
und die alle auf unterschiedlichen Stacks und
Kulturen und Architekturen sitzen
und du dann halt das irgendwie
beherrschen willst.
Es kommt auch immer darauf an, wo man hinschaut.
Also
wie weit man das spannen möchte. Manchmal reicht es ja schon, wenn es
innerhalb von, wenn es, keine Ahnung, eine
große Firma ist, wo fünf verschiedene Sachen sind
oder aufgekauft wurden,
mit völlig verschiedenen Stacks, die
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.
Wo man da gar keine Kontrolle drüber hat.
Ja.
Ja, und
genau, das ist auch wieder, also
meine Erfahrung ist auch, dass auch da
das Verständnis oft dann fehlt, wofür
und so was. Was ist denn eigentlich ein Fireball?
Das ist aber sehr
enttäuschend.
Fireball ist was, ist ja sicher.
Die große Waffe.
Die 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 durchdauert
und was nicht. In die eine oder die andere Richtung.
Naja, aber was ist das denn?
Ist das ein Hardwaregerät?
Das ist eine gute Frage.
Ja, aus der theoretischen Sicht würde ich sagen, ja.
Das ist halt ein Konzept zur Umsetzung
und einer Policy am überrennen zwischen den beiden.
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.
Weil, mit einem anderen Kunden mal gesprochen,
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 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.
Ja, aber das würde zum Beispiel, wenn du rein die Route
optimieren würdest, würde sowas unter den Tisch fallen.
Weil du hast von 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, also auch jetzt Beispiel.
Es gibt einen hypothetischen Konzern, der eine Kultur hat,
die, ich sag jetzt mal, relativ konservativ ist.
Und da hast du jemanden, der aber eigentlich so ein modernes
Platform-Driven-Mindset hat, denn er irgendwie versteht,
dass diese Sachen so ein bisschen 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 so rum dauert das denn so lange und wie
teuer ist das denn und du hast halt auch so
da so
die richtige Form finde ich jetzt schwer zu beschreiben, aber wenn
Projekt am Anfang viel Geld kosten und am Ende irgendwas bringen.
Es ist 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änderungen 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, deine Sachen anzubinden.
Also du hast recht,
eine Kultur, die richtigen Leute an der richtigen Stelle
und die richtige
Plattformarchitektur zu finden,
wie man überhaupt Services deployed, 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 er 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,
Businessmodell
der ganze
Aufsichtsrat oder die ganze Vorschlage haben.
Ja, genau.
Oder hast du halt das Problem, ich meine, gerade wenn
der letzten Konsul etwas anderes macht.
Ja, also die verstehen überhaupt nicht, wovon du redest.
Genau, eben. Also das ist die Frage,
was sie erwarten, dass sie damit
beschäftigen wollen.
Vielleicht kriegen 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, das was diese
heute hochkomplexe Geschichte, warum man Cloud
braucht, also 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.
Das ist auch irgendwie komisch
zu verstehen und wo das Netzwerk halt hingeht
und warum man das so weit alles machen muss.
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
eine
allgemeingültige Antwort auf diese
Problematik.
Ich kann ja nochmal eine andere Story erzählen von
den vorherigen Arbeitgeber, wo ich war.
Da war ich aber extern an einer anderen Firma
verkauft, so consultantmäßig.
Und das fand ich auch spannend, weil da war ich quasi
in so einem Ops-Team
um
Firewall-Regeln zu managen.
Das war halt dann deduktiert.
Weil da war es dann halt auch so,
ein Team müsste von A nach B
Firewall-Freischaltung haben. Dann wurde
ein Ticket aufgemacht in einen der 5000
Jira-Instanzen, die es also gab.
Und dann lag das erstmal eine Woche rum.
Dann hat 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 kann
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, sozusagen 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 brauche zum Beispiel
sowas häufiger mal und ich hatte auch überhaupt
keinen Bock auf so einen Prozess und ich habe dann einfach
angefangen, mir so
Requests auszudenken, also echt
Requests, ich habe viel entwickelt
und dann unterschiedlich aus Sachen umgehängt, also
Fehler produziert, weil es muss ja doch
anders sein, also ich dachte, ich habe 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, 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 geschmiert werden.
Genau, das ist der Grund, warum ich das gemacht habe, weil halt irgendwann halt klar wird, hey, okay, da eskaliert
was nach oben und dann gibt es halt dieses Kommunikationsproblem und man muss halt einen neuen Prozess vielleicht finden
oder den Prozess verbessern, um halt irgendwie die Kommunikation und die Kosten, die dadurch entstehen,
so ein bisschen runter zu kriegen. Aber das ist halt krass, weil in so festgefahrenen Strukturen
das sind politisch-taktische
Dinge um da irgendwie weiterzukommen Es ist f ehrlicherweise Ja vor allem da gab es dann noch ganz viele andere Sachen Und da muss ich jedes Mal dr denken wenn ich DevOps rede
weil da gab es halt Entwicklungsteam, die haben das halt entwickelt.
Dann gab es ein
AppOps-Team, die haben
nur die Anwendung irgendwie betrieben.
Und dann gab es nochmal das
Team, in dem ich war. Da ging es dann mehr um
das Betriebssystem und
das, was gebraucht wird, damit das AppOps-Team
da irgendwas hindeployen kann. Dann gab es aber
auch nochmal irgendwie so ein,
ich krieg das nicht mal ganz auf die Reihe, dann gab es aber auch noch
ein QA-Team, was nachgelagert war,
die auch nochmal einen eigenen
Jenkins irgendwo 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, sie sind bei der
Änderung immer hinterhergelaufen.
Ja, auf der Enderung sind unsere Tests kaputt, also oh Mist, was machen wir?
Das waren dann nur so zwei Leute in diesem Team oder was
und der war
total demotiviert
eigentlich die ganze Zeit, weil er
immer nur hinter irgendwelchen Änderungen hergelaufen ist.
Der konnte ja nichts anderes tun.
Und eigentlich macht es halt nicht Sinn, das nachgelagert
zu machen, sondern, wie du vorhin ja auch meintest,
Shift-Left, möglichst frühzeitig das halt auch zu
machen, damit es Teil des Prozesses wird.
Wenn das aber schon irgendwie so
von einer Organisationsstruktur
so aufgebaut ist, dass man gar nicht mit den Teams
redet,
dann macht das irgendwie nicht so viel Sinn.
Ja, auch Security, diese ganzen Regeln, diese Policies,
wo kommen die denn eigentlich her?
Irgendjemand hat ja irgendwann gesagt,
das muss so sein. Der schon rennte.
Ja, aber was auch noch spannend war, ist dann halt das Team, in dem ich dann war, hatte halt mehr so diese Mittelwärter da betreut und da fand ich es halt spannend, da ist dann fast jedes Mal jemand in der Nacht aufgeweckt worden, weil irgendwas im Monitoring gemeckert hat.
und was hat da gemeckert?
Voll oft, weil da irgendwie eine Festplatte
vorgelaufen ist.
Und da kommen wir jetzt wieder auf den Punkt
von wegen verschiedene Ziele,
weil wenn ich als Entwickler nachts
aufgeweckt werde, dann will ich eigentlich nur, dass dieser
verdammte Warnung weggeht
und ich mich wieder hinlegen kann.
Abstellen?
Zum Beispiel, oder halt das Log-File
deaktivieren, weil halt irgendwie
Logs total voll geschrieben hat.
Ja, und was passiert am nächsten Tag?
Passiert halt nochmal und nochmal, aber es gab
keinen richtigen Feedback-Channel zu das eigentliche Team,
um das
eigentliche, weil
das ist halt irgendeine Anwendung.
Ich habe auch schon so Sachen gesehen, also Security-Regeln
total wichtig und alles zugemacht und so weiter,
aber dann brauchte halt jemand irgendein Monitoring, irgendein
Logging-Tool. Was hat er halt gemacht? Also
nicht das Logging konfiguriert und dann irgendwie den
Port-Stecker richtig reingesteckt, sondern einfach alle Ports
aufgemacht, weil er mit seinem Tool da drauf holte.
Ja, und
da merkt man halt, wenn die
jetzt in einem Team wären,
Dev, QA und Ops,
Ja.
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.
Ja, muss man. Oder sollte man,
wenn man Shared Responsibilities hat.
Da ist ja im eigenen
Interesse, dass du eben nicht
jede Nacht wach wirst.
Ja.
Und wenn du aber auch die Person tatsächlich
kennst, die jede Nacht aufgeregt wird,
fragst halt eher mal nach, warum
eigentlich wirst du aufgeweckt und erzähl dir dann
was. Wenn das aber so weit in der
Organisationsstruktur auseinanderhängt,
dass du gar nicht dazu kommst, mit denen zu reden,
wenn du nur über irgendwelche E-Mails und irgendwelche
Ticketsystemen
redest,
dann ist das halt schon sehr, sehr schwierig.
Ich hatte das auch so, dass ich irgendwie im Urlaub
Zeugs machen musste oder sowas, weil
einfach aber die Kollegen, die in meiner eigenen
Abteilung sind, irgendwie keinen Bock hatten, sich
darüber Gedanken zu machen. Und das ist ja noch weiterhin
völlig egal. Sei denn, die müssen es selber
machen. Und dann müssen die sich damit auskennen.
Aber wenn die sich damit auskennen,
dann sagen die so, oh, da weiß ich gar nichts von. Das ist schon schwierig.
Ja gut,
also solche Probleme gibt es natürlich auch immer
noch, aber das ist dann halt schwer zu lösen.
Genau, ja, aber
jetzt sind wir bei demselben Problem.
Man wird ja auch
nicht alle Probleme damit los, klar.
Aber dass du
die Leute zum Beispiel gar nicht kennst,
mit denen du reden müsstest,
wenn du dann bei dem gleichen Team bist, dann hat man
das schon mal nicht mehr.
Das kannst du ja,
du kannst ja auch nicht alle kennen.
Genau, also gerade wenn du ganz viele
verschiedene Teams hast, wir tun ja so, als haben wir irgendwie
100 Projekte gleichzeitig oder sowas, wie würde man denn da
mit den ganzen Leuten, wie will man die alle kennen?
Über Jahre vielleicht.
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,
dann will man ja auch nur eins davon haben,
und will endlich jedes Team das Rad neu erfinden
und alles selbst betreiben.
Das Tooling drumherum.
Und das willst du eigentlich ja auch ein bisschen zentralisieren.
Wie welches?
Ja.
Ja, aber das ist auch wieder eine interessante
Frage. Ich meine, wir hatten jetzt
eben diese ganzen Probleme,
die man hat, 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?
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 ganz 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
es 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.
Entschuldigung, wenn ich nicht gar
aber warum nicht einfach sagen, hey,
wir haben hier so ein Monitoring, bitte sorgt doch dafür, dass eure
Anwendung hier drin hin kommuniziert, also
sowas wie Event Streaming oder sowas.
Naja gut, aber
sag mal so, 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, ne? Ich muss halt irgendwie
Bluehead und irgendwie dann das geben
Aber ich kann die Sachen trotzdem ja alle
noch selber machen
Das verstehe ich nicht
Aber wenn zum Beispiel jemand sagt, hey, ich habe hier so einen Endpunkt, bitte
poste doch dahinter eine 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,
das wäre so diese Monitoring-Abteilung, die könnte
da inzident... Genau das meine ich ja.
Genau das meine ich ja. Das muss ja
jemand trotzdem zur Verfügung stellen.
Bei großen Firmen halt eher als bei kleinen.
Wenn da 50 Leute Firma ist,
das ist ja,
da kannst du ja einfach rüberlaufen, so gesehen, wenn du im Office
sitzt oder jemanden anpingen, das ist jetzt nicht das Ding.
aber das muss er trotzdem ja 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 es 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 das 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
meinen Anwendungsfall erfüllt und sonst
nix. Dann
ist es vielleicht so, dass ich dann besser
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
Redis 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 etwas, was
jede Firma braucht.
Und dann kannst du das lieber selbst betreiben.
Aber wenn es halt so um was Elementares wie Source Code Management
und CICD geht, was halt wirklich jeder braucht.
Ja, klar. Also eigenes Git schreiben ist vielleicht
nicht so über das...
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 dann halt irgendwie so eine
Supply Chain Thematik wieder aufkommt,
wie bei der Log4j Thematik.
Dann fangen sie erstmal an zu gucken,
dann so, oh. Du musst ja dann alles finden.
Richtig.
Und das ist dann wieder
schwierig und dann hast du lieber wieder was Zentrales.
Und genauso macht es natürlich
dann auch bei anderen
monitoren, wie wir es vorhin halt hatten.
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, und dann
habe ich auch das Heftmodell,
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 dahingehend ändert und man dann so ein bisschen
in so ein Dual Diligence
getriebenes Entwicklungsmodell verfällt,
aber nicht weiß, worum es eigentlich geht,
das kann sehr frustrierend sein.
Ja, das ist generell
sowas, was anstrengend ist. Also auch von
mehreren Perspektiven, ja, also auch wenn ich jetzt
was Tolles gebaut habe, dann das abgenommen
zu bekommen und das standardieren 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 10 Jahren keine Lust mehr hatten, sich den neuen Teils anzugucken
und das einfach irgendwie dahingesetzt haben, wie es früher so war.
Das ist halt auch super nervig.
Das ist ein
Kulturproblem.
DevOps, also eine Kommunikationsrolle.
Ja, ich meine,
wir haben irgendwie so über ganz
vieles gesprochen, aber irgendwie,
aber das ist ja genau das, was ich
spannend finde dann halt auch
und genau deswegen dann überhaupt das
Bewusstsein zu schärfen, naja als normaler
Entwickler kann man da ja gar nicht so viel machen, weil
wenn die Struktur, Teamstruktur
wenn man jetzt den reinen Techie anhört und ich würde jetzt mal sagen
wahrscheinlich hören viele reinen Techies jetzt erstmal zu
die können halt nicht
so viel tun, weil wenn es
halt... Dann musst du deine Flight-Level-Kompetenz
ein bisschen raisen
weil wenn ich halt
und ich meine im Endeffekt sind der Entwickler
halt zum entwickeln da
und es
muss halt trotzdem noch Leute geben, die das betreiben
und das sind ja nicht unbedingt die gleichen. Ich hatte jetzt
letzte Woche erstmal mit einem das
Gespräch gehabt, der meinte dann so, ah DevOps findet
er irgendwie doof, nee, ist ja warum denn?
Naja, so wie es bei uns
umgesetzt wird, das finde ich doof.
Wie wird es denn umgesetzt?
Dann so, ja, also das ist ein Großkonzern, den
jeder kennt, den nenne ich jetzt mal nicht
und der
meinte dann halt so, naja,
da sind dann so Entwicklungsteams, sind dann so
5, 6, 7 Leute
und dann gibt es dann halt
viele einzelne Teams,
die unsere einzelnen Services bereitstellen,
wie ich vorhin auch schon ein bisschen erzählt,
und als beratend
quasi tätig sind,
aber die Teams selbst sind für sich einzeln
verantwortlich für alle ihre Microservices oder sonst was.
So,
und dann fragt ihr so, okay, was funktioniert nicht?
Dann so, naja, das sind halt von
diesen sechs Leuten, sind sechs Entwickler.
So,
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
Ressourcen, aber halt überhaupt nicht
der Fokus, der es eigentlich sein sollte.
Ja, das ist natürlich schlecht. Da braucht man auch,
wenn man halt irgendwie alles machen soll,
dann muss man halt auch die entsprechenden Kompetenzen auch alle
da haben eigentlich, ansonsten wird es halt schwierig.
Genau, weil du musst ja die Anwendung entwickeln,
du musst dann auch wissen, wie man das auf
Kubernetes zum Beispiel deployt oder auf OpenShift
oder was auch immer oder wohin auch immer man
deployt. Wenn es halt ein Kubernetes ist, dann ist
ist halt von der Lernkurve
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-Store
anbinden oder selbst hosten vielleicht noch
ganz schlimmer. Und
dann musst du ja noch das House-Code-Management
und das CI-CD-Tool noch bedienen.
Also mehr auf 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.
nach so einem 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,
die dann auch eben irgendwo
laufen müssen. Und da muss man halt so viele
verschiedene Sachen können. Das kann halt nicht
fünf Personen
machen, die nur entwickeln.
Ja, gut, klar.
Das ist halt...
Und wenn es dann so ein bisschen
geshared ist, dann geht das dann ja noch. Aber wenn es
wirklich so rein
rein entwickler ist,
dann ist das schwierig.
Ja, wobei
ich glaube auch, dass es halt
wenn die
also dieses, wenn es halt groß
wird, dann ist es immer problematisch, weil ich weiß auch nicht,
wie will man das lösen. Also Leute,
die halt alles können, wenn man
eine sehr komplexe Umgebung hat, das ist halt, dann
wird immer weniger. Und
das Problem ist aber auch irgendwie, kann man
es halt nicht einfacher machen, weil
weil man will ja davon profitieren, dass man Dinge zentralisiert und halt irgendwie sehr schwierig.
Ich hätte eine Lösung dafür, einfach nicht so groß werden.
Das ist blöd.
Du meinst Microservices?
Nein, nee.
Microservices?
Microcompanies.
Ja, Microcompanies.
Microsoft.
Namen haben wir dann schon mal.
Ja.
Das machen wir nur noch im Betriebssystem.
Ja, ist auch nicht mehr so micro inzwischen,
aber naja, machen
inzwischen auch andere Dinge. Machen die noch
Betriebssysteme? Ja? Ja.
Echt? Ich weiß nicht so genau.
Ich würde sagen, kein Betriebssystem.
Wird das so kraftet? Naja, gut.
Keine Ahnung, aber
ja, also ich,
weil, wenn man halt klein ist,
dann kann man ja diese ganze Komplizität da rausnehmen.
Dann macht man halt irgendwie kein Kubernetes.
Und dann braucht es eigentlich auch,
ehrlich gesagt dann wahrscheinlich nicht.
Ja, das ist wahrscheinlich auch nicht die ganze
Skalierungsthematik.
Also ich habe tatsächlich, der Hauptgrund, warum
Leute, die ich kenne, so kümmern, wenn die das unbedingt haben
wollen, ist, weil sich dann
andere Teams darum kümmern,
was da passiert.
Ja, aber genau, ich glaube, du kannst
das nicht delegieren, du kannst das nicht wegquatschen.
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
das Problem ist halt ja, wenn es irgendwie Änderungen gibt und die
Entwickler gar nicht wissen, wie man halt so eine Python 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 Voids passiert,
weil irgendwelche Versionsänderungen beim
Entfernen von irgendwelchen Migrationen irgendwelche Probleme machen,
weil die Datenbank irgendwie trotzdem SLA hat.
Dann, oh,
ups, da muss man ja doch irgendwas
von wissen halt. Das ist irgendwie blöd.
Ja, ich meine, das ist halt die Frage, wo man
die Abstraktion
macht.
Ja, also der Konzernmisch ist 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 den Menschen,
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.
Und jetzt
komme ich wieder zurück auf die Management-Ebene.
Ich habe genau einen,
ich weiß nicht genau, was für eine Rolle der hat,
relativ hoch bei einer alten Bank
ist.
Oder denkst du, naja, alte
Bank, da ist alles langsam
oder sonst was.
Und der war ganz klar,
lag vielleicht auch daran, dass er ein Ami ist,
der ganz klar
dann gesagt hat,
naja, ich will das hier zu einem Tech-Konzern
umbauen und
das ist halt total ineffizient, wenn
Entwickler anfängt und er muss erstmal 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 freiberuflich
unterwegs, das heißt, ihr habt ja auch dann, wo ihr dann
so, ja, jetzt warte ich noch auf Zugänge für
verschiedene Sachen oder sonst was,
sodass du dann nur noch
einen Zugang bekommst
und dort dann alles mit
komplett idealerweise
durchautomatisiert ist,
so von wegen so,
dass du nachher
Zugang zu den entsprechenden Projekten
bekommst, die du halt brauchst,
dass dann auch 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 lokal jetzt nicht nochmal
gucken musst,
wie installiere ich jetzt überhaupt meine
Entwicklungsumgebung. Ja, aber was ist denn dein Problem?
müssen, weil ich ja mit dem Durchschlüsselloch irgendwie in den Container
rein...
Das kannst du dann ja. Also
bei GitLab heißt das
Remote Development Workspaces,
bei GitHub heißt das zum Beispiel
Codespaces und da kannst du ja
direkt in die Container reinfriebeln.
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 erst mal
den ganzen Stack...
Also klar, irgendwie musst du schon verstehen, wie
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.
Und dann musst du halt theoretisch mal
komplett durchgehen und gucken, was kannst du alles automatisieren,
um das angenehmer zu machen.
Und da können wir zum Beispiel auch mal über
Security sprechen.
Weil wenn wir jetzt mal von Abhängigkeiten
zum Beispiel angucken, finde ich immer ein relativ einfaches
Thema, weil es, also einfach
zu erklären zumindest, weil wenn ich
jetzt irgendeine völlig
veraltete Python-Abhängigkeit
habe, muss ich erstmal wissen,
dass sie 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 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
nachgucken, welche Dependencies es denn gibt, also so ein JavaScript-Ding 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 so, ja, okay, dürft ihr machen
oder die sagen halt so, nee, ihr dürft kein JavaScript nutzen oder so
und dann, ja. Ja, genau. Und du musst dann natürlich gucken,
wie machst du es dann richtig und dann kommen wir wieder zu dem Shift Left so
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,
dass das Projekt gebaut, getestet und irgendwo hindeployed wird.
Aber du hast dann ja auch
zum Beispiel
den Security Scanner, den du ausführen musst.
Also deine eigene YAML-Pipeline hat
irgendwelche Prozesse, die da sind und es gibt
ein Repo, in dem deine eigenen YAML-Pipelines liegen,
die alle nutzen müssen.
Naja, erstmal gibt es ja nur
die Pipeline. Und jetzt ist halt die Frage,
ich möchte jetzt als Firma
durchsetzen,
weil du sprachst ja davon, wie kann man das jetzt machen,
dass man komplett durchautomatisiert zum Beispiel.
Und das muss man ja gucken, wo man das
automatisiert und wo man das dann auch eventuell
durchsetzt. Weil ich
und Jochen unterhalten sich über die Programmiersprache Python
DevSecOps dann entsprechend
DevSec und Ops gleichzeitig
drauf gucken können und das bringt halt nichts, wenn es ganz am Ende ist.
Das ist schon mal das Erste.
So, idealerweise hast du aber diesen Scan
Durchlauf ja schon in der Pipeline drin,
sodass du das schon in dem Tool, in dem du eh schon
arbeitest, dann halt sehen kannst,
was ein Security, wie der
Securitystand in dem Projekt ist, zum Beispiel, wenn
ein Main Development Board ansteht und 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 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
und 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
merchen, wenn du auch wirklich keinen
neuen
Vulnerabilities einführst,
womit du halt schon
so 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
jetzt ein Critical Vulnerability mit einführen würdest,
bräuchtest du jetzt noch ein Review
vom Security Team. Die können also dann, wenn du es
schon einbindest, wenn sie es dann halt schon
sehen. Und als
Entwickler ist dann so, ah shit, ich brauche jetzt noch ein Approval,
eigentlich willst du das ja auch nicht. Also guckst du lieber,
statt einen Downgrade von irgendeiner Abhängigkeit zu machen, lieber
ein Upgrade zu machen und zu gucken, was das eigentliche Problem ist.
Das ist natürlich der Idealzustand.
Wie gut das funktioniert, ist halt die Frage.
Weil das sind halt
zum Beispiel so Policies, kann man ja dann
setzen, genauso wie man Approval Policies halt eben
setzt. Aber die Frage ist dann halt zum Beispiel so,
naja, wie entforst du das Ganze jetzt?
Weil ich hatte vor
Jahren, als ich mal in einem Uni-Projekt
war, da hatte ich dann halt
mehr um die Bildinfrastruktur in diesem Projekt
gekümmert, in so einem Projekt, in dem ich drin war.
Wir waren irgendwie zehn Leute oder so, keiner hatte Ahnung, was sie machen,
jeder hat irgendeinen Scheiß gemacht.
Und einer hat dann angefangen, die Tests
rauszuwerfen, weil sie fehlgeschlagen sind.
Ja, okay.
Genau.
Und das willst du dann mit Security Scanner
ja zum Beispiel nicht machen.
Weil wenn da eine Meldung kommt, so fängt man an zu denken,
du hast jetzt hier so viele, so viele
Security-Volume-Lobilities
drin, dann könntest du ja einfach
als Team hingehen und sagen,
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 Plattes vorgedorfen irgendwas, das heißt,
du musst sie redeployen, weil ohne irgendwie anders
konnte man das nicht, 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, musst das Ding halt wieder hochkriegen.
Ja, genau. Und da kommen wir
dann wieder zu dem Punkt, dass du es an der richtigen Stelle
halt blockieren musst 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.
Weil, ich hatte mal einen Kunden, der hat
dann gesagt, 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 hat dann geheißt, sie hätten das halt
Open Source machen müssen oder sowas in die Richtung.
Und das wurde aber kurz vor der Freigabe
ist das halt aufgefallen.
Das willst du
nicht so spät haben, nicht in einem halben Jahr
später, weil sie 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, 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 Ganze auch unterstützen müssen,
dass man bestimmte Sachen auch enforcen kann, zum Beispiel
Approval Rules, weil wenn wir uns diese XZ-Lücke
nochmal anschauen, da hatten wir zum Beispiel
ja auch nochmal den Punkt,
dass ja in dem Fall einfach Maintainer
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
und dann hätten die wahrscheinlich eh zwei Leute
reingeschleust, aber
wenn man jetzt als Unternehmen
guckt, dann kannst du ja gucken, 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, also
kannst du fast nicht.
Ja, also komplett kannst du es nicht, aber du
möchtest das ja so ein bisschen
so in die Richtung machen, wie die ganzen
Schutzmechanismen bei der Corona-Pandemie,
wo du ganz viele verschiedene hast und je nach
Faktor, die du hast, geht halt nicht alles durch,
aber dadurch verminderst du natürlich
die Risiken.
So wie es bei der Chirurgie halt ist.
Defense in depth quasi.
Ja, ein paar Sachen fangen ja schon an, dass du in dem Tooling
Zweifakt-Authentifizierung aktivierst
für das Housecraft-Management.
Ja, ja.
Das ist dann halt, wenn du irgendwie
durch Phishing oder sowas, dass du dann halt wirklich
oder irgendwie halbwegs sicher sein kannst, dass die Person,
die da was committet, auch die
Person ist, die Zugang zu dem Account hat.
Also du willst zertifizierte Schlüssel haben
quasi. Ja, du kannst auch mit signingen
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.
Also erzwungen halt.
Und das kannst du dann auf der technischen Ebene ja auch erzwingen.
Auch in kleineren Teams.
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, das ist ein Klassiker, ne?
Weil ich habe jetzt irgendwie seit
die ganze Zeit gesagt, hey, wir brauchen Rebus, wir brauchen Rebus,
wir brauchen Rebus. So, ja, ja, dann gibt es halt
irgendwie so eine Kanban, irgendwas,
Python, 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
Jahre Arbeit. Ja, nee, das macht ja überhaupt keinen...
Also, habt ihr schon mal drüber nachgedacht?
und so was, 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, es hält nicht das Deployment auf.
Aber es wird nicht reviewed, ever.
Und dann steht das halt die ganze Zeit im Review
und irgendwann sagen Leute, die Spalte creates aber so voll.
Schiebt das doch auf, dann hat er lange...
Ja gut, ist ja auch eine Entscheidung,
wie man eventuell treffen kann.
Ich verstehe das, das Problem ist nur,
es gibt halt dieses Review immer nicht,
und die
Das ist ja komisch irgendwie.
Das ist jetzt etwas, wo ich denken würde, so
ja, wo
schlägt denn das? Nein,
das meine ich jetzt gar nicht. Das ist nicht das Budget, sondern ich meine
wo schlägt denn das auf, wenn das schief geht?
Ja, bei dem Budgetknapp-Ding.
Oh, das war teuer.
Ich glaube, das ist gerade ein guter
Zeitpunkt, um über die Dora-Metriken zu sprechen.
Kennt ihr Dora-Metriken? Bitte erklär uns das.
Hat gehört, aber kann nochmal erklären.
Die Dora-Metriken sind
ursprünglich vier, mittlerweile fünf Metriken,
um DevOps quasi
auf technischer Prozessebene
zu messen.
Die erste ist Deployment Frequency.
Also wie oft deploy ich
überhaupt die Änderungen, die ich mache.
Und da gilt natürlich,
je höher die Frequenz,
im Moment,
je häufiger du deployst,
desto besser.
Continuous wäre das dann, ja.
Aber da ist natürlich auch die Frage,
nur weil du oft deployst, hast du ja nicht unbedingt, dass du gut deployst.
Ich habe ja nochmal ein Leerzeichen entfernt,
deploy. Ja, das wird halt
theoretisch dann nach oben ziehen Aber du kannst ja auch schlechten Code schlechte Qualit deployen Also ich w zum Beispiel sagen es gibt einen Aspekt wo continuous Discipline gar nicht so gut ist das w 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 zehnmal am Tag
nur einmal am Tag läuft und das halt für den Kunden
keinen Unterschied macht, dann hat man
halt nur ein Zehntel Stromverbrauch für den
Run einer Pipeline. Und wenn das
zu tun. Alle Leute machen würden bei Amazon schon einiges an Strom, was da rausfällt.
Also ich weiß nicht, wenn du beim Arbeiten ein Glas Milch trinkst,
dann kannst du die Pipeline auflaufen lassen. Warum ist die ineffizient?
Genau, also gucken, wie lange dauert
überhaupt die Pipeline auszuführen. Bei einigen dauert das ja drei Stunden.
Und das sollte idealerweise nicht drei Stunden dauern, sonst hast du ein Architekturproblem.
Ja, oder ja.
Aber so, ich glaube
die Idee hinter den Deployment Frequencies
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. So, deswegen hast du
da noch immer die zwei
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, was war es denn
bei Fehlern?
Mean time to recover?
Genau, genau.
Und die willst du dann ja auch
möglichst klein haben.
Also wenn...
Genau, weil das ist halt so ein Beispiel,
du hast ein Security
Issue und ich finde diese Log4j-Thematik,
gut, wir sind im Python-Podcast,
aber das fand ich halt spannend, weil es halt in der
Tagesschau drin war.
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 vielleicht nichts, wenn du
diese Abhängigkeit, die du dann halt hast
und auch vielleicht aktualisiert hast,
wenn das erstmal drei Wochen oder drei Monate dauert,
bis es überhaupt ausgerollt ist.
Egal welches Vulnerability,
es ist schön und dann
werden komische Sachen gemacht.
Oder nur auf die falschen Sachen
geguckt, so, okay, es ist gefixt, aber es wird
dann irgendwie in drei Monaten ausgerollt. Das hilft dann
irgendwie auch noch nicht so viel.
Und aus der Sicht muss man das halt auch
betrachten, dass das wirklich effizient ist.
Also, wie der Unimed-Management-Sicht.
So, also,
da kommen dann halt ganz viele Sachen rein.
Und jetzt fällt mir natürlich die vierte Dorametrik
nicht ein. Das eine
war,
ach.
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.
Dora selbst ist halt so eine
Research-Organisation, die mittlerweile zu Google gehört
und die haben jetzt dann halt auch
entsprechend jedes Jahr diesen
State-of-Devops-Report, den sie rausbringen
und da ist es dann auch entsprechend
spannend, auch mal reinzugucken
wo das
denn genau funktioniert
oder nicht
Change-Failure-Rate
das ist entfallen, genau
Dankeschön.
Genau, wie
oft das überhaupt zu Fehlern kommt.
Weil wenn keine Fehler passieren, dann ist
natürlich gut. Und deswegen muss man eigentlich alle gleichzeitig
betrachten. Das hilft also nichts, wenn du
ständig eine hohe
Deployment-Frequenz hast, aber ständig zu Fehlern kommt
und du ganz schön lange brauchst, bis
die Services wieder recovered sind.
Dann ist das nicht so toll.
Dann willst du lieber mit der Deployment-Frequenz
runtergehen und dann gucken, dass du die
anderen Metriken auch richtig beziehst.
Und deswegen ich das jetzt
zusätzlich noch mal erwähnen ist,
ich habe von einer Firma gehört,
die haben das für die Teams
dann als
Zielvorgabe dann gemacht,
um
deren variablen Bonus zu
...
Und
man muss das nicht unbedingt gut finden.
Man kann das noch gamen, dann ...
Wenn die Metric 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, auch als Definitiven
aber da muss dann halt auch von
der Firmenkultur das auch irgendwie gemacht
werden, aber da fängt es halt bei deutschen Firmen
finde ich schon sehr stark drauf an
also kommt es sehr stark
darauf an, wie überhaupt die Fehlerkultur überhaupt ist
darfst du auch Fehler machen
weil das ist ja das Hauptproblem
Wenn ich bei dir auf die Mädchen gucke, ist immer alles kaputt
wenn da was gehen würde, wirst du das gar nicht mehr sehen
Das finde ich auch interessant, du hast
hauptsächlich quasi deutsche
Kunden sozusagen, oder hast du auch mal
und siehst du da Unterschiede?
Weil ich glaube, das gibt da wahrscheinlich
einige spezielle Probleme hier.
Ja, naja, 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 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 ein bisschen
drauf rum. So von wegen so,
viele Firmen haben überhaupt noch nicht mal verstanden,
dass sie schon eine Softwarefirma sind,
auch wenn sie nur produzieren.
Ja, ja.
Das Einzige, was der Digitalis-Sachkampf
hat, hat 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, ja wir sind ja eine Hardwarefirma
bla bla, und dann so, ja so sieht eure Software
auch aus
Also
ich habe zu Hause einen Wechselrichter
für meine 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
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 Softwareentwicklungsprozessen
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
innerhalb der Firma
also die Softwareentwicklungsteam
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.
Genau, und
wenn es halt intern ist, dann ist halt
erst recht dann mehr Kostcenter.
Und wenn es dann Kunden ist,
dann ist es ein bisschen was anderes.
Aber da
siehst du ja manchmal, manche sagen
dann Kunden irgendwas
und das und das ist total
wichtig und so bla bla bla und dann
google ich das und dann so, weil es dann ja manchmal
so Headlines sind, weil es ein großes Konzern ist, die man kennt.
so, weil wenn ein Kunde sagt dann so, ja, wir mussten hier ganz am Anfang Corona-Pandemie
irgendwie Testmanagement-Software und sonst was, weil wir alle durchtesten mussten bei uns in der Fabrik
oder sonst was, war typisches internes Tool
kurz Firmennamen und Corona eingetippt, so, hm, Massenausbruch
bei bla bla, ein halbes Jahr nachdem Corona schon
lief, ja, vielleicht kam das danach, nicht vielleicht ganz
am Anfang, aber das war dann halt wiederum
ein gutes Beispiel, finde ich, weil da muss es halt wieder schnell
gehen.
Und da ist es dann wiederum
interessant, weil wenn die Firma nicht operieren
kann, weil gerade Pandemie ist
und sie müssen alle durchtesten,
weil halt das
Geschäftsmodell halt so ist, dass du dann halt in
einer Fabrik halt bist zum Beispiel,
dann ist
es halt total wichtig, dass 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.
Aber 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 dem Beschluss
und der eigentlichen Implementierung
oder 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
dem 1. Juli, glaube ich, war das
2020, 2021.
muss 2020 eigentlich gewesen sein, weil mich hat es auch noch getroffen.
Genau, da musste ja jeder irgendwie
deren Software da umstellen, damit die Rechnungen
richtig gestellt werden.
So, und das haben die ja auch irgendwie hinbekommen.
Aber wenn du dann halt irgendwie
wieder nur drei Monate brauchst, um irgendwie eine Änderung
herauszubekommen, wenn du aber gleichzeitig
Mobilfunkprovider bist, der ständig
Rechnungen schreibt,
dann musst du dann halt das richtig
hinbekommen und getestet haben.
Deswegen muss das halt wieder ganz oben sein.
genauso. Neun-Euro-Ticket
hat super funktioniert, wenn man es denn
möchte.
So.
Und dann kam Deutschland-Ticket, das hat dann wieder ganz lange gedauert.
Meinst du das Management,
ja.
Deswegen,
wenn man es wirklich möchte, dann geht es
das schon. Ja, wenn man Durchsetzungskompetenz
hat auch. 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 ihrem anderen
C-Level ist überhaupt vorhanden.
Also das hängt vielleicht damit zusammen, ist es ein Tech
Driven Konzert oder nicht.
Wenn du jetzt bei deutschen Konzerten, wie viele davon haben denn
ein CTO bitte?
Gibt es einen, 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?
Wie sind die auch intern, also haben die von Ansehen?
Der CEO denkt das also, ja, ja, das ist irgendwie der Typ,
der macht das dann irgendwie so nebenbei oder wird er
ernst genommen, das ist auch so ein kulturelles
das Ding wahrscheinlich.
Ja, also.
Also es ist halt oft das Problem, wenn das Kerngeschäft
eigentlich gut lief,
dann hat man keinen Veränderungsdruck
auf solche Strukturen.
Also ich glaube, das ist rational.
Das ist nicht nur so, dass 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
brauchst du eine gewisse Zeit, um halt
so umzubabbeln in einem Konzern.
Und dann bist du dann halt da irgendwie
und überlegst dir jetzt, okay,
und Jochen unterhalten sich über die Programmiersprache Python
Das ist leider nicht vom Konzern
Ich finde das witzig, weil ich musste gerade
an einen Kunden denken, weil da war es auch so
mit dem hatte ich vor 2-3 Jahren zum ersten Mal
gesprochen, da war ein Typ da, der war total
blockiert, da hat er gesagt, nee, das ist zu viel Auffahren und
Migration und überhaupt, also so von
Bitbucker, Jenkins und noch mehr
Jenkins und sonst was auf GitLab zu migrieren halt
Ah, und das ist so teuer und bla bla
und dann passiert ja nichts, dann passiert
ja nichts, halb bis sehr später, da war
eine Rente, plötzlich passiert was
Ja, ich fand
oder denken, warum blockiert er das?
Kann das völlig egal sein? Und die ganzen Entwickler
sind dann so. Das Problem ist halt
genau, wenn er jetzt was macht, dann
wird es ihm halt angerechnet
und wenn
das halt irgendwie dem Nachfolger auf die Füße
fällt, dann ist das nicht mehr sein Problem.
Ja, also der Nachfolger wollte dann ja auch
was verändern. Ja, klar, der hat
dann auch ein Interesse daran.
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 man halt in der Transformationskrise
steckt. Ja, Transformation nach Transformation.
Zu einem gewissen Rahmen ist das ja auch
menschlich so, ne? Weil dann
Veränderungen halt eh immer wieder
was sind, die
du immer anstrengend findest.
Du hast 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 Chef überschritten ist.
Kein großer Fan von dem ewigen Transformationsmonster.
Das, ähm,
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 deine
Kultur,
deine Kulturempfehlung?
Management-Schlangen.
Das ist halt wieder die Frage, wen stellt man diese Frage?
Also wer hört hier gerade zu?
Und wer denkt, also ich glaube, viele, die werden hier zuhören, denken,
ja, ich meine, das hatten wir ja jetzt schon vorher.
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 Off-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,
ich habe früher in meinem ersten Job
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 irgendwie 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 hab halt hingegangen und das ist komplett
durchautomatisiert, sodass wenn eine neue
Version rauskommt, von welcher Distribution auch immer
und das muss ja für verschiedene Distributionen
für Windows gebaut werden, das ist dann halt komplett durch
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 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 mehr Leute mehr Zeit reingeschickt haben.
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
DevOps-Tooling-Krams zu machen.
Und wenn ich manchmal dann
sehe, was für komplexe Strukturen
dann mit Riesenteams, mit Jenkins zum Beispiel
gebraucht werden, das ist halt damals
vor so zehn Jahren oder
vielleicht so sieben, acht Jahren,
oder sechs, sieben Jahren vielleicht noch sinnvoll gewesen,
das mal alles 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 ist,
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
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
einigsteinig mal auch so die Quick-and-Dirty anders
Ja, ich meine letztendlich auch eine Frage von
Build versus By dann ja auch.
Was willst du?
Deswegen gehen auch viele zur Cloud.
Weil man halt auch
viel verkaufen kann und dann ist fertig.
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.
Du hast jetzt aber eigentlich nur über Technologie
geredet und über
diese Kulturempfehlung.
Hat das was mit Open Mindset
zu tun, mit Gross Mindset zu tun, mit
Customer-Centric-Mindset zu tun.
Ich weiß es nicht.
Ding, ding, ding, ding.
Keinen dieser Begriffe je
mal.
Ja,
ich weiß es nicht.
Ich glaube schon, dass es wichtig ist, dass
die Leute wenigstens
Entwicklungen nicht ganz abgeeignet sind,
also dass sie zumindest neugierig
sind. Also ich finde, dass das so
der Teil vom
Commitment, den man mitbringen sollte und wenn man
den gar nicht hat, aus welchem oder immer,
und Jochen unterhalten sich über die Programmiersprache Python
kann, wenn man sich das traut, der hart ist,
aber das muss man halt, gibt es dafür Metrics, I don't know,
ich würde sagen ja. Ja, also ich kann ja
von mir aussprechen, was mich motiviert bei
der Arbeit.
Für mich und im Vergleich
zu den früheren Firmen,
wo ich war, da war
bei den alten Firmen immer das Problem, fand ich,
ich hatte halt überhaupt keine Ahnung, was ich da überhaupt
tue. Also klar, ich wusste, was ich für mich
tue, aber was das
im Gesamteffekt für die ganze Firma ausmacht,
keine Ahnung, ich hatte keine Ahnung,
wie das hindeployed wird, das ist schon mal das
1. 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 drum herum gemacht,
aber ich hatte keine Ahnung, wie das jetzt ganz so funktioniert.
Und so
visionsmäßig...
Also ich würde sagen,
für mich wären es jetzt so zwei Sachen.
Also eins der wichtigen Sachen ist halt so,
ich glaube, du meinst was dasselbe ist, why?
Also warum value?
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 keine externen Welten drin findet,
also weil die Kundenwelt ja 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 Intentions.
Genau.
Kann man das
balancen?
Ja, irgendwie ist das ja für jede Person ja auch ein bisschen
individuell. Du meinst die
Values? 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 habe, 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, was ich halt dann besser finde als, keine Ahnung, bei irgendeinem
Cloud Provider zu sein, bei einem US Cloud Provider zu sein, wo ich halt auch ein paar Leute kenne,
wo der Sinn und Zweck deren Jobs ist, also meines
ä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. Das Businessmodell ist halt einfach ein bisschen
anders. Ja, genau. 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? Also, weil mich fragen
dann auch so Leute, naja, willst du,
wie wenn wir GitLab selbst betreiben,
dann sag 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
aus 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,
mit dem so, pfff,
Ja, aber ich bin immer mehr so
in der 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
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.
Und
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.
Aber es kann in anderen Bereichen nicht 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.
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 Beientscheidungen zu treffen.
Du sagst, sie ist wichtig.
Beispiel jetzt, ich weiß nicht, VMware oder sowas,
die auf einmal jetzt ihre Lizenzkosten
alle Leute
kriegen. Ja, das war und dann
alle Maschinen laufen auf, wie können wir das machen? Ja, verdammt, müssen wir jetzt
schucken für die nächsten drei, vier Jahre.
Ja, aber da ist auch wieder
irgendwie selber Schuld so ein bisschen.
Und ich meine, dieses Böse,
also wer jetzt irgendwie
große Schmerzen hatte mit dieser Geschichte, der sollte sich gut
überlegen, ob er All-in-Cloud-Native
repräsentiert, weil das
kann ganz genauso wieder sehr, sehr schmerzhaft
werden. Also auch LLMs,
wenn man da einbeinbindet mit seiner
neuen, wie nennt man das,
Analytics
Dings über Infrastruktur,
Insights, lalala, keine Ahnung, ich wollte die ganzen
Drücken anwenden, ich aufzeige.
Egal, aber ja, natürlich, also das
ist, ja,
das ist ein Problem.
Aber um nochmal auf deine Frage zu kommen, bezüglich was meine Empfehlung ist, ein Punkt, worüber man DevOps ja auch anders betrachten kann, außer die Dorometriken, ist ja auch noch das CALMS-Modell.
Hast du auch in deinem Buch direkt am Anfang erwähnt.
Ja genau, weil das ist dann ja die WU-Scharm C-A-L-M-S, C für Culture, was wir jetzt ja 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 halt techy, genau, kannst du das nämlich gut machen, aber wenn du halt
Scheißprozesse automatisierst, hast du halt immer noch Scheißprozesse, die werden aber wenigstens automatisiert.
Ja. So, wenn dadurch Fehler passieren,
du aber eine schlechte Kultur in dem Sinne hast, dass du gar keine Fehler
machen darfst, was also sehr, sehr gefährlich ist... Wenn du so einen Prozess weiter hast, wie willst du den überhaupt
erst verstehen, weil du kannst den ja quasi nur
optimieren, 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, also die Kundenperspektive.
Und das ist das Hauptproblem, was
du an guten Architekten, auch bei Projektmanagern
übrigens hast, dass die meisten Leute, Peter, auf der einen
oder der anderen Seite richtig drüber sind.
Ja, ich meine, wenn wir über Kultur
sprechen, wir kennen ja verschiedene
Abstufungen sein. Es reicht ja schon, wenn du
Fehler machen kannst, machen darfst.
Wie handhaben wir Fehler?
So in Richtung Blameless
Postmortems zum Beispiel.
Dass wir überhaupt mal aufschreiben, was ist
überhaupt ein Fehler passiert, was war da
eine Root-Course-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 da der ist schuld, aber trotzdem
benennen, was schiefgegangen
ist und wie wir das ja zukünftig
verbessern wollen.
das ist dann halt eben die Frage, also 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 Lieblingsbeispiel
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 Primary gemacht
und dann war halt
GitLab.com damals offline, ich glaube das war
2016, 17, ewig lange her
so und
der ganze Fehlerprozess wurde
und ich habe 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 Backups
verschiedene Backups-Methoden
gab, die aber alle nicht funktioniert haben.
Weil die nie jemand getestet hat.
Ja, klar.
Und viele aus meinem Umfeld,
die ich dann also kannte, die haben dann erst mal angefangen,
im Unternehmen zu gucken, ich glaube, ich teste
mal meine Backups.
Ja, sollte man tatsächlich machen.
und das sind halt so Sachen, wo du dann ja auch von anderen Firmen lernen kannst.
Genauso wie du von der XZ-Lücke lernen kannst,
was kann ich davon vielleicht in der Firma adaptieren oder sowas.
Und das trauen sich ja schon viele nicht, wenn Fehler passieren.
Oder zuzugeben, 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 an, die Sachen zuzuschließen und nicht wieder aufzumachen.
Ja, und spannend finde ich das jetzt auch nochmal,
das ist ja noch irgendeine Direktive, die NIST 2
Direktive oder sowas gibt
wo ja auch
das Management
verantwortlich gemacht wird
wenn du als Firma
eiklatante
Sicherheitslücken hast oder sowas
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 dafür das, was er möchte
in so Finanzindustrie und vielleicht
aus Automotive-Sachen. Da gibt es nochmal ein bisschen
der 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 einem Autokonzern
gehört, so von wegen, da hat er einen
und Compliance-Regeln haben wir eigentlich schon so einen Sinn,
warum es diese gibt. Und häufig sind es halt irgendwelche
Excel-Listen, wo du einen Hacken machen kannst oder eine
Conference-Liste oder sowas.
Und einer hatte überhaupt nicht das Problem gesehen,
den Hacken zu machen, habe ich
getestet, ohne irgendwie den Nachweis zu haben,
dass er es wirklich getan hat. Und viele
Sachen kannst du ja schon automatisieren
und so ein Reporting machen, was vor allem
bei dem Banken-Finanzumfeld
kam nämlich bei mir die Frage
nämlich ganz oft auf, wie kann ich
dokumentieren, dass auch wirklich
ein Change, den gemacht wurde, dass das auch
wirklich zwei Leute reviewed haben,
zum Beispiel.
Wer reviewed denn? Der eine von den anderen?
Würde einem niemanden gegen den Schienbein treten,
weil man Ärger kriegt, wenn man irgendjemandem was aufhält?
Nee, also da, wenn du
als Reviews, da bist du ja auch
betroffen, also sozusagen, da hast du
schon ein Interesse auch, würde ich jetzt mal so
vermuten, dass
das ja auch vielleicht, wenn das wirklich...
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 zusammenhängen muss,
ist auch wieder die Frage.
Ja, ich meine,
mein Blickwinkel jetzt ist
jetzt mehr so, naja, ich habe jetzt
eine, ich habe jetzt verschiedene
Regeln, die müsste ich auch umsetzen, die müssen
dann auch gemacht werden und die muss sie 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 gar nicht
wissen, wer da was committed hat oder sonst was
oder welche sich halt Sachen im Audit-Trail
Thematiken, wer hatte wo Zugriff
oder sonst was.
Das muss halt auch irgendwo angehakt werden und bisher ist
es halt sehr, sehr stark, finde
ich, danach getrieben.
Jeder macht halt das, was er möchte.
Und es gibt halt
also generell, ganz ganz allgemein
und ich glaube, das kann
zukünftig jetzt nicht mehr so viel
so gut weitergehen. Das Problem ist jetzt folgendes,
hast du keine Leute, die haben von Security eigentlich gar keine Ahnung
und die stehen halt dann da. Also das Problem
bei der Compliance ist halt immer, das tendiert
dann auch, also ein
Modus, in dem das dann schief geht, ist halt
auch das, dass man das Ganze zu so einem
Theater verkauft, was halt
tatsächlich 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
und 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 Close machst, geht es halt auch nicht.
Oder du bist halt auf irgendwelchen ganz Legacy-Geschichten,
wo dann auch eigentlich die CVEs
alle offen sind, weil du nicht hinterherkommst,
damit die Sachen zu patchen. Du musst halt
irgendeinen Tod dann da sterben.
Ja, irgendwas hast du immer.
aber worauf ich noch hinaus
wollte ist, dadurch
dass du ja die
also weil ich ja meinte, so naja, für einiges
ist es einfach nur was abhaken, ohne was wirklich zu testen
da gibt es ja Leute, auch Führungstreffer
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 Autofirm kommt, wo du dann denkst, so
also ich möchte schon wissen, dass
wenn ich die Bremse drücke, dass es auch wirklich bremst
so das soll
und dafür gibt es ja eine Regulation
Systemfehler, Systemfehler, Systemfehler
Yeah, genau, da nur.
oder sowas sonst was.
Weil das soll ja schon funktionieren, das soll ja auch getestet werden.
Ich glaube, da sind
manche auch Leute irritiert, wie das bei Tesla
oder sowas geht, weil die pushen ja auch viele Änderungen
schnell raus. Aber das kommt immer darauf an,
glaube ich, 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.
Oder wo auch immer
du da was tanken kannst, laden kannst.
Das macht halt schon einen deutlichen
Unterschied.
und deswegen muss man auch ein bisschen unterscheiden,
was für Software reden wir jetzt hier, aber
ich meine, man muss ja nur auf den
Chaos Communication Congress 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.
Also ich würde sagen, nein.
Ich würde sagen, Prozess hilft nicht.
Ja, die Prozesse müssen gut sein.
Ja genau, so 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
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 die Lösung ist, das heißt du musst irgendwie rumexperimentieren
und du kannst ja, also
tolles Beispiel jetzt in der Ökonomie
und du überlegst dir irgendwie so eine Policy für so ein Land, wie es aus irgendeiner Schuldenfalle rauskommt,
Entschuldigung, ich muss das falsch gerade nehmen,
und dann fängst du halt an mit so einem
Bevölkerung zu experimentieren, was denn
eigentlich alles funktionieren könnte, und dann hast du vielleicht
so ein paar Spielbälle, das dauert dann halt 10 Jahre, bis du den Effekt siehst,
dann merkst du dann 10 Jahre später so, ups,
keine Ahnung, BIP ging runter,
Lebenserwartung
ging runter,
die Wirtschaftsversorgung ging runter, dumme Idee.
Mein Punkt war ja auch mehr, dass diese
Compliance-Thematik, die es ja schon in der
Finanzbranche gibt,
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.
Das ist ja nochmal ein weiteres Problem.
Und die Frage ist halt,
was dein Ziel ist, auf was optimierst
du dann? Also willst du überhaupt
ein Auto haben, das fährt in dem Beispiel, ja?
Oder
möchtest du halt dann die Veränderungen beschränken?
Und das ist glaube ich,
das ist halt ein Dreieck, in dem du
und Jochen unterhalten sich über die Programmiersprache Python
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, dass es Leute haben, die am Anfang total neugierig
sind, aber die keinen Bock mehr haben, weil
der Rest irgendwie von Values oder sowas
die immer wieder gegenwärtig waren ist.
Das ist 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 habe dann, also sie saß dann
vor diesem Kapitel in dem Buch, was sie da schreiben
wollte und dachte so,
Jo, 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 Durchlaufdinge zu optimieren, Intentives an die richtigen Stellen zu setzen, also um das Ergebnis zu verbessern.
und die K in der w jetzt sowas wie tats zu versuchen alle Faktoren die es gibt selbst wenn es 295 sind zu identifizieren und auf jeden einzelnen
Kosmos,
was dann, keine Ahnung,
ein Stadtwirtbild 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, und das sind
ja, warum ist die Technologie so teuer?
Ja.
Also,
sag mal so,
ich glaube,
wenn man jetzt guckt, wie
sieht es denn im Alltag oft aus, dann ist das, glaube ich,
nicht so schwer, da 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 ändern zu können.
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,
brauche ich jetzt überhaupt diese hunderte Tools,
die ich da so drin hab, weil da gibt's dann tatsächlich
so, ich mein 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
ich manchmal so sehe wie viele Tools da sind
weil was ich gerade ja
noch ignoriert hatte war ja sowas wie
Package Registry, Container Registry
und
die Pendency-Proxie
und dann haben wir eigentlich für alles
wirklich ein eigenes Ding und
was sonst hä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 so einiges gibt es auch keine Lösung.
Es gibt ja nicht unbedingt, also
zum Beispiel wird vieles abgedeckt,
ein 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,
OpenTofu
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.
Ja. 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,
da können wir jetzt auch nochmal eine Stunde reden,
was ist ein DevOps-Engineer?
Auch wenn man jetzt mal von, es sind häufig ja die
Leute, die dann irgendwie von allem etwas können, aber
nichts ordentlich, so ein bisschen wie ein Full-Stack-Entwickler.
wurde halt auch immer die Frage gesagt,
okay, was,
wie ist da die Teamstruktur?
Idealerweise ist es in DevOps-Engine halt der
Mensch, der halt in die Teams geht
und das die
der von uns zusammenbringt
und halt sowohl auf kulturell
als auch die Tools dann
ein bisschen verdrahtet miteinander.
Ist es ein Schweißer, der die Sachen zusammenschweißt
oder ist das jemand, der nur die Knoten macht?
Genau.
mit mehrter verschiedenen mit.
Und dann, wenn sie fertig ist, ist er fertig, dann kann er halt wieder raus.
Sollte halt keine eigene Rolle in einem Team sein.
Aber es macht schon Sinn,
dass es ein Team gibt, die dann halt
Pipeline-Bausteine baut,
weil eben
Deployments
auf Kubernetes gemacht werden sollen zum Beispiel.
Und das halt
unternehmensspezifisch oder sowas ist dann Also deswegen da kann man schon vieles machen Aber es ist halt sehr abh 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 es halt auch alles so.
Auf der Tooling-Ebene muss halt auch irgendwie
deployed werden, aber
darum geht es mir ja auch.
Der Toolstack sollte wirklich einfach gehalten
sein, dass man eben
nicht so viel darüber reden muss.
Das verpeist dann oft nicht ganz. Also wenn du halt zum Beispiel
dieses ganze Linting drumherum definieren musst
und das ganze, wo kommen die Pakete alle her,
definieren musst, dann 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.
Aber so aus DevOps-Sicht
und Jochen unterhalten sich über die Programmiersprache Python
natürlich immer so ein bisschen, wenn es kompiliert,
dann ist es auch okay, aber ich
weiß es nicht so genau.
Unsafe, unsafe.
Nee, gar nicht unsafe,
sondern einfach so, ja.
Ich weiß es nicht.
Also,
ja.
Ja, ich glaube,
da fällt uns auch nicht mehr so viel ein.
Ja, ich bin gespannt.
Aber die kulturelle Sache haben wir, glaube ich, schon festgestellt.
Es ist ja relativ offen und es ist noch nicht so ganz
klar, was das überhaupt heißt und es gibt
Aber ist das nicht auch immer, oder das würde mich
mal interessieren, gibt es 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 glaube, es ist tatsächlich ein Problem.
also Kultur überhaupt zu verstehen
und das zu harmonisieren und
das zu implementieren
Kommunikation ist eine wichtige Rolle
Natürlich können einen Sachen
halt aus so einer gewissen
botanischen
Interesse halt irgendwie
beschäftigen, 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 selbstverständlich ist, was es aber nicht ist
und das 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.
Man bringt sich das irgendwie weiter.
Ich glaube schon.
Ich würde sagen, man kann das jetzt alles, man könnte jetzt
aufschreiben und macht dann halt irgendwie, keine Ahnung,
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...
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 so was...
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.
Ich habe auch viel mit Leuten drüber geredet,
und so weiter Das hei du willst sagen viel zu teuer einfach machen wir es fr Nee das nicht sondern vielleicht auf Dinge gucken wo man Sachen ver kann Aber ich meine gut das ist jetzt etwas
defetistisch, aber...
Okay, ich glaube,
das ist Schlusswort.
Nein, nein, das muss auch jemand was Optimistisches
sagen.
Finde ich das gut.
Habt ihr einen Pick euch ausgesucht?
Ich habe tatsächlich heute keinen.
Du hast keinen? Nein, heute nicht.
DevOps,
Ich
Schreckli 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 IDE ist, 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
PyCharm 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
und
jetzt wollte ich in letzter Zeit mal wieder ein bisschen
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
total kompliziert geworden
und dann habe ich
immer mal so ein bisschen angefangen und dann wieder abgebrochen
und dann habe ich gedacht, 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 LazyVim.
Und
ja, das macht dann einen
Großteil der Konfiguration. Also es hat bei mir
dazu geführt, dass ich jetzt wieder mehr Vim
verwende, beziehungsweise NeoVim,
aber ja.
LazyVim. Das macht die ganzen
in den Geschäftsverkram, so wie man es nicht möchte.
Das meiste davon.
Ohne Konfiguration kommt man damit auch nicht aus.
Und man muss eine ganze Menge Zeugs installieren.
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
es ist deutlich
einfacher, als wenn man das jetzt irgendwie
von Grund auf selber machen wollte.
Tagsbisschen nicht schonend. Ich würde das ja auch gerne nochmal in Angriff nehmen.
Aha.
Ja.
Hast du ein Pick gemacht?
Irgendein Tool vielleicht im DevOps-Bereich,
der das irgendwie voll interessant wäre,
wo man was drüber erfahren könnte.
Da gibt es vieles.
Tatsächlich jetzt gerade aus dem Stehgreif jetzt nicht,
ich habe auch nicht vorher drüber nachgedacht.
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.
Ja, dann vielleicht noch
M-Boys oder so.
Was ist das?
und
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 Vokoder, ein bisschen
Reverb, ein bisschen Echo, ein bisschen, ja, egal.
Wundervoll, dass ihr uns wieder zugehört habt
und bleibt uns gewogen
Hallo at pythonpodcast.de für jedes Feedback, Anmerkungen, Anregungen usw.
Vielen Dank an dich, dass du heute da warst
Ja, vielen Dank
Danke, dass ich da sein konnte
Und dann hört uns wieder rein
Bis zum nächsten Mal
Tschüss