Transcript: Devops Redux

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.

Ja.

Ja.

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.

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