Sam Newman über Software Factories: Warum KI eure Incidents noch nicht beheben kann

Intro

Benedikt Stemmildt 00:11
Guten Morgen zusammen. Willkommen zurück bei Rethink Engineering. Ich bin Benedikt, euer Host dieser Show, und in diesem Podcast versuchen wir herauszufinden, wie Agentic Engineering einen tiefgreifenden Effekt auf die Teams hat, die Software liefern, und auf eure Organisation. Die Show wird präsentiert von hackers&wizards und re:cinq, und heute sprechen wir mit Sam Newman. Ihr kennt ihn wahrscheinlich, weil er viele Bücher über das Bauen von Microservices geschrieben hat, und jetzt hat er ein Buch über Resilience in verteilten Systemen geschrieben.

Dieses Thema ist für mich in Zeiten von Agentic Software Engineering sehr wichtig, weil wir selbst ein verteiltes System von Systemen sind. Sam hat eine Sache gesagt, die mir wirklich hängen geblieben ist: dass es bei Resilience nicht darum geht, sicherzustellen, dass nichts schiefgeht, sondern darum, sicherzustellen, dass so viele Dinge wie möglich gut gehen. Lasst uns mehr darüber herausfinden. Hier ist Sam.

Sams neues Buch über resiliente verteilte Systeme

Benedikt Stemmildt 01:17
Hallo, Sam. Willkommen in unserem Podcast. Ich fühle mich super geehrt, dass du hier bist. Wie geht's dir zurzeit? Was machst du so? Wer bist du? Vielleicht führst du uns ein bisschen in deine aktuelle Welt ein.

Sam Newman 01:29
Fangen wir damit an, dass ich sage: Mir geht's gut. Super geht's mir eigentlich nicht. Ich hab eine Erkältung, das ist so der Nachteil.

Es wäre schön, wenn wir uns persönlich treffen würden, weil ein Gespräch von Angesicht zu Angesicht immer schöner ist. Aber der Vorteil, wenn man sich nicht persönlich trifft, ist, dass du dir meine Erkältung nicht holen kannst. Ich funktioniere also gut, aber du bist auf deiner Seite in keinerlei Gefahr.

Mir geht's im Moment ziemlich gut. Ich hab buchstäblich, bevor ich mich hier zugeschaltet habe, die allerallerletzten Überarbeitungsrunden für mein neues Buch gemacht, Building Resilient Distributed Systems.

Ich hab noch drei Kapitel durchzugehen, und das erscheint dann Ende September. Ihr könnt es jetzt schon vorbestellen, aber die gedruckten Bücher bekommt ihr so Anfang Oktober, Ende September rum. Und wenn ich das nicht mache und nicht über Resilienz rede, verbringe ich viel Zeit damit, mich mit KI und Architektur zu beschäftigen, weil all diese Dinge irgendwie, ich liebe Dinge, die sich überschneiden.

Aber ich meine, ich bin Entwickler, Sysadmin, Entwickler und Architekt, so ein bisschen eine Mischung aus allen drei Sachen, wahrscheinlich jetzt schon seit fast 30 Jahren.

Es sind, schätze ich, technisch gesehen jetzt gerade fast 30 Jahre, die ich dafür bezahlt werde, Software-bezogene Sachen zu machen. Und eigentlich seit 2004 arbeite ich so als eine Art Berater, anfangs bei einer großen Beratung, und jetzt arbeite ich selbstständig. Und wenn ich nicht mit Kunden arbeite und Trainings und Beratung für Kunden mache, schreibe ich Bücher, was ich wirklich gern mache.

Benedikt Stemmildt 02:51
Ja, ich bin auch ein großer Fan deiner Bücher. Ich hab, glaube ich, die meisten davon gelesen. Deshalb interessiert mich das neue super. Vielleicht kannst du uns ein bisschen mehr darüber erzählen. Ich meine, die letzten Kapitel zu schreiben ist immer so ein, ich schreib gerade selbst eins, mein erstes. Ich kenn also jetzt irgendwie das Gefühl, wie es ist, die allerletzte Überarbeitung zu machen, weißt du, das ganze Zeug.

Sam Newman 03:12
Also, das ist eine komische Sache, weil die, weißt du, einen großen Teil meiner Karriere hab ich mich darauf konzentriert, Dinge schnell rauszubringen, oder? Ich hab ganz, ganz viel Zeit damit verbracht, Leuten bei Sachen wie Continuous Delivery und all so was zu helfen, also: Okay, ich hab die Idee, ich hab's gemacht, jetzt bring es richtig, richtig schnell raus. Und deshalb finde ich diesen kleinen Teil des Buchschreibprozesses schon etwas frustrierend, weil das so die redaktionelle, die finale, das ist so der Durchgang fürs Buchlayout.

Das ist also der, aber eigentlich war ich mit dem Schreiben vor ungefähr zwei Monaten fertig. Und das ist also irgendwie erst anderthalb Monate her. Es fühlt sich also so an, als wäre ich emotional schon fertig.

Aber es gibt noch einiges, was erledigt werden muss. Das Buch hab ich aus so zwei Hauptgründen geschrieben, aus denen ich das Buch geschrieben hab, und dieses Buch konzentriert sich auf Resilience Engineering im Kontext verteilter Systeme, das ist so irgendwie der Pitch auf hoher Ebene. Es nimmt also Ideen aus der Welt des Resilience Engineering und schaut, wie sie sich auf die verteilten Systeme anwenden lassen, die wir bauen, mit ein paar sehr konkreten, so praktischen Sachen, so: Was ist ein Timeout, wie macht man Retries und Idempotenz.

Also sehr irgendwie praxisnah, Dinge, die man, glaube ich, anfangs leicht versteht, aber auch sehr stark in diesem Geist des Resilience Engineering, bei dem es ganz darum geht, ich glaube, wenn Leute an Resilienz rangehen, denken sie anfangs naiv, es geht darum sicherzustellen, dass nichts schiefgeht. Und das ist etwas, das ich im ersten Kapitel versuche anzugehen, so: Das kann eine gute Idee sein. Aber eigentlich sollte dein Fokus darauf liegen sicherzustellen, dass so viele Dinge wie möglich gut laufen.

Genau, das ist der Geist und so irgendwie das Konzept hinter Resilience Engineering. Wie gehen wir das also in einem, in einem verteilten System an? Und aber auch die Tatsache zu bekräftigen, dass ein verteiltes System mehr ist als nur die Computer und die Netzwerkkabel, es sind auch die Leute, die das System betreiben. Wie beeinflussen also Organisationsdynamik, Kultur, psychologische Sicherheit, all diese anderen Dinge unsere Fähigkeit, dieses System zu bauen. Darum geht's also irgendwie in dem Buch.

Und ich hab es so aus zwei Gründen geschrieben. Einer davon ist, dass, obwohl ich viel Zeit damit verbringe, Leuten zu sagen, keine Microservices zu nutzen, weil sie wirklich, sie können zu vielen Quellen von Komplexität und Schmerz und Leid beitragen, viele Leute es trotzdem machen. Und deshalb haben wir mehr Leute, die verteilte Systeme bauen, als wir, sagen wir, vor 10, 15 Jahren hatten.

Und deshalb fühlte es sich so an, als ob der Schmerz, weißt du, ich glaube, das Problem ist, dass der Dopaminkick, den Kick kriegst du vor dem Schmerz, der Schmerz und das Leid kommen erst später.

Ja, der zukünftige Sam wird den Schmerz und das Leid haben. Und deshalb jetzt, weißt du, und deshalb treibt dich zum Beispiel so eine Microservice-Architektur dazu, schneller zu verteilen, aber du, es gibt die natürliche Tendenz, ziemlich früh feingranular zu werden, ob das nun eine gute Idee ist oder nicht. Und ich hab so erkannt, dass, so sehr ich den Leuten auch sage, langsamer zu machen, sie nicht hören, das ist okay, das ist, das ist euer Leben.

Aber dann hab ich gedacht, na ja, wenn du dich dann in einer Situation wiederfindest, wo du ein bisschen zu weit gegangen bist, oder jemand anders dafür gesorgt hat, dass es zu weit geht, wie helfe ich dir dann sicherzustellen, dass dein System tatsächlich resilient ist?

Es ist also so, meine Hoffnung ist, dass dieses Buch so wie ein Rettungsring ist, den du jemandem gibst, der am Ertrinken ist, so: Okay, das ist es, das ist das Buch.

Dafür sorgen, dass Dinge gut gehen

Benedikt Stemmildt 06:10
Ich meine, ich habe das Gefühl, dass das etwas ist, das mit mit KI auch immer wichtiger wird. Das ist also wahrscheinlich etwas, worüber wir in der nächsten Stunde auch noch sprechen werden. Aber zuerst dachte ich, als du gesagt hast, dass die Idee von Resilienz in diesem Fall nicht so sehr ist, dafür zu sorgen, dass nichts schiefgeht, es ist eher so: sicherstellen, dass Dinge gut laufen.

Ich glaube wirklich, dass das ein fundamentaler Unterschied ist, den wir vielleicht noch ein bisschen genauer anschauen sollten, bevor wir ins KI-Thema wechseln, weil ich das Gefühl habe, dass das auch für das KI-Thema sehr zutrifft, diese andere Sicht auf die Dinge, weißt du,

Sam Newman 06:50
und das ist irgendwie der andere Grund, warum ich das Buch geschrieben habe: Es gibt viel, es gibt ein ganzes Forschungsfeld rund um Resilience Engineering, das aus der Welt der sicherheitskritischen Systeme kommt. Denk also an Dinge wie, weißt du, Leitsysteme von Kraftwerken, Flugsicherungssysteme, Fly-by-Wire-Flugzeuge, aber sogar bis hin zu Dingen wie, weißt du, Operationssälen und wie Krankenhäuser laufen, oder, das sind alles sicherheitskritische Systeme, es gibt ein ganzes Forschungsfeld in dieser Welt, weil die Folge davon, diese Dinge falsch zu machen, ist, dass Menschen sterben.

