Willkommen zu einer neuen Episode vom Tilpott. Hier im sehr verregneten Grüß, der Dirk und da hinten im, was für ein Wetter habt ihr? Nass, auch sehr nass. Im sehr nassen Castro Braux ist der Sujivan. Guten Tag. Guten Tag. Wir sind bei Episode 62 und wir haben fünften Geburtstag gehabt, wenn diese Episode erscheint. Jippie. Ich wiederhole es jetzt nicht, dass es ein guter Zeitpunkt wäre aufzuhören. Nein, aber wir hätten beide nicht gedacht, dass es so lange hält. Aber wir sind noch dabei. Genau. Aber erstmal zum Vorker-Pinker. Genau. Da gab es gar nicht... Ja, mach du. Diesmal haben wir gar nicht so viel Feedback bekommen. Oder zumindest nicht aktiven. Was man schon erwähnen kann, ist, wir hatten zuletzt auch häufig irgendwie Diskussionen über was sind gute und schlechte Dailies im Unternehmen. Und das ist, also der Konsens ist, und da waren sich glaube ich alle einig, das Standard-Daily ist schlecht. Also das Standard-Daily im Sinne von so, wie es viele machen. Genau, so als Hausaufgabenbesprechung oder dass jeder einen Rapport macht, wo eigentlich der Teamleiter informiert wird, das kann man auch anders machen. Das könnte dann wirklich schriftlich passieren, aber die Leute im Chat waren dann auch der Meinung, dass Dailies durchaus sinnvoll sein können, vielleicht in einer anderen Frequenz. dann dürften sie eigentlich nicht mehr Daily heißen oder aber mit anderem Inhalt und auf anderen Inhalt konnten wir uns glaube ich alle einigen Ja. Ich fand davon Stöbbs die Aussage lustig das fühlt sich manchmal an wie der Kindergartenstuhlkreis Ja genau, das hat viel, Genau. Dann sagst du noch was ganz Kleines, was wir gelernt haben. Und zwar sagen wir immer so lustig, Kastor Brauxel ist Lateinisch für Wanne Eickel. Und weil der Postillon das neulich gepostet hat auf Mastodon, hat da jemand darunter noch geschrieben, er kam blind vor das Englisch für Wanne Eickel, wo du hier herkommst. und Neheim Hüsten ist niederländisch ebenfalls über Neike. Ist schon sehr lustig, also wie der Doppelname so die Runde macht. Ja, eigentlich fehlt ja noch Neukirchen Vluin. Oder wie auch immer das ausgesprochen wird. Ich meine Vluin. Neukirchen Vluin. Ja, irgendwie so. Das ist ja auch hier die Ecke. Oer-Erkenschwick heißt es. Ja, aber eigentlich, ich sage immer O-Erkenschwick. O-Erkenschwick? Effektiv sage ich das so. Ich meine, du kommst ja aus den Tropen, wissen wir ja alle. Waldtrop, Kastrop, Bostrop. Genau. Damit habe ich mal Leute irritiert, weil ich bei Hitler auch einen Kollegen hatte. Auch ein Deak, der Spottrop kam und wir hatten uns dann irgendwo mal mit als die Leute aus den Tropen vorgestellt. Das hat Leute irritiert. Das ist das glaube ich sofort. Eher ein Insider. Früher war es so, dass man Wanne Eickel auch eher kannte als Herne, wo es mittlerweile oder seit 1974 ein Teil von ist. Aber Wanne Eickel kannte jeder Herne, kannte keiner. Ja, Wanneikel ist auch größer als Herner, oder nicht? War, war, war, war. Ja, also wenn man... Schon ewig, ja, ja, ja. Ja, warum auch immer man das so eingemeindet hat, ich weiß es nicht. Im Zuge der Gebietsreform sind viele größere, viele erfolgreiche Städte, den nicht erfolgreichen Städten eingemeindet worden. Das ging mit Wattenscheid und Bochum so. Das ging mit Kettwig und Essen genauso. Und das ging mit Wanneikel und Herner eben auch so. Warte, die nicht erfolgreichen, die erfolgreichen oder andersrum? Die Erfolgreichen wurden von den Nicht-Erfolgreichen geschluckt. Warum das denn? Genau. Andersrum würde ja mehr Sinn machen. Gemeindereform irgendwie 1974 oder 1975. Ja, da gibt es einige. Aber da sind halt die ganzen, eingemeindeten Städte entstanden. Es gibt ja auch Henrichenburg, was dann damals eingemeindet wurde in Kastropraux. Genau, da hat Henrichenburg ein Schiff das Hebewerk. Wenn man Kinder hat, ein schöner Besuch. Ja, da fahre ich manchmal mit dem Fahrrad lang. Wenn man Kinder hat wie Sushi, dann kann man da gucken. Ich habe keine bekannten Kinder. Das ist ja selber eins. Also. Jeder war mal Kind. Genau. Wir sind als Kinder da mit unseren Eltern mal gewesen. Schon ewig und drei Wochen her. Ja, aber es ist auch in Datteln. Echt? Naja, es ist da ja direkt an der Grenze. Zwischen Datteln und... Also ich verbinde mit Henrichenburg immer das Schiffshebewerk. Ja, genau, aber das Schiffshebewerk gibt es ein altes und ein neues. Und ich bin mir gerade nicht sicher, welches ob das andere nicht sogar in Datteln steht, weil es drei Meter weiter ist. Das neue kenne ich glaube ich nicht. Das neue gibt es auch schon seit ein paar Jahrzehnten. Aber so modern bin ich nicht. Das bekommen ja die Hörer hier eh im Podcast schon immer mit, dass ich nicht so modern bin, ja. Genau. Ja, okay, es ist komplett an der Grenze. Ich habe nochmal nachgeschaut. Aber es ist irritierend manchmal, wenn du da langläufst. Und dann siehst du an der einen Straßenseite das gelbe Ortseingangsschild für Waltrop und auf der anderen Seite dann Datteln. Okay. Weil du dann direkt an der Grenze langläufst oder fährst. Ja, genau. Und das gehört zu Kastrup-Rauxel. Nee, das nicht. Henrichenburg? Ist das nicht? Nein, ich meine Datteln und Waltropf. Henrichenburg ist der nördlichste Stadtteil der Stadt Kastrup-Rauxdländer. Das ist korrekt. Und Krems an Waltropf und Datteln. Auch da, bis 1975, also bei der großen Gemeindereform, genau. Genau. Ja, willkommen bei Tilpott, dem Gemeindereform-Podcast aus 1974. Genau, lange vor deiner Zeit. Auch lange, bevor meine Eltern nach Deutschland kamen. Ich bin 1974 in die Grundschule gekommen. Ja, meine Eltern sind 85 nach Deutschland gekommen. Ei, ei, ei, ei. Du könntest mein Vater sein. Ich könnte wirklich, vom Alter ganz bestimmt. Genau. Ja. Aber lass uns bei uns gemeinsam was gehen, sprechen, was das für uns fehlt. Was ist es geworden, ein Elefant? Da ist es schon raus. Genau. Fünf Jahre Till Pott. Genau. Voll krass. Das crazy, sagt man heutzutage. Das crazy. In den Sendungsnotisten habe ich noch ein A hintergeschmissen. Voll krass A. Ja, haben wir glaube ich beide nicht gedacht, dass wir so lange durchhalten, oder? Ja. Also ich habe nicht darüber nachgedacht, ob es lange hinten kurz wird. Ehrlich gesagt. Ich habe zwischendurch mal gesagt, für wie lange das was wird, weil ich ja schon einige Podcasts auch vor dir hatte. Ich hatte Podcasts vor dir. Ja ja ich bin der zweite oder dritte. Wahl bist du vierte wahl ja musst du halt durch aber ich bin bin froh dass wir das so lange gemacht haben und ich, Wir haben am Anfang eine unfassbar lange Themenliste gehabt und dann, wie es immer so ist mit unfassbar langen Themenlisten, dann guckt man da zwischenzeitlich mal rein und dann merkt man, wie es da in den Schubladen stinkt und dass man da Themen wieder rausbasteln muss, weil eigentlich keiner mehr Bock drauf hat. Ja. Eigentlich war mein Plan ja auch gewesen, dass wir die Themen, die wir so behandeln, weil wir sie halt im alltäglichen Leben ja behandeln, dass wir die dann halt, also wollte ich eigentlich, dass ich meine Themen dann halt auch nochmal runterschreibe und dann verblocke oder andersrum erst verblocken und dann hier im Podcast besprechen, um halt so aus einem Content dann mehrere Ausgabeformen zu haben. Ja. Hat, glaube ich, nicht so ganz funktioniert. Wie oft? Einmal? Keinmal? Naja, nicht geplant. Also ich habe es dann ungeplant dann halt ja schon gemacht, aber jetzt nicht so konsequent. Hey, wir haben jetzt ein Thema für die Podcast-Folge. Oder andersrum habe ich es schon gemacht, dass ich manche Themen hatte, die ich dann halt hier und da schon behandelt habe und dann halt dann, okay, daraus machen wir jetzt eine Folge draus. Was für mich super erstaunlich war, ist, dass wir, wir haben ja Matrix gewählt als Chat und nicht Telegram, was damals noch angesagt war. Und ich habe nicht gedacht, dass es so voll wird im Chat. Also wir haben über 100, Teilnehmer, wovon auch sehr viele sich tatsächlich an Diskussionen beteiligen. Ja. Also nicht nur Teilleser oder wir haben auch Teilgeber. Genau. Und nicht nur wir. Und nicht nur wir. Genau. Genau, das finde ich echt cool, weil das auch irgendwie so eine lose Freundesgruppe, erweiterte Freundesgruppe, oder weniger geworden ist mit einigen. Sowohl da drin selbst, als auch ein bisschen außerhalb. Ja, wir haben ja so Sachen noch versucht, wie den Buchclub oder die Ironblogger oder die Strava-Gruppe. Das war am Anfang mal ein bisschen Betrieb drin, aber es hat dann irgendwie nicht lange durchgehalten, oder? Ja, genau. Stimmt, Ironbloggen, das habe ich auch schon ganz vergessen. Ja, also Iron Blogging bedeutet, dass man sich gegenseitig verpflichtet, einmal im Monat einen Artikel zu schreiben. Wenn man das nicht tut, dann war man verpflichtet, einen Filmwein in die Kasse zu werfen und die Kasse ging dann an einen gemeinnützigen Zweck. Genau, und das war zuletzt immer Sea-Watch gewesen, aber dieses Jahr haben wir, glaube ich, da fast gar nichts mehr gemacht. Nein, das ist komplett eingeschlafen. Ja, ja. Genau. Ja, ich fand es grundsätzlich cool. unser Format, unsere Struktur gefällt mir auch, dass wir halt verschiedene Themen haben, die wir dann auch eben ranbringen können. Nicht nur technische Sachen oder karrieretechnische Sachen, sondern halt auch irgendwie persönlich die Hobbys wie meine Ultramarantons. Oder die Therapiestunden, wenn es ums Schreiben meiner Bücher geht. Ja, ab nächstem Jahr brauche ich wieder Therapiestunden. Gerne. Ja, einzig mein Gesprächsvater, den finde ich doof. Ja, den kann man sich halt nicht immer aussuchen. Aber wie es halt mit Zweckgemeinschaften ist. Wenn man Erfolg haben will, dann kann man sich nicht immer den Partner aussuchen. Das ist schon so. Genau. Was ich ganz gut finde, ist, dass wir einen fixen Release-Termin haben, also eigentlich immer am 1. des Monats veröffentlichen und manchmal als Bonus dann quasi nach einem 15. des Monats. Das haben wir auch zweimal gemacht oder dreimal. Gut, eine Auswahl hatten wir ja. Fällt mir gerade ein. Genau, da warst du gerade. Genau. Aber ansonsten hat das ja ganz gut funktioniert. Ja. Das hilft mir eigentlich auch immer, dann darüber nachzudenken, weil hätten wir jetzt, glaube ich, keinen fixen Termin, dann würden wir ständig was aufschieben und dann nichts aufnehmen. Und ich merke auch, wir haben ja tief gestapelt, wir wollten ja beide mehr machen und wir haben gesagt, aber einmal im Monat müssen wir hinbekommen und es war gut, dass wir nicht einen häufigeren Termin genommen haben. Weil selbst das einmal im Monat artet manchmal schon den Stress aus, je nach unseren Terminkalendern. Ja. Genau, weil ich bin ja auch viel unterwegs gewesen in den Jahren. Gut, am Anfang nicht so viel wegen Covid. und, Genau. Wir nehmen übrigens am 24. November auf, das habe ich zu Beginn gar nicht gesagt. Eine Woche vor Veröffentlichungstermin. Genau, damit sind wir schon sehr spät. Ja, aber ich sag mal, viel mehr als zwei Wochen waren wir meist nicht entfernt. Das war meistens mindestens ein komplettes Wochenende dazwischen, dass man auch noch in jedem Fall sich Zeit nehmen konnte für Schneiden, auch wenn es beruflich mal eng wurde. Und das war schon gut so oder ist schon gut so. Ja. Ja, genau. Wobei witzig fand ich auch noch, als wir an verschiedenen Tagen gleichzeitig aufgenommen haben. An verschiedenen Tagen gleichzeitig? Ja, weißt du nicht mehr? Ah, da. Vor so einem Jahr. Als du in Down Under warst. Genau, wo ich sieben Uhr morgens hatte und du hattest, glaube ich, neun Uhr abends oder sowas. Ja, genau. Wir haben verschiedene kalendarische Daten aufgenommen. Genau, in verschiedenen Jahreszeiten. Und in verschiedenen Jahreszeiten. Das ist richtig, ja. Verschiedenen Welthalbkugeln. Sehr lustig, ja. Was ich ganz spannend finde, ist, dass auch ich sehr viel gelernt habe in der Zeit, die wir hier machen. Wir erzählen ja von Dingen, die wir gelernt haben und ich habe von dir eine Menge gelernt und ich habe auch von den Leuten drumherum eine Menge gelernt im Rahmen. Definitiv. Im Rahmen dieser Reise, genau. Das ist nicht zu unterschätzen. Ja, aber das habe ich jetzt wieder deutlich bei diesen Daily-Diskussionen. Jeder macht irgendwie die Dailies ein bisschen anders. Und je nachdem, wie sie es machen, ist es dann halt auch vorteilhafter oder nicht vorteilhafter. Da merkt man dann halt auch wieder so, okay, man hat meistens dann doch einen eingeschränkten Blick. Oder will irgendwie nur was sehen, wie man es sehen möchte, unabhängig davon, was jetzt andere Leute davon denken, sehen. Ja, vor allem wenn man von dem Daily-Format ausgeht, wie man es bei sich in der Firma hat, dann denkt man, alle anderen Daily sind genauso. Und die Diskussion hat genau gezeigt, dass es anders ist und dass es durchaus auch Formate gibt, die sinnvoll sind. Ja. Genau. Ansonsten finde ich übrigens auch noch schön, dass unsere, Downloadzahlen stabil steigend sind. Zwar nicht exponentiell oder sowas. Relativ linear, würde ich schon sagen. Aber das ist eigentlich ganz schön zu sehen, dass es auch mal so ein Stückchen mehr wird. Ja, was ich faszinierend finde, ist, dass sich die Situationen häufen, wo mich Leute an der Stimme erkennen. Das habe ich zum Beispiel gar nicht. Also nicht an der Stimme. Du lebst ja in deinem Isolationskaff da hinten. Das ist halt der Vorteil, wenn man nicht nur im Homeoffice ist, sondern wenn man auch mal rauskommt. Ja. Und das ist mir in der Kantine mal zwei, dreimal so gegangen. Ja, bei mir mehr so bei Konferenzen schon eher. Aber dazu muss man rausgehen. Ja, ich war neulich erst wieder draußen. Ach du warst das. Auf einer Konferenz. Zwei in den Nachrichten. Gibt es eigentlich ein Video von? Ja, du meinst von meinem... Von deinem Vortrag? Von meinem Vortrag auf der Continuous Lifecycle in Mannheim gibt es keine Aufzeichnung. Ach, wie schade. Da wurde nichts aufgezeichnet. Es ist quasi nur für die, die dort waren. Aber ich habe überlegt, ob ich das, also um, nochmal, weil der Kontext fehlt, ich habe da einen Vortrag ja über Freitags-Deployments gemacht. Oder zumindest war das der Aufhänger, um dann zu erzählen, was denn, dass eigentlich die Kultur das Thema ist, warum man Freitags nicht deployt. Ich überlege, ob ich das als YouTube-Video oder so auch mal aufzeichne und publische. Kannst du es dir auch leicht machen und das für die Chemnitzer Linux-Tage anbieten. Hatte ich auch überlegt, ja. Oder beides. Oder beides, ja. Finde ich gut. Ich weiß noch nicht, ob die Chemnitzer Linux-Tage ein passendes Format für das Thema ist. Aber lass das doch die Programmkonferenz entscheiden. Ja, ich glaube, da ich gerade eh kein anderes Thema sonst habe. Doch. Ja, aber für mich alleine meine ich. Die Boyband wird auftreten. Wenn es angenommen wird. Natürlich, wenn es angenommen wird. Genau, aber ich meinte jetzt für mich alleine quasi. Genau, ähm... Wo waren wir stehen geblieben? Das war eigentlich schon wieder so ein Abzweig. Ja, macht ja nichts. Dafür kennt man uns ja. Also mir macht es immer noch Spaß, den Podcast zu machen. Mir macht es auch Spaß, mich auf Themen vorzubereiten. Und was ich, ein interessantes Learning, was ich mitgenommen habe, ist, dass wenn wir einen Gast haben, das unseren kompletten Flow kaputt macht. Genau. Und das waren zufällig, hießen die immer Michael. Ja, bis auf den Hans, der hieß Franz. Nein, ja, wirklich nichts gegen unsere Gäste. Aber ich habe gemerkt, dass wir den Flow, den wir zusammen haben, dass wir den mit dem Gast zusammen nicht aufrechterhalten. Ja. Von daher ausprobiert, war in Ordnung, aber müssen wir nicht weitermachen. Gesehen, gelacht, F8, genau. Wer sich erinnern mag, F8 war im Norton Commander, die Taste zum Löschen, ja. Kenn ich nicht. Klar, es war vor deiner Zeit. Weißt du noch, damals im Kartoffelkrieg, ich habe geworfen, du hast geschält. und eine Entscheidung, die wir beide nicht bereuen, ist, dass wir das Hosting einem Dienstleister überlassen haben und dass wir das nicht selber machen. Genau, wir nutzen da ja Let's Cast, let'scast.fm Das ist quasi, ich glaube, die eine Alternative zu Podigy, wenn man jetzt von den Dienstleistern guckt. Mir beziehungsweise uns gefällt Let's Cast aber besser, weil die einfach nur gucken, Feature ist für alle gleich und der Preis hängt davon ab, wie viele Downloads es gibt. Und scheinbar haben die auch die Preise erhöht, aber nicht für uns, sondern nur für neue. Was auch gut ist, dass sie das dann halt darum sagen, okay, das ist dann halt so, fertig. Was ich bei dem Abrechnungsmodell halt relativ klasse finde, dass sich die Downloads auch auf verschiedene Podcasts verteilen dürfen. Also man darf auch mehrere Podcasts haben, wenn man in der Gesamtsumme der Downloads nicht über die bestimmte Grenze kommt. Ah ja, das habe ich schon schon nicht im Glück. Ja. Ich hatte ja mal überlegt, mit meiner Frau Podcast zu machen für die Hundeschule, und immer wieder kommen wir darauf zu sprechen, aber wir machen es einfach nicht. Aber das würden wir dann auch bei Let's Cast machen, auf jeden Fall. Also wir bekommen für die Werbung nichts, wir sind einfach zufriedene Kunden. Genau. Und dazu muss man auch sagen, wir haben noch sehr viel Puffer zum nächsten Preismodell. Also brauchen wir mehr Downloads. Und wenn nicht, wir sind ja von einer Firma gesponsert. Die Firma kann dann auch das höhere Modell tragen. Genau, seit wann ist das jetzt offiziell? Seit ein paar Wochen ist jetzt offiziell zahle ich alle Rechner. Mein Arbeitgeber zahlt alle Rechner. Genau. Hat es ein bisschen einfacher gemacht. Ein Podcast der Friday Deployments Gruppe. Genau. Vor allem mit den zahlreichen Mitarbeitern. Mich. Und Subdienstleistern, Steuerberaterin. Genau. Genau. Und keine Kunden. Ah, einen hast du ja. Ja, zwei. Zwei? Ja, LinkedIn Learning ist theoretisch ja noch. Ja, und dann auch noch, da wo du Artikel ablieferst, sind ja auch noch Kunden. Ja, genau. Genau, aber ja, außer dass die vorher der Diplomats GmbH die Richtung bezahlt, ändert sich quasi nichts. Ah, da könnten wir übrigens auch mal eine Folge drüber machen, was deine Learnings sind. Welche Learnings? Mit dem Selbstständig machen. Ja, das machen wir nach einem Jahr, würde ich sagen. Ist notiert. Ja. Hast du wirklich ein Ticket drauf gemacht? Ich sehe keinen. Nein, noch nicht. Genau. Ansonsten... Achso, was ist deine Lieblingszufallsbegegnung, die dir so in den Kopf kommt? Meine Lieblingszufallsbegegnung? Ja, oder eine lustige Sache. Du hattest ja vorhin erwähnt, in der Kantine oder sowas, aber war das jetzt irgendwas, was du besonders lustig fandst? Nein, aber ich habe in einer Stange gestanden mit Kollegen und mich mit einem Kollegen unterhalten und einer hinterher sagte, einer, die Stimme kenne ich, aber das fand ich schon lustig. Die lustigste Zufallsbegegnung war für mich der Pizzamenschen, den wir da in Bern kennengelernt haben, wo man wahnsinnig gut Pizza essen kann. Achso, ja, ja, die Pizza ist sehr gut. Pizzeria Danilo in Bern. Haben wir, glaube ich, auch hier schon mal beworben. Wir kriegen auch dafür leider kein Geld. Wir müssen noch kein Geld bezahlen, aber der einzige Pizzeria, oder eine der wenigen, wo ich das Gefühl habe, noch eine zweite Pizza zu essen, nachdem ich die erste schon gegessen habe. Ja, sogar schmacklich, ne? Vom Völlegefühl her würde ich es nicht runterkriegen. Ja, genau. Vom Völlegefühl würde ich es anderthalb, aber... Ja, genau. Genau, ne, meine Zufallsbegegnung, Semi-Zufallsbegegnung war, mir fallen jetzt so drei Sachen ein. Eins war der Mehmet, hallo Mehmet, bei der CubeCon vor ein paar Jahren in Amsterdam, wo er dann zum GitLab-Stand kam und nach mir gefragt hat, weil er ja den Podcast hört. Und dann hat mich ein GitLab-Kollege, der kein Deutsch spricht, dann darauf angesprochen, irgendjemand war hier und hat dich gesucht und meinte irgendwas mit dem Podcast. Und wenn die Leute das dann halt nicht wissen, dann ist das ein bisschen komisch. Ist ja auch ein interessantes Hobby. Obwohl die Podcast-Blase jetzt gerade wieder explodiert, aber das Hobby haben nicht so viele. Ja, also im Englischen gibt es dann ja schon wieder was, aber du kriegst ja auch nicht mit Werbung was alles machen. Das fand ich witzig, genauso wie bei der gleichen in CubeCon, kamen irgendwelche Leute zum Stand, haben über irgendwas GitLab-Themen gesprochen, auf Deutsch, mit mir. Und plötzlich dann nur noch, wie steht's mit deinem Buch? Ist es endlich fertig? Das ist auch gut. Das war so ein Plottwist, wo ich dachte, oh Gott, was ist hier los? Sehr schön. Irgendein drittes hatte ich auch noch im Kopf, jetzt hab ich's vergessen. Ja, ist es nicht. Ja, okay, der Flughafen-Erlebnis, aber das war ja FrostCon und kein Podcast. Naja, die einen sagen so, wo die anderen sagen so. Genau. FrostCon, Vorträge der Friday-Deployments-Gruppe. Das ist auch keine bezahlte Werbung. Nein, nein. Keine unbezahlte. Ja, wer uns live sehen möchte, der kann mal auf die Chemnitzer Linux-Dage kommen. Da sind wir in jedem Fall. Genau, die ist im März. Ende März, genau. Genau, und wenn jemand Vorträge einreichen will, der Call for Papers ist offen. Ja, und wenn jemand Themenvorschläge hat, über das wir reden sollten, Wir sind auch offen. Ja, vielleicht sind wir zu blind vor den Augen, dass wir unsere eigenen Themen, die wir hier im Podcast hatten, nicht erwähnen. Vielleicht sollte ich deswegen unser Thema von heute und von vorletzter Episode mit dem Secure Your SDLC als Vortrag machen. Ja. Oder einreichen zumindest. Ja, warum nicht? Gut. Prima. Viel mehr habe ich jetzt nicht, aussah, kann gerne so weitergehen mit dem Podcast. Ja. Wenn ich mal einen neuen Partner finde, wird das noch viel besser. Nein, kann gerne so weitergehen. An die, die uns noch nicht so lange hören, wir foppen uns gegenseitig und das relativ häufig. Eigentlich haben wir nichts Wirksames gegeneinander. Das denkst du. Gut. Gut, prima. Kommen wir zum nächsten Schottie, und zwar von dir. Ja, genau. Ich habe einen Schottie. Ich habe gestern gelernt, dass es einen Fachbegriff gibt, der nennt sich Arrival Fallacy. Das ist die Fehlannahme, dass wenn man ein bestimmtes Ziel erreicht hat, dass dann alles in Ordnung ist und dass dann die Welt schön ist und im Hintergrund Geigenmusik läuft. Und dass das häufig nicht so ist, sondern dass man sehr häufig merkt, dass die Ziele, die man erreicht, gar nicht so, immer hochjaustend sind, sondern dass es einfach nur Stationen auf einem langen Weg sind. Ja. Hast du ein Beispiel? Ja, meine aktuelle berufliche Reise, ich habe ja gedacht, dass der Epic Owner Linux Workplace, den ich im Moment innehaben, Traumjob wäre und ich habe das jetzt im Nachhinein gemerkt, was da alles dranhängt und was da alles drumherum noch nicht so läuft, wie es laufen könnte. und das ist weit davon entfernt, dass es so toll ist, wie ich es mir vorgestellt habe. Es ist ja bei Arbeit immer. Also es ist jetzt nicht so, dass es besonders schlimm wäre, aber es ist halt so, dass ich mir etwas anderes darunter vorgestellt habe, als ich letztendlich angetroffen habe. Ja, ich meine ganz grundsätzlich, das deckt sich ja mit vielen Themen, die wir so schon noch irgendwie hatten. Was mir nämlich dazu noch einfällt, ist, Wenn ich Sachen geschafft habe, dann fühlen sie sich hinterher auch immer einfacher an. Das ist ja meistens so, oder? Weil ansonsten hat man es ja nicht geschafft. Oder so Steuererklärungen, aber das ist andersrum eigentlich. Man schiebt die vor sich hin und dann, wenn man es gemacht hat, sagt man, warum hat man es nicht schon längst gemacht? So viel Arbeit war es ja gar nicht. Aber das ist ein anderes Thema. Aber wenn man so ein Ziel vor Augen hat und auf das Ziel hinarbeitet und dann das Ziel erreicht hat, dann, stellt sich das Ziel oder das Drumherum meistens anders da, als es wirklich ist. Also. Ja, das hatte ich nach meinem 100-Kilometer-Lauf. Ja, auch so. Hatte ich das auch so ein bisschen. Ja, und jetzt? Ja, Haken dran. Ja, ich habe mich jetzt für die nächstlängere Distanz angemeldet. Du bist ja auch bekloppt. Nein, aber ich habe es zum Beispiel gemerkt, zur Zeit, als ich Abi gemacht habe, da haben einige Leute sich so weit ins Zeug gelegt, dass sie keine Freizeit mehr hatten, dass sie wie wahnsinnig gelernt haben, um einen guten Abischnitt zu machen. und dann sind sie zur Uni gekommen, haben kein Fach mit Numerus Clausus belegt und sind dann ins Audimax gegangen, damals in Bochum, haben das Abitzeugnis vorgelegt, haben ganz stolz den Mitarbeiter des Studentensekretariats angeguckt und der guckte sich das Zeugnis an und macht in der Spalte Abitur einen Haken. Fertig, das war's. Ja, aber so fühle ich mich auch mit meinem Studium. Also ich habe ja studiert und abgeschlossen und für mich ist das im Kopf ein Haken, aber effektiv interessiert es ja keinen. Außer am Anfang vielleicht. Ja, also wir suchen ja viele im Jobtitel einen bestimmten Titel. Ja, was halt Käse ist. Wie mit den Zertifikaten, über die wir schon mal gesprochen haben. Ja, genau. Sind ja eigentlich nur Momentaufnahmen. Beziehungsweise zeigen, dass du eine bestimmte Art zu denken gelernt hast. Vielleicht ist es das. Ja. Ja. Nee, das ist es eigentlich. Also das Arrival Fallacy heißt es. Ich versuche noch einen Link dazu zu finden und wird ja dann auch die Sendungsnotiz packen. Ja, das erinnert mich gerade auch an das Thema. Den Weg dahin muss man ja auch irgendwie mögen. Weil wenn man den Weg dahin, wenn man die ganze Zeit darin arbeitet, keine Ahnung, Millionär zu werden, und dann irgendwelche Sachen macht, nur um Geld zu verdienen, die aber keinen Spaß machen, dann ist man irgendwann da und denkt man so, toll, jetzt habe ich irgendwie, keine Ahnung, 20 Jahre gearbeitet, bin Multimillionär, keine Ahnung. Eine Million ist heutzutage auch nicht mehr viel. und denkt an sich, ja toll, und jetzt? Aber ich glaube, das geht viel mit der Rente so. Ja. Dass sie sagen, sie arbeiten lange und hart, um sich die Rente zu ermöglichen und dann sind sie in der Rente und das ist dann irgendwie Langeweile. Ja, und jetzt? Und jetzt, genau. Das habe ich mein ganzes Leben gemacht. Genau. Ja. Ja, das ist für dich, glaube ich, eher ein Thema als für mich gerade. Ja, aber ich habe es halt auch bei meinen Eltern erlebt. Mein Vater ist halt in Burnout gegangen. meine Mutter ist dann schwer krank geworden die haben halt Zeit ihres Lebens gearbeitet und Geld zurückgelegt, damit sie einen tollen Lebensabend hatten und den konnten sie dann gar nicht mehr genießen weil meine Mutter so krank geworden ist ja, auch Arrival Fantasy, also zu sagen wenn wir mal so weit sind, dass wir die Zeit haben, können wir viele Sachen unternehmen und dann funktioniert es dann doch nicht ja genau. Also effektiv, wenn ich X erreicht habe bin ich glücklich, das stimmt meistens dann ja halt auch nicht ja genau. Gut, mehr habe ich dazu gar nicht zu sagen, ja. Dann kommen wir zu unserem Thema, was die Fortsetzung von dem Thema aus Episode 60 ist, also von vorletzter Folge. Und zwar hatten wir da ja über die Absicherung der Software-Delivery-Lifecycle gesprochen. Und hatten da ja auch schon gesprochen über die DevOps-Stages Plan, Build und Test. und was man da alles absichern kann und das ist ja dann quasi der CI-Part und jetzt geht es mal weiter mit dem CD-Part, also Continuous Delivery or Deployment. Was sagst du, Dirk? Ja. Ich sage ja zu Continuous. Ich sage eigentlich Delivery. Ja. Was ist nochmal der Unterschied? Ich komme selbst jedes Mal durcheinander, muss noch mal über nachdenken, was ist noch mal der Unterschied. Am Ende von Delivery steht ein Lieferobjekt, womit man was anfangen kann und am Ende von Deployment steht ein Deployment, was dann tatsächlich in Produktion geht. Also eigentlich müsste es ja dann Continuous Deployment sein. Im Idealfall ist es Continuous Deployment, aber Continuous Delivery ist, glaube ich, im Deployment enthalten. Genau. Genau. Und genau, weil Container-Slevel ist ja quasi dann, wenn man agil alle zwei Wochen sein Ding hat, das ist auch eine gewisse Kontinuität am Ende des Sprints. Aber nicht unbedingt geht es halt im Einsatz. Ich mag das Beispiel mit der Waschmaschine. Kennst du das Waschmaschinen-Beispiel? Nein. Der Waschmaschinen-Beispiel ist, du kriegst eine, eine Waschmaschine delivered, aber sie ist nicht im Einsatz, also nicht deployed, weil die andere Waschmaschine noch läuft. Wenn du jetzt noch anfängst, 10% der Workload auf die neue Waschmaschine zu transferieren, dann hast du ein Canoey-Deployment mit Waschmaschinen. Kannst gucken, ob alles funktioniert. Ich hätte bei Continuous Delivery jetzt Nightly Builds im Hinterkopf, die man noch aufgeregt hat, was ich sehen kann, wo dann delivered wird, wo es aber kein Release wird. Das Release wäre dann das Deployment. Ja, genau, unter anderem. Ja, die Konferenz, wo ich letzte Woche war, das war ja die CLC-Conference in Mannheim, die ursprünglich halt für Continuous Lifecycle Container Conf stand. Jetzt haben die es gekürzt, weil das so lang war. Ja. Womit? Mit Recht. Zurecht. Genau. Genau. Genau, also was haben wir da grob gesprochen? Kurzzusammenfassung ist, wenn man erstmal mit dem Plan anfängt und dann mit dem, fangen wir mal beim Code an, dann gibt es ja sowas wie Branch Protection Rules, sodass wir eben absichern können, wer was wie merchen darf und nicht, zum Beispiel über Code Reviews, dass dann da zum Beispiel nur über mit signierten Commits gearbeitet wird, die dann halt auch ordentlich gereviewt werden, die da von den bestimmten Personen, die es auch dürfen, gemercht werden können, was dann auch alles konfiguriert werden kann und dann geht es dann auch weiter zu Build und Test was ja eigentlich wieder zusammen gehört eigentlich gehört eh alles zusammen, weil da ging es auch sowas wie SAST, also Static Application Security Testing, Dependency Scanning hat man Reproducible Builds dass ja auch jedes Mal das gleiche Paket hinten rausfällt und dass man vielleicht auch noch ein sicheres IACD Bausteine hat, für die Pipeline selbst, damit man nicht jedes Mal was neu erfinden muss oder sowas, geht dann ja auch in die Richtung Security. Beziehungsweise Sicherheit. Und, Dann geht es ja auch weiter, weil die Stages danach sind ja effektiv Release, Deploy, Operate, Monitor und dann geht es ja wieder zurück in Plan, und entsprechend gucken wir auch uns heute mal Release, Deploy, Operate an und Monitor und da merke ich gerade auch wieder oder was heißt gerade jetzt zur Vorbereitung dann auch, mein Fokus ist vor allem persönlich der CI-Part, der CD-Part ist nochmal so ein bisschen was anderes, weil da hast man noch mal wieder die klassischen Operations-Themen noch mit drin, ganz unabhängig davon, ob man nach DevOps arbeitet oder nicht. Aber auch da gibt es natürlich diverse Sicherheitsaspekte, die man über die Pipeline auch abdecken kann. Aber nicht unbedingt nur die Pipeline, weil das halt eh alles sehr fließende Übergänge sind. Vielleicht erwähnen wir noch kurz, dass wir gesagt haben, dass bei den manuellen Eingriffen, die sind, also dass man halt Merge-Requests, acceptet, dass da der Mensch die Schwachstelle ist, wenn er zu viele Merch-Requests bekommt, dass er einfach durchklickt und nicht näher anguckt und dass so Methoden nur so gut sind, wie die Leute, die damit umgehen. Genau, ja. Und damit geht es dann auch nahtlos eben weiter, weil wenn wir uns jetzt mit Release angucken und wie gesagt, es überlappt sich das ja auch mit Deploy zum Beispiel. Ich fasse meistens Release und Deploy zusammen, weil irgendwie gehört das schon sehr stark zusammen, stärker zusammen als der Rest so. Was heutzutage ja schon relativ, ja, normal nicht ganz, aber wo viele drauf arbeiten, ist so die Thematik S-Bombs. Hatten wir eigentlich auch schon im CI-Part, weil da wird es ja auch schon generiert, sodass man dann auch mal eine komplette Liste hat, welche Abhängigkeiten nutzen wir, in welcher Lizenz werden diese verwendet, dürfen wir diese Lizenz überhaupt verwenden. Hat jetzt weniger mit Security im klassischen Sinne zu tun, sondern mehr um License Compliance zu tun. Aber dann halt auch, wenn so Themen wie die Log4J-Thematik halt eben aufkommt, dass man dann halt auch sehen kann, okay, welche Abhängigkeiten haben wir überhaupt in Nutzung in unserer Webseite, Anwendung oder in den Anwendungen selbst, die wir, die man so betreut. Wir haben da so eine Schnittstelle von intern zu extern, oder? Also wenn wir uns das S-Bomb im vorherigen angucken, das ist eine S-Bomb für internal use, wo wir die Sachen intern benutzen dürfen oder auch nicht. Und wenn wir die Sachen rausgeben wollen, also wenn ein Softwareprodukt am Ende da rausfällt oder ein Service da am Ende rausfällt, dann müssen wir gucken, ob wir die in die S-Bomb gucken, ob wir die Lizenzen, die wir da finden, wirklich für ein, Deployment nach außen wirklich freigegeben sind. Also sprich zum Beispiel bei den Copy-Left-Lizenzen ist in meinem Release der Quelltext enthalten oder habe ich einen Link auf den Quelltext in meine Web-Anwendung gebaut, beispielsweise. Solche Sachen. Aber das bei Internal-Use spielt das keine Rolle, bei External-Use dann halt schon. Ist wahrscheinlich jetzt völlig verkehrt erklärt mit internal, external, aber ihr wisst, worauf ich raus möchte. Das eine ist halt, im Unternehmen bleibt, wenn das andere ist, wenn es aus dem Unternehmen rausgeht. Ja, rausgeben, die nur von anderen Kunden ausgeliefert werden, die es dann einsetzen. Genau, oder durch Kunden zugreifbar sein, genau. Genau. Aber ja, das überlappt sich ja dann auch, weil du kannst die gleichen, du nutzt die effekte für die gleichen Informationen, ja auch für deine eigenen Prozesse. Gleichzeitig geht es aber auch, wenn du ein Projekt von irgendetwas anderes übernimmst, als, Weil es von wem anders kommt, dann würdest du ja quasi im Release-Stage reintragen, wenn du es in deiner Umgebung mit übernimmst. Ja, aber du kannst ja in deinem Deployment-Prozess ziemlich weit vorne Tools verwenden, die du gar nicht mit rausgibst zum Beispiel. Dann musst du intern checken, ob du die überhaupt verwenden darfst, um so ein Produkt zu erstellen. Genau. Und wenn du es dann hinterher rausgibst, dann greifen vielleicht andere Lizenzen für andere Bibliotheken. Genau. Aber das überlappt sich zu weiten Teilen, das ist schon so. Ja, genau. Ich meine jetzt nur, wenn du eine Software von wem anders einsetzt, was ja bei vielen Open-Source-Sachen darin ist, dann fängst du ja nicht beim Release, sondern eher beim Deploy-Stage dann noch an. Und hast den Zyklus dann erst ab da, weil das davor ist halt alles vom Fremdanbieter. Ja, aber wie an den Beispielen, Entschuldigung, wenn ich darauf rumreite, wir haben in Beispielen gerade gesagt, Release kann ja auch der letzte Stage sein. Deploy ist ja nur, wenn es ein Service ist. Oder vielleicht ist das Deploy dann einfach auch das Bereitstellen des Releases für zum Download als Deployment. Ja, genau. Genau, was man im Release ja auch nochmal hat, ist, weil wir hatten das ja beim Code ja auch, dass man Commits signen kann, also signieren kann. Das machst du in der Regel mit Paketen ja auch. Und Pakete, da fass ich jetzt mal Container auch mal mit hinzu, Container und normale Pakete, die man dann so baut, die kannst du dann auch mit GPG signieren oder halt auch eben Cosign oder sowas verwenden, um die ganze zu signieren, um sicherzustellen, dass das Paket auch wirklich von uns kommt und nicht von irgendjemand anders. Und das Release zu signieren, das ist das eine, das sollte dann idealerweise natürlich auf der Port-Umgebung dann ja auch geprüft werden, ob das auch wirklich im Einsatz ist und nicht irgendwas anderes. Ja, ja. Also ich weiß, dass bei vielen Software-Releases ein Signature-File dabei liegt, aber ich kenne wenige Leute, die das wirklich testen. Ja, wenn man es stringent machen würde, müsste man das eigentlich. Ja. Und dann natürlich, dass es auch richtig ist, von der richtigen Quelle ziehen. Es ist genau das Gleiche, wie wenn man ein Auto fährt, sich vor der Antritt der Fahrt überzeugen muss, dass das Auto komplett funktioniert, dass alle Blinker funktionieren, dass alles Licht funktioniert. Ja. Das macht auch keiner. Ja, das ist ein gutes Beispiel. Genau, was man dann auch noch mal in der Release-Stage noch eben sicherstellen kann, sollte, wie auch immer, dass die ganzen Sachen nur auf freigegebenen Package und Container Registries gepusht werden. Wenn es gebaut und getestet wurde, dann kann es ja theoretisch überall hinlaufen, aber auch da sollte man eigentlich sicherstellen, dass es dann tatsächlich... dorthin gepusht wird, wo es auch hin sollte, mit den richtigen Berechtigungen dahin, weil du kannst ja theoretisch, sowohl irgendwie Container-Images als auch Pakete pushen und dann mit dem gleichen Account das einfach wieder weglöschen. Sollte häufig eigentlich auch nicht der Fall sein. Haben die wenigsten im Blick, ist meistens auch nicht so das Problem, aber wenn mal was kaputt geht, dann können halt theoretisch die Historie hinterher nachträglich verändert werden, oder zumindest die Registry da drin, nicht unbedingt die Commit-Historie. Und das wäre dann ein Problem oder könnte ein Problem sein, wenn die Historie selbst, die GTS-Historie selbst, auch nicht ordentlich gemacht wurde. Da kann man vielleicht im Hinterkopf behalten, dass es den amok laufenden Mitarbeiter gibt oder den Mitarbeiter, der die Schnauze voll hat und dem scheißegal ist, ob er verbrannte Erde hinterlässt oder nicht, sondern versucht das Unternehmen erstmal runterzureißen. und da an der Stelle merkt man vielleicht, dass das Sicherheitskonzept nicht so ausgewogen ist, wie man es gerne hätte. Genau. Oder in der Neubunärtenwelt ein AI-Agent. Natürlich. Das ist mein klassisches Beispiel. Aber irgendwie gefühlt denken die meistens, naja, wie wahrscheinlich ist schon, dass da irgendwer was kaputt macht. Aber es kann ja auch ein AI-Agent sein, der in Panik gerät, was ja schon das eine oder andere passiert ist. Oder halluziniert, ja. Genau. Und in Panic natürlich in Anführungsstrichen. Und hatten wir auch schon in der vorherigen Folge dazu gehabt. Und dass man dann auch eben dann sicherstellt, das theoretisch kann es ja auch sein, dass wenn dein User-Account gekapert wird, dann, dann kann ja mit deinem User-Account Schindluder betrieben werden. Das willst du in der Regel ja auch nicht. Wenn der User-Account das einzige ist, was dazu führt, dass sie irgendwo zugreifen können, ja. Ja, wenn du dann noch mal bedenkst, wenn man richtiges reproducible Builds macht, und dann geht jemand hin und löscht die Package Registry weg, dann ist theoretisch kein so großes Problem, mehr alte Versionen wiederherzustellen. wobei jetzt auch natürlich wieder darauf vorangekommen, was für ein Projekt haben wir. Machen wir jetzt echte CICD, wo mehrfach pro Tag deployed wird, dann ist die alte Historie, was Packages angeht, nicht mehr ganz so relevant. Wenn du es aber an Kunden auslieferst, dann schon. Ja, vor allem wenn man sich überlegt, dass es eigentlich, dass man Changes, die man eben wirklich häufig deployen machen soll, dass die eigentlich Atomic sein sollen, dass man sie auch einfach wieder zurückrollen kann, weil es was schief geht. dann muss man ja wieder den Zugriff auf das alte Release haben, beziehungsweise auf dem Fallback, nicht Fallback, sondern Rollback-Möglichkeit haben und bei Kunden sieht es dann nochmal anders aus als bei einem selber, das ist schon so. Aber wenn wir schon dabei sind, können wir eigentlich auch schon in den Deploy-Stage mal rüberwechseln quasi, weil Canoe-Deployments und Blue-Green-Deployments ist ja quasi das, was du gerade beschrieben hast. Das kannst du ja einmal aus der Sicht betrachten, okay, wir haben jetzt neue Features, die wir jetzt ausrollen wollen, oder Bugfixes, die wir ausgerollt haben und dann auch nutzen wollen, aber halt stufenweise und auch wieder zurückrollen können. Aus Security-Sicht kannst du das ja auch betrachten, weil wenn du das so umgesetzt hast, dann kannst du ja merken, oh, wir haben jetzt ein Security-Incident in der neuesten Version. Ich switch mal schnell zu Alten drüber, weil sie da eh schon läuft oder halt schnell ausgerollt wird. Haben wir hier jemals schon mal Blue-Green und Canary erklärt eigentlich? Ich glaube nicht, oder? Ich glaube schon, aber können wir noch mal kurz. Effektiv hatte ich das ja gerade mit der Waschmaschine erklärt. Ja, aber ich kann es halt von YouTube sagen, ich war da mal zu Besuch, da haben die erklärt, wie die da deployen. Die deployen halt Canary und die sagen, dass sie wenn sie neue Features ausrollen, dass die die erst für einen Bruchteil der User ausrollen, vielleicht 0,1 Prozent. Und dass sie dann das Feedback abwarten. Wenn das Feedback gut ist, dann geht es an 1 Prozent der User und dann stufen die sich halt hoch, bis alle User haben. Gängige Canary-Deployments sind das erst die internen Leute Zugriff drauf haben und bevor halt das für Externe freigeschaltet wird, das kenne ich relativ häufig. Genau. Ja, und Blue Green Deployments ist quasi von 0 auf 100, aber man hat das schon mal laufend auf der Deployment-Umgebung und kann es schon mal theoretisch testen, auch wenn es noch nicht auf alle oder überhaupt auf User draufgelassen wird. Ja, es läuft parallel quasi, es wird dann einfach nur umgeswitcht. Genau, genau. Man kann auch genauso gut wieder zurückgeswitcht werden. Ja, genau, das ist ja in Container-Umgebungen meistens dann eh schon keine WeDeployments. beziehungsweise es ist egal, ob das, also früher war es ja so, früher in Anführungsstrichen, die älteren, also du erinnern dich, wenn es halt auf fixen Servern installiert worden ist, hast du den einen Server bei den Green Deployments, der eben Green war, wo dann halt die eine Version, der so ein 1.0.0 ist und die auf dem blauen Deployment dann 1.0.1 und dann wird auf dem Load Balancer dann einmal gesitzt und der andere Server ist dann weiterhin da mit der alten Version. Wenn man auf container-basierten Setups hast, dann hast du das ja eh alles ein bisschen flexibler gehandhabt. Setzt natürlich voraus, dass die einzelnen Deployments keine Strukturänderungen im Backend haben. Ja, genau. Das kannst du aber nicht immer verhindern. Datenbanken im Wesentlichen eigentlich. Wobei man da viel, viel mehr machen könnte, als man es gemeinhin macht. Ja, man kann relativ viel mit Views machen, wird aber selten getan. Ja, genau. Deswegen sind ja auch so Cloud-Native-Sachen sind ja meist auch rollbackfähig. Genau. Dann Datenlocken weniger, aber so ist es dann manchmal. Ja, aber wie gesagt, man kann viel mit Views machen. Man kann eine View-Version 1 haben, eine View-Version 2 haben und das neue Deployment greift auf die View-Version 2 zu, das alte Deployment auf die View-Version 1. Und wenn jetzt nicht grundlegende Strukturen sich geändert haben, dass die Views komplett nicht mehr funktionieren, dann kann man immer wieder zurückrollen. Wenn man das nicht hat, dann, nach mir die Sintflut, dann eben nach Deployment verreist. Genau, nach Bad Gradeway. Ja, genau. Bad Gradeway. Genau, was ebenfalls helfen kann, ist, und im Sinne der Deployment-Infrastruktur, weil wir haben ja schon über Container gesprochen, so grob, Immutable, also die Infrastrukturen sollten immutable sein, sodass sie halt austauschbar sind, und um so zu vermeiden, dass irgendjemand per Hand Modifikationen vornehmen kann. das ist jetzt ein klassisches Ops-Thema, würde ich sagen was aber halt eben da reinspielt dass die Container zum Beispiel das dann auch natürlich dann unterstützen dass man zum Beispiel, keine Root-Rechte auf Docker-Containern hat oder so weiter. Ehrlicherweise ist das ein typisches Ops-Thema geworden es war nicht immer ein Ops-Thema Immutable Infrastruktur zu haben also früher wurden die Server noch von Hand geklöppelt und mit next, next, next, fertig installiert. Wir hatten ja nichts anderes. Genau, wir hatten ja nichts. Und die Zeit ist glücklicherweise vorbei. Aber zu sagen, dass wir, in der Lage sein wollen, immer wieder die Infrastruktur identisch aufzubauen, dass es halt eine Forderung, die unter anderem durch DevOps gekommen ist. Ja, durch DevOps und Cloud, das gehört ja auch stark zusammen. Die bei Ops, die das schon länger machen, schon häufig der Fall war, dass die das sehr viel automatisiert hatten, aber das hat durch die DevOps-Bewegung nochmal einen Schub gegeben. Ja, ich meine, wenn du Puppet zum Beispiel anguckst. Puppet gibt es ja auch schon, bevor es DevOps als Begriff gab. Der Punkt ist halt der, dass man also ich, das Beispiel haben wir glaube ich schon mal gebracht, Pets und Kettle, also das früher der Fall war, dass die Server waren wie Haustiere, dass jeder einzeln gehegt und gepflegt und gestreichelt wurde. Und hat einen Namen. Und hat einen Namen. Und mittlerweile ist Infrastruktur Kettle, also Vieh, wo man einfach, wenn ein, Infrastrukturteil kaputt ist, dann baut man halt neun identisch auf, fügt den Insgesamte ein und dann läuft es einfach nochmal weiter. Genau, und die alte Kuh wird getötet, wenn es krank ist. Ja. Kennst du die vegane Variante davon? Nein. Dann hättest du mal mein Buch gelesen. Ich habe dein Buch gelesen, aber es schien nicht erinnerungswert zu sein. Hatte ich neulich auch wieder ein Gespräch drüber gehabt, weil ich eben geguckt habe, also Pets vs. Kettel ist ja eigentlich schon sehr brutal gegen Tiere. Und dann dachte ich so, gibt es eigentlich ein gutes Beispiel, was tierfreundlicher ist? und da hatte ich irgendwo ein Beispiel gefunden, die alte Eiche versus ein Maisfeld. Die alte Eiche wird halt gepflegt und gepflegt auf Dauer, damit sie auch schön alt wird, 100 Jahre alt wird und das Maisfeld, naja, wenn es halt kaputt ist, dann ist es halt kaputt. Nächstes Jahr kommt was Neues oder mit der nächsten Ernte. Ja, also ich habe auch Pets und Kettle ja in Verbindung gebracht mit Einzel versus Viel, genau. Das ist so die eigentliche Verbindung, die ich dahinter habe. Ja, aber wie baust du das Ganze auf? Hoffentlich nicht mit Terraform. Kannst du mit, nee, genau, ich wollte aber auf Infrastructure as Code, hinaus. Und da kannst du auch nochmal ein Scanning machen, was ja effektiv dann auch wieder ein SAR-Scanning ist. Das fand ich, als ich das getestet habe, aus der Rolle von GitLab heraus recht spannend, weil ich habe nicht viel Terraform-Erfahrung, also relativ Basics. Und man sieht halt von so einem Terraform wie KIX zum Beispiel, KI, CS, ich glaube, wir hatten das in irgendeiner Folge schon mal erwähnt, dann sieht man recht schnell schon, okay, hier ist ein Netzwerk, was open to the world ist, hier ist, ein SSH-Key oder irgendwelche Permissions, die nicht so sein sollten, wie sie sein sollten und dadurch kriegst du halt schon sehr gut und frühes Feedback, wenn du das mit in die Pipeline einbaust zu deiner Infrastruktur, bevor sie ausgerollt wird, bevor du eben das Scheunentor aufmachst, um dann die Kettle reinzulassen oder rauszulassen. Ja, also ich habe mich länger mit, also Kix hat mir in Episode 22, ich habe mich, länger mit Terraform auseinandergesetzt und man merkt halt sehr, sehr stark, dass es relativ kompliziert parametrierbar ist und dass es wirklich für viele Systeme, die gleich oder sogar identisch aufgebaut sind, gedacht ist. ja da da funktioniert das wirklich gut und sehr und da dann auch sehr performant aber wenn man so die klassische klein it hat wurde es dann ein server für def ein server für test ein für die abnahme und eine für die produktion gibt dafür ist das nicht gedacht, Da bin ich relativ schnell an die Grenzen gekommen. Ja, das heißt aber bei vielen Config-Management-Tools effektiv. Also ob Ansible, Puppet, was auch immer. Aber die Frage ist, kleiner Ausflug an der Stelle, wie man das Ganze zusammenbaut. Man hat eine Infrastruktur, auf der Infrastruktur kommt ein Application Layer oder eine Runtime, mit der man die Applikation betreibt. Und darauf kommt der Applikations-Layer. Und für jeden Layer kann man vielleicht unterschiedliche Tools einsetzen, um den aufzubauen. Genau, aber Terraform ist hauptsächlich die Infrastruktur. Genau, die unterste Layer, genau. Aber ja, da kann man auch sehr, sehr viele Fehler machen, vor allem, wenn man nicht viel Ops-Erfahrung hat und Security-Erfahrung. Da können ein paar Scanner helfen, die die Sachen scannen. Was man auch nicht machen sollte, ist das Terraform-State-File, wo quasi beschrieben ist, was wird in diesem Cluster, das man sich hochgezogen hat, gemacht, dass das irgendwo public steht, weil ansonsten kann da jeder Leute drauf aufzugreifen. Ja, und das sollte vor allem auch so sein, dass alle Leute, die was an dem Terraform ändern, dass die auf das gleiche State-File zugreifen. Wenn der dann das kann man viel mit kaputt machen. Genau, und das sollte halt eben auch wieder eingeschränkt werden. Wer darf da was machen? Ja, na klar. Einmal open to the world, aber halt auch intern. Firmen intern ist auch nicht so geeignet. Ja, also zumindest für die, die damit arbeiten, die sollten darauf Zugriff haben und die sollten alle auf das gleiche State-File Zugriff haben. Ja. Und auch da kann man das dann einschränken zum Beispiel, dass es nur über die Pipeline laufen sollte. Zum Beispiel, wenn was auf Brot deployed wird. Ob das so sinnvoll und praktisch ist, sei man nochmal dahingestellt. Da muss man nochmal Fall für Fall unterscheiden. Ja, also das, was du jetzt gerade sagst, beschreibt, kennst du die normalen Form in Datenbanken, kennst du, oder? Äh, nochmal? Normale Informationen in Datenbanken kennst du, oder? Ich erinnere mich dunkel. Die Idee ist, dass alle Informationen nur einmal gespeichert werden in der Datenbank und dass man halt, wenn man Informationen an einer anderen Stelle braucht, dass man über IDs darauf zugreift. Ja. Ganz platt formuliert. Und das ist ein theoretisches Konstrukt, weil häufig muss man aufgrund von Performance-Anforderungen Daten redundant speichern, um halt die maximale Performance rauszuholen. Und genauso ist es, es gibt gute theoretische Konzepte, die aber meistens in der Praxis nicht halten. Ja, also darauf wird es ja erst. Ja, okay. Ich habe schon gewonnen, so hey. Was redet er? Er redet wir. Genau. So alt ist er doch gar nicht. Wobei doch. Ja. Ansonsten, was auch nochmal relevant ist, sind Passwörter, Secrets, Credentials für ein Port Deployment. oder generell, was alles in der Pipeline genutzt wird. Auf jeden Fall einen sicheren, Password-Manager, in Anführungsstrichen, nutzen. Zum Beispiel wie Hedgehog Vault, oder OpenBao als Fork oder irgendwas in die Richtung, wo die Passwörter auch sicher verwahrt sind, sodass man die auch rotieren kann und sicher darauf zugreifen kann, ohne dass man die einfach in der Pipeline mal mit ausgibt, was nämlich diverse CICD-Tools machen können. Und ganz viele Gedanken darüber machen, über die Infrastruktur. Diese Key-Value-Stores, diese Walls müssen immer verfügbar sein. Müssen immer verfügbar sein. Ja, und sonst kommst du nicht an irgendwelche Systeme. Das heißt, sie dürfen nicht im gleichen Cluster laufen, wie die Software auf der Aufwand greift. Und sie müssen auch dann noch verfügbar sein, wenn das Cluster kaputt ist. Ja, könnte helfen. Das ändert mich an meinen, Kubernetes-Cluster, den ich hier so hobbymäßig betreibe. und da habe ich auch ein GitOps-Repo quasi, und mit Flux und da habe ich auch alles definiert, was da drin ist, aber und da drin ist dann ja unter anderem auch ein GitLab drin, was ich dann ausrolle. Aber das Repo liegt auf gitlab.com, damit ich ja das Bootstrap-Problem nicht habe, wo ansonsten hätte ich ja ein Hennerei-Problem. Ja. Ja. Und damit sind wir auch schon bei Operate. Jups. Jups. Weil GitHub-Themen sind eigentlich auch relativ bekannt. Folge 1, glaube ich, war das sogar. Was ist GitHub? Ich glaube, damit haben wir angefangen. Keine Zeit für GitHub hieß die Folge, das weiß ich noch. Ja, boah. Du weißt Sachen. Das ist doch die einzige. Das fünfjährige Gedächtnis. Wow. Genau, damals war ich doch unter 30. Ach. Weil man da dann ja auch mal sicherstellen kann, dass kein Schindluder betrieben wird auf der Infrastruktur, weil wenn man dann sicherstellt, dass das, was in den Git-Repos drinsteht, was die Deployments angeht, sei es Flux wie bei mir jetzt privat oder auch Argo CD oder sowas, mit der ganzen Historie auch dahinter, dass die dann so auf dem Kubernetes zum Beispiel dann ausgerollt wird und dass man dann halt auch sehen könnte, wenn es eine Abweichung davon gibt. Die muss man teilweise selbst aktivieren, teilweise nicht. Das kommt ein bisschen auf die Tools an. Das ist jetzt auch nichts... GitHub-Skamp zwar aus der Kubernetes-Ecke, aber eigentlich gibt es das ja auch schon länger mit Puppet und so ein Kram, weil man effektiv das gleiche macht, nur anders. Um eben sicherzustellen, dass da niemand per Hand reinfriemelt, wenn da wer was reinfriemelt. Aber dann haben wir auch wieder die Immutable-Infrastrukturen, dass du das teilweise ja auch vermeiden kannst, wenn es eh Container sind. Also es kommt darauf an, auf welchen Layer wir jetzt gucken, auf das Buzzsystem, auf den Container, in den Container, oder wo der Container-Image eben ausgetauscht oder so weiter. Aber auch da kann man ja noch sehr viele Sachen machen wie, dass die Container nicht als Root laufen sollten, was ja sowohl innerhalb des Containers teilweise konfigurieren muss, als auch im Kubernetes zum Beispiel oder auf dem Container-Host. Das muss ja nicht immer Kubernetes sein, das muss auch nicht immer Container sein. Und dass man die Systeme auch klassisch abschottet, sag ich jetzt mal, klassisch im Sinne von den typischen Linux-Capabilities, die es auch so gibt. und mit Linux-Capabilities meine ich auch so die Kernel-Sachen, die es da so teilweise gibt, bevor ich keine Ahnung habe. Ja, die ich relativ selten brauche und wenn, dann muss ich auch immer nachlesen. Ja, genau, aber auch die Sachen kann man machen und angucken. Was ich noch relativ neu gelernt habe, ist, es gibt ja auch für Kubernetes so ein paar Policy-Tools, Open Policy-Agent gibt es, glaube ich. OPA, ja. OPA, genau, habe ich nicht verwendet. Und das gibt es auch noch Kai Wernuch. Und damit kann man halt auch Policies definieren, um zu gucken, ob das, was in diesem Cluster drin ist, zum Beispiel dann richtig umgesetzt wurde. Was bei Enterprise-Sachen vielleicht relevant ist, sind auf irgendwelchen bestimmten Container-Images, Deployments in Kubernetes, bestimmte Labels gesetzt oder so weiter, damit man klar attributieren kann, wer wem was gehört. hat. Aber man kann das theoretisch ja dann auch mal verwenden, glaube ich, für sind die Container Images, die da laufen, auch die, die tatsächlich von den freigegebenen, Container-Registries gezogen werden. Weil das willst du dann ja auch feststellen, weil es ist schön, wenn du das am Anfang in der Pipeline zwar schön durchprobierst, dass da sichergestellt wird, dass es nur auf die richtige Container-Image geht, aber wenn dann auf ein Zielsystem was ganz anderes angezogen wird, dann bringt das alles vorne nichts. Ich weiß gar nicht, ob das mit Kaverne oder sonst was alles geht. Ich schätze es jetzt mal. Fehlen mehr Erfahrung, ehrlicherweise. Ja, mir auch. Ich war neulich in einem Vortrag dazu, aber das ging mir dann schon ein bisschen zu tief, wenn man keine Ahnung davon hatte. Aber da gibt es einige Themen, die man, es geht jetzt auch mehr ums Prinzip, nicht um das einzelne Tunnel, was es jetzt unterstützt. Aber da kannst du auch noch mal sehr, sehr viel prüfen, testen, machen, gucken, um das sicherzustellen aus Operations-Sicht. Fallen dir noch weitere Punkte ein, die erwähnenswert sind? Außer Monitoring, zu dem wir gleich noch kommen? Nee, im Moment nichts. Gut, dann können wir weitermachen zum Monitoring. und ich glaube, da kannst du mehr sagen zu dem Thema Siem. Was ist ein Siem? Siem, Security Information and Event Management hat mein Kollege hier ins Showpad, oder in die Issue geschrieben. Das ist eine Möglichkeit, erstmal Daten zu sammeln, zu analysieren. In den meisten Fällen kommt Splunk zum Einsatz und kostet richtig viel Geld und aus diesen Findings, die da zusammenkommen, Tickets zu generieren, die wieder bearbeitet werden müssen. Ja. Also da geht es überwiegend, das ist ein Security Monitoring oder ein Abad von Security Monitoring. Da geht es insbesondere darum, das Hardening der Systeme durchzuführen. Ja, genau. Das ist letztendlich dann auch wieder zu überlappen mit OPPOID, OPPOID und Monitor, weil es irgendwie auch wieder zusammengehört. Überraschung, Überraschung. Und dazu passt dann auch ganz gut der nächste Unterpunkt quasi. Wir hatten ja das Vulnerability-Scanning sowohl im Source-Code als auch im Container-Image zum Beispiel innerhalb der Pipeline. Man könnte jetzt zusätzlich nochmal ein Container-Scanning oder ein Vulnerability-Scanning auf der Plattform, wo es dann letztendlich läuft, dann nochmal ausführen. Sei es die Container, sei es das darunterliegende Linux-Basis-Image. Das sollte man auch tun, tatsächlich. Genau, weil dann ja auch nochmal steht, okay, braucht der Server ein Reboot, weil ein neuer Kernel da ist oder sonst was. Ja, oder gibt es vielleicht ein CVE, was zum Zeitpunkt des Bauen des Containers noch gar nicht da war? das wir jetzt neu beachten müssen. Genau. Wenn man echtes CICD macht, dann wird es eh regelmäßig neu gebaut, dann heißt, wird man es eh sehen, aber das sind auch nochmal so Sachen, nicht alles wird jedes, nicht jedes Projekt wird jeden Tag neu gebaut, auch wenn es, wenn Teile davon kontinuierlich ausgerollt werden. Ja, ich kenne es auch so, dass dann häufig Registries gescannt werden, weil man annimmt, dass die Container, die in der Produktion laufen, aus irgendeiner Registry kommen, auch aus einer internen Registry, um halt den offenen Betrieb nicht zu bremsen. Ja. Was ich häufig nur sehe, ist, die meisten Leute, scannen nur die Container Registry. Also entweder in einem Harbor oder sonst was und die landen dann per E-Mail, kommen dann die Benachrichtigungen, wo irgendwelche Critical Vulnerabilities drin sind. Die E-Mails kannst du sehr schnell, sehr einfach wegfiltern und ignorieren. Ja. Deswegen macht man in der Regel Tickets auf und lässt die von Security schließen. Genau. Nee, schön ist dann ja tatsächlich, wenn es dann beim Bau des Containers auch auffällt frühzeitig, dass man vielleicht auch nochmal bei größten Unternehmen vor allem dann nochmal eine Pipeline oder eine Struktur hat, ein Team, was sichere Container-Images, Basis-Images bereitstellt für die Umgebung, wo die Sachen laufen sollen. Mittlerweile gibt es ja auch Zero-CVE-Container-Image-Services von Docker, von Chainguard und so weiter. Können wir vielleicht nochmal separat drüber unterhalten. Das spielt da ja nochmal mit rein. Das sollte auch überwacht werden. Du hast ja auch gerade von Reproducible Builds gesprochen. Vielleicht muss man auch mal sagen, dass es eigentlich ein sinnvolles Feature wäre, die Container auf regelmäßiger Basis neu zu bauen. Das, was du auch schon angesprochen hast. Nicht nur neu zu deployen, sondern auch neu zu bauen, um mit den aktuellen Security-Daten abzugleichen. Ja, genau. Und so schließt sich das dann halt komplett, dass man an jeder Stelle dann auch mal mal prüft und guckt und das dann auch entsprechend komplett absichert und nicht. Scheuntuch zumacht, aber 6 ist dann sperngelweit offen. Ja, mach nur. Ich hab gleich zum Abschluss noch was. Genau. Ansonsten gibt es noch recht viele Audit-Events, die man eventuell konfigurieren kann. Oder die vielleicht so schon da sind, um zu gucken, ob kein Schindluder betrieben worden sind für den kompletten Entwicklungsprozess. In GitLab gibt es zum Beispiel dann auch so Features, wo du dann auch eben sehen kannst, okay, jemand hat, der die Berichtung hatte, ein Code-Review deaktiviert, um dann irgendwie was zu merchen und dann wieder reaktiviert, damit das nicht auffällt, fällt dann halt auch in Audit-Sachen dann auf, muss man aber halt dann auch reingucken, wenn es richtig konfiguriert worden ist. Und das geht dann halt auch im Thema Compliance rüber, über Compliance können wir glaube ich nochmal separat drüber sprechen, weil das ja sehr, sehr viele Punkte gibt, die man da betrachten kann, das ist License Compliance, Regulatorik, sei es DORA, sei es NIST 2 oder sonst was, wo ich mich auch noch mal reinlesen wollte und auch wenn es erstmal und operative Compliance oder halt auch den Softwareentwicklungsprozess, wo es auch viele Sachen gibt. Aber viele Sachen, die wir in dieser Folge und in der vorherigen Folge ein Stück dazu hatten, kommen viele Sachen vor, die auch in den Compliance-Thematiken mit drin sind. Im Vorgespräch hast du schon festgestellt, dass Compliance ein sehr, sehr weites Feld ist, was sehr viele Berührungspunkte hat an verschiedenen Stellen. Bei manchen Compliance-Themen müsste man es auch auditieren lassen durch jemanden, der nicht direkt im Projekt involviert ist. Das muss nicht unbedingt einer der großen Dienstleister sein. Das kann auch durchaus ein separates Team in der gleichen Firma sein. Ja. Und da will ich mich ja mit meiner Selbstständigkeit ja auch hin entwickeln, weil das Problem wird nicht weniger, das wird eher mehr. Vor allem alles, was die SDLC betrifft, gibt es ja auch sowas wie BSE C5, DORA, nicht die DevOps Metriken, die DORA Metriken, sondern die ich weiß gar nicht, wofür es genau steht, aber das ist vor allem für Finanzinstitute relevant. Regulations Act. Ja, habe ich auch mit zu tun gehabt, ja. Digital Operations Act. Operational Resilience Act, genau. Resilience Act, sowas, ja. Genau. Und da gibt es auch viele Sachen, die du halt aus der DevOps-Plattform entsprechend dann auch absegnen kannst, wenn du es richtig automatisierst und weißt, wie es geht. Viel Papier übrigens, also, oder viel Dokumentation, die da nötig ist. Ja, aber vieles kannst du halt automatisieren. Nicht alles, aber vieles. Ja, aber um es dem Regulator vorzulegen, brauchst du halt echt was gedrucktes Buch, wo eh keiner mehr reinguckt, der guckt einfach nur, dass das Ding da ist. Ja, beziehungsweise viele Informationen sind ja teilweise schon da in dem System, die musst du dann nur wieder aufbereiten. Ja, korrekt. Weil eine Sache ist dann ja zum Beispiel so, okay, dass zu jedem Change, der gemacht wurde, ein komplettes Tracing effektiv da ist. Welches Ticket, in welchem Commit, in welchem Versionspaket, wann wurde das ausgerollt? Wenn du deine CICD-Umgebung oder DevOps-Plattform in den Griff hast, dann hast du diese Informationen grundsätzlich da. Das heißt aber nicht, dass du unbedingt einen guten Report daraus ziehen kannst. Ein Report, den ein Regulator wirklich lesen will. Oder den er anerkennt. Nicht lesen will, sondern anerkennt, ja. Aber ich hatte mal mit einem Kollegen, Bekannten gesprochen, aus einer Versicherung, der da meinte so, ah, Friday Deployments ist ein lustiger 4M-Name, bei uns wird alle halbe Jahr deployed und dann hatten wir auch so, habt ihr aber nicht diese ganzen DORA-Zeugs, die relevant werden, Compliance-Segle so, ja, da haben sie schon gesagt, da werden wir auf jeden Fall durchfallen. Dann sie, ja, warum denn? Dann sie, ja, wir hängen noch auf Subversion rum und da ist alles ein bisschen anstrengend. Ja, prima. Das ist 20, 25. Das war mindestens immerhin seid ihr schon von CVS weg. Aber ja, das sind also Themen, die kann man machen und kann man auch Alerting machen. Sollte man Alerting zu machen, wenn irgendwie was Falsches krumm ist. Also generell zu Alerting, bitte nur alarmieren, wenn eine Aktion folgen muss. Und wenn man die tatsächlich dann auch durchführen kann. Nicht Alerting, nur weil man Alerting kann. Und Alerting auch nur an das Team, das zur Lösung des Problems beitragen kann. Ja, und wenn es eine DEF-Umgebung ist, die völlig irrelevant ist, dann muss man da auch nicht alerpen. Hatte ich jetzt noch nicht. Ich leide mit dir. Ich fühle deinen Schmerz. Genau, viel mehr möchte ich dazu auch nicht sagen. Ich möchte mich nicht in Probleme begeben. Genau, ansonsten Observability-Themen, also Metrics-Logs-Traces, sind ja auch gegebenenfalls relevant, weil man dadurch halt auch Fehler finden kann, die auch Security-Relevanz sein können, nicht müssen, weil Error-Tracking gehört ja irgendwie dann auch da in dieser Ecke, was dann auch aus der Traces heraus passieren kann. Und da ist auch zu Effizienzgründen allein wichtig, dass man sich an einer Stelle einloggt und alles sehen kann und nicht in fünf verschiedenen Sachen, weil dann tut man es nicht. Wobei, ja, ich stoße mich manchmal an den Griff Observability, weil ich eigentlich am blick in die vergangenheit oft werfe weil ich irgendwas nachvollziehen möchte was in vergangenheit passiert ist ja das ja observer observability, macht bei mir den Eindruck, dass ich auf den aktuellen Zustand gucke. Das ist aber nur die eine Hälfte. Die andere Hälfte ist halt das Tracing. Ja, genau. Das hast du meistens ja für gewisse Wochen oder Monate. Je nachdem, wie viele speichern willst. Du kannst. Oder wie viel Lizenzkosten es geben willst. Genau. Ja, ich meine, Observability ist halt teuer, weil viele Daten anfallen. Vor allem bei großen Unternehmen hat man teilweise ja, wenn man Datadog einsetzt, der mehr kosten für Datadog als für die Cloud-Infrastruktur selbst. Ja, das ist häufig so. Das stimmt. Geht aber für AppDynamic genauso, ja. Ja, die sind alle teuer. Aber ja, da gibt es ja diverse Lösungen. Genau. Und wenn Alerting oder sonst was passieren oder Fehler aufgefunden werden, dann landen wir schnell wieder in der Plan-Stage, um das Ganze wieder in den nächsten Sprint oder in den nächsten Iterationen wieder zu verpacken. Und dann sind wir auch schon wieder bei Folge 60. und fangen wir sie dann von vorne an. Das, was ich gerade sagen wollte, ist, man merkt vielleicht, dass die, einzelnen Stufen aus dem DevOps-Modell, aus dieser liegenden Acht, aus dem Unendlichkeitszeichen nicht hart getrennt sind, sondern dass die ineinander übergehen. Also dass es immer Berührungspunkte zwischen den einzelnen Stufen gibt. Ja, genau. Das war bei meinem Buch auch immer so ein Problem, weil ich dann nicht wusste, wo schreibe ich das jetzt rein? Das gehört jetzt eigentlich da rein, aber auch da. Und dann habe ich es überall reingestellt. Ja, du Seitenhai. Irgendwie muss ich auf meine 400 Seiten kommen. Genau. Genau, und ich habe vor Jahren, und ich wollte Sujiven das auch für das Buch raussuchen, habe es leider nicht mal gefunden. Ich habe vor Jahren eine Grafik gesehen, die DevOps, das DevOps-Unendlichkeitszeichen dargestellt hatte. Nur, dass die, das, Auf der liegenden Acht oben noch ein Knubbel war, der dazu geführt hat, dass da Security eingeschleift wurde. Und ich habe das Bild nie wiedergefunden. Und wenn jemand aus der Hörerschaft das Bild kennt und findet, her damit, ich will es haben. Ich habe das mit so einem Schutzschild, Security Compliance, was dann dahinter liegt, quasi optisch dargestellt. Aber ich habe, so wie du diese DevOps-Unendlichkeit zeichnest, wo du die Stufen durchlaufen kannst und dann wieder am Anfang stehst, So ist da halt das Security-Thema eingeschleift worden, sodass du dann noch eine extra Runde über Security führst und dann wieder weitergehst. Das habe ich nie wieder gefunden. Schade eigentlich. Ja, ich meine gerade Security, also Thema der Folge von heute und von vorletztes Mal, ist ja genau das, was sich durch jede Stage durchzieht. Weil einige packen das eher am Ende, oder viele Sachen ist es am Ende, und das ist ja eben das Falsche. Deswegen muss man das von Anfang bis Ende drehen und dann passt das ja auch. Ja. Genau. Gut. Prima. Mich würde noch interessieren, da habe ich was vergessen. Nicht nur an dich, sondern jetzt an unsere Hörerschaft. Dann gerne melden. Es gibt viele Sachen, die man darüber noch diskutieren kann. Wenn wir was vergessen haben, liefern wir das auch gerne nach. Vielleicht nicht als separates Thema, sondern als Shorty. Gucken wir mal. Genau, mich würde auch tatsächlich auch interessieren, gibt es welche, die das auch so wirklich konsequent mal irgendwo durchgezogen haben? Ich kenne es jetzt so richtig konsequent, nämlich nicht, nirgendwo. Wenn das jemand konsequent durchziehen möchte, dann, ich bin selbstständig, dann würde ich das gerne machen, weil da kann man das auch viel halt schon machen. Einige müssen das halt auch eben, aber ignorieren die Compliance-Sachen dann halt auch. Ja. Genau. Prima. Kommen wir zum Medientipp, und zwar von dir. Ja, ich habe nach meinem Vortrag auf der Frostcon ein Buch vorgeschlagen bekommen, was ich mal lesen sollte. Das hieß das kleine Handbuch des Stoizismus. Mir hat Stoizismus so gar nichts gesagt. Und ich habe im Rahmen der Beschäftigung gemerkt, dass Stoizismus eigentlich eine Sache ist, die ich versuche schon seit ewig zu leben. Und natürlich grandios scheitere, wie auch immer. den Link dazu tun wir euch in die Sendungsnotizen und es gibt das auch als gratis Hörbuch bei Deezer und Spotify Spotify. Also es geht vor allem darin, dass man dass man mit sich selbst im Reinen ist und das auch lebt und dass man immer so die beste Version seines Selbst zeigen soll, was mir natürlich auch nicht immer gelingt und, da geht es um Kardinaltugenden die Klugheit, Gerechtigkeit, Tapferkeit und Selbstdisziplin, weil mir hapert es in vielen Belangen einer Selbstdisziplin und ob ich klug bin, das müssen auch andere entscheiden aber Gerechtigkeit ist mir ein Anliegen, da bin ich auch vorgeprägt ich bin mit dem Mordsgerechtigkeitssinn, erzogen worden und da der klingelt halt relativ häufig und Tapferkeit, also es gibt genau vier Bereiche an denen ich arbeiten kann, nämlich an Klugheit Gerechtigkeit, Tapferkeit und Selbstdisziplin und, ich finde das ganz spannend Also eine der Sachen, die mit Stolizismus wichtig ist, ist zu sagen, man sollte sich auf das konzentrieren, was in meiner Macht liegt und das akzeptieren, was nicht in meiner Macht liegt. Das schließt dann die Circles of Influence an, aber es geht halt darum, das Beste aus sich selbst rauszuholen. Und ja, ich habe mich bestärkt gefühlt, da nochmal tiefer einzutauchen und dann nochmal ein bisschen mehr zu lesen, weil eigentlich ist es das, wie ich leben möchte. Ja, ich hatte ein Buch zu Stoizismus gelesen von Ryan Holiday. Ja, genau, das gibt es auch. Da gibt es eine Trilogie. Und das hat mich überhaupt nicht abgeholt. Also nicht das Thema selbst, sondern wie das geschrieben hat. Ich habe es aber auch auf Englisch gelesen. Vielleicht war das bei dem Buch ein Problem. Ja, also ich habe vier Bücher auf meiner Leseliste von Ryan Holiday. Das richtige Tun genau jetzt. Disziplin, Mut und Weisheit. und es müsste irgendwann noch ein viertes geben oder ein fünftes, ich weiß gar nicht, ob die alle zu einer Reihe gehören. Ja Ich muss gerade mal gucken, welches ich gelesen habe, ist nämlich schon eine Weile her Ach. Das sind die vier Tugenden, Mut, Disziplin das richtige Tun und Weisheit Okay. Ich habe es anfangs 2024 gelesen und es war Stillness is the Key, Auf Englisch Ja. Das weiß ich da nicht, was ich habe mir nur die deutschen Titel rausgeschrieben. Ja, aber wie gesagt, das fand ich nicht so, hat mich nichts abgeholt. Also ich fand das kleine Handbuch des Stolzismus sehr gut lesenswert, sehr gut zu lesen und es ist interessant, sich mal damit auseinanderzusetzen. Er hat am Ende des Buchs dann auch irgendwie 50 Übungen oder 55 Übungen nennt er die, wo es dann darum geht, verschiedene Punkte nochmal zu beleuchten. Wie man dulden kann, was im Weg steht, wird zum Weg der Vergänglichkeit, Bewusstsein und, und, und, und. Also es gibt eine ganze Menge Themen dazu. Ich bin dankbar für den Tipp. Danke an den Besucher meines Vortrags, dass du mir den Tipp gegeben hast. Ich habe es mit sehr viel Gewinn gelesen. Sehr gut. Muss ich vielleicht auch mal lesen. Vielleicht holt mich das mehr ab als das von... Ja. Der Anfang ist ein bisschen theoretisch, der geht ein bisschen in die Geschichte, um was Stolzismus eigentlich ist. Aber es wird dann relativ schnell konkret. Ja. Gut. Kommen wir zu meinem Medien-Tipp. Und zwar ist das diesmal eine ZDF-Serie namens Chabus. Und die, ich glaube, wenn du die gucken würdest, da ziehst du, glaube ich, nicht so viel raus wie ich. Ich fand es irgendwie schon sehr passend für mich, weil die Serie spielt sowohl in der aktuellen Zeit als auch in der aktuellen Zeit mit so Mit-30ern. In den Mit-30ern, sagen wir so. Und mit der gleichen Person dann halt auch im Jahr 2006 als Schüler. Das passt für mich halt genau, weil ich da ja auch Schüler war und jetzt Mitte 30 bin oder Anfang 30 bin. Und die Kern-Story ist relativ simpel. Ein Typ wird zum Klassentreffen nicht eingeladen und fragt sich, warum und fängt an zu recherchieren, indem man dann guckt, okay, was machen die Leute von damals aus seiner Schulklasse und so weiter. Und wie gesagt, dadurch, dass es halt auch so mein Zeitalter ist, passt das irgendwie super. Das war dann nämlich ein extrem, Nostalgie-Thema für mich. Und was halt auch nochmal ist, das Spiel in Duisburg in und um Duisburg. Das heißt, man sieht dann auch mal ein paar Ecken, die man so auch nochmal kennt, also die wir zumindest kennen. Ja. Und mit den typischen Ruhrgebiet-Siedlungen dann halt. Und dann fühlt er sich nochmal mehr nach zu Hause an, so ein bisschen. Ja. Und ja, warum hat das so einen, so ein Nostalgie-Effekt für mich. Das eine ist, da sind dann halt die Schüler, die ICQ verwenden, wo sie dann sagen, ich weiß gar nicht, ob du ICQ verwendet hast. 1056000. 259061118. Beantworte das deine Frage. Wie viele, wie lange warten die Sache noch mal? Sieben Ziffern. 1056. Sieben, ja okay, bei mir waren es der Neuen. 0, 0, 0, ja. Es gab aber noch welche mit 4 oder sowas. Ja, gab's bestimmt, aber ich war's nicht. Aber das war halt meine Jugend und genauso wurden die halt auch dargestellt mit den fetten Monitoren und alles im Kinderzimmer und bla bla. Dazu gehören dann auch so Sachen wie Frisuren von den Kindern, die ich halt auch voll aus meiner Schulzeit kenne von anderen Leuten. Da spielt nochmal die Sprache rein, die zu der Zeit halt normal war, in der Jugendsprache quasi. Was ich da auch super witzig fand, da hat dann jemand eine Website-Baukasten geschrieben. eine Webseite mit einem Website-Baukost-System mit BeepWorld gemacht und genau das unternet.devu-Adresse genutzt. Genau das gleiche habe ich damals auch gemacht. Vielleicht warst du das Rollmodel für die Serie. Weil ich ja auch mit BeepWorld angefangen habe und das war auch eine DEVU-Adresse. Okay, das ist jetzt irgendwie witzig. Da kann auch noch mal Sachen vor, die haben sich den Film Sword 2 angeguckt, habe ich auch damals geguckt, illegal runtergeladen da ging es nämlich auch um illegal runterladen und auch sowas wie mit die verschiedenen Torensachen und was es da noch so gab und spielt halt auch zur Fußball-WM 2006 nochmal, und dann war da auch nochmal irgendwie so ein Ding dass dann Wetten, dass lief in der Serie auf dem Fernseher und ich konnte mich an die Folge erinnern sehr, sehr glücklich ja, spannend, und das fand ich dann halt irgendwie so viele Sachen, wo ich dann dachte, okay, das ist jetzt witzig daran erinnere ich mich jetzt auch, weil auch so viele Sachen, die ich halt vergessen habe, aber einfach nur wie gesprochen wie gemacht wurde da zu der Zeit, die Story ist jetzt nicht super toll oder sonst was, aber, allein dieser Nostalgieeffekt das habe ich dann direkt ein paar Leuten auch empfohlen, die so mein Alter sind und sonst was damit so, hey, das könnte was für dich sein. Das gucke ich mir auch an, finde ich klasse. Ja. Ja, aber ja, ich glaube, für mich passt es nochmal eher als für dich, aber ja, kann man sich angucken, also es ist nichts Komplexes, aber es ist eine leichte Unterhaltung. Kommt aus dem Ruhrgebiet, alles gut. Ja, es ist jetzt halt auch deutsche Produktion so, jetzt kein High-End-Netflix-Zug. Ja und, egal. Aber dafür zahlen wir unsere Rundfunkgebühren. Ja, aber ich habe eh kein Netflix, von daher. Ja, ich auch nicht. Leute, muss ich das hätten. Aber ja, lohnt sich, kann man sich angucken. Er kam diesen Sommer, glaube ich, raus. Super Tipp. Das ist nicht super halt. Ganze Folgen kann man sich natürlich via Mediathek wie Web herunterladen. Genau. Und die Folgen sind so zwischen 30 und 40 Minuten lang. Habe ich gerade gesehen. Und acht Folgen, also es ist nicht super viel oder super lang. Ja, aber sehr cool. Genau. Wunderbarer Tipp. Und dann haben wir noch einen Tooltipp für heute. Der Tooltip ist Litchi. Litchi ist ein Linkchecker. Wer jetzt denkt, ein Linkchecker ist eigentlich ein relativ einfaches Tool. Da muss man ja nur gucken, ob die Gegenseite einen 200er Call zurückgibt, einen 200er HTTP Return Call zurückgibt. Ja, weit gefehlt. Wer genau wissen möchte, wie so ein Link-Checker funktioniert, dem sei die Folge vom Engineering-Kiosk-Konzert gelegen, das ist die Folge 201, wir verlinken die natürlich auch in den Sendungsnotizen. Da habe ich das Tool auch her, daher kenne ich das Tool und das ist ein Link-Checker, den man auf ein Bündel Markdown-Dateien loslassen kann und sagen kann, prüfen wir bitte alle Links, die in den Markdown-Dateien erwähnt werden, die man einfach auf Webseiten, auf URLs, laufen lassen kann, um zu gucken, ob alle Links noch funktionieren. Ich lasse das Tool regelmäßig gegen meinen Block laufen. Es ist ein kleiner Container, mit dem man das machen kann. Ich finde es richtig super. Gut gelungen und tolle Software. Ach so, das kann auch direkt auf HTML, auf Markdown zugreifen. Ja. Weil ich habe das nämlich, nachdem du mit dem Tool meine Website geprüft hast und auf kaputte Links hingewiesen hast, habe ich das in meine Pipeline eingebaut. Die läuft aber direkt gegen die Webseite und nicht gegen HTML oder Markdown-Code, der dann noch lokal liegt. Das heißt, ich muss das noch umbauen. Ja, aber du kannst es einfach auf das Git-Repository laufen lassen zum Beispiel. Ja, genau, weil im Moment ist nämlich das Problem, so wie meine Pipeline jetzt eingebaut ist, aufgebaut ist, ist ich, Hugo baut die Webseite, dann läuft Litchi aber gegen die Deployte-Webseite vom effektiven Container, vom Pipeline-Lauf davor, also was halt schon Deployte ist. Das heißt, die Änderung, die ich dann gemacht habe, prüft er gar nicht. was natürlich dann falsch ist. Ja, wobei man sagen muss, dass natürlich Links, die erst dann funktionieren, wenn das Ding deployed ist, kriegt das du nicht mit. noch mal ich habe ja verlinke ich habe ja auch ein blog mein change block ja und in dem change stock habe ich ein static bereich ja die static links löst nicht auf in meinem blog, ok zum beispiel ja ja aber alles was so http request sind dass das kann das ding direkt erledigen. Ja, das steht auf der Webseite auch drauf, dass das JSON-Output hat, sodass du das in CRCD-Pipelines mit nutzen kannst. Aber es ist wirklich ein cooles Tool. Die Podcast-Episode, vielleicht ist das auch nochmal ein zweiter Medientipp an der Stelle, kann ich euch auch ans Herz legen. Also man macht sich keine Vorstellung davon, an was man alles denken muss, wenn man Leak-Checker baut. Ja, das sollte ich mir vielleicht auch mal ankommen. Ja, ich fand es sehr cool. Gut. Ja. Dann sind wir fertig, glaube ich. Ja, wir sind fertig und wir wollen Feedback. Ja. Wie lange hört ihr uns schon? Alles unter fünf Jahre kann nach Hause gehen. Und alles über fünf Jahre? Lügt. Hat auch ein LLM so gesagt. Nein, ich würde mich freuen, wenn wir ein bisschen Feedback von euch bekommen, ob es euch der Podcast als Ganzes was bringt und euch ein bisschen weiterhilft und dass das nicht nur hier Sujivan und Dirk bespaßend sich gegenseitig Programm ist. Wir würden uns freuen, wenn ihr in unsere Matix-Gruppe kommt oder wenn ihr generell Feedback da lässt über Kontaktformular, E-Mail, Mastodon. Wir sind eigentlich überall zu finden. Im alternativen Internet, wenn man so will. Nicht in den Mainstream. Wir haben nur keine Faxnummer. Müssen wir Ihnen reekommen. Ja, wir sind natürlich der Urlaub im UserSpace-Podcast. Genau. Also Feedback sehr willkommen, umso mehr, dass wir jetzt fünf Jahre dabei sind. Genau. In dem Sinne, danke fürs Zuhören. Und bis zum nächsten Mal. Genau, bis nächstes Jahr. Oh ja. Wenn man das noch in 2025 hört zumindest. Ja, genau. Bis dann. Tschüss.