Datensouveränität wird gebaut, nicht gekauft: VSHN an den Cloud Native Days Austria 2026

Am 29. September 2026 stand Aarno Aukia in Wien auf der Bühne – mit einer einfachen These: Souveränität bekommst du nicht, indem du einen Vertrag mit einem Hyperscaler unterschreibst. Du bekommst sie, indem du deine Architektur danach ausrichtest.

Cloud Native Days Austria 2026

Die Cloud Native Days Austria haben die Community am 29. und 30. September 2026 wieder zusammengebracht, dieses Mal in zwei Kinosälen des Cineplexx Wienerberg in Wien. Zwei Tage voller Talks, Gespräche in den Pausen und ein Abendevent – für Entwickler:innen, Platform Engineers und alle anderen, die ihre Systeme auf Kubernetes betreiben.

Wir waren dabei und unser Mitgründer und Partner Aarno Aukia hat am ersten Tag direkt nach der Opening Keynote das technische Programm eröffnet.

Wenig Zeit? Lade dir die Slides als PDF herunter und spring direkt in die Präsentation.

Aarnos Talk: „Data Sovereignty Is Built, Not Bought“

Aarno begann mit dem Deal, den die Hyperscaler seit zwanzig Jahren anbieten. Das Angebot: moderne Managed Services – Datenbanken, Queues, KI – im Self-Service, in Minuten. Der Preis: Deine Daten ziehen in ihr Rechenzentrum, und das Recht folgt dem Anbieter. Oder wie Aarno es formulierte: Das Gesetz folgt dem Provider, nicht dem Rack. Eine Executive Order kann deinen Service abschalten. Der CLOUD Act kann die Herausgabe deiner Daten erzwingen.

Daten haben Schwerkraft

Für viele Organisationen war es nie wirklich eine Option, alles zu einem Hyperscaler zu verschieben. Gesundheits-, Finanz- und Behördendaten müssen in kontrollierten Umgebungen bleiben. Workloads müssen nahe bei den Systemen laufen, mit denen sie kommunizieren. Und grosse Datenmengen bewegen sich nicht im Rhythmus eines Projektplans. Gleichzeitig erwarten Entwickler:innen genau das, was die Cloud verspricht: eine Managed Database, im Self-Service, jetzt.

Mohammad Alavi, CTO von Health Info Net (HIN), dem sicheren Netzwerk des Schweizer Gesundheitswesens, bringt es auf den Punkt: „Keine finanzielle Entschädigung könnte je geleakte medizinische Daten wiedergutmachen.“

Der häufige Denkfehler

Die Reflex-Antwort lautet: „Dann ziehen wir halt in eine Sovereign Cloud.“ Das Ergebnis ist meist ein Migrationsprojekt, eine doppelte Plattform und eine neue Abhängigkeit. Du hast geändert, von wem du abhängig bist – nicht, ob du abhängig bist.

Aarno verwies auf die EU-Cloud-Ausschreibung über 180 Millionen Euro vom April 2026, die erste, bei der Souveränität bewertet wurde. Drei Gewinner erreichten SEAL-3, sie können also nicht von einer Drittpartei ausserhalb der EU blockiert werden. Ein weiterer Anbieter mit EU-betriebener Infrastruktur auf Basis von Google Cloud landete bei SEAL-2. Auf dem Etikett stand souverän. Die Bewertung sah das anders.

Souveränität als drei Tests

Statt auf Etiketten zu vertrauen, schlug Aarno drei konkrete Fragen vor:

1. Standort: Kannst du ändern, wo es läuft, ohne zu ändern, wie Entwickler:innen es nutzen? Provider-spezifisches Terraform fällt durch, ein Kubernetes Service Claim besteht.
2. Betreiber: Kannst du austauschen, wer es betreibt, ohne die Technologie auszutauschen? Die Managed Database eines Hyperscalers fällt durch, ein Open-Source-Operator mit der Konfiguration in Git besteht.
3. Hersteller: Kannst du die Software austauschen, ohne neu zu bauen? Dafür braucht es Open Source. VMware nach der Übernahme durch Broadcom ist das warnende Beispiel – Redis zu Valkey in acht Tagen das Gegenbeispiel.