Und daraus gibt es viele Lektionen und viel Wissen, aber es ist oft ziemlich akademisch und schwer zu verarbeiten. Und ich bin zum ersten Mal auf dieses Zeug gestoßen, vielleicht vor so 15, 20 Jahren, aber wir haben es nicht verstanden. Und ich dachte mir: Kann ich das zugänglicher machen?

Und so habe ich versucht, ich habe mir, weißt du, diese Papers regelrecht in den Kopf gehämmert. Und das, was bei vielem davon irgendwie den Groschen hat fallen lassen, dieses Ding, über das ich im ersten Kapitel spreche, ist, dass man irgendwie klassisches Sicherheitsmanagement hat.

Und dann hat man das, was wir heute als Resilience Engineering bezeichnen. Sicherheitsmanagement, also so klassische Ansätze, um sicherzustellen, dass Dinge sicher sind, war sehr darauf fokussiert: Lass uns sicherstellen, dass nichts kaputtgeht. Genau. Das ist so wie, weißt du, bei den Simpsons, da gibt es dieses Schild, weißt du, wie viele Tage seit dem letzten Unfall, oder, das ist ein Fokus auf: Lass uns sicherstellen, dass nichts, nie etwas schiefgeht. Und das ist keine schlechte Idee.

Es ist nicht falsch, nicht zu wollen, dass Dinge schiefgehen. Aber für sich allein reicht es nicht.

Benedikt Stemmildt 08:22
Das Problem ist, dass in der Realität eine Menge schiefgeht, oder. Und sogar so, wenn man mit KI schneller ist und so verteilter ist und so weiter, gibt es mehr Faktoren, die Dinge schiefgehen lassen, oder?

Sam Newman 08:33
Absolut. Ja, ich meine, es ist zum Teil ein Zahlenspiel. Es ist zum Teil auch ein Spiel mit Dingen außerhalb deiner Kontrolle.

Ich meine, wenn man es aus Sicht der Zahlen betrachtet, einfach als so eine Art theoretische Übung, stell dir vor, du hast eine Komponente in deinem System. Und an jedem beliebigen Tag hat diese Komponente eine Chance von eins zu 100, auszufallen. Das ist ziemlich hoch als Ausfallrate für so ein Stück Hardware, oder?

Aber nehmen wir es einfach mal so an. An jedem beliebigen Tag hast du also eine Chance von eins zu 100, dass diese Komponente kaputt ist.

Wenn du also nur eine Komponente in deinem gesamten System hast, kann es tatsächlich sinnvoll sein, Aufwand hineinzustecken, damit diese Ausfallrate auf eins zu 1000 sinkt. Denn wenn sie ausfällt, geht das ganze System down, oder? Du, du behandelst das also irgendwie ein bisschen anders.

Wenn du jetzt 100 Komponenten hast, nähert sich die Wahrscheinlichkeit, dass an einem beliebigen Tag eine Komponente ausfällt, der Eins, es ist nicht genau eins, es nähert sich der Eins, es wird einfach immer sicherer. Sobald du also in diese Welt kommst, denkst du dir: Na ja, ich kann weiter versuchen, die Wahrscheinlichkeit zu verringern, dass einzelne Komponenten ausfallen, oder ich kann jetzt mein Mindset darauf umstellen, wie ich sicherstellen kann, dass das System weiter funktioniert, selbst wenn Dinge ausfallen.

Und eine der besten, so, physischen Ausprägungen davon, die ich gesehen habe, war, als ich einige der alten Google-Server zu sehen bekommen habe. Die kann man im Science Museum sehen, ich glaube in UK, ich glaube, die sind immer noch da, und dann gab es ein Rack davon im Computer Museum im Silicon Valley. Und ich durfte sie damals 2007 auf dem Google-Campus sehen.

Aber die waren so, also denk an einen klassischen Server in einem Rack, oder, da siehst du irgendwie leuchtende Lämpchen und all diese schönen Panels, die alten Google-Server sind einfach nackte Mainboards, direkt ins Rack gesteckt, kein Gehäuse obendrauf.

Und es stellt sich tatsächlich heraus, dass das für den Luftstrom in Ordnung ist. Das ist kein großes Problem. Ja, wenn man sie anschaut, merkt man ein paar interessante Dinge.

Erstens siehst du die Netzteile hinten aus dem Gehäuse raushängen. Das ist nicht eingebaut, das hängt hinten aus dem Gehäuse raus. Und es ist mit Klettband befestigt.

Die Festplatten im Gehäuse sind auch mit Klettband befestigt. Denn die Dinge mit beweglichen Teilen, die Dinge, die im Server am ehesten ausfallen, Netzteile, Festplatten mit rotierenden Scheiben, die haben unter den Komponenten die höchsten Ausfallraten.

Und Google hatte also erkannt: Wir haben so viele Computer, einer wird sowieso ausfallen. Also lasst uns erstens unsere Software so bauen, dass wir weiterlaufen können, selbst wenn uns ein Computer ausfällt, check. Und zweitens lasst uns Aufwand hineinstecken, damit wir, wenn ein Ausfall auftritt, diese Maschine schnell wieder zum Laufen bringen. Und so ist es buchstäblich so, wenn ein Computer ausfällt, ist das der Software ziemlich egal. Ich meine, wir sind hier in den Zeiten von MapReduce, oder?

Du hast ein Tray rausgezogen, du hast gesehen, okay, das ist die Festplatte, Klettband auf, ab in den Müll, eine andere Festplatte rein, Klettband drauf, rein damit, PXE-Boot, und los geht's. Und es gibt also irgendwie zwei Ebenen davon. Es gibt einen Typen namens David Woods, der ein ziemlich wegweisendes Paper über Resilience Engineering geschrieben hat, so die vier, vier Konzepte von Resilience Engineering, und zwei dieser Konzepte, über die er spricht, sind so Robustness und Rebound.

Robustness ist also die Fähigkeit des Systems, weiterzulaufen, selbst wenn Dinge schiefgehen. Das ist also so wie der ausfallende Computer. Und Rebound ist dann deine Fähigkeit, dich zu erholen, wenn etwas ausfällt. Und das ist das Beispiel mit dem Computer, der wieder hochkommt, wieder läuft. Und so kann man das irgendwie von zwei Ebenen aus angehen. Sie haben also darauf optimiert, dass es egal ist, wenn ein einzelner Computer ausfällt, und dass es wirklich einfach ist, einen einzelnen Computer wieder zum Laufen zu bringen.

Und das ist natürlich nicht für jeden das Richtige. Wenn du nur einen Computer hast, ist es absolut sinnvoll für dich, Dinge in Betracht zu ziehen wie redundante Netzteile, Netzteile und, weißt du, redundantes rack-lokales Networking und mehrere NICs und all diese anderen Dinge, die du vielleicht machst, um eine Maschine irgendwie resilienter zu machen. Aber zunehmend hängen unsere Systeme sowieso nicht von einer einzelnen Maschine ab. Das verändert also ein bisschen, wie wir darüber, darüber denken, unsere Systeme am Laufen zu halten.

Robustness und Rebound

Benedikt Stemmildt 12:34
Ich finde, wir sollten diese Rebound-Idee noch ein bisschen weiter vertiefen, weil ich das Gefühl habe, dass das gerade jetzt super interessant ist, mit der KI-Arbeitsweise, mit KI zu arbeiten und KI auch zum Bauen von Systemen zu nutzen. Weil es ja diese Vorstellung gibt, dass KI so weniger Qualität reinbringt und so weiter. Also die Seite, die dafür sorgt, dass das System keine Fehler macht, könnte schlechter werden.

Vielleicht hast du dazu auch ein paar Gedanken. Aber auf der anderen Seite könnten wir jetzt vielleicht auch auf der Rebound-Seite viel besser sein, weil wir KI haben, also können wir mit KI viel schneller reagieren.

Also ich denke, wir vielleicht kannst du. Aber was ist deine Idee? Wie siehst du das?

LLM-Anbieter sind noch nicht auf Cloud-Niveau

Sam Newman 13:20
Ja, wir können da verschiedene Teile auseinandernehmen. Ja. Also erstens, auf einer ganz grundlegenden praktischen Ebene: Wenn du dich auf Modelle der Foundation-Firmen verlässt, wenn du so Anthropic- oder OpenAI-Modelle nutzt, ist deren Quality of Service im Vergleich zum Normalen ziemlich schlecht. Sehr schlecht. Auf der Basisebene laufen sie nicht immer. Du hast, du hast Konnektivitätsprobleme, du hast so irgendwie, ich meine, sie versuchen, das zu verbessern, beide Firmen versuchen, das zu verbessern.

Aber grundsätzlich bekommst du nichts, was annähernd an die Quality of Service herankommt, die du von einer normalen Managed-Cloud-Ressource erwarten würdest. Und deshalb lassen auf der Basisebene viele Firmen ihre Foundation Models entweder von Amazon auf AWS laufen, so mit Bedrock, oder sie gehen zu Microsoft oder zu Google, entweder als primären Ort, an dem sie diese Foundation Models laufen lassen, oder als Fallback. Und ich habe mit ein paar Firmen gesprochen, die sie im Grunde als Fallback nutzen.

Das ist also irgendwie einfach die Basisebene, oder? Man kann nicht, sie sind nicht toll. Da steckt aber noch ein zweites Problem drin, bei dem es mehr um die Qualität der Antworten geht, die wir zurückbekommen.

