June 2026 DevOps Meetup

Gespräch 1
**Titel: Die Plattform sind die Menschen: SLAs, DORA und Vertrauen bei Milliarden von Anfragen pro Monat**
Von: Harry Bouras
Rolle / LinkedIn: KI- und Cloud-Engineering-Leiter, früher Leiter der API-Organisation eines führenden, äußerst globalen und multikulturellen Unternehmens. LinkedIn: https://www.linkedin.com/in/harry-bouras/

Zusammenfassung:
Bei den meisten „Plattform“-Gesprächen geht es um Tools. Dies ist nicht der Fall. Als Leiter der API-Organisation eines führenden, äußerst globalen und multikulturellen Unternehmens, das jahrzehntelange Legacy-Systeme miteinander verbindet, dabei Milliarden von Anfragen pro Monat bearbeitet und sowohl über Azure als auch über Google Cloud skaliert, habe ich auf die harte Tour eine widersprüchliche Lektion gelernt: Bei diesem Volumen scheitern Plattformen nicht an der Technologie und Cloud-Rechnungen explodieren nicht wegen schlechter Terraform. Sie scheitern oder haben Erfolg, wenn es darum geht, wie die Organisation darauf ausgerichtet ist, die Sache zu besitzen, zu liefern und weiterzuentwickeln. Das Organigramm ist die eigentliche Architektur.

Ich werde durch die Hebel gehen, die die Nadel tatsächlich bewegt haben, und jeder davon ist in echten Momenten dieser Skala verankert. Wie SLAs, die als Klarheit und nicht als Bestrafung formuliert sind, das Verhalten von Ingenieuren mehr verändern als jedes andere Dashboard. Warum einem Team von vornherein Vertrauen und Zeit schenken – das Unbequemste, was eine Führungskraft tun kann – ist genau das, was die Verarbeitungsqualität erhöht und die Nacharbeit reduziert, die Sie sich bei Milliarden von Anfragen nicht leisten können. Was hat sich wirklich geändert, als wir eine wasserfallförmige Organisation in Richtung einer iterativen, Scrum-basierten Bereitstellung überführt haben, und warum es dabei darum ging, Feedbackschleifen zu verkürzen und nicht um die Einführung von Zeremonien? Und wie DORA-Metriken zu unserer objektiven Antwort auf eine Frage wurden, über die jedes Team streitet: Was macht eigentlich einen erfolgreichen Senior Software Engineer und was einen DevOps Engineer aus?

Dann der menschliche Kern, ehrlich erzählt, das heißt als Komödie erzählt. Was einen guten Manager auf dieser Welt ausmacht, wird durch die Dinge erzählt, bei denen ich mir sicher war und bei denen ich völlig falsch lag. Der Running Gag ist auch der eigentliche Punkt: Fast jeder Instinkt, der mich zu einem guten Ingenieur machte, machte mich zu einem mittelmäßigen Manager, bis ich ihn verlernte.

Abschließend noch ein Blick darauf, was wir gemeinsam allesamt falsch machen werden: KI zwingt DevOps dazu, zu DevSecOps heranzuwachsen – und die Teams, die gut damit umgehen, werden bereits über die Eigenverantwortung, das Vertrauen und die Wachstumskultur verfügen, um die es in diesem Vortrag wirklich geht.

Gespräch 2
**Postmortem-Kultur: Misserfolge in Lernen verwandeln, nicht in Schuldzuweisungen**
Von: Dani Yelovitch
Die meisten Entwicklungsteams behandeln Vorfälle als Peinlichkeiten, die es zu begraben gilt – eine schnelle Lösung, eine vage Slack-Nachricht, und schon geht es weiter. Dieser Vortrag plädiert für einen anderen Ansatz: jeden Misserfolg als Geschenk zu betrachten.
Die Kernidee sind tadellose Post-Mortem-Analysen – eine bei Google und Netflix entwickelte Praxis, deren Ziel nicht darin besteht, einen Sündenbock zu finden, sondern zu verstehen, wie das System (Personen, Tools, Prozesse) einen Fehler überhaupt erst ermöglicht hat. Wenn ein Mensch einen Fehler gemacht hat, ist die eigentliche Frage: Warum hat das System es leicht gemacht, diesen Fehler zu machen?
Der Vortrag würde Folgendes umfassen:
Wie eine gute Obduktion aussieht (und wie sie häufig schief geht)
So führen Sie eine tadellose Überprüfung durch, ohne dass es zu einer Sitzung mit Schuldzuweisungen durch den Ausschuss kommt
Aktionspunkte in tatsächliche Veränderungen umwandeln, nicht in ein Friedhofsdokument, das niemand liest
Aufbau psychologischer Sicherheit, damit Ingenieure Probleme frühzeitig melden, anstatt sie zu verbergen
Die wichtigste Erkenntnis: Teams, die schneller als ihre Konkurrenten aus Fehlern lernen, liefern bessere Software mit weniger katastrophalen Zwischenfällen – nicht weil sie bessere Ingenieure haben, sondern weil sie bessere Feedbackschleifen aufgebaut haben.

**Vortrag 3:**
Titel: Von der Serviceorganisation zum Self-Service: Plattform-Engineering in Aktion
Von Pavel Bureš von Sky

Moderne Ingenieursorganisationen bauen Plattformsilos schneller auf, als sie diese abbezahlen können – jedes Team wählt seinen eigenen Weg zur Bereitstellung von Arbeitslasten, Datenbanken, Warteschlangen und Caches, jeweils mit leicht unterschiedlichen Sicherheits-, Beobachtbarkeits- und Kostenprofilen. In diesem Vortrag teilen wir mit, wie wir dieses Problem im großen Maßstab angehen, und zwar mithilfe einer Plattform-Engineering-Praxis, die auf dem Prinzip einer einheitlichen, abstrahierten Schnittstelle für die anwendungszentrierte Konfiguration basiert – ein Ansatz, der Plattformteams von „ticketgesteuerter Installation“ zum Produktdenken verlagert: stabile Verträge, goldene Pfade und standardmäßige Selbstbedienung.

In der zweiten Hälfte konzentrieren wir uns auf PEaaS (Persistence Engineering as a Service), unsere konkrete Umsetzung dieser Prinzipien für zustandsbehaftete Workloads. Wir werden durch die Architektur gehen – Crossplane 2.0-Kompositionsfunktionen auf EKS, anwendungszentrierte Kubernetes-Ansprüche (XRs) und ein Mandanten-Onboarding-Modell, das IAM, VPC-Endpunkte, OIDC- und S3-Bereitstellung automatisiert – und wie es heterogene Backends (Keyspaces, Aurora DSQL, Redis Cloud und Kafka auf EKS) hinter einer konsistenten Schnittstelle abstrahiert.

Die Teilnehmer werden mit Folgendem abreisen: Ein praktisches Muster für die Gestaltung von Engineering-Plattformen in ihren eigenen Organisationen.
Eine Referenzarchitektur für Persistenz-as-a-Service auf Crossplane.
Ehrliche Lektionen zu Standardisierung, Mieter-Onboarding und Plattformeinführung.