Kurz gesagt: Souveränität ist das, was du morgen noch austauschen kannst.

Die neutrale Plattformschicht

Die Architektur, die alle drei Tests besteht, setzt eine einzige Plattform-API zwischen Entwickler:innen und Infrastruktur. Entwickler:innen sprechen mit der API, darunter kann Cloud A, Cloud B, ein privates Rechenzentrum oder die Edge liegen. Es geht nicht darum, Plattformen zu vermeiden, sondern darum, für Veränderung zu designen.

Genau so funktioniert unser VSHN Application Catalog (AppCat). Entwickler:innen bestellen Managed Databases und Services als Kubernetes-Ressourcen. Crossplane auf Kubernetes stellt die Service-API bereit, und die Services laufen bei cloudscale, Exoscale, Switch oder in privaten Clustern – jeweils mit eigenem lokalem Prometheus und Grafana, rund um die Uhr betrieben, dort wo die Daten sind.

Heute bietet AppCat PostgreSQL, MariaDB, Redis, Keycloak (mit Inventage), Forgejo, Nextcloud und S3 Object Storage der darunterliegenden Infrastruktur. Als Nächstes kommen Kafka (mit Spoud) und OpenBao (mit bespinian).

Eine produktive Datenbank braucht zehn Zeilen:

yaml

apiVersion: vshn.appcat.vshn.io/v1
kind: VSHNPostgreSQL
metadata:
  name: pgsql-app1-prod
spec:
  parameters:
    size:
      plan: standard-2
  writeConnectionSecretToRef:
    name: postgres-creds

Keine Cloud, keine Region, kein Operator, keine Storage Class. Zurück kommt PostgreSQL mit TLS, täglichen Backups, Monitoring und einem Wartungsfenster. Ein echtes Produktionsteam legt mehr fest – Service Level, drei Instanzen für Hochverfügbarkeit, Backup-Zeitplan und Aufbewahrung, Wartungsfenster, Löschschutz. Jede dieser Entscheidungen gehört dem Team. Und trotzdem steht nirgends in der Spezifikation, wo das Ganze läuft.

Über 2000 Instanzen in Produktion

AppCat ist kein Konzept. Seit 2021 haben wir über 2000 Managed-Instanzen ausgeliefert, auf zwei Wegen: Jeder Managed-OpenShift-Cluster, den wir betreiben, enthält AppCat standardmässig – in der eigenen Infrastruktur der Kundinnen und Kunden, VMware inklusive, oder bei einem Schweizer Partner wie cloudscale, mit SLAs bis 99,99%. Und in geteilten Umgebungen bestellst du AppCat-Services wie SaaS über Servala oder nutzt sie direkt in APPUiO.

Zu den Kundinnen und Kunden gehören finnova, acrevis, HRM Systems, das Schweizerische Bundesarchiv, HIN mit über 50’000 Gesundheitsfachpersonen und Taurus. Sebastien Pasche, VP Engineering bei Taurus: „Wir haben die monatlichen Incidents von zwölf auf null reduziert und unser SLA von 99% auf 100% verbessert.“

Der Beweis: Der Motor wechselt, die API bleibt

Der stärkste Teil des Talks: Wir bestehen die Tests selbst. In AppCat blieb kind: VSHNPostgreSQL gleich, während der PostgreSQL-Operator darunter ausgetauscht wurde: CloudNativePG kam im September 2025 als Option dazu, war im April 2026 inklusive Self-Service-Restore ausgereift, wurde im Mai 2026 Standard für neue Instanzen, und StackGres erreichte am 31. August 2026 das Ende seiner Lebensdauer. Die Kundinnen und Kunden behielten ihre API und planten die Migration in ihrem eigenen Tempo.