Und deshalb spreche ich im Buch nicht wirklich über funktionale Korrektheit, in den Resilienz-Büchern, ich finde, es gibt einen Ort, an dem wir darüber sprechen können. Aber das ist grundsätzlich ein Problem bei der Nutzung jedes LLM-basierten Produkts, weil der Nichtdeterminismus bedeutet, dass herauszufinden, ob es das Richtige tut, irgendwie schwieriger wird.

Ich bin sicher, die Leute haben das schon gehört, aber nur für den Fall: Wenn ich ein deterministisches Stück Code habe, bekomme ich bei gleichen Inputs die gleichen Outputs, deshalb ist es ziemlich einfach zu testen und zu verifizieren, dass es in einer bestimmten Situation das Richtige tut. Die LLM-basierten Agenten sind nicht deterministisch, bei gleichem Input geben sie uns unterschiedlichen Output. Und das macht es ziemlich schwer, sie auf traditionelle Weise zu testen. Tatsächlich zu verifizieren, dass sich diese Dinger korrekt verhalten, ist also schwierig.

Und hier kommt man in die Welt der Evals und muss Evals im Grunde in seine Produktivsysteme einbauen. Und es erhöht auch die Bedeutung von Observability rund um deine agentischen Systeme. Da gibt es noch ein kleines verstecktes Stück, das darauf zurückkommt, wie sehr wir den Model-Providern hier vertrauen können, nämlich dass wir definitiv Beispiele sehen, in denen Modelle ohne ersichtlichen Grund einfach in ihrer Qualität nachlassen. Sie sind also nicht im Steady State, sie sind nicht einmal inkonsistent innerhalb einer schmalen Bandbreite von Inkonsistenz.

Es gibt Zeiten, in denen sie aus irgendeinem Grund einfach ein bisschen dümmer wirken. Und das ist nicht toll. Ein paar Checks dafür zu haben, ist also irgendwie echt, echt wichtig.

Und deshalb gibt es auch andere Aspekte, die aus Resilienz-Sicht dazukommen, aber im Grunde lohnt es sich, diese Dinge aufzubrechen, in kleinere Stücke zu zerlegen. Und wenn du Resilienz wirklich groß denkst, wenn du Resilienz langfristig denkst, dann musst du auch an Multi-Model und Multi-Vendor denken, denn inwieweit wir garantieren können, dass es diese Anbieter in den nächsten fünf Jahren, nächsten 10 Jahren noch in der Form gibt, wie sie jetzt sind, da halte ich die Wahrscheinlichkeit für gering, bei allem, was gerade so los ist.

Was kannst du also tun, um in deiner Architektur Möglichkeiten zu schaffen, das durch andere Dinge zu ersetzen, alternative Anbieter, alternative Modelle? Ich denke also, im Moment, weißt du, würde ich dir dringend empfehlen, zumindest ein bisschen damit zu experimentieren, Modelle von verschiedenen Providern zu mischen, seien es Open-Weights-Modelle oder verschiedene Foundation Models, einfach um sicherzustellen, dass du eine andere Richtung hast, in die du gehen kannst, falls einer dieser großen Provider irgendwie wegfällt.

Das ist also so das große Bild.

Benedikt Stemmildt 16:59
Ich glaube, das geht eher nicht um den Rebound-Teil, oder? Das geht eher darum, so, wie man das, wie man es von vornherein sicher baut, oder, mit den Evals und so weiter. Und ich meine, die konkreten Fragen, die ich hier habe, sind, wenn wir uns noch ein paar Minuten darauf konzentrieren können.

Aber ich habe das Gefühl, dass auch das, was du gesagt hast, so das Wechseln eines Modells, nicht nur so der technische Teil ist, es einfach über einen anderen Server zu routen oder so. Sondern wenn es ein komplett anderes Modell ist, werden die Antworten nicht nur von anderer Qualität sein, sondern sie werden auch komplett anders sein, oder?

Also ja, derselbe Skill oder derselbe Prompt wird nicht zum selben Output führen, und zwar nicht im Sinne von, okay, es ist ein bisschen schlechtere Qualität, es könnte so komplett anders sein, oder?

Sam Newman 17:44
Und das ist das hier aber, für mich ist das so, also es gibt hier eine Analogie zu Multi Cloud. Und so: Sollte man auf Multi Cloud gehen? Und ich sage meistens nein, lass es, weil es zu viel Arbeit ist, es ist zu viel Aufwand.

Und das basiert auf den Risikofaktoren: Wird ein Cloud-Anbieter wirklich seine Preise im Vergleich zur Konkurrenz massiv hochschrauben? Das ist unwahrscheinlich. Wird ein Cloud-Anbieter verschwinden? Das ist unwahrscheinlich.

Ja, ich glaube nicht, dass eins dieser beiden Dinge im Moment auf die großen Model-Anbieter zutrifft.

Ja, die Preise schwanken wild. Absolut. Absolut.

Genau. Die Risikofaktoren sind also anders. Aber du hast völlig recht, dass sie weniger Utility sind als die anderen Teile.

Und mein Ansatz dazu ist also nicht zu sagen, für einen bestimmten Workload, lass ihn auf beiden laufen, sagen wir auf Anthropic und OpenAI. Sondern wenn wir uns unseren agentischen Workflow als eine Reihe von Schritten vorstellen, oder, eine Reihe kleiner, abgegrenzter Einheiten, dann probierst du vielleicht eine dieser Einheiten, vielleicht laufen alle deine Einheiten auf Anthropic-Modellen, du nimmst eine davon und sagst, eigentlich wollen wir bei diesem Stück hier ausprobieren, diese Komponente unseres Workflows auf einem Open-Weights-Modell von einem anderen Provider laufen zu lassen.

Du sicherst also nicht dein Risiko bei einem einzelnen Stück Workflow ab, sondern du verbreiterst deine Skills und dein Bewusstsein. Und du, du verschaffst dir institutionelles Wissen. Das heißt, wir wissen ein bisschen mehr über dieses Open-Weights-Modell, oder wir wissen ein bisschen mehr über diesen alternativen Provider dieser Modelle.

Und das, das geht also mehr um, ich meine, das ist auch so der Unterschied zwischen einer Lösung, die Multi Cloud ist, und einer Organisation als Ganzes, die manches mit AWS macht und manches mit Azure.

Ich glaube also, da gibt es einen Unterschied. Und ich bin optimistischer, so, was das mit Modellen angeht, als ich es bei Multi Cloud unbedingt bin, ich glaube, die Trade-offs sind anders. Um aber auf den letzten Teil deiner Frage zurückzukommen, bei dem es um den Rebound geht: Ich glaube, das, worüber du gesprochen hast, ist, okay, hilft es uns, schneller wieder hochzukommen? Und da gibt es definitiv ein paar Argumente. Und ich glaube, allerdings nicht im automatisierten Sinne.

Wir wollen die Leute also zur Vorsicht mahnen, oder? Rebound ist also irgendwie die Fähigkeit des Systems, sich nach etwas zu erholen, das wir vorhersehen konnten. Und Rebound in Woods' Kontext meint typischerweise die Dinge, bei denen unser System das irgendwie einfach von selbst regelt, oder?

Bei viel Rebound geht es also um automatisierte Dinge. Automatisierte Remediation mit KI ist noch weit weg. Und das ist nichts, was ich empfehlen würde.

Weil wir wieder diese Herausforderung haben, dass wir die Vertrauenswürdigkeit der Modelle haben.

Vertrauenswürdigkeit, das heißt auch dieser Nichtdeterminismus, ich bin nicht sicher, ob wir uns das leisten können, so, im Moment funktionieren automatisierte Remediations ziemlich gut, wenn sie deterministisch sind und für eine schmale Bandbreite von Dingen. Wo KI uns meiner Meinung nach sehr hilft, ist der Moment, in dem ein Mensch einsteigen muss, um herauszufinden, was zum Teufel da los ist. Und da, wenn du gute Signale aus deinen Produktivsystemen bekommst, wenn du also gute Observability hast, dann kann KI meiner Meinung nach unglaublich viel helfen.

Also Dinge wie, ich meine, weißt du, Dinge wie, also ich habe mit Martha Lambert von incident.io gesprochen, sie erzählt, wie ihr KI-SRE-Zeug so funktioniert. Und eins der Dinge, die es macht, ist, es sieht etwas, das ein bisschen falsch ist. Und es sagt, schau mal, das sieht ein bisschen falsch aus.

Es erstellt dir also so einen kleinen Incident. Und dann denkst du, oh, das sollte ich mir mal anschauen. Du fängst an, es dir anzuschauen.

Und das kann natürlich, aber es könnte auch sein, dass so ein SLO gerissen wurde, oder?

SLO gerissen, okay, wir lösen einen Alert aus. Und hinter den Kulissen denkt die KI so, okay, gut, schauen wir mal, was los ist. Okay, gut, das sieht interessant aus. Sie schickt dir ein paar Informationen. Sie macht, und dann, während du dir das anschaust, oh, ich habe auch diese Dinge gefunden, das könnte zusammenhängen. Oh, es gab kürzlich eine Code-Änderung. Und was sie also anfängt zu tun, ist, dir irgendwie Informationen zu liefern, um dir dann zu helfen zu verstehen: Könnten diese Dinge die Ursache sein?

Und es ist also, weißt du, was ihre Arbeit, ich meine, natürlich, ich glaube, die Informationen zu sammeln ist, glaube ich, ziemlich unkompliziert. Und das machen viele Leute. Woran incident.io viel gearbeitet hat, ist: Können wir die KI dazu bringen, überhaupt erst festzustellen, dass es einen Incident gibt? Und daran arbeiten sie jetzt seit ungefähr drei Jahren, vier Jahren, glaube ich. Das ist auch keine triviale Arbeit. Wir werden also schlauer darin zu erkennen, dass es ein Problem gibt.

