Eine Tour durch unser digital-souveränes Ökosystem – Liene am KCD Czech & Slovak 2026

Am KCD Czech & Slovak 2026 in Prag habe ich das Publikum durch fünf Jahre Aufbau eines digital-souveränen Managed-Services-Ökosystems geführt – die Architekturen, die funktioniert haben, die, die wir verworfen haben, und das grosse Bild, wohin das alles führt. Die Konferenz fand am 21. und 22. Mai an der Fakultät für Informationstechnologie der CTU in Prag statt, in drei Sprachen und mit der gesamten europäischen Cloud-Native-Community.

Meiner Gewohnheit entsprechend habe ich den ganzen Vortrag rund um tschechisches Essen aufgebaut – jedes Kapitel der Reise mit einem Gericht verknüpft.

Schau dir die Aufzeichnung meines Vortrags an

Der Ausgangspunkt: ein einzelnes Kundenprojekt

Die Geschichte beginnt im Februar 2021 mit dem, was wie ein normales Kundenprojekt aussah. Die Zutaten: Crossplane v0.17, MariaDB, Redis und ein externes Cloud Foundry, das Datenbanken auf Abruf über die Open Service Broker API benötigte. Wir nannten das Framework 0.1.

Die Architektur war bereits erkennbar das, worauf wir später aufbauen würden – ein Control-Plane-Cluster mit Crossplane, XRDs und Compositions, der über provider-helm, provider-sql und provider-kubernetes mit einem oder mehreren Service-Clustern kommuniziert. Kunden bestellten eine Instanz, Crossplane komponierte sie, und die richtigen Helm-Releases, Datenbankobjekte, Benutzer und Kubernetes-Ressourcen erschienen im Service-Cluster. Vier Umgebungen: dev, nonprod, prod-nonpremium, prod-premium.

Das funktionierte. Also stellte ich die naheliegende Folgefrage: Wenn es für einen Kunden funktioniert, kann es ein Produkt werden?

AppCat 1.0: vom Projekt zur Plattform

Im Dezember 2022 hatten wir AppCat 1.0 – den VSHN Application Catalog – zunächst an externe Services angebunden, dann ab 2025 mit unserem eigenen Katalog aus managed PostgreSQL, Redis, MariaDB, Keycloak und MinIO. Das Framework hatte sich zu dem weiterentwickelt, was wir heute Framework 1.0 nennen: ein klarer Stack mit Service Definitions (XRDs), Service Implementations (Compositions), Crossplane als Control Plane und Provider-Plugins für $App, $Cloud und Helm – alles über die Kubernetes-API gesteuert und über die OSB-API exponiert.

Das ist das Bild, das die meisten sehen, wenn wir bei VSHN über Crossplane sprechen. Wir betreiben es seit 2021 in Produktion, sind offizieller Crossplane-Vendor und vertreten gerne die These, dass man aufhören sollte, mit Terraform-State zu kämpfen, und die Infrastruktur stattdessen über Kubernetes verwalten sollte. Aber das Framework-Diagramm auf einer Folie verbirgt alles, was einen Managed Service tatsächlich managed macht.

Das unspektakuläre Mittelstück: alles, was einen Service managed macht

Die „more features“-Folie war absichtlich langweilig – eine Wand aus Wörtern, die jeder kennt, der schon mal eine managed Datenbank ernsthaft betrieben hat: Backup, Restore, Logs, Metriken, Alerting, Wartung, Versions-Upgrade, Skalierung, Benutzerverwaltung. Dazu applikationsspezifische Dinge wie Collabora für NextCloud, plus die freie Wahl der darunter liegenden Infrastruktur für die Kunden.

Hier steckt die eigentliche Ingenieursarbeit. Die Control Plane ist der einfache Teil. Der schwierige Teil ist alles, was man bauen, automatisieren und betreiben muss, bevor sich ein Kunde sonntags um 3 Uhr morgens darauf verlassen kann.

Der Umweg: Split Architecture (und zurück)