Und wir machen es gerade wieder, diesmal mit unserer eigenen Control Plane. AppCat läuft seit 2021 auf Crossplane und wird das bis 2027 und darüber hinaus tun, aber wir wechseln auf Helmetica, ein Betriebs-Framework für beliebige Software auf Kubernetes, das wir schrittweise als Open Source veröffentlichen. Es überwacht, sichert und verwaltet jeden Service per GitOps – nach demselben Prinzip wie unser Puppet-Framework auf VMs. Der Unterschied ist deutlich: Redis auf Crossplane brauchte 2076 Zeilen Go- und Shell-Code, um ein Helm Chart zu rendern. Redis auf Helmetica braucht 320 Zeilen – das Upstream-Chart plus die gemeinsamen Templates des Frameworks für Backup, Netzwerk, Wartung und Zugangsdaten. Vom Helm Chart zum Service in fünf Minuten und jede Änderung ist ein lesbarer Diff.

Souveränität ist jetzt messbar

Das EU Cloud Sovereignty Framework bewertet Anbieter anhand von acht Zielen, von SEAL-0 bis SEAL-4. Drei davon – betriebliche Unabhängigkeit, Transparenz der Lieferkette und die Möglichkeit, ohne Neubau zu migrieren – machen zusammen die Hälfte der Bewertung aus. Und alle drei entscheidet deine Architektur, nicht dein Vertrag.

Aarno schloss mit der Frage, die alles zusammenfasst: Entscheidend ist nicht, welche Cloud du wählst, sondern ob dir deine Architektur morgen noch eine Wahl lässt. Abhängige Teams fragen um Erlaubnis. Souveräne Teams liefern.

Kurz gesagt: Datensouveränität wird gebaut, nicht gekauft.

Die Slides zum Download

Du willst tiefer einsteigen – in die drei Souveränitäts-Tests, die AppCat-Architektur, die YAML-Beispiele und den Helmetica-Vergleich? Hier findest du Aarnos komplette Präsentation von den Cloud Native Days Austria als PDF.

Souveränität war überall

Wir waren nicht die Einzigen, die darüber gesprochen haben. Souveränität, Unabhängigkeit und Compliance zogen sich durch das ganze Programm:

• Lukas Zainzinger (willhaben) zeigte einen Blueprint, wie man mit einer Open-Source-basierten, anbieterunabhängigen Datenpipeline vom Edge bis in die Cloud die Datensouveränität zurückgewinnt.
• Niels Claeys (Dataminded) fragte, wie eine Cloud-Strategie nach der Hyperscaler-Ära aussieht – von reinen On-Prem-Plattformen über souveräne Control Planes bis zu europäischen Cloud-Alternativen.
• Dr. Constanze Roedig präsentierte ein eBPF-basiertes Kubernetes-SOC, das node-lokal läuft und airgapped betrieben werden kann, sodass keine Daten den Cluster verlassen müssen.
• ORF erzählte, wie sie EKS mit Hybrid Nodes, Cilium und Crossplane an eigene On-Prem-Hardware anbinden.
• Artem Lajko und Nick Berthold (iits-consulting) warfen mit Gardener, Kamaji und Cluster API einen Blick hinter die Kulissen von Managed Kubernetes.
• Auf der regulatorischen Seite machten Talks zum EU Cyber Resilience Act und zu NIS2 in Österreich klar: Compliance wird zum Engineering-Thema, nicht nur zum juristischen.

Unterschiedliche Blickwinkel, dieselbe Schlussfolgerung: Die Community fragt nicht mehr, ob Souveränität wichtig ist, sondern wie man sie baut. Genau dieses Gespräch wollen wir mitprägen.

Danke, Wien

Ein grosses Dankeschön an die Organisatorinnen und Organisatoren, Volunteers und Sponsoren der Cloud Native Days Austria für eine weitere tolle Ausgabe und an alle, die bei uns vorbeigekommen sind, um über Souveränität, Crossplane und Managed Services zu sprechen.

Du willst wissen, wie dieses Modell in deiner Umgebung funktionieren könnte? Melde dich bei uns – wir zeigen es dir gerne.