Wir sind schon ziemlich gut darin, dir zu helfen, wenn es ein Problem gibt. Ich glaube, das, was ich immer noch für ein Hirngespinst halte, ist, ist der Teil mit der automatisierten Remediation. Für die meisten Dinge sind die meisten Organisationen, glaube ich, ziemlich schlecht darin, automatisierte Remediation mit deterministischem Code zu machen, geschweige denn mit nicht deterministischem Code.

Und dafür gibt es einen ganzen Haufen Gründe. Aber so, einer der Hauptaspekte, warum ich glaube, dass KI im Moment für automatisierte Remediation nicht nützlich ist, ist, dass, wenn man sich Incident Response anschaut, Incident Response kein klarer linearer Prozess ist.

Es ist ein ziemlich chaotischer, explorativer Prozess. Er erfordert viel Intuition. Er erfordert viel Exploration, bei der man in verschiedene Richtungen losgeht.

Und Menschen haben schon ein so schlechtes Verständnis von Incident Response, geschweige denn zu erwarten. Und die Sache ist, das ist das Problem mit KI. Wenn wir wollen, dass KI Dinge für uns tut, müssen wir ihr sagen können, was sie tun soll.

Und wir müssen auch Dinge etablieren können, um sicherzustellen, dass wir wissen, dass die KI Dinge korrekt macht.

Und ich glaube, Menschen haben ein so schlechtes Verständnis von Incident-Analyse, dass wir keine Chance haben, das mit KI zu machen. Also vielleicht in fünf, 10 Jahren, oder vielleicht bei wirklich trivialen Fällen. Aber ich glaube schon, dass sie gerade jetzt beim Sammeln dieser Daten und auch bei Dingen wie Post-Mortem-Prozessen, so den Post-Incident Reviews, wirklich hilfreich sein können. Eins der großen Dinge, die man als Teil eines Post-Incident Reviews machen muss, ist, dass man eine Timeline braucht, was wann passiert ist, wer was gemacht hat.

Und dafür verlässt man sich immer noch auf menschliche Aussagen, man führt dafür auch Interviews. Aber was viele dieser Tools jetzt können, ist, dass sie einfach viele der Rohdaten sammeln und dir so eine Art Entwurf der Timeline geben. Und ich sage nochmal, es machen so wenige Firmen richtige Post-Incident Reviews, dass etwas zu haben, das dir zumindest den Einstieg ermöglicht, meiner Meinung nach auch wirklich wertvoll ist.

Warum Auto-Remediation mit KI noch weit weg ist

Benedikt Stemmildt 24:08
Ja, danke. Das denke ich auch. Zum Rebound hatte ich noch eine Idee.

Und mich interessiert irgendwie, was du davon hältst. Also wenn man zum Beispiel ein LLM zum Coden nutzt, ich meine, das meiste davon machen wir nicht im Produkt, sondern eher, um irgendeine Art von Produkt zu bauen. Und die Agenten, die machen die ganze Zeit ganz viel Rebound, oder?

Das Modell sagt, ruf dieses Tool auf, und dann sagt das Modell es vielleicht auf eine falsche Art. Und dann gibt es einen Fehler, oder, weil der CLI-Befehl falsch war oder der Tool Call falsch war.

Und dann sind der Harness und das Modell selbst zusammen in der Lage, einen Rebound hinzubekommen, weil sie es einfach nochmal versuchen, oder? Sie sagen, okay, das war der falsche Aufruf. Vielleicht kannst du einen anderen Aufruf probieren, um es zu machen.

Und dann machen sie mehrere Iterationen. Und dann schaffen sie es, es richtig zu machen. So hatte ich mir das eher gedacht, dass das auch irgendwie hilfreich ist für die Arten, wie wir jetzt den Rebound machen können, die wir vorher nicht machen konnten, weil das in einem deterministischen System nicht möglich gewesen wäre, oder, es hätte die ganze Zeit denselben falschen Aufruf gemacht.

Denke ich da irgendwas falsch?

Sam Newman 25:12
Na ja, ich finde die Analogie da interessant. Es geht mehr darum, wie wir den Prozess handhaben und wo wir es machen. Ich meine, es gibt so in den ersten zwei Kapiteln, Kapitel drei und Kapitel vier, mein Buch, Kapitel drei dreht sich komplett um so Timeouts, und Kapitel vier dreht sich komplett um Retries, oder?

Also wenn man darüber nachdenkt, wir müssen das schon bei diesem deterministischen System machen, Unterschiede, dass wir verarbeiten müssen, was wir machen werden. Also wenn ich einen Server-Endpoint aufrufe, so, also ich sage, okay, ich muss wissen, wie viel dieses Ding kostet, oder?

Also mache ich einen Aufruf, und wenn ich keine Antwort bekomme, was mache ich dann? Jetzt ist es ein bisschen anders bei, sagen wir, einem Harness, wo man irgendwelche Informationen bekommt, es gibt vielleicht andere Stellen, wo ich Informationen herholen kann, aber ich weiß, das ist die Stelle, wo die Kosten liegen, und die kann ich nicht bekommen. Okay, also mache ich einen Retry, ich versuche es nochmal.

Okay, wie oft mache ich einen Retry? Das Wichtige an so etwas wie einem Retry ist ja, Retries legen ständig Systeme lahm. Also wenn ich einfach nicht weiß, wie die Retries gemacht werden, sind das massive Probleme.

Denn wenn ich zu viele Retries mache, verursache ich eine Ressourcensättigung, und die legt Systeme lahm. Also müssen wir sorgfältig nachdenken, okay, ich mache einen Retry, aber ich mache nur zwei Retries, und ich habe einen Abstand dazwischen. Also müssen wir über das Zeug nachdenken. Und, weißt du, man kann zum Beispiel Sachen wie Resilience4j nutzen, die einem helfen, diese Retry Policies umzusetzen, aber wir müssen darüber nachdenken. Aber das ist eigentlich, weil wir wissen wollen, was passieren wird.

Wir wollen wissen, was passieren wird, weil wir so gut wie irgend möglich vorhersagen können wollen, was unser System tun wird. Und dann kommt der Haken. Und das ist noch so ein, was passiert, wenn man die Retries gemacht hat und immer noch nicht weiß, wie viel etwas kostet.

Was macht man dann? An dem Punkt will man nicht sagen, ach, es wird das schon selbst rausfinden. Wahrscheinlich keine gute Antwort.

Weißt du, an dem Punkt, dann geht man zu einem Business Stakeholder und spielt mit ihm das Szenario durch und sagt, schau mal, okay, also in dieser Situation, wenn wir in dem Moment nicht rausfinden konnten, was etwas kostet, was willst du als Business Stakeholder, dass wir machen?

Wie willst du, dass das System sich verhält, oder Nutzer oder wer auch immer? Ich glaube nicht, dass wir es dem Raten überlassen wollen, was das, was es in dem Moment entscheiden könnte zu tun. Ich glaube, in solchen Situationen wollen wir ein gewisses Maß an Genauigkeit.

Ich glaube, der Unterschied ist, wenn wir es im Context von Harnesses und Coding betrachten, dass das, was wir da generieren, etwas ist, das dann weiter validiert werden kann, um sicherzustellen, dass es das Richtige gemacht hat. Wohingegen, wenn wir in einem Produktivsystem eine Entscheidung treffen, ob wir A oder B machen sollen, das ist ein bisschen was anderes als, ich habe Code auf Basis einer Spec erstellt.

Jetzt können wir die Iterationen durchgehen, die Tests laufen lassen, um sicherzustellen, dass ich gute Arbeit gemacht habe. Was auf dem Spiel steht, wenn man das falsch macht, ist ziemlich wenig. Und ich glaube, wir können es uns leisten, den Harness das irgendwie selbst ausarbeiten zu lassen.

Wenn man es in Produktion falsch macht, kann das für einen einzelnen Nutzer schlecht sein und katastrophal, wenn es so ein Produktionsproblem verursacht. Also ich glaube, ich bin mir nicht sicher, ob wir die Dinge, die Harnesses können, nehmen und annehmen können, dass sie in unseren, na ja, produktiv laufenden Systemen genauso funktionieren würden.

Ich glaube, es steht ein bisschen was anderes auf dem Spiel, und die Kosten, wenn man Dinge falsch macht, sind ein bisschen anders.

Benedikt Stemmildt 28:24
Ja, ich finde, das ist eine sehr gute Unterscheidung, weil, aus der Arbeit, die wir mit unseren Kunden und Unternehmen machen, KI oft sehr ähnlich behandelt wird, ob ich ein Produktivsystem bauen will, das KI nutzt, oder ob ich KI nutze, um ein Produktivsystem zu bauen, oh ja, entweder mit oder ohne KI drin. Und es ist genau das, was du da sagst, richtig, dass das, man muss diese beiden Szenarien sehr unterschiedlich betrachten.

Ja, und ich glaube, es gibt jetzt auch diese, diese Brücke, die du am Anfang erwähnt hast, wie wirkt sich das auch auf die organisatorische Seite aus, oder?

So, bei der Resilienz geht es nicht nur um das System und die Technologie, sondern auch um die Organisation, die sie nutzt. Das könnte auch für beide Fälle sehr unterschiedlich sein, oder?

Sam Newman 29:14
Ja, wobei ich glaube, das Erste ist, du liegst einfach, du liegst mit dieser Unterscheidung genau richtig. Ich finde, das ist eine wirklich wichtige Unterscheidung, nämlich die Entwicklung, weißt du, wir können mit KI großartige Produkte erstellen, in denen gar keine KI drin ist, oder? Wir können einen KI-gestützten Software-Delivery-Prozess haben, der großartige Software erstellt, großartige Produkte, in denen trotzdem keine KI drin ist. Wir können KI auch nutzen, um Software zu erstellen, in der KI drin ist, oder?