Nicht jede Entscheidung übersteht den Kontakt mit der Realität, und ich war offen über eine, die wir rückgängig gemacht haben. Irgendwann versuchten wir eine Split Architecture – die strikte Trennung von Control Cluster und Service Cluster, mit Crossplane auf der einen Seite, Managed Resources und Providern in einem eigenen Namespace, und Instanzen, die in einen Service Cluster deployt werden. Das Diagramm war elegant. Die operative Realität war es nicht.

Also gingen wir zurück zu einem Cluster. Die „Nope – back to one cluster“-Folie – mit dem dramatisch rot eingekreisten Instance-Namespace – sorgte für Lacher, und sie macht einen ernsthaften Punkt: Souveränität und operative Einfachheit schliessen sich nicht aus. Manchmal ist die richtige Antwort die langweilige.

Crossplane v2.0 – bewusste Adoption

Im August 2025 war Crossplane v2.0 am Horizont, mit wesentlichen Änderungen daran, wie Compositions und Packages funktionieren. Unsere Position war einfach: wir warten. Nicht weil wir grundsätzlich konservativ sind, sondern weil das Framework, das wir gebaut hatten, echte Produktions-Workloads trug und die Migration bewusst und nicht opportunistisch erfolgen musste.

In der Zwischenzeit machten wir weiter.

Framework 2.0 und AppSlap

Im Mai 2026 hatten wir Framework 2.0, mit einer viel klareren Trennung zwischen dem, was Service-Maintainer tun, und dem, was Framework-Engineers tun. Service-Maintainer arbeiten mit einem ServiceBundle, das ihre Custom-Functions referenziert. Ein Converter wandelt das in echte Crossplane-Artefakte um – Composition, Composite, Package-Metadata – unter Verwendung der VSHN-Funktions-Stdlib. Die Crossplane-CLI liest diese Artefakte und baut das Crossplane-Package. Die gesamte Pipeline ist das, was wir jetzt AppSlap 2.0 nennen.

Der Punkt dabei ist nicht das Diagramm. Der Punkt ist, dass wir neue Services onboarden können, ohne das Framework drum herum neu zu bauen – was man braucht, wenn man ein Ökosystem und kein Produkt will.

Servala – der souveräne App Store

Im Mai 2026 lief auch die erste Codey-Instanz in Produktion auf Servala – der Teil, der aus einem Framework ein Ökosystem macht. Servala ist, einfach gesagt, ein souveräner App Store: ein Marktplatz und Ökosystem-Hub, der vier Arten von Akteuren verbindet und Services zu Kunden leitet.

• Cloud Service Provider bringen souveräne Infrastruktur – Compute, Storage, Network
• Software Vendors bringen die Applikationen und Tools, Open Source und kommerziell
• Managed Service Provider bringen 24/7-Betrieb und Support
• Implementation Partners bringen Beratung und Integration

Servala sitzt in der Mitte. Kunden erhalten souveräne Managed-Applikationen, ohne das Netzwerk selbst zusammenbauen zu müssen, und ohne sich an eine einzelne Partei zu binden.

Das ist es, was ich meine, wenn ich sage, dass Souveränität ein Netzwerk-Problem ist, kein Software-Problem. Kein einzelner Vendor kann glaubwürdig behaupten, von Anfang bis Ende souverän zu sein. Was man tun kann, ist das Bindegewebe aufzubauen, das unabhängig souveräne Provider zu etwas zusammensetzt, das ein Kunde tatsächlich kaufen und betreiben kann.

Was ein souveräner Cloud-Provider mitbringen muss

Eine praktische Anmerkung aus dem Vortrag: Nicht jede Cloud nennt sich souverän, und nicht jede souveräne Cloud ist bereit, diese Art von Stack zu hosten. Ich nannte die konkreten Anforderungen: eine echte API zur Verwaltung von Cloud-Ressourcen, Self-Service-VM-Provisionierung, Upload eigener VM-Base-Images, S3-kompatibles Object Storage, schnelles SSD-Block-Storage, CSI-Storage-Attachments im grossen Massstab (100+), ein Managed Load Balancer mit 100+ Listeners, NAT Gateway und Firewall. Fehlt eines davon, landet das Ökosystem nicht.

