Built to fail: Rückblick auf die KubeCon 2026

Letzte Woche saßen wir mit einem Teil des Teams in der RAI zur KubeCon + CloudNativeCon 2026. Dreizehntausend Engineers aus der ganzen Welt, eine gemeinsame Annahme: Software, die für Kunden wirklich zählt, ist Software, die davon ausgeht, dass irgendwo etwas kaputtgeht.

Bei DCSolutions nennen wir das 'built to fail'. Das klingt wie ein Widerspruch, deshalb zunächst eine Erläuterung, was es bedeutet und was nicht.

Der Ausgangspunkt

Traditionelle Software wird unter der Annahme gebaut, dass alles weiter funktioniert. Datenbank steht. Server läuft. Netzwerk ist da. Wenn dann doch etwas schiefgeht (und irgendwo geht immer irgendwann etwas schief), wird das Problem groß. Ein Ausfall mitten im Schadenprozess. Ein träges Portal an einem vollen Dienstag. Eine verlorene Einreichung, weil eine Komponente hängen bleibt.

Built to fail dreht diese Annahme um. Die Plattform geht davon aus, dass irgendwo etwas kaputtgehen wird, und ist dafür konzipiert. Mehrere Kopien jeder Komponente. Automatischer Neustart bei Ausfall. Lastverteilung, die sich anpasst, wenn eine Node wegfällt. Das System läuft weiter, während Teile davon es nicht tun.

Die Technologie, die das möglich macht, ist Kubernetes, und das breitere Cloud-native-Ökosystem darum herum. Darum ging es auf der KubeCon.

Drei Beobachtungen aus der RAI

Cloud native ist keine Nische mehr. Banken, Telekommunikationsanbieter, Behörden, große Händler betreiben darauf kritische Workloads. Was vor zehn Jahren experimentell war, ist heute die Art, wie seriöse Software gebaut wird. Wir nicht als Einzige.

Das Ökosystem ist ausgereift. Das Tooling rund um Monitoring, Security, Deployment und Datenmanagement steht. Für einen Plattformanbieter bedeutet das weniger Eigenbau und mehr Kombinieren von Komponenten, die von Tausenden Engineers weltweit validiert werden. Das ist nicht nur effizienter, es ist auch sicherer.

Compliance bekam viel Aufmerksamkeit. Die Governance-Anforderungen, mit denen Versicherer zu tun haben (DORA, NIS2, KI-Verordnung (AI Act)), waren auf der KubeCon deutlich präsent. Die nativen Tools für Audit-Logging, Secret-Management und Data Residency, die man für diese Regulierung braucht, stecken in dem Stack, auf dem wir bauen. Das ist kein Zufall.

(Side Note: Drei Kollegen waren in der offiziellen Aftermovie von Tag 2 zu sehen, etwa bei 0:43. Darauf sind wir ein bisschen stolz.)

Was das für Schadenversicherer bedeutet

Eine Claims-Plattform darf nicht down sein. Nicht halb. Nicht 'kurz'. Ein Anspruchsteller, der an einem Samstagabend nach einem Unfall Informationen einreichen will, erwartet, dass es funktioniert. Ein Bearbeiter, der am Montagmorgen Akten abruft, erwartet, dass sie da sind. Ein Kettenpartner, der ein Dokument validieren muss, erwartet eine Antwort innerhalb von Sekunden.

Dem stehen drei konkrete Eigenschaften unserer Architektur gegenüber.

Unverwüstliche Zuverlässigkeit.
‍Fällt eine Komponente aus, übernimmt eine andere dieselbe Arbeit sofort. Der Endnutzer merkt nichts davon. Keine lange Prozedur, kein manueller Eingriff, keine Support-Tickets, um alles wieder hochzufahren.

Skalierbarkeit, die mitatmet.
‍Ein ruhiger Sonntag oder eine Spitze durch eine Sturmfront mit Hunderten Meldungen gleichzeitig: Die Plattform skaliert automatisch mit der Last. Keine manuelle Kapazitätsplanung. Keine Performance-Probleme im falschen Moment.

Garantierte Kontinuität.
‍Automatisierte Wiederherstellung, automatische Backups, Monitoring, das Abweichungen erkennt, bevor ein Nutzer sie zu spüren bekommt. Teil des Grunddesigns, kein Modul, das man separat ankreuzt.

Kein Migrationsprojekt, eine Schicht obendrauf

Was wir nicht tun: einen Versicherer zu einer langen, teuren Migration weg von bestehenden Systemen zwingen. Solche Projekte gehen selten gut aus und sind in den meisten Fällen auch nicht nötig.

Was wir tun: eine intelligente Schicht auf die bestehende Infrastruktur legen, die die Kette verbindet und Daten strukturiert. Auf der Axon-Seite bleibt Axon stehen. Auf der Seite des Schadenbearbeiters bleibt das System, das dort steht. Dazwischen läuft die Composable-Claim-Plattform, die die Kommunikation abwickelt, die Workflows orchestriert und die Daten für spätere Analysen und Compliance-Prüfungen festhält.

Diese Plattform läuft auf der Architektur, die die KubeCon letzte Woche erneut als Standard bestätigt hat. Eine Plattform, die einfach funktioniert. Immer. Weil sie gebaut ist, um jeden Schlag abzufangen.

Versicherer, die mehr darüber wissen möchten, können über den Button unten ein Gespräch einplanen. Ein Intake, ein technischer Walkthrough. Danach wissen Sie genau, wie es funktioniert und was es für Ihre Kette bedeutet.

‍