Und das kann auch fantastisch sein. Aber dann kommt ein Haufen anderer Belange dazu, die berücksichtigt werden müssen. Das Resilienz-Thema, das ich vorhin angerissen habe, die Security-Seite auch, so Dinge wie die Lethal Trifecta berücksichtigen. Und, und ich finde, es ist irgendwie wichtig, zwischen diesen, diesen beiden Fällen zu unterscheiden. Ich glaube, du liegst, du liegst genau richtig. Ich glaube, was das angeht, irgendwie über diese Robustness und den Rebound hinauszugehen, hast du ein paar der organisatorischen und menschlichen Faktoren rund um Resilienz angesprochen.

Das führt zurück zu Woods' vier Modell, vier Konzepten, den vier Konzepten, er gibt uns Robustness und Rebound, die er irgendwie angesprochen hat. Die anderen beiden, die aus diesem Paper kommen, sind Sustained Adaptability und Graceful Extensibility. Das sind ziemlich sperrige, so schwer verständliche Begriffe, weil, wieder, die ursprünglichen Paper nicht dafür gedacht sind, dass wir sie lesen, sie sind dafür gedacht, dass andere Leute sie lesen, oder? Also wenn er über Graceful Extensibility spricht, spricht er über die Fähigkeit unseres Systems, mit dem Unbekannten umzugehen.

Vor allem, wenn wir versuchen, unser System robust zu machen, müssen wir Voraussicht haben, wir müssen wissen, was schiefgehen könnte, und Dinge in unser System einbauen, um mit den bekannten potenziellen Problemen umzugehen, denen wir begegnen könnten, so, wir könnten einen Timeout haben, wir könnten einen Fehler haben, also brauchen wir keinen Retry. Das sind also Dinge, von denen wir wissen, und die können wir in unsere Systeme einbauen.

Was ist mit den Dingen, die wir nicht erwarten? Wie gut gehen wir mit dem Unerwarteten um? Ich hatte mal eine Netzwerkpartition, verursacht von Kaninchen, die Netzwerkkabel angefressen haben, ich wäre verrückt gewesen, wenn ich vorher gedacht hätte, was ist mit Kaninchen?

Ich hatte einen anderen Fall, wo eine SSD Feuer gefangen hat, es hat fünf Tage gedauert, bis man uns gesagt hat, dass das passiert war, bei einer SSD in einem SAN, oder? Solche Dinge kann man nicht vorhersehen. Also kommt dann die Frage, okay, wie stellen wir weiterhin sicher, dass so viele Dinge wie möglich gut laufen, wenn Dinge passieren, die wir nicht erwarten?

Und da geht es vor allem um Menschen. Es geht nicht nur um Menschen, aber es geht hauptsächlich um Menschen und Organisationskultur. Denn wenn man in einer Organisation ist, die ziemlich hierarchisch ist, wo man eine sehr starre und strukturierte Rollenbeschreibung hat, oder, man wird in eine Schublade gesteckt, und das sind die Dinge, die von einem erwartet werden.

Und das sind die Dinge, die man tun darf. Oft basieren diese Einschränkungen, die einem auferlegt werden, darauf, wie die Organisation auf Basis von früherem Wissen arbeitet. Wenn dann also etwas Überraschendes passiert, findet man alle möglichen Einschränkungen, die einen davon abhalten, andere Dinge zu tun, um mit der überraschenden Situation umzugehen. Deshalb sind Organisationen, die behaupten, resilient zu sein, oft eigentlich fragil, weil sie keine Fähigkeit haben, sich zu ändern, sie haben keine Fähigkeit zu reagieren.

Und das ist also irgendwie ein Beispiel, wo organisatorische Dynamiken ins Spiel kommen können. Also es ist so, Überraschung, es ist so, na ja, wie gut werden wir damit umgehen? Was werden wir tun?

Wie werden wir in dem Moment handeln? Und darin kann man besser werden, oder? Es gibt viele großartige Übungen und Sachen wie zum Beispiel Game-Day-Übungen, die einem helfen können, als Einzelner besser mit Überraschungen umzugehen.

Aber man braucht auch eine Art Unternehmenskultur und eine Reihe von Kontrollen, die flexibel genug sind, um einem den Spielraum zu geben, auch mit dieser Überraschung umzugehen.

Und der letzte Teil davon war Sustained Adaptability. Und das ist, dass unser System sich tatsächlich über die Zeit verändert. Also wieder, weißt du, ich habe ein System, das gerade richtig gut funktioniert, aber die Welt um uns herum verändert sich, oder? Wir bekommen neue Technologie, die ins Spiel kommt, neue Arten von Angreifern da draußen, neue Arten von Nutzern, unsere Kunden wollen andere Dinge, unsere Business Stakeholder wollen andere Dinge, die Welt verschiebt sich ständig. Passt sich unser System auch weiterhin an, basierend auf dem, was wir lernen?

Und so ist es auch langfristig resilient. Und das ist dieser Teil mit der Sustained Adaptability. Damit das passiert, müssen wir Gelegenheiten schaffen, zu reflektieren, wenn Dinge schiefgehen. Also gute Post-Incident Reviews haben, aber auch die Gelegenheit schaffen, zu reflektieren, wenn Dinge gut laufen, und Informationen von außen aufnehmen. Psychologische Sicherheit spielt eine riesige Rolle bei Sustained Adaptability. Denn wenn man sich nicht sicher genug fühlt, ein Problem anzusprechen, ist das ein Problem.

Oder man hat das Gefühl, zuzugeben, dass man einen Fehler gemacht hat, führt dazu, dass man sofort gefeuert wird, dann vertuscht man es. Und so, in einem Umfeld wie dem, kommen all diese wertvollen Informationen und Learnings nicht ans Licht. Und das untergräbt die Fähigkeit, sich anzupassen und das System zu verändern. Das ist also irgendwie der Bereich, wo viele der menschlichen und organisatorischen Dynamiken sehr stark ins Spiel kommen.

Kaninchen, brennende SSDs und das Unerwartete

Benedikt Stemmildt 34:09
Ja, sehr, sehr interessant. Ich hatte so ein bisschen ein, ich weiß nicht, es ist so, vielleicht können wir das jetzt hinkriegen, wo wir nicht können, ich hab so ein bisschen ein Experiment. Also

Ist eine Software Factory resilient?

Sam Newman 34:18
Leg los.

Benedikt Stemmildt 34:19
Ja, also wir reden ja viel über die diese Konzepte und Ideen rund um so, das ist so ein produktiv laufendes System, und wir müssen es betreiben und so weiter. Und in meinem aktuellen Denken, oder was ich gerade viel sehe, ist, dass man, statt über produktiv laufende Systeme zu reden, auch über jede Art von Organisation, die etwas baut, als dieses Produktivsystem reden könnte, oder?

So, es ist eine Organisation, die etwas baut. Und man könnte sich das auch als ein KI-System vorstellen, so eine Fabrik oder so was, die dir irgendeine Art von.

Also ich weiß, das ist so ein bisschen ein Mind. Ich weiß nicht. Es ist so, ja, für mich, für die Zuschauer, für die Zuhörer, oder, weißt du, es ist so, man muss irgendwie ein bisschen um die Ecke und auf die Metaebene. Und du weißt, was ich meine. Und jetzt müssen wir neu denken, was heißt das jetzt für Resilienz? Ja, unser System und das System, das das System baut.

Sam Newman 35:16
Es gibt diesen schönen Begriff, soziotechnische Systeme. Und das ist ein Begriff, der jedes System beschreibt, in dem Menschen und Technologie zusammenarbeiten. Das ist eigentlich ein ziemlich alter Begriff.

Er kommt aus so Studien, die im Kohlebergbau gemacht wurden, ob du's glaubst oder nicht. Und der Punkt, den ich im Buch mache, ist, dass unser verteiltes System ein soziotechnisches ist. Es sind die Menschen und die Technologie, die zusammenarbeiten.

Also musst du diese ganzheitliche Sicht einnehmen. Und deshalb tut es das in, ich meine, auch wenn sich ein großer Teil meines Buchs auf so die Art von Dingen konzentriert, die man in Produktivsystemen macht, du bist, wenn du das System als Ganzes betrachtest, musst du dir unbedingt all diese Teile anschauen, diese vier Konzepte, die ich erwähnt habe, weißt du, Rebound, Robustness, Graceful Extensibility und Sustained Adaptability.

Die kommen aus einem Paper, das sich die Resilienz von Systemen allgemein anschaut, einschließlich biologischer Systeme, Wahlsysteme, Flugsicherungssysteme. Also kann man absolut sehen, wie diese Konzepte, diese vier Konzepte, an diesen diesen verschiedenen Stellen greifen. Aber nehmen wir mal eine Software Factory. Ich weiß ja, ihr arbeitet ziemlich viel daran.

Benedikt Stemmildt 36:28
Und Sam, sorry, dass ich dich da für nur 10 Sekunden unterbreche. Weil ich das Gefühl habe, dass diese Software Factories für mich so ein Knoten im Kopf sind, weil du das System baust, das das, wie du's beschrieben hast, dieses soziotechnische System ist. Aber dieses System ist jetzt eine Software Factory, die wiederum das System bauen muss, das resilient sein muss und so weiter.

So, vielleicht ist es so, vielleicht kannst du versuchen, mir zu helfen, das in meinem Kopf auseinanderzunehmen, weil das für mich immer super schwer zu begreifen ist.