Das sind keine exotischen Anforderungen. Sie sind die Baseline, die Hyperscaler vor einem Jahrzehnt normalisiert haben. Die gute Nachricht ist, dass eine wachsende Zahl europäischer und Schweizer Provider heute alle Punkte erfüllt – was das ganze Projekt 2026 realistisch macht, was vor fünf Jahren noch nicht der Fall gewesen wäre.

Immer im Bau

Eine der Folien zeigte nur ein Bild der Sagrada Família. Ich habe den Witz – und den Ernst dahinter – aufgegriffen. Ein souveränes Ökosystem aufzubauen ist ein langer Prozess. Es gibt keine Version, in der man fertig wird, ein Foto macht und geht. Das Framework wird sich weiterentwickeln, Crossplane wird sich weiterentwickeln, Partner werden kommen und gehen, und Kunden werden Dinge verlangen, an die noch niemand gedacht hat.

Die CNCF-Landscape-Folie machte denselben Punkt auf andere Weise – das Cloud-Native-Ökosystem ist riesig, und auf seinen Schultern zu stehen ist der einzig vernünftige Weg, etwas in diesem Massstab zu bauen. Souveränität bedeutet nicht, alles neu zu erfinden. Es bedeutet, die richtigen Dinge zusammenzustellen, mit den richtigen Partnern, in den richtigen Jurisdiktionen, und sich die Option offenzuhalten, die Meinung zu ändern.

Fazit

Nach fünf Jahren sticht eine Lehre über alle anderen hinaus: Digitale Souveränität ist kein Produkt, das ein einzelnes Unternehmen verkaufen kann. Es ist ein Ökosystem, das gemeinsam aufgebaut werden muss.

Danke, Prag

Herzlichen Dank an die Organisatoren des KCD Czech & Slovak und die lokale Cloud-Native-Community für zwei hervorragende Tage an der FIT ČVUT. Die Gespräche nach dem Vortrag waren genauso wertvoll wie der Vortrag selbst – es ist klar, dass viele Menschen in ganz Europa intensiv darüber nachdenken, wie ein souveränes, offenes und operativ ernsthaftes Cloud-Native-Ökosystem aussehen sollte.

Die Diskussionen, Fragen und das Feedback nach der Session haben mich wirklich begeistert. Es ist ermutigend zu sehen, wie gross das Interesse an praktischen Ansätzen zur digitalen Souveränität ist und wie viele Organisationen ähnliche Herausforderungen angehen.

Wenn du souveräne Cloud-Plattformen, Managed Services oder Ökosystem-Partnerschaften aufbaust, würde ich mich freuen, Erfahrungen auszutauschen und zu erkunden, wie wir zusammenarbeiten können.

Möchtest du mehr über VSHNs Arbeit an digital-souveränen Managed Services erfahren? Besuche crossplane.ch, servala.com oder appcat.ch.

Über den VSHN Application Catalog (AppCat)

VSHN Application Catalog (AppCat) ist VSHNs Plattform zur Bereitstellung von produktionsreifen Managed Services über mehrere Cloud-Provider und Kubernetes-Umgebungen hinweg. Auf Crossplane und Kubernetes aufgebaut, automatisiert AppCat den vollständigen Lebenszyklus von Services wie PostgreSQL, MariaDB, Redis und Keycloak – von der Provisionierung und Upgrades bis hin zu Backups, Monitoring und Day-2-Operationen.

Was als Lösung für ein einzelnes Kundenprojekt begann, hat sich zu einem Framework entwickelt, das Managed Services für Organisationen in der Schweiz und darüber hinaus betreibt. AppCat ermöglicht es Kunden, Services über Self-Service-Schnittstellen zu beziehen, während Operatoren eine konsistente Möglichkeit erhalten, Applikationen über verschiedene Infrastrukturen hinweg zu verwalten.

Heute ist AppCat ein zentraler Baustein des breiteren souveränen Ökosystems, das in meinem Vortrag vorgestellt wurde. Es bietet die Automatisierungs- und Betriebsgrundlage, die es Managed-Service-Providern, Cloud-Providern, Software-Vendoren und Implementation-Partnern ermöglicht, über Plattformen wie Servala zusammenzuarbeiten – bei gleichzeitiger Offenheit, Portabilität und Wahlfreiheit für die Kunden.