Sam Newman 36:57
Wir sollten wahrscheinlich, ich meine, vielleicht darüber reden, was wir so mit einer Art Software Factory meinen. Gute Idee, was ja, was irgendwie, weißt du, wir haben gerade diese Diskussion, nämlich wie sehr sind wir als Menschen auf Code-Ebene involviert? Schreiben wir den Code selbst?

Lassen wir KI den Code schreiben? Und dann, wenn wir KI den Code schreiben lassen, müssen wir den Code lesen? Also wird gerade viel Arbeit von Leuten gemacht, die mehr Zeit mit so einer Art spec-driven Development verbringen.

Also eine Spec schreiben, die definiert, was sie wollen. Und dann ist die Frage, nutzen sie sie nur, um den Code zu generieren, den sie dann pflegen? Oder arbeiten sie nur auf Spec-Ebene?

Und wenn du an einen Punkt kommst, wo du rein auf Spec-Ebene arbeitest und dir den Code nie mehr anschaust, dann baust du im Grunde einen Apparat darum, wie diese Spec ausgeführt wird. Also fängst du an, die Fähigkeit aufzubauen, irgendwie den Code zu erzeugen und das Verhalten des Systems zu validieren, das du jetzt verändert hast.

Ein riesiger Teil einer Software Factory und von spec-driven Development, wenn du das bis in diese Extreme treiben willst, ist, richtig gut darin zu werden zu sagen, wie gut aussieht. Und das wird kommen, ich glaube, das könnte einige deiner Herausforderungen hier lösen, was die Frage angeht, wo die Menschen sind.

Benedikt Stemmildt 38:01
Aber dieser Apparat ist jetzt auch ein System, das resilient sein muss, weißt du, es muss so korrekt sein. Und es muss auch in der Lage sein, sich zu erholen. Und das finde ich super interessant. Weil dieses System wiederum eine Vorstellung von der Resilienz des Systems haben muss, das es baut, oder das aus den Specs herauskommt.

Sam Newman 38:23
Ja, auch hier, glaube ich, können wir das an zwei Punkten festmachen. Also erstens ist so, so, so, und das ist etwas, was Leute früh bei CI erkannt haben, CI ist ein Produktivsystem. Denn wenn mein CI-Server nicht läuft, kann ich keine Software ausrollen.

Das ist ein großes Problem. Also ist es ein Produktivsystem, oder? Also müssen wir aus dieser Sicht den Apparat rund um unsere Software Factory genauso behandeln.

Wir brauchen, und deshalb hatte ich vor ein paar Tagen ein Gespräch mit Charity Majors, wir haben darüber geredet, weißt du, wir sehen Observability als etwas, das in Produktion wirklich wichtig ist, und genauso wichtig ist es, Observability aus deinem, dem Prozess zu bekommen, mit dem du die Software erstellst.

Also solltest du deine Observability auch in dieser Welt haben, oder? Also das ist ein wirklich wichtiger Teil davon. Also 100 % ist es ein Produktivsystem. Das Nächste, was du gesagt hast, was ich auch völlig berechtigt finde, ist: Wenn wir erwarten, dass die Software Factory Software erstellt, die dann in Produktion läuft, dann muss diese Software Factory das Wissen bekommen, um zu verstehen, wie man Software erstellt, die sich so verhält, wie wir wollen, dass die Software, die erstellt wird, läuft.

Also um es wirklich konkret zu machen, wir haben vielleicht SLOs, also Service Level Objectives rund um akzeptable Uptime und Latenzen und solche Dinge. Also sagen wir vielleicht, wir brauchen, keine Ahnung, 99,9 % Verfügbarkeit bei einer bei einer 99-Perzentil-Latenz von, weißt du, 300 Millisekunden oder weniger für die Bestellverarbeitung. Okay, das ist ein Beispiel-SLO, das wir haben könnten.

Also können wir das in Produktion haben. Die Frage ist dann, das ist, was wir wollen. Wie können wir dann die Software Factory anweisen oder anleiten, damit sie weiß, wie sie diese Anforderungen erfüllt?

Ja, ich weiß nicht, ob wir die Antwort darauf kennen.

Benedikt Stemmildt 39:57
Ja, ich kenne die Antwort nicht. Ich habe keine Ahnung.

Sam Newman 40:00
Nein, und ich glaube, wir auch nicht. Aber deshalb glaube ich auch, das ist das Problem. Ich glaube, wir, manche Leute nehmen die Software-Factory-Ideen und treiben sie bis ins logische Extrem.

Ich baue mein ganzes System aus Software Factories. Spulen wir mal ein bisschen zurück und denken über das Konzept von Software Factories nach, das sich ja eigentlich die Idee von dem abschaut, was wir in der physischen Welt Dark Factories nennen. Also eine Dark Factory in der physischen Welt ist eine automatisierte Anlage, in der Roboter, typischerweise Industrieroboter, und andere Arten von Automatisierung Komponenten herstellen.

Menschen haben diese Anlage gebaut, sie haben geholfen, sie zu errichten, sie haben definiert, wie sie funktionieren soll, sie haben die Möglichkeit, sie zu überwachen. Aber im Großen und Ganzen müssen sie nicht eingreifen, weil es einfach funktioniert. Und Dinge gehen rein, Dinge kommen raus. Und sie heißen oft Dark Factories, weil das Licht nicht an ist. Es macht ziemlich Spaß, online nach Bildern von Dark Factories zu suchen, weil die alle KI sind, weil die echten Dark Factories dunkel sind, die kann man nicht fotografieren.

Ja, sie bauen im Großen und Ganzen keine fertigen Kundenprodukte. Sie bauen meistens Zwischenkomponenten.

Benedikt Stemmildt 41:04
Und ich habe das Gefühl, die sind deterministisch, oder? Weil die eingerichtet sind. Das ist so ein super deterministischer, sehr, sehr deterministischer Prozess, oder?

Sam Newman 41:12
Absolut. Aber sie sind deterministisch, sie haben Validierung eingebaut, sie haben da Qualitätsprüfungen drin. Und sie bauen auch kleine Komponenten, sie bauen keine ganzen, da kommt nicht, weißt du, man schickt nicht Eisenerz und Bauxit rein und raus kommt ein Auto, so funktioniert das nicht. Das ist nicht Factorio. Stattdessen könnten sie wahrscheinlich Dinge bauen, die dann in andere Dinge eingehen. Also nimm diesen Teil mal für den Moment, Dinge, die in andere Dinge eingebaut werden.

Wir brauchen nicht unbedingt eine Software Factory, die ein ganzes System erstellt. Davon sind wir wirklich noch weit entfernt. Es gibt ein paar Firmen, mit denen ich rede, über die ich nicht reden kann, die vielleicht nah dran sind, aber im Großen und Ganzen sind wir da nicht.

Also, aber wir können sie in bestimmten Bereichen nutzen. Also lass, lass, das ist das, wozu ich gerade versuche, einige meiner Kunden zu ermutigen. Diese ganze Sache ist beängstigend.

Also denk nicht an deine, so wie du, ich glaube, wir haben immer noch diese Vorstellung, dass wir einen Einheitsprozess dafür haben, wie wir von einer Idee zu laufendem Produktionscode kommen.

Und ich glaube, worauf wir jetzt schauen, ist, dass wir verschiedene Denkweisen haben. Also stell dir dein System nicht als große Box vor, sondern stell es dir jetzt als eine Menge von Modulen vor, wie auch immer diese Modularchitektur aussieht. Manche Module, manche Teile der Funktionalität sind wirklich wichtig, ultrakritisch, und du machst dir echt Sorgen, wenn mit denen irgendwas schiefgeht.

Es gibt auch Teile von Modulen in deiner Codebase gerade jetzt, die du nutzt, die du dir nie angeschaut hast, die du nicht geprüft hast, die du reingezogen hast, und du hast sie in dein System gepackt, und es ist okay.

Das machst du gerade jetzt. Aber ich wette, du hast Millionen Zeilen Code von der Sorte. Denk an die Third-Party-Libraries.

Also jemand anderes hat das geschrieben, du hast eine API, du packst es rein, es ist okay. Also wir haben Software Factories. Wir glauben eigentlich nicht, dass sie Systeme erstellen können, die ein besseres, größeres, breiteres Verständnis von Resilienz haben.

Aber was, wenn wir sie einige der Module bauen lassen? Also statt, das ist unser ganzes System, lassen wir sie zwei, drei, vier Module machen und plumpsen die rein.

Und dann können wir als Menschen immer noch sagen, okay, also wenn ich eine Service-Grenze habe, muss diese Service-Grenze diese SLOs und alles andere haben, ich könnte trotzdem die Factory irgendwie das Innenleben davon erstellen lassen. Und so vieles davon, und das befreit mich, den Menschen, um über die übergeordneten Belange nachzudenken, wie all das Zeug zusammengenäht ist.

Und ich glaube, das ist eine Auffahrt für die Software-Factory-Idee. Einige der Herausforderungen vermeiden, die du hier, finde ich, ziemlich vernünftig skizzierst, nämlich, ich glaube, wenn wir, man kann diese Dinger sowieso nicht one-shotten, oder?

Ich meine, wenn du versuchst, dich per One-Shot zu einem großen verteilten System durchzuschlagen, bist du verrückt. Aber ich glaube nicht, dass man sagen kann, hier ist der Code, hier ist das SLO, mach mal. Ich meine, schau, technisch ist es möglich, dass es das schafft.

Es würde dich so viel Geld kosten, weil es voraussetzen würde, dass deine Software Factory in der Lage ist, irgendwie Produktions-, Lasttestszenarien hochzufahren, und sie könnte das alles selbst herausfinden, oder? Und dafür hat keiner Zeit. Aber ich glaube schon, dass wir, statt auf das so, dieses riesige so, vielleicht weit entfernte Endziel hinzuarbeiten, das vielleicht nie erreichbar ist, darüber reden sollten, was heute praktikabel ist.

Nimm dein großes System, zerleg es, nimm ein Teil, das vielleicht nicht so kritisch ist, versuch, ein paar Specs rund um diese eine Komponente zu machen. Wenn es für dich gut funktioniert, super. Wenn es für dich nicht gut funktioniert, na ja, dann kannst du zurückgehen und Dinge so machen, wie du es immer gemacht hast.

Teams statt KI-Vorgaben von oben

Benedikt Stemmildt 44:27
Ich finde, das ist eine super interessante Idee. Und eine Sache, die für mich jetzt der nächste Schritt in diesem Gedankenexperiment ist, könnte man sagen, ist: Wie wirkt sich das jetzt auf die Organisation aus, weißt du, also, wie wirkt sich das auf unsere aktuelle Art aus, Software oder Features zu bauen?

Sam Newman 44:45
Ich bin mir nicht sicher, ob es das tut. Also stellen wir uns vor, du hast schon Sams ideale Organisation, was vielleicht so ist oder vielleicht auch nicht, aber du hast Teams, die für einen Teil deiner Business-Domäne verantwortlich sind, oder? Das Team ist für x verantwortlich, das Team ist für y verantwortlich, das Team ist für z verantwortlich, sie arbeiten eng mit ihren Business Stakeholdern zusammen, ihren Product Ownern, um zu verstehen, was gebraucht wird. Und dann findet das Team heraus, wie es dieses Ziel am besten erreicht.

Team x da drüben merkt, wir sollten hier einfach ein Drittanbietersystem reinholen, um genau dieses Problem zu lösen, wir kaufen ein System, wir können ein SaaS-Produkt nehmen. Das Team hier drüben sagt, wir bauen dafür Software. Dann fragen die sich, wie bauen wir am besten Software?

Oh, wir könnten hier eine Software Factory nehmen. Also ich glaube, eigentlich kann man sagen, wenn du so eine Organisation hast, wo du Teams hast, die Verantwortung und Rechenschaft gegenüber ihren Product Ownern haben,

Benedikt Stemmildt 45:37
End-to-End, oder, so wie so ein Stream-aligned Team, wenn du Team Topologies hättest,

Sam Newman 45:41
100%. Und dann natürlich, in der Sprache von Team Topologies, wenn du siehst, dass hier und da und überall mehr Leute Software Factories bauen wollen, dann brauchst du Enabling Teams, die dich dabei unterstützen. Ja.

Also Platform Capabilities zu haben, die zum Beispiel Spec-driven Development einfacher machen. Ein Freund von mir, Ben hat, der arbeitet gerade an einem Buch darüber, wie man agentische Plattformen darum herum baut. Für mich ist es also eher so: Wir kennen den Problemraum, wir kennen die Risiken, wir wissen, was unser Product Owner braucht, wir sollten abwägen, ob wir das machen oder nicht.

Und dann können wir die neuen Tools um uns herum nutzen. Ich glaube, das ist ein gesunder Ort dafür. Ich glaube, das Problem ist, dass in vielen Organisationen das Gegenteil passiert, wo wir so Mandate von oben haben, du musst X machen, das ist das, was du machen wirst.

Gutes Beispiel dafür wäre Meta, oder? Die haben kürzlich gesagt, okay, wir gehen all in. Jeder muss KI für seine gesamte Softwareentwicklung nutzen.

Das hat vielleicht oder vielleicht auch nicht etwas damit zu tun, dass sie Milliarden und Milliarden und Milliarden und Milliarden für GPUs ausgegeben haben und nicht wissen, was sie damit anfangen sollen.

Aber lassen wir das mal beiseite. Sie sind also von so 10- bis 20-Personen-Teams zu so Vier- bis Fünf-Personen-Teams gegangen, die mit diesem ganzen KI-Zeug Software bauen. Und sie haben festgestellt, dass die Menge an Code, die sie erzeugen, um 225% gestiegen ist.

Was sie tatsächlich ausgeliefert haben, die tatsächliche Steigerung beim Delivery, lag bei etwa 20 bis 30%. Nicht nichts. Production Incidents um 40 bis 50% gestiegen.

Zeit fürs Feuerlöschen um 70% gestiegen. Und so hast du dieses Top-down-Mandat, macht dieses Zeug.

Das hat nicht so gut funktioniert. Mein Gefühl ist: Wenn du eine Organisation hast, in der diese Teams verstehen, was ihr Product Owner braucht, ihre Verantwortung gegenüber der größeren Organisation verstehen, dann stell ihnen diese Dinge zur Verfügung, ermutige sie, unterstütze sie dabei und sag, ich will sehen, dass mehr von euch das machen. Aber nicht alle Teams sind gleich, weil nicht aller Code gleich ist.

Und ich glaube, wir müssen auch diesen Teil davon anerkennen, nämlich, ich glaube, ein großer Teil des Problems ist, dass die Leute denken, aller Code ist gleich.

Genauso wie sie irgendwie denken, dass Programmieren Tippen ist. Ist es nicht, oder. Also verschiedene Teile deines Produkts werden die Arbeit, die sie machen.

Die können unterschiedliche Anforderungen vom Business haben. Und deshalb glaube ich, wenn wir da etwas differenzierter rangehen, dann gibt uns das die Gelegenheit, mit diesen wirklich tollen neuen Ideen zu experimentieren und zu sehen, was funktioniert, und uns anzupassen, während wir diese Dinge einführen, statt einfach zu versuchen, pauschal massive Veränderungen durchzudrücken, die am Ende unglaublich teuer werden und oft, glaube ich, leider am Ende die Ideen selbst überhaupt erst in Verruf bringen.

Haben wir probiert, hat nicht funktioniert. Du hast es auf eine wirklich schlechte Art probiert. Und das ist es, wozu ich die Leute ermutigen will, es irgendwie ein bisschen mehr in Stücke aufzuteilen.

Versteh mich nicht falsch, Ben, bei vielem davon geht es darum, dass ich wirklich immer noch modulare Architekturen pushen will, weil ich die für eine großartige Idee halte, oder? Ihr habt sie trotzdem nicht gemacht, obwohl es die Ideen seit den 1960ern, 1970ern gibt, oder? Aber grundsätzlich, sobald du dein Produktivsystem als modulares System siehst, wird das ganze Zeug einfach.

Benedikt Stemmildt 48:52
Ich meine, da bin ich total auf deiner Seite. Mir gefällt richtig gut, wie du das beschrieben hast. Und es ist echt hilfreich.

Die Sache ist, dass du auch absolut recht hast, dass man diese neuen Ideen bewusst so einführen muss, wo es Sinn ergibt, und nicht so überall. Und du hast auch absolut recht, so Code ist so, da muss man stark unterscheiden zwischen den Modulen und so auf so vielen Ebenen, das ist irre. Aber oft, wenn ich Organisationen sehe, die schon sehr, sagen wir mal, agil sind, so im positiven und guten Sinne, wie du es beschrieben hast, so End-to-End-Stream-aligned-Teams und so weiter, dass die das jetzt auch bewusst und sehr gut machen, weil die jetzt schon die, die haben schon eine Struktur in der Organisation, die es ihnen möglich macht, diese neuen Ideen auch auf eine sehr bewusste und differenzierte und gute Art aufzugreifen.

Und dann gibt es andere Organisationen, die noch nicht so weit sind, oder die sagen, dass sie schon so weit sind. Und die jetzt gemeint, also das ist so eine Abwärts- und eine Aufwärtsspirale. Ich weiß nicht, was du darüber denkst oder wie du so,

Nur so schnell liefern, wie man sich noch kümmern kann

Sam Newman 49:56
Ich glaube, es gibt viele Unternehmen, die denken, sie wären besser, als sie sind. Und deshalb denken sie, sie können schneller gehen, als sie können. Und ich glaube, das wird immer so sein.

Ich weiß nicht, was man dagegen tun kann, außer zu sagen: Messt sowohl qualitativ als auch quantitativ. Trackt auf jeden Fall: Sind die Leute zufrieden? Haben die Leute Freude an ihrer Arbeit?

Seht ihr ein steigendes Maß an Burnout? Ziemlich viele Studien zeigen ein steigendes Maß an Burnout bei der Nutzung von KI-Software, Leute arbeiten mehr Stunden.

Also musst du dir das anschauen, weil letztlich, deine Leute, dein größtes Kapital. Schau dir auch die quantitativen Messungen an: Bringen wir mehr Software-Features in die Hände unserer User? Der nächste Punkt ist wirklich wichtig.

Haben die User Freude an diesen Features? Du bist bestimmt schon auf ein paar Produkte gestoßen, in die KI reingequetscht wurde. Und es ist einfach so: Wofür zum Teufel ist das?

Und deshalb glaube ich, wenn du diese Informationen sammelst, gibt dir das die Möglichkeit, ein Stück von deinem eigenen persönlichen Investment da rauszunehmen.

So machen wir das. Wenn du diese Informationen hast, gibt dir das die Möglichkeit, zu versuchen, deine Meinung zu ändern und in andere Richtungen zu gehen. Also, eine tolle Konferenz namens ShipItCon in Dublin letzte Woche.

Und da gab es einen Talk von, ich hole mir mal den Namen der Sprecherin, weil ich ihren Namen nicht falsch sagen will. Es ist ein Talk von Jennifer Cox, die in der Cybersecurity arbeitet. Sie hat einen richtig tollen Talk gehalten namens Ship Fast Enough to Care.

Ich habe ihr gesagt, sie sollte den Namen des Talks in ship fast enough to care ändern, aber es ist etwas, das sie am Ende gesagt hat.

Und sie hat darüber gesprochen, dass KI uns diese Vorstellung gibt, dass wir viel, viel, viel schneller gehen können, aber dass wir eigentlich prüfen sollten, ob Geschwindigkeit das Wichtigste ist. Und wir sollten auf jeden Fall schneller auftauchen, aber nur so sehr, wie wir uns kümmern können, uns um unsere Leute kümmern, uns um das Produkt kümmern, das wir bauen, uns darum kümmern, wie es sich auf unsere User auswirkt. Denn wenn wir schneller gehen als das, werden wir ein Problem haben.

Und ich glaube, da stehen wir gerade, es ist so, als hätte man uns diesen richtig starken Sportwagen gegeben, und alle springen rein und fahren los, aber noch keiner denkt: Sollten wir so schnell fahren?

Du wirst in diese Richtung fahren. Man sieht auch diese Art von Problem rund um Cognitive Debt, worüber Margaret-Anne Storey ziemlich viel gesprochen hat, wo man, weil Leute schneller arbeiten können, Teams bekommt, in denen Leute in verschiedene Richtungen losziehen. Ich mache das, und so verlieren die Leute ihr zusammenhängendes Verständnis des Systems. Es gibt ein Ganzes, das wir bauen. Wir verlieren das Gespür für unser kollektives Verständnis des Pro... Problems. Wir verbringen weniger Zeit mit Reden.

Wir verbringen weniger Zeit damit, Gespräche zu führen. Es gibt ein richtig tolles Paper von Peter Naur namens Programming as Theory Building. Und er argumentiert, dass unser Verständnis eines Programms, davon, was ein Programm grundlegend ist, im Grunde ein mentales Modell ist, das die Entwickler teilen.

Das Paper wurde 1985 geschrieben. Es ist ein richtig faszinierender Text. Er hat dafür den Turing Award gewonnen, glaube ich.

Aber die Verschiebung jetzt, würde ich sagen, ist, dass unser Verständnis davon, was ein Programm ist, eigentlich ein mentales Modell in den Köpfen der Entwickler und des Product Owners und auch der User ist.

Ich glaube, es ist ein kollektives mentales Modell. Unsere Nutzung von KI sollte dieses Verständnis nicht fragmentieren. Sie sollte uns mehr Zeit geben, uns darauf zu konzentrieren, dieses Verständnis aufzubauen und zu verfeinern.

KI soll uns von stumpfer Plackerei befreien. Sie soll unsere Plackerei nicht vergrößern. Sie soll nicht die Menge an Context Switching erhöhen, die wir machen, und die Menge an paralleler Arbeit, die wir machen.

Wir haben das Gefühl, wir haben weniger Zeit, innezuhalten und nachzudenken. Die Studien rund um Cognitive Debt haben gezeigt, dass bei Leuten, die darunter leiden, die Fähigkeit zum kritischen Denken abnimmt.

Benedikt Stemmildt 53:48
Ich habe das Gefühl, das bringt uns zurück zur Resilience und zu den Systemen.

Sam Newman 53:58
Das führt zurück zu deiner Graceful Extensibility und Sustained Adaptability. Man muss kritisch denken können. Incident-Analyse braucht klares, nüchternes Denken. Ich finde, wir sollten KI nutzen, um uns freizumachen, damit wir menschlicher sein können. Das ist ein Zitat von einem meiner Kunden in den USA. Er hat gesagt: Ich will, dass meine Entwickler menschlicher sind. Menschen sind besser darin, über Trade-offs nachzudenken. Sie sind besser darin, kritisch zu denken, Gespräche zu führen, Ideen zu teilen, zu lernen, weil wir irgendwann darauf kommen können.

Unsere Nutzung von KI sollte uns freimachen, damit wir mehr nachdenken und mehr zusammenarbeiten. Ich habe neulich eine Ankündigung von Chainguard gesehen, dass sie das menschliche Review von Diffs als Teil von PRs einstellen, weil sie Leute freimachen wollen, damit sie mehr Zeit mit Arbeit rund um Dinge wie Design Docs verbringen, was irgendwie impliziert, wir stoppen menschliche Code Reviews nicht, damit wir Leute freimachen können, mehr über Design und Architektur und Trade-off-Gespräche nachzudenken. Das fühlt sich für mich nach einem okayen Trade-off an.

Ich glaube, es ist immer so: Was bekommen wir dafür? Wir müssen auch anerkennen, dass wir noch ganz am Anfang stehen. Alles bewegt sich sehr schnell.

Die Studien, die wir zum Uplift durch KI sehen, basieren auf einem kurzen Zeitraum. Wir kennen die langfristigen Auswirkungen nicht, und gleichzeitig werden die Modelle besser. Es ist also wirklich ein volatiler Bereich.

Ich glaube, das Wichtigste, was du tun kannst, wenn du diesen extrem volatilen Bereich hast, ist, bei der Arbeit ein Umfeld zu schaffen, in dem du bewusst darüber nachdenken kannst, was du tun willst, in dem du experimentieren kannst, in dem du verschiedene Dinge ausprobieren kannst, in dem du die Möglichkeit schaffen kannst, dich abzusichern, denn das ist der einzige Weg, wie du überleben wirst.

Ich finde, voll auf X zu setzen, ist total verrückt, wenn es X vielleicht gar nicht gibt und X innerhalb von zwei Jahren von Y oder Z abgelöst werden könnte.

Benedikt Stemmildt 55:56
Zwei Wochen? Man weiß es nicht.

Sam Newman 55:59
Jeder, der dir sagt, er wüsste es, belügt sich selbst oder belügt dich, und er versucht wahrscheinlich, dir irgendwas zu verkaufen.

Benedikt Stemmildt 56:05
Ich habe selbst so ein bisschen einen Leitspruch. Und daran werde ich oft erinnert. Es ist so: Langsam machen, um schnell zu werden. Es ist ein bisschen, ich weiß nicht.

Sam Newman 56:16
Ich glaube, es ist so wie bei dem Team, mit dem ich in den USA ziemlich viel arbeite, die gehen sehr durchdacht mit ihrer Nutzung von KI um. Sie haben verschiedene Teams, die es auf unterschiedliche Weise nutzen. Sie reden die ganze Zeit miteinander.

Sie teilen Wissen. Sie passen sich an. Sie triangulieren.

Und sie denken: Oh, das ist toll. Das übernehmen wir. Aber das ist keine transaktionale Aktivität.

Das ist etwas, das einfach kontinuierlich passiert, als Teil davon, wie sie arbeiten. Und ihr Verständnis der Fähigkeiten von KI und wie sie sie in der Entwicklung nutzen, beeinflusst jetzt auch, wie sie sie in ihren Produktivsystemen nutzen, wie sie sie einbetten und den Kunden Dinge an die Hand geben.

Und ich glaube, das ist etwas, das für mich Sinn ergibt. Es ist so: freie Zeit haben, um menschlicher zu sein. Geh nicht davon aus, dass die Zukunft feststeht. Zurück zu diesen vier Konzepten der Resilience.

Benedikt Stemmildt 57:01
Ja, das macht sie resilient, weißt du.

Sam Newman 57:04
Man muss mit Überraschungen umgehen, oder? Also, ich glaube, das ist für mich alles Teil davon. Es ist so: Leute, die zusammenarbeiten, um gemeinsam ein Produkt zu bauen, um auf das Peter-Naur-Zeug zurückzukommen, wir müssen Zeit damit verbringen, diese mentalen Modelle zu verfeinern, diese Dinge aufzubauen.

KI sollte uns freimachen, damit wir das mehr tun können, oder uns dabei helfen. Aber wir können dieses mentale Modell nicht durch das ersetzen, was KI denkt, weil es so nicht funktioniert. Also, ich glaube, es gibt ein, ja, ich glaube, die Welt ist unsicher.

Und deshalb musst du einen Weg finden, wie dein Unternehmen funktionieren kann. Und wenn du mit Unsicherheit umgehen sollst, ganz grundlegend, sowohl auf persönlicher Ebene, auf Prozessebene, auf Architekturebene, auf Strategieebene.

Benedikt Stemmildt 57:47
Sam, vielen, vielen Dank. Ich glaube, das ist ein sehr, sehr guter Punkt, um aufzuhören. Ich, alle, bitte kauft das neue Buch. Es steht schon auf meiner Liste.

Sam Newman 58:03
Ich habe so kleine Postkarten von dem neuen Buch, die du hoffentlich sehen kannst. Ich weiß nicht, ob du das besser siehst. Da haben wir's. Es wird spiegelverkehrt sein, aber vorne drauf ist ein Dachs.

Benedikt Stemmildt 58:10
Vielen Dank. Und ja, vielleicht sieht man sich.

Sam Newman 58:15
Bis bald.

Benedikt Stemmildt 58:16
Vielen Dank fürs Zuhören bei dieser Folge von Rethink Engineering. Sam, auch dir vielen Dank. Es war mir eine Freude, mit dir über Resilience zu sprechen. Und ich glaube wirklich, dass KI auch in diesem Bereich viel verändern wird. Und ja, das können wir alles in deinem Buch nachlesen, oder? Building Resilient Distributed Systems. Wir können darüber auf deinem Blog lesen, samnewman.io. Und ich glaube, wir können dich auch auf ein paar Konferenzen sehen, auf der GOTO und anderen Events.

Die Links packen wir unten in die Beschreibung. Und in der nächsten Folge sprechen wir mit Patrick Debois. Darauf freue ich mich auch richtig. Das wird großartig. Bitte abonniert, damit ihr sie nicht verpasst. Und das war Rethink Engineering von re:cinq und hackers&wizards.