Allgemein Sovereignty

Wer kann es abschalten

7. Okt. 2026

Aarno Aukia, VSHN. Oktober 2026

In Diskussionen über digitale Souveränität geht es fast immer darum, wer deine Daten lesen kann. Dafür gibt es inzwischen brauchbare Antworten: Verschlüsselung, Datenstandort, Zugriffsprotokolle, ein Auftragsverarbeitungsvertrag, der jeden Unterauftragnehmer benennt. Seltener gestellt und deutlich schmerzhafter ist die andere Frage: Wer kann deinen Dienst abschalten?

Vertraulichkeit zu verlieren ist schlimm. Den Dienst zu verlieren ist schlimmer, denn dann steht das Geschäft noch am selben Nachmittag. Und die beiden Risiken haben nicht denselben Eigentümer: Deine Daten können in Zürich liegen, während der Entscheid, sie weiter auszuliefern, ganz woanders fällt.

Vier Wege, auf denen ein laufender Dienst endet, ohne dass jemand deine Daten anfasst

Das sind nicht vier Varianten desselben Risikos. Der Unterschied liegt im Vorlauf: Der erste beendet den Dienst heute, die nächsten zwei setzen dir eine Frist, die du nicht gewählt hast, und beim vierten muss niemand etwas entscheiden.

1. Jemand ordnet die Abschaltung an. Tage, ohne Rekurs. Ein Anbieter befolgt das Recht der Rechtsordnung, zu der er gehört. Sanktionen, Exportkontrollen und Gerichtsentscheide treffen das Unternehmen, nicht das Rechenzentrum, und der Kunde sitzt bei diesem Entscheid selten mit am Tisch. Adobe deaktivierte im Oktober 2019 sämtliche Konten in Venezuela, um ein US-Dekret zu befolgen, drei Wochen nach der Ankündigung, und erklärte zunächst, bereits bezahlte Abonnemente nicht zurückerstatten zu dürfen, bevor es diese Haltung unter öffentlichem Druck korrigierte. Im Mai 2025 verlor der Chefankläger des Internationalen Strafgerichtshofs den Zugang zu seinem Microsoft-Konto, nachdem die USA Sanktionen gegen Mitarbeitende des Gerichts verhängt hatten. Microsofts Präsident bestreitet, dass das Unternehmen Dienste für das Gericht ausgesetzt hat. Was das Gericht daraus gemacht hat, ist belegt: Im Oktober 2025 bestätigte es die Umstellung von rund 1’800 Arbeitsplätzen auf openDesk.

2. Die Lizenz ändert sich unter dir. Monate, plus Rechnung. Dafür braucht es gar keine Politik. Red Hat verschob im Dezember 2020 das Lebensende von CentOS Linux 8 von Mai 2029 auf Dezember 2021: acht Jahre eingeplante Laufzeit weg, zwölf Monate Vorlauf, und kein Vertrag gebrochen. Broadcom beendete im Dezember 2023 den Verkauf von VMware-Dauerlizenzen und stellte vollständig auf Subscriptions um. Im Mai 2025 verschickte es Unterlassungsschreiben an Inhaber von Dauerlizenzen mit abgelaufenem Support, mit der Aufforderung, alle nach Vertragsende veröffentlichten Updates und Patches zu deinstallieren. Das Recht, die Software zu betreiben, blieb. Das Recht, sie zu patchen, nicht, und einen ungepatchten Hypervisor betreibt niemand weiter. Oracle rechnet Java SE seit Januar 2023 pro Mitarbeitenden ab, gezählt auf dem gesamten Personalbestand und nicht auf denen, die Java nutzen: gleiche Software, gleiche Installation, eine Rechnung aus dem HR-System.

3. Das Produkt wird eingestellt, dem Anbieter geht es gut. Monate, plus eine Migration, die niemand budgetiert hat. Bei kleinen Anbietern fürchten alle den Konkurs, und das ist die falsche Furcht. Der Normalfall ist ein gesundes Unternehmen, das ein Produkt einstellt. Microsoft stellte Azure Database for MariaDB am 19. September 2025 ein, angekündigt zwei Jahre vorher, neue Instanzen gesperrt achtzehn Monate vorher, und laut eigener Dokumentation werden am Stichtag noch laufende Workloads gelöscht und ihre Daten sind verloren. AWS stellte Amazon QLDB am 31. Juli 2025 ein, mit rund einem Jahr Vorlauf, und dem empfohlenen Ersatz fehlt die kryptografische Nachweisbarkeit, also genau der Grund, QLDB zu wählen: Aus der Migration wurde ein Redesign. Google stellte Cloud IoT Core im August 2023 mit zwölf Monaten Vorlauf ein, mit der Begründung, Partner bedienten diesen Bedarf besser. Azure Blockchain Service nahm ab Mai 2021 keine neuen Deployments mehr an und war im September abgeschaltet, vier Monate später. Alle diese Anbieter sind weiterhin im Geschäft.

4. Niemand entscheidet etwas, und es hört trotzdem auf. Die Zündschnur ist die Pflicht, den Hersteller zu erreichen. Software auf deiner eigenen Hardware muss oft ihren Hersteller erreichen, um weiterzulaufen, und kaum ein Team hat nachgelesen, wie lange sie ohne diese Verbindung durchhält. Azure Local, das Microsoft für souveräne und verteilte Standorte positioniert, schreibt die Antwort in die eigene FAQ: Synchronisiert das System 30 aufeinanderfolgende Tage nicht mit Azure, wechselt der Status auf „Out of policy“ und das System in einen Modus mit reduzierter Funktionalität, in dem bestehende VMs weiterlaufen und neue nicht mehr erstellt werden können, bis die Synchronisierung wieder gelingt. Deine Hardware, dein Gebäude, deine Daten, und das Recht, eine VM zu starten, erneuert sich monatlich aus einer Cloud. Für dauerhaft getrennte Standorte verkauft Microsoft eine Disconnected-Variante: Die Zündschnur steckt also im Standardprodukt, und sie herauszunehmen ist ein eigener Kauf. Microsoft 365 ist derselbe Mechanismus mit kürzerer Schnur. Nach dem Enddatum eines Abonnements gibt Microsoft 30 Tage mit normalem Zugriff, danach wechseln die Programme in einen Modus, den die eigene Dokumentation „read-only, reduced functionality mode“ nennt: Du kannst deine Dokumente ansehen, nicht bearbeiten. Und es braucht nicht einmal ein abgelaufenes Abonnement: Im November 2020 blieben weltweit Macs beim Starten von Programmen hängen, weil Apples Server für den Zertifikatsstatus nicht mehr antwortete, und der Tipp, der die Runde machte, war, das Internet zu trennen.

Der lehrreichste Fall der Datenbankwelt gehört in die dritte Kategorie, nicht in die erste. Sun Microsystems kaufte 2008 MySQL, Oracle kaufte 2009 Sun, und der Erfinder von MySQL forkte den Code, statt abzuwarten, was der neue Eigentümer damit vorhat. Oracle ist nicht verschwunden, und MySQL wurde nicht eingestellt. Der Fork geschah wegen dessen, was der Eigentümer entscheiden könnte, und er war möglich, weil die Lizenz ihn erlaubte. Deshalb gibt es MariaDB.

Warum ein Vertrag die Frage nicht erledigt

Ein Vertrag bindet deinen Anbieter. Er bindet nicht den Staat, der deinen Anbieter reguliert, und er überlebt den Anbieter nicht. Vertraglicher Schutz lohnt sich, und er ist die Ebene, auf der Beschaffungsprozesse die meiste Zeit verbringen. Genau deshalb ist die Lücke so verbreitet: Die Unterlagen sind gründlich bei Haftung und schweigen zur Fortführung, wenn die Gegenseite verpflichtet, übernommen oder verschwunden ist.

Beim Datenstandort ist die Lücke gleich geformt. Er sagt dir, wo die Bytes liegen. Er sagt nichts darüber, wer den Dienst betreibt, welchem Recht die betreibende Gesellschaft untersteht und wer zum Abschalten verpflichtet werden kann. Das sind drei getrennte Fragen, und jeder Anbieter beantwortet sie anders.

Was das Risiko tatsächlich senkt

Vier Fragen, in der Reihenfolge ihrer Bedeutung:

1. Kann dir jemand das Recht entziehen, die Software zu betreiben? Bei einer proprietären Engine ja, über geänderte Bedingungen oder ein eingestelltes Produkt. Bei einer Engine unter GPLv2 oder einer vergleichbaren Lizenz nein. Der Code, den du betreibst, bleibt deiner, und ein Fork bleibt möglich. Das ist der strukturelle Grund, warum die MySQL-Geschichte überhaupt eine Fortsetzung bekommen konnte.

2. Wer betreibt die Lösung, und nach welchem Recht? Software zu betreiben ist etwas anderes, als ihre Lizenz zu halten. Sitzt der Betreiber als Tochtergesellschaft im Ausland, fallen die Betriebsentscheide in der Rechtsordnung der Mutter, ganz gleich, welche Adresse das Rechenzentrum hat.

3. Was hört auf zu funktionieren, wenn du aufhörst zu zahlen? Das ist der schärfste Test, und fast niemand führt ihn durch. Streiche die kommerziellen Komponenten auf dem Papier und schau, was übrig bleibt. Bleibt eine Datenbank übrig, die weiter Abfragen beantwortet, hast du einen Ausstieg. Bleibt nichts übrig, hast du eine Abhängigkeit, die du bisher Partnerschaft genannt hast. Stelle die Frage danach ein zweites Mal, nicht zur Zahlung, sondern zur Erreichbarkeit: Was hört auf zu funktionieren, wenn der Hersteller einen Monat lang nicht erreichbar ist? Beide Antworten stehen in der Dokumentation. Keine davon steht im Vertrag.

4. Wer nimmt um drei Uhr nachts ab? Unabhängigkeit, die niemand betreiben kann, ist keine Unabhängigkeit, sondern ein Hobby. Souveränität zielt auf Fortführung, und Fortführung braucht jemanden, der vertraglich verpflichtet ist, den Betrieb wiederherzustellen, nahe genug an deiner Zeitzone und deiner Sprache, um es auch zu tun.

Wie das konkret aussieht

Nimm eine MariaDB-Installation, das Beispiel, das ich am besten kenne, und zerlege sie in Schichten:

  • MariaDB Server und Galera Cluster stehen unter GPLv2. Produktiv frei betreibbar, ohne Lizenzaudit-Risiko auf der Datenbank selbst. Dieses Recht kann dir niemand entziehen, dieses Jahr nicht und in fünf Jahren nicht.
  • Die Connectors stehen unter LGPL, lassen sich also in proprietäre Anwendungen einbinden, ohne dass du deinen eigenen Code offenlegen musst.
  • MaxScale, der Enterprise Kubernetes Operator, der Enterprise Manager und die Analytik-Komponenten sind kommerziell lizenziert und kommen mit einer Subscription.

Führe Frage 3 gegen diesen Stapel aus. Kündigst du die Subscription, läuft die Datenbank weiter: Du verlierst die Proxy-Schicht, die gehärteten Builds und den Support des Herstellers, was echte Verluste sind, und du beantwortest weiter Abfragen, während du entscheidest, wie es weitergeht. So sieht ein Ausstieg aus, wenn er strukturell verankert ist und nicht nur vertraglich.

Dann führe Frage 2 aus. Die Subscription ist eine Geschäftsbeziehung mit einem europäischen Hersteller. Der Betrieb kann bei einem Schweizer Unternehmen liegen, nach Schweizer Recht, mit der Infrastruktur in einem Schweizer Rechenzentrum oder in deinem eigenen. Zwei Lieferanten, zwei Arten von Verantwortung, und keiner von beiden kann den Teil des anderen einseitig beenden.

Genau diese Aufteilung haben VSHN und MariaDB am gemeinsamen Webinar vom 1. Oktober beschrieben, dessen Aufzeichnung online ist: MariaDB baut die Datenbank und steht hinter der Engine, VSHN verkauft die Subscription in CHF und betreibt die Plattform. Du unterschreibst einen Schweizer Vertrag und hast trotzdem die Entwickler der Datenbank im Rücken.

Der unbequeme Teil

So gekaufte Souveränität ist nicht gratis. Die kommerziellen Komponenten kosten Geld, der Betrieb kostet Geld, und jemand muss die Architektur betreiben, die ein Failover unsichtbar macht, statt zu hoffen, dass der einzelne Knoten durchhält. Dafür bekommst du die Fähigkeit, einer Aufsicht, einer Revision oder dem eigenen Verwaltungsrat mit Fakten zu antworten: Hier liegt die Lizenz, hier liegt der Betrieb, das ist das anwendbare Recht, und das läuft weiter, wenn eine der Parteien wegfällt.

Der Schweizer öffentliche Sektor zahlt diesen Preis inzwischen bewusst, und die Entscheide dazu sind aktenkundig. Das EMBAG verpflichtet die Bundesverwaltung seit dem 1. Januar 2024, Software, die sie selbst entwickelt oder entwickeln lässt, als Open Source zu veröffentlichen. Damit gehört die Schweiz zu den ersten Ländern, die das gesetzlich festschreiben. Im Juni 2026 ging der Ständerat weiter und nahm eine Motion für ein Impulsprogramm zur digitalen Souveränität mit 30 zu 7 Stimmen an, entgegen der Empfehlung des Bundesrats; im Nationalrat ist sie noch offen. Dieselbe Überlegung gilt eine Schicht tiefer, bei der Datenbank unter der Anwendung, von der das Geschäft lebt.

Wo du anfängst

Schau dir die Systeme an, die du keinen Tag verlieren darfst, und schreib für jedes fünf Antworten auf: Wer hält die Lizenz der Engine, wer betreibt sie, welchem Recht untersteht der Vertrag, was läuft weiter, wenn du aufhörst zu zahlen, und was läuft weiter, wenn nichts mehr den Hersteller erreicht. Die ersten drei können die meisten Teams aus dem Kopf beantworten, bei den letzten zwei wird es still.

Gehört MariaDB zu diesen Systemen, machen wir diese Bestandsaufnahme mit dir. VSHN und MariaDB bieten sie gemeinsam an: welche Versionen laufen, wo sie exponiert sind, was unter Support steht und was nicht. Die Bestandsaufnahme ist kostenlos und endet mit einer schriftlichen Antwort, nicht mit einer Offerte.

Kostenlose Bestandsaufnahme buchen

Wenn du lieber mit der Technik anfängst als mit deinem eigenen Bestand: Am 19. Oktober läuft im VSHN Tower in Zürich ein Hands-on-Nachmittag mit den MariaDB-Engineers und Michael „Monty“ Widenius, der MySQL und MariaDB geschrieben hat. Auf dem Programm stehen ein Failover mit MaxScale live, der Enterprise Kubernetes Operator und Migrationen. Vierzig Plätze.

Platz für den 19. Oktober in Zürich reservieren


Quellen:

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

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

6. Okt. 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.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein OpenShift Tech

OpenShift 4.22 lets your pods mount container images as volumes

2. Okt. 2026

Whenever Red Hat releases a new version of OpenShift, our team works through the release notes and asks one simple question: what does this actually mean for the people running their applications on VSHN Managed OpenShift?

OpenShift 4.22 has been available since June 9th, 2026. It’s based on Kubernetes 1.35 and CRI-O 1.35, and the Red Hat CoreOS (RHCOS) image now uses RHEL 9.8 packages, which bring the latest fixes, enhancements, hardware support and driver updates. VSHN Managed OpenShift clusters currently run 4.21, and we’ve started testing 4.22. Here’s what you can look forward to.

Good news for developers: static data in its own image

Some applications rely on large amounts of static data. With OpenShift 4.22, that data can be distributed in a separate container image and mounted straight into your pods as a volume, opening the door to new ways of structuring applications.

Under the hood, this works with OCI images and artifacts. These let you store and distribute arbitrary files and metadata through OCI-compliant registries, the same kind of registries that hold your container images.

More flexibility with Gateway API

Until now, OpenShift blocked any attempt to install Gateway API resources from the experimental channel. With 4.22, that restriction is gone, which gives you more flexibility in adopting Gateway API.

Behind the scenes: one reboot less, safer updates

Some improvements you won’t notice directly, but they make the platform run more smoothly.

New worker nodes used to start in the generic worker machine config pool and then had to be moved to their actual target pool, which required an extra reboot. With 4.22, new nodes boot directly into their target pool, saving one reboot cycle during provisioning.

OpenShift also keeps a closer eye on the images nodes boot from. On supported infrastructures, the Machine Config Operator checks whether a node’s boot image is too old. If it is, OpenShift blocks cluster updates until the boot image has been updated.

A good release for vSphere users

If your OpenShift runs on VMware vSphere, two features are now generally available:

  • Zones for vSphere host groups: OpenShift failure domains can be mapped to vSphere host groups, enabling seamless use of the high availability offered by a vSphere stretched cluster. The feature was introduced as a technology preview in OpenShift 4.19.
  • Boot image management for worker nodes: the node boot image is now updated automatically during cluster updates. New nodes created afterwards are based on the new version, while existing nodes aren’t affected.

What doesn’t affect you

  • runC is deprecated: OpenShift 4.22 deprecates the runc container runtime for CRI-O. All VSHN Managed OpenShift clusters use CRI-O with the default crun runtime, so this doesn’t affect our clusters.
  • RHCOS 10.2 as technology preview: OpenShift 4.22 supports RHCOS 10.2 as a technology preview. We’ll start testing RHCOS 10 internally, but won’t update any customer clusters until RHCOS 10 is generally available for OpenShift.

What happens next

We’re currently testing OpenShift 4.22, and our plan is to have all clusters running 4.22 before the end of the year.

Want all the details? Our engineers‘ summary is in the VSHN Knowledge Base, and Red Hat’s complete OpenShift Container Platform 4.22 release notes cover everything else.

Questions? Get in touch – we’re always happy to talk OpenShift.

Simon Gerber

Simon Gerber ist ein DevOps-Ingenieur bei VSHN.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Triff Monty Widenius: ein technischer Deep Dive in MariaDB im VSHN Tower

23. Sep. 2026

VSHN ist jetzt offizieller MariaDB-Partner. Um das gebührend zu feiern und Teams, die MariaDB bereits einsetzen (oder darüber nachdenken), etwas Praxisnahes zu bieten, veranstalten wir einen technischen Workshop im VSHN Tower in Zürich, mit Michael „Monty“ Widenius, dem Schöpfer von MySQL und MariaDB, persönlich vor Ort.

Wann: Montag, 19. Oktober, 13:30 – 17:00 Uhr (MESZ)
Wo: VSHN Tower, Neugasse 6, Zürich
Plätze: Begrenzt auf 40

Das ist eine technische Hands-on-Session, kein Sales-Pitch. VSHN- und MariaDB-Engineers zeigen dir live, was MariaDB Enterprise gegenüber Community tatsächlich bietet, und wie sich das im Produktivbetrieb zeigt, live, nicht in Slides.

Das erwartet dich

  • Eine Live-Demo von MaxScale-Failover und Read-Write-Splitting, kombiniert mit Enterprise Monitor, damit du siehst, was unter der Haube wirklich passiert
  • Ein Rundgang durch MariaDB Cloud, inklusive AI Agents, Managed Deployment und wie dir BYOA und BYOC erlauben, dein eigenes Cloud-Konto oder deinen eigenen Provider einzubringen, auch souveräne und Nicht-Hyperscaler-Clouds
  • Wohin sich KI bei Datenbanken entwickelt: RAG, Vector Search und was „AI-native“ auf der Datenebene wirklich bedeutet, dazu ein Blick auf den aktuellen Stand von Open Source
  • Monty Widenius zu Migrationen, der MariaDB-Roadmap und dem breiteren Ökosystem, aus zwei Jahrzehnten Erfahrung mit dem Aufbau der Datenbank, die viele von euch bereits einsetzen

Warum das jetzt wichtig ist

MariaDB-Community-Deployments wachsen oft organisch, nützlich, bis sie geschäftskritisch werden. Dann werden Fragen zu Support, Patching, Lizenzierung und operativem Risiko schnell unumgänglich. Dieser Workshop ist für alle, die diese Systeme tatsächlich betreiben: eine Gelegenheit zu sehen, was die Lücke zwischen „es funktioniert“ und „es wird richtig betrieben“ schliesst und die Engineers direkt zu fragen, die es bauen.

Über Michael «Monty» Widenius, CTO & Co-Founder, MariaDB

Monty hat 95 Prozent des Server-Codes von MySQL geschrieben, dem Vorgänger von MariaDB. Zuvor war er Co-Founder von SkySQL und CTO der MySQL AB, bis diese an Sun Microsystems (heute Oracle) verkauft wurde. Ausserdem gründete Monty die TCX DataKonsult AB, ein schwedisches Data-Warehousing-Unternehmen. Er wurde zu einer der 100 einflussreichsten Personen im finnischen IT-Markt gewählt und widmet sich heute der Produktentwicklung, spricht an Konferenzen und gibt sein Wissen an Entwicklerinnen und Entwickler weiter.

Bring deine Fragen mit

Gibt es etwas Konkretes, das du behandelt haben möchtest, zu MaxScale, MariaDB Cloud, Migrationen oder sonst was? Lass es uns bei der Anmeldung wissen, wir sorgen dafür, dass es zur Sprache kommt. Die Session endet mit offenem Q&A, danach gibt’s einen Apéro mit genug Zeit für den fachlichen Austausch.

Jetzt anmelden für Montag, 19. Oktober, 13:30 – 17:00 Uhr im VSHN Tower, Zürich

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Rückblick Cloud Native Computing Meetup September 2026

16. Sep. 2026

Gestern fand unser Cloud Native Computing Switzerland Meetup im VSHNtower in Zürich statt – die neueste Ausgabe einer Reihe, die es nun seit fast zehn Jahren gibt, mit über 3’000 Mitgliedern und mehr als 50 Meetups.

Man merkt’s: Die Gruppe steht auf Meetup aktuell bei einer Bewertung von 4.6 aus 338 Reviews und auch gestern gab es wieder gute Gründe, warum die Leute immer wiederkommen. Nette Leute, spannende Talks und gute Gespräche beim anschliessenden Apéro.

Danke an unsere Speaker

Benjamin Koltermann (cenroq AG) – How to: securing your clusters. Ein praxisnaher Einblick, wie Kubernetes-Cluster trotz scheinbar sicherer Konfiguration angegriffen werden können – und wie du solche Sicherheitslücken erkennst und schliesst.

Slides herunterladen

Chris Bingham (CTO Switzerland, Fujitsu) – Paddelbuch – How Kiro Changed the Game. Ein Update zu paddelbuch.ch, dem serverlosen Geoinformationssystem für die Schweizer Paddelsport-Community, und wie ein unerwartetes Gespräch am AWS re:Invent 2025 dessen technisches Fundament grundlegend verändert hat.

Slides herunterladen

Christian Blättler (zeitlos.software) – A swiss, cloud-native Alternative to Vercel and Heroku. Ein tiefer Einblick in Lucity, seine Open-Source-Alternative zur Developer Experience von Vercel und Heroku, gebaut auf Standard-Kubernetes und Helm, mit „Ejectability“ als hartem Design-Kriterium.

Slides herunterladen

Drei ganz unterschiedliche Talks, alle verbunden durch denselben Cloud-Native-Spirit – und viele gute Diskussionen in den Pausen und danach beim Apéro.

Videos der Talks

Die Videos aller drei Talks findest du auf unserem YouTube-Kanal: vshn.tv – abonniere ihn, um benachrichtigt zu werden.

Nächster Termin: November-Meetup bei Open Systems

Unser nächstes CNC Meetup findet am 17. November 2026 statt, diesmal bei Open Systems AG in Zürich. Wir suchen noch Speaker – wenn du ein Cloud-Native-Projekt, Tool oder eine Story hast, die du teilen möchtest, reiche deinen Talk-Vorschlag auf cnc-meetup.ch ein. Wir freuen uns auf dich!

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event Sovereignty Tech

Open Source im grossen Massstab: Warum Schweizer Organisationen eine souveräne Datenbankstrategie brauchen

15. Sep. 2026

MariaDB ist überall. Es steckt in unzähligen Linux-Distributionen, treibt Cloud-native Plattformen an und läuft still im Hintergrund vieler Applikationen, auf die Organisationen täglich angewiesen sind. Genau diese Allgegenwart ist der Grund, warum MariaDB mehr Aufmerksamkeit verdient, nicht weniger. Wenn Community-Builds vom „reicht schon“ zum geschäftskritischen System werden und KI-Workloads zusätzliche Anforderungen an die Datenschicht stellen, summieren sich die Risiken: nicht unterstützte Versionen, ungepatchte Schwachstellen, Lizenzunklarheiten und operative Reibung.

Genau das haben wir am 1. Oktober 2026 in einem gemeinsamen Webinar mit MariaDB angepackt. VSHN-Mitgründer Aarno Aukia hat mit Jonas Schwegler von MariaDB darüber gesprochen, wie digitale Souveränität in der Praxis konkret aussieht: nicht als Buzzword, sondern als Architekturentscheid für deine Datenschicht.

Du hast es verpasst? Kein Problem, die Aufzeichnung ist jetzt online.

Jetzt Aufzeichnung ansehen.

Darum geht es in der Aufzeichnung

  • Wie eine einheitliche MariaDB-Enterprise-Architektur zusammen mit MaxScale-Zero-Downtime-Failover genau die Zuverlässigkeit liefert, die Compliance-Vorgaben verlangen
  • Warum in der Schweiz gehostete OpenShift-Operations wichtig sind, wenn du ein souveränes Fundament für KI brauchst: RAG-Pipelines, native Vektorsuche und agentische Workloads, ganz ohne Public-Cloud-Lock-in
  • Wie du transaktionale, analytische und KI-Workloads in einer einzigen Engine konsolidierst und dadurch die ETL-Komplexität eliminierst, die entsteht, wenn separate Systeme nebeneinander laufen
  • Was es bedeutet, wenn dein Datenbank-Estate nativ innerhalb der Schweiz betrieben wird, mit direktem Zugang zum MariaDB-Engineering, wenn du ihn brauchst

Warum das gerade jetzt zählt

Open-Source-Datenbanken geben Organisationen Flexibilität und Kontrolle, aber nur, wenn sie bewusst gemanagt werden. Zu oft wachsen MariaDB-Community-Deployments organisch, bis niemand mehr genau weiss, welche Version wo läuft, ob sie gepatcht ist oder was passiert, wenn sie um drei Uhr morgens ausfällt. Souveränität heisst nicht nur, wo deine Daten liegen, sondern ob du wirklich für die Zuverlässigkeit, Sicherheit und Compliance der Systeme geradestehen kannst, die sie betreiben.

Triff Monty Widenius im VSHN Tower

Am Montag, 19. Oktober 2026, 13:30 bis 17:00 Uhr laden wir gemeinsam mit MariaDB zum Technical Workshop in den VSHN Tower in Zürich ein. Mit dabei sind MariaDB-Gründer Michael „Monty“ Widenius, Jonas Schwegler, Anders Karlsson sowie Aarno Aukia und Tobias Brunner von VSHN.

Das erwartet dich:

  • Live-Demo von MaxScale und MariaDB Cloud, inklusive BYOA/BYOC
  • Community vs. Enterprise im direkten Vergleich
  • Eine Customer Case Study aus der Praxis
  • Ein Kahoot-Quiz mit Preis
  • Zum Abschluss ein Apéro mit Zeit für Fragen und Austausch

Die Plätze sind auf 40 Personen begrenzt.

Jetzt für den Workshop anmelden.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Wieder dabei: VSHN an der DINAcon 2026

10. Sep. 2026

Update, 22. September: Gleich zwei VSHNeers halten einen Talk an der DINAcon 2026 – Details zu den Vorträgen von Tobias und Aarno findest du weiter unten.

Am Mittwoch, 18. November 2026, trifft sich die Schweizer Community für digitale Nachhaltigkeit wieder im Kongresszentrum Bern, zu einer weiteren Ausgabe der DINAcon. Und dieses Jahr sind wir nicht nur dabei, wir sponsern den Apéro.

Warum wir immer wieder dabei sind

Die DINAcon ist die einzige Konferenz in der Schweiz, die sich ganz der digitalen Nachhaltigkeit widmet, organisiert vom gemeinnützigen Verein CH Open, bei dem VSHN schon lange Mitglied ist. Sie bringt Menschen aus IT, Verwaltung, Politik und Zivilgesellschaft zusammen, die sich für dieselbe Frage interessieren wie wir: Wie stellen wir sicher, dass digitale Infrastruktur langfristig den Menschen dient und nicht nur dem nächsten Quartal.

Wir waren die letzten Jahre schon dabei und genau diese Mischung ist es, die uns immer wieder zurückbringt: weniger Verkaufsgespräche, dafür echte Diskussionen über Datenschutz, Open Source und digitale Souveränität mit den Menschen, die Politik und Praxis in der Schweiz tatsächlich mitgestalten.

Zwei VSHN-Talks, direkt hintereinander

Dieses Jahr bringen wir gleich zwei Speaker auf die Bühne im Hodler Souveränität, direkt nacheinander.

Tobias Brunner – Furniture, Not Lumber: What Sausages, Furniture and Airplanes Have to Do with Digital Sovereignty (14:10-14:30, Englisch)
Tobias nähert sich einem vertrauten Problem auf ungewöhnlichem Weg: Warum sich der Einkauf von Cloud-Services in Europa und der Schweiz immer noch so anders anfühlt als bei einem Hyperscaler, obwohl darunter oft dieselbe Open-Source-Technologie steckt. Wurst, Möbel und Flugzeuge als unerwartete Lehrmeister – und eine frische Antwort auf „aber es ist doch alles Open Source, wo ist also das Problem?“

Aarno Aukia – Sovereignty Is More Than Data Residency: Eight Dimensions for Sustainable Digital Infrastructure (14:35-14:55, Deutsch)
Aarno knüpft nahtlos an Tobias an. Ausgehend vom neuen Cloud Sovereignty Framework der EU-Kommission gliedert er digitale Souveränität in acht messbare Dimensionen, von Eigentum und Rechtsprechung bis zu Transparenz der Lieferkette und Umweltauswirkungen, und macht daraus eine praktische Checkliste für Beschaffung, Architektur- und Open-Source-Entscheidungen in Schweizer Organisationen.

Zusammen ergeben die beiden Talks einen schönen Bogen: Tobias erklärt, warum die Souveränitätslücke existiert und sich so anfühlt, wie sie sich anfühlt, Aarno zeigt, wie man sie misst und schliesst.

Dieses Jahr sponsern wir den Apéro

Dieses Mal steigen wir als Apéro-Sponsor ein. Wenn die letzten Vorträge vorbei sind, geht die Konferenz in den Abend-Apéro über und die Getränke gehen auf uns. Eine kleine Geste, aber genau in solchen Momenten entstehen oft die besten Gespräche: aus einem kurzen Hallo am Gang wird schnell eine spannende Diskussion bei einem Glas Wein.

Halt Ausschau nach unserem Logo vor Ort und komm an die Bar. Falls dir dein Drink schmeckt, weisst du jetzt, wem du danken kannst. 🙂

Was dich erwartet

Die DINAcon 2026 rechnet mit über 300 Teilnehmenden und mehr als 35 Vorträgen zu vier Schwerpunktthemen: KI, öffentliche Verwaltung, Mobilität und nachhaltige Digitalisierung. Zu den Keynote-Speaker:innen gehören Gina Plat vom Open Source Program Office des niederländischen Innenministeriums, Florian Dieminger, Senior Engineering Manager bei Firefox Enterprise, und Alexander Smolianitski, Head of Open Source Products beim Zentrum Digitale Souveränität (ZenDiS).

Wenn du die Debatte um digitale Souveränität verfolgst, wird dir dieses Line-up bekannt vorkommen. Es ist dasselbe Gespräch, das sich durch die meisten Events zieht, bei denen wir dieses Jahr dabei waren, und genau die Gesellschaft, die wir suchen.

Tickets sichern

Tickets gibt es über Eventfrog.

Wir sehen uns am 18. November in Bern. Halt Ausschau nach unserem Logo und sprich uns an!

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein

Betrieb nach Stundenaufwand einkaufen: eine Wette gegen Automatisierung

5. Sep. 2026

ISG hat im Juli einen Beitrag für Sourcing-Verantwortliche veröffentlicht, in dem ein Satz steht, den man zweimal lesen sollte: Ein Vertrag über den Applikationsbetrieb könne „vertraglich lebendig und kommerziell überholt“ sein. Die Argumentation: Verträge, die heute unterschrieben werden, laufen teilweise bis 2030. Bis dahin erledigen eingebettete Agenten Arbeit, die heute als menschlicher Aufwand abgerechnet wird, und ein Vertrag, der den Wert in Aufwand misst, misst dann das Falsche.

Für den praktischen Teil ist keine KI-Prognose erforderlich. Er gilt heute schon, und er hat mit Agenten nichts zu tun:

Wer Betrieb nach Stunden bezahlt, hat jemanden beauftragt, der nicht motiviert ist zu automatisieren, weil sein Umsatz mit jeder Automatisierung sinkt.

Das ist kein Vorwurf, sondern Arithmetik. Und es lohnt sich, sie zu verstehen, bevor du einen Vertrag über drei Jahre unterschreibst.

Der stärkste Einwand zuerst

Ein guter Anbieter automatisiert ohnehin. Reputation ist real, Kunden reden miteinander, und niemand überlebt im Schweizer IT-Dienstleistungsmarkt, der Stunden verrechnet, die ein Skript erledigen sollte. Alles richtig.

Nur behandelt dieser Einwand Automatisierung als Haltung. Sie ist eine Investition, und jemand muss sie vorschlagen.

Betriebsqualität entsteht fast immer aus Vorarbeit. Ein Alarm, der nicht mehr auslöst, ein Upgrade, das ohne Aufsicht durchläuft, ein Restore, der getestet ist statt erhofft: dahinter stehen Engineering-Stunden, die investiert werden müssen, lange bevor sie sich auszahlen. Im Stundenmodell bezahlst du diese Stunden, und das ist in Ordnung. Das Problem liegt eine Stufe früher. Vorschlagen muss die Arbeit der Anbieter, und jeder solche Vorschlag kürzt seinen eigenen künftigen Umsatz. Die Frage ist deshalb nicht, ob er automatisieren will, sondern warum er es je zur Sprache bringen sollte.

Zur Sprache bringen kann es ohnehin nur er. Du siehst deine Rechnung. Er sieht, welche wiederkehrende Handarbeit dahintersteckt und welcher Teil davon ein Skript sein könnte. Ein Vorschlag, der nie gemacht wurde, hinterlässt keine Spur: keine abgelehnte Offerte, keinen Protokolleintrag, nichts, was du im Quartalsmeeting aufgreifen könntest. Die Automatisierung, die dir fehlt, ist die, von der du nie erfahren hast.

Manche Anbieter bringen es trotzdem zur Sprache: um den nächsten Auftrag zu gewinnen, weil sich Engineers nicht beliebig einstellen lassen und frei gewordene Kapazität die einzige Art zu wachsen ist, oder schlicht, weil man gute Leute nicht hält, indem man sie jahrelang dieselbe Handarbeit wiederholen lässt. Alles real. Umsatzpositiv wird Automatisierung im Stundenmodell dadurch trotzdem nicht, bestenfalls umsatzneutral, denn die eingesparten Stunden müssen anderswo verkauft werden. Und diese Antriebe sind nicht deine. Sie stehen in keinem Vertrag, und du kannst nicht nachsehen, ob sie noch wirken.

Drei Arten, Betrieb zu bezahlen

Nach Aufwand

Du bezahlst Stunden, im Vertrag meist als Time and Material bezeichnet. Das belohnt Anwesenheit und ist ehrlich darin, was es ist: Du kaufst Zugang zu Menschen.

Das Modell passt, wenn sich die Arbeit vorab nicht spezifizieren lässt. Genau darum passt es zur Beratung und nicht zu einem laufenden Service.

Pro Ticket oder pro Incident

Du bezahlst die Anzahl der Ausfälle. Das ist noch schlechter, und es kommt häufiger vor, als es sollte, weil es nach Bezahlung von Resultaten aussieht. Belohnt wird der Anbieter, der viele Tickets effizient abarbeitet. Das ist nicht derselbe Anbieter wie der, dessen Systeme nur wenige Tickets erzeugen. ISG formuliert denselben Punkt aus Kundensicht: Der stärkste Anbieter ist womöglich nicht der, der Tickets am schnellsten löst, sondern der, bei dem Störungen gar nicht erst zu Tickets werden. Ein Vertrag pro Ticket kann die beiden nicht unterscheiden und bezahlt den ersten besser.

Fixpreis pro Instanz, pro Service oder pro Service Level

Du bezahlst ein laufendes Ergebnis, kalkuliert, bevor jemand weiss, wie viel Arbeit darin steckt. Damit wechselt die Automatisierung die Seite der Bilanz. Jede verhinderte Störung, jedes automatisierte Upgrade, jeder wegoptimierte Alarm senken die Erbringungskosten des Anbieters, und die Differenz behält er. Dein Preis bewegt sich nicht. Dein Service Level auch nicht. Was sich ändert, ist das Ziel des Anbieters: weniger Störungen statt mehr verrechenbarer Stunden. Diese Ausrichtung kaufst du ein, und sie ist mehr wert als der Rabatt, den du sonst verhandelt hättest.

Das ist unser Modell für den laufenden Betrieb. Application Operations wird pro Applikation und pro Service Level Indicator verrechnet, ab CHF 800 pro Monat. Ein schlechter Monat wird also nicht zur grösseren Rechnung. Deshalb können wir den Vergleich auch offen hinschreiben: dieselbe 24×7-Abdeckung intern aufzubauen heisst vier bis sechs Engineers zu je CHF 150’000 bis 200’000 pro Jahr, und wir liefern das Äquivalent für weniger als die Kosten einer halben Vollzeitstelle. Diese Zahl ist nur möglich, weil die Automatisierung bei uns auf der Margenseite statt auf der Umsatzseite liegt.

Sei skeptisch gegenüber jedem, der behauptet, sein Modell komme ganz ohne Stundenanteil aus, uns eingeschlossen. Bei uns verläuft die Grenze entlang der Schichten, und sie wird von der Zuständigkeit, nicht von der Technik, gezogen. Plattform und Infrastruktur, also der Kubernetes-Unterbau, die Managed Data Services sowie Server, Storage und Netzwerk darunter, sind im Fixpreis gepatcht, change-managed und gesichert. Ein Plattform-Patch, der etwas kaputt macht, ist unser Problem, also spielen wir ihn ein, ohne zu fragen. Dein Container-Image bleibt deins, weil nur deine Testsuite weiss, ob dein Produkt eine aktualisierte Extension überlebt. Applikationsspezifische Engineering-Arbeit, die du zusätzlich beauftragst, etwa CI/CD, Observability oder einen Business-Continuity-Test, wird separat offeriert, ebenso die Beratung.

Der übliche Einwand darauf lautet: dann sind unsere Abhängigkeiten unser Problem. Die brauchbare Antwort ist Renovate in deiner CI/CD. Updates kommen als Pull Requests an, deine Tests sind das Tor, dein Team merged. Automatisiert von deiner Seite, ohne die Entscheidung zu verschieben.

Entscheidend ist deshalb nicht, ob ein Anbieter je nach Anzahl der Stunden verrechnet, sondern ob er den laufenden Betrieb deines Service nach Stunden verrechnet. Der Anreiz wirkt auf der fixen Schicht, und dort entsteht der grösste Teil der Arbeit.

Wie sich das von aussen zeigt

Das Preismodell deines Anbieters siehst du nicht direkt. Du siehst seine Symptome. Monatliche Change Freezes. Ein Jira-Ticket für einen DNS-Eintrag. Vier Wochen Vorlaufzeit für eine Konfigurationsänderung, die zehn Minuten dauert. Das sind die Spuren eines Prozesses, den niemand einen Grund hatte zu automatisieren, und sie kommen in der Schweizer Unternehmens-IT häufig genug vor, dass „Change Freeze vermeiden“ als Suchbegriff eingetippt wird.

Bei diesen Symptomen geht es nicht nur um fehlende Automatisierung im Hintergrund, sondern darum, wer den Knopf drücken darf. Ein Anbieter kann den DNS-Eintrag intern längst automatisiert haben und dich trotzdem ein Ticket schreiben lassen. Interne Automatisierung spart ihm Kosten. Dir Selbstbedienung zu geben, streicht eine Position von der Rechnung. Im Stundenmodell gibt es dafür keinen Grund und pro Ticket erst recht nicht.

Vorsicht ist hier bei der Kausalität geboten: Blast Radius, Funktionstrennung und Auditpflichten sind echte Gründe, eine Produktionsänderung durch eine Kontrolle zu führen. Die Frage ist nicht, ob es eine Kontrolle gibt, sondern ob sie eine Leitplanke oder eine Warteschlange ist. Eine Leitplanke ist ein Pull Request mit Policy-Prüfung, Freigabe und Audit-Trail: dein Team führt die Änderung selbst aus, und die Kontrolle greift innerhalb weniger Minuten. Eine Warteschlange ist derselbe Anspruch ohne die Vorarbeit. Leitplanken kosten den Anbieter einmal Engineering-Zeit und danach nichts. Warteschlangen verrechnen sich pro Vorgang.

Dasselbe gilt für den Change Freeze selbst. Er entsteht auch aus echtem Risikomanagement, aus Audit-Fenstern und aus dünner Testabdeckung, und ein gut geführter Anbieter kann aus guten Gründen einen haben. Die lohnende Frage ist deshalb nicht, ob es den Freeze gibt, sondern ob er kleiner wird. Ein Anbieter, dessen Ökonomie Automatisierung belohnt, kann dir sagen, dass seine manuelle Oberfläche kleiner ist als vor drei Jahren, und ungefähr um wie viel. Ein Anbieter, der nach Stunden verrechnet, hat keinen solchen Trend zu berichten und misst ihn meist gar nicht.

„Fixpreis heisst doch nur, dass gespart wird“

Die ehrliche Fassung dieses Einwands lautet: ein Anbieter, der gleich viel erhält, ob er gut oder schlecht arbeitet, driftet Richtung schlecht.

Die Antwort ist das Service-Level-Agreement. Verfügbarkeitszusagen und Service Credits bepreisen den Nachteil in der Rechnung des Anbieters selbst, sodass zu wenig Investition als Rechnung auftaucht, die er sich selbst stellt. Das ist ein echter Mechanismus, und er ist der Grund, warum der Fixpreisbetrieb überhaupt funktioniert.

Genau darum ist ein Fixpreisprojekt etwas anderes. Ein Projekt endet. Danach gibt es nichts mehr in der Hand, keine Gutschrift einzufordern, und das Betriebsmodell danach ist dein Problem. Laufender Betrieb ist die einzige Konstellation, in der der Anbieter im dritten Jahr noch dasteht, wenn die Abkürzung aus dem ersten Jahr sichtbar wird.

Wo Beratung genau richtig ist

Nichts davon heisst „keine Berater beauftragen“. Wir verkaufen selbst Beratung, zu CHF 250 pro Stunde, und tun nicht so, als wäre es anders.

Stunden sind das richtige Instrument für eine abgegrenzte Veränderung: ein Architektur-Review, eine Migration, ein Plattform-Assessment, die Ausbildung deines Teams. Der Umfang ist offen, das Mandat endet, und Aufwand zu bezahlen ist die einzige ehrliche Art, etwas zu bepreisen, dessen Form man vorher nicht kennt.

Der Fehler ist eine Kategorienverwechslung, kein Lieferantenproblem. Er besteht darin, den laufenden Betrieb als offenen Stundenstrom einzukaufen und sich im zweiten Jahr zu wundern, warum derselbe Alarm immer wieder ausgelöst wird. Plane die Veränderung als Projekt. Kaufe den Betrieb als Service. Unser eigenes Partnernetzwerk funktioniert genau nach dieser Trennung: Beratungsunternehmen konzipieren und bauen die Plattform, wir betreiben sie, weil 24/7-Betrieb innerhalb eines Beratungsgeschäfts still und leise die Beratungsmarge auffrisst.

Die Exit-Frage, die fast niemand stellt

Hier steht der schärfste Gedanke des ISG-Beitrags. Jede Exit-Klausel, die du je gelesen hast, deckt die Daten ab. ISGs Fassung geht einen Schritt weiter: Kann der Kunde die Intelligenz behalten, die im Betriebsmodell steckt?

Nach drei Jahren Betrieb ist der wertvolle Gegenstand nicht der Datenbank-Dump. Es ist alles, was über den Betrieb deiner Workload gelernt wurde: die Runbooks, die auf deinen realen Traffic getrimmten Alarmschwellen, das Upgrade-Verfahren, das den Kontakt mit deinen Extensions überlebt hat, der Restore-Test, die Infrastrukturdefinitionen. Liegt das alles im proprietären Werkzeugkasten eines Anbieters, dann berechtigt dich dein Exit-Recht zu deinen Daten und zu einem Neuanfang bei null. Du baust drei Jahre Betriebswissen neu auf und entdeckst es auf demselben Weg wie beim ersten Mal, nämlich durch eine Störung nach der anderen.

Stelle die Frage also direkt: ist die Automatisierung, die meinen Service betreibt, Open Source, und bekomme ich sie?

Bei uns ist die Antwort in guter Form, weil das Werkzeug öffentlich zugänglich ist. Project Syn und Commodore, die die Cluster konfigurieren und betreiben, AppCat, das die Managed Services selbst definiert, und K8up, das die Backups fährt, liegen offen auf GitHub, unter BSD-3-Clause und Apache-2.0. Dein Team oder ein neuer Anbieter kann nachlesen, wie dein Service betrieben wird, und dieselben Werkzeuge einsetzen, ohne uns zu fragen. Was deinen Service betreibt, ist keine Blackbox zur Miete, sondern ein GitOps-Repository, das dir gehört. Was am Vertragsende genau übergeben wird, gehört in den Vertrag und nicht in einen Blogbeitrag. Aber ein Anbieter mit proprietärer Automatisierung kann darauf keine gute Antwort geben, wie auch immer die Klausel formuliert ist.

Wo weiterhin ein Mensch entscheidet

ISGs zweite nützliche Korrektur: „Human in the Loop“ ist zu unbestimmt, um eine konkrete Bedeutung zu haben. Die bessere Frage ist, welche Entscheidungen einen benannten Menschen erfordern. Diese Frage gehört schriftlich beantwortet, bevor sich das Betriebsmodell ändert, und nicht erst, wenn die Verantwortung strittig wird.

Naheliegende Kandidaten: die Freigabe eines Releases in Produktion, die Gewährung einer Sicherheitsausnahme, die Annahme von Produktionsrisiko und die Ausrufung eines Major Incidents. Lass dir von deinem Anbieter seine nennen. Sei skeptisch gegenüber einer Floskel als Antwort und noch skeptischer gegenüber einem Anbieter, der seinen Betrieb als autonom bezeichnet. Unserer ist es nicht. Er ist automatisiert, was eine andere und besser prüfbare Aussage ist, und für eine regulierte Organisation ist es die, die ein Audit übersteht.

Was du vor der Unterschrift fragen solltest

  1. Bewegt sich mein Preis mit den Stunden, die ihr aufwendet, oder mit dem Service, den ich erhalte?
  2. Wenn ihr euren Aufwand auf meinem Konto nächstes Jahr halbiert, wer behält die Differenz?
  3. Was messt ihr ausser der Verfügbarkeit und der Wiederherstellungszeit? Irgendetwas zur Vermeidung?
  4. Bekomme ich beim Weggang meine Daten, oder meine Daten und die Automatisierung, die sie betrieben hat?
  5. Ist diese Automatisierung Open Source oder eure?
  6. Welche Entscheidungen verlangen bei euch immer einen benannten Menschen, und welche bei mir?
  7. Welche Teile davon sind ein abgegrenztes Projekt und welche sind laufender Betrieb? Werden sie unterschiedlich bepreist?
  8. Wie viel von dem, was ihr heute für mich tut, war vor drei Jahren manuell? Was hat sich geändert, und könnt ihr mir den Verlauf zeigen?
  9. Was kann mein Team ohne euch ändern, und ist diese Liste in den letzten zwei Jahren länger oder kürzer geworden?

ISG hat recht damit, dass das grösste Risiko nicht in Applikationen liegt, die sich selbst verwalten. Es liegt in einem langfristigen Vertrag, der sich nicht anpassen lässt, wenn sie es tun. Die kurzfristigere Fassung kommt ganz ohne Prognose aus: unterschreibe keinen Betriebsvertrag, der deinen Anbieter dafür bezahlt, nicht zu automatisieren.


VSHN betreibt seit 2014 Open-Source-Infrastruktur für regulierte Schweizer Organisationen. Wir sind der erste CNCF Kubernetes Certified Service Provider der Schweiz, Red Hat Premier Certified Cloud and Service Provider sowie ISO-27001-zertifiziert. Der laufende Betrieb wird pro Applikation und pro Service Level verrechnet, nicht nach Stunden. Kostenschätzung für den Betrieb deiner Applikation anfordern.


Quellen:

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Über 50 Meetups und kein Ende in Sicht: das CNC Switzerland Meetup am 15. September

5. Aug. 2026

VSHN organisiert das Cloud Native Computing Switzerland Meetup seit bald einem Jahrzehnt. Was als kleine Gruppe von Leuten begann, die Cloud Native Technologien und Kubernetes verstehen wollten, ist heute eine der grössten Cloud-Native-Communities des Landes: über 3’000 Mitglieder, mehr als 50 Meetups und ein steter Strom von Leuten, die wegen der Talks kommen und wegen der Apéros bleiben.

Die nächste Ausgabe findet am Dienstag, 15. September 2026 im VSHNtower in Zürich statt. Melde dich auf Meetup an, solange es noch Plätze hat.

Was das Meetup ist – und was nicht

Das CNC Meetup ist ein neutraler Platz für die Schweizer Tech-Community und soll kein Event für Sales-Pitches sein. Wir als VSHN oder andere Unternehmen stellen den Raum und den Apéro bereit und kümmern uns um die Logistik. Die Bühne gehört aber allen, die etwas Sinnvolles zum Betrieb in Produktion beizutragen haben. Unsere Speaker kamen bisher aus Startups, Banken und Hochschulen, von Cloud-Providern und aus Einpersonen-Open-Source-Projekten.

Der Eintritt ist frei, willkommen sind alle von komplett neu bis CNCF-Maintainern und die Talks werden aufgezeichnet und auf vshn.tv veröffentlicht, damit die Inhalte den Abend überdauern.

Drei Talks am Di. 15. September 2026

How to: securing your clusters von Benjamin Koltermann (cenroq AG) nimmt die Angreiferperspektive ein. Alle wollen sichere Kubernetes-Cluster, kaum jemand erreicht das wirklich. Benjamin zeigt, wie Cluster trotz auf dem Papier solider Konfiguration kompromittiert werden und wie du diese Lücken findest, bevor es jemand anderes tut.

Paddelbuch: How Kiro Changed the Game von Chris Bingham, CTO Switzerland bei Fujitsu, führt eine Geschichte weiter, die er 2024 hier begonnen hat: paddelbuch.ch, ein serverloses Geoinformationssystem für die Schweizer Paddelsport-Community. Dann kam Kiro und ein unerwartetes Gespräch an der re:Invent 2025 hat den technischen Unterbau komplett verändert.

A swiss, cloud-native alternative to Vercel and Heroku von Christian Blättler (zeitlos.software) geht tief in Lucity, seine Open-Source-PaaS auf Basis von Standard-Kubernetes und Helm mit einer harten Bedingung: Du kannst jederzeit aussteigen. Keine eigene Datenbank, keine CRDs, der gesamte State wird aus Kubernetes abgeleitet. Aussteigen heisst damit, ein Helm-Chart herunterzuladen, statt eine Datenmigration zu fahren.

Alle Abstracts und den detaillierten Zeitplan findest du auf der Event-Seite.

Praktisches

Wann: Dienstag, 15. September 2026, 15:00 bis 18:00 Uhr, Türöffnung um 14:30 Wo: VSHNtower, Neugasse 6, 8005 Zürich Kosten: Gratis, Apéro inklusive Anmeldung: auf Meetup

Unser Eventraum hat eine begrenzte Kapazität und die letzten Ausgaben waren jeweils recht schnell voll. Melde dich also besser heute noch an. Und falls du dich angemeldet hast und nicht erscheinen kannst, melde dich bitte wieder ab. Dann wird dein Slot für eine weitere Person auf der Warteliste frei. Die Aufzeichnungen landen danach auf vshn.tv, und wir ergänzen sie hier im Beitrag, sobald sie online sind.

Wir erwarten von allen Teilnehmenden, dass sie sich an VSHNs Conference Code of Conduct halten.

Du willst sprechen oder sponsern?

Bald ein Jahrzehnt Meetups gibt es nur, weil sich immer wieder Leute freiwillig vor den Raum stellen. Wenn du an etwas Cloud-Native arbeitest und darüber sprechen möchtest, oder wenn deine Firma eine kommende Ausgabe sponsern will: Schick uns deine Idee auf cnc-meetup.ch. Wir sind immer auf der Suche nach spannenden Talks!

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Wieder dabei: VSHN am Swiss Cloud Native Day 2026

4. Aug. 2026

Am 17. September zieht es die Schweizer Cloud Native Community wieder auf den Gurten, zur sechsten Ausgabe des Swiss Cloud Native Day. Und wie schon die vergangenen Male steht VSHN auf der Sponsorenliste. Wir lassen uns das nicht entgehen.

Warum wir immer wieder kommen

Der Cloud Native Day ist keine Verkaufsmesse. Organisiert wird er vom gemeinnützigen Verein bernerit.rocks, getragen von viel Freiwilligenarbeit und gemacht für die Leute, die diese Technologien tatsächlich in Produktion betreiben. 250 Teilnehmende, ein Tag, zwei Tracks, und eine Standseilbahn den Berg hinauf. Konferenzticket zeigen, und die Fahrt mit der Gurtenbahn ist gratis.

Genau diese Mischung aus Engineers, Gesprächen im Gang und guter Bergluft ist ein Event, den wir gerne unterstützen. Deshalb sind wir wieder als Sponsor dabei.

Besuch uns an unserem Stand

Das VSHN Team findest du an unserem Stand im Uptown-Bereich, gleich neben einem der beiden Sessionräume. Komm zwischen zwei Talks vorbei, trink einen Kaffee mit uns und erzähl uns, was du gerade baust.

Gute Gründe für einen Halt:

  • Du betreibst Kubernetes und willst dich über die unspektakulären Teile austauschen: Upgrades, Backups, Pikett, Day Two.
  • Dich interessiert, wie wir Managed Services auf Schweizer Infrastruktur betreiben, für Kundinnen und Kunden, denen wichtig ist, wo ihre Daten liegen.
  • Du willst einfach den Menschen hinter dem VSHN Logo Hallo sagen. Das freut uns natürlich ebenso. 🙂

Unser Talk

VSHN hat ausserdem einen Sponsor-Talk an der Konferenz. Zeit, Raum und Thema geben wir näher am Event bekannt. Wirf also einen Blick in den Schedule oder frag uns einfach vor Ort am Stand.

Wer die Souveränitätsdebatte in der Schweizer IT verfolgt, merkt schnell: Sie zieht sich durch das ganze diesjährige Programm. Confidential Computing, das Paradox der Cloud-Souveränität, Supply Chain Security. Ein gutes Jahr, um dieses Gespräch persönlich zu führen.

Und dann ist da noch der Abend

Der Tag endet um 17:45 Uhr mit der Closing Session, danach gibt es Drinks und Party im Pavillon bis 22:00 Uhr. Bern, ein Berg und die Cloud Native Community bei bester Laune. Wer nur wegen der Talks bleibt, verpasst die Hälfte.

Es ist auch die Frage hinter Servala, dem Sovereign App Store, den wir seit 2025 aufbauen. Wie das in der Praxis aussieht und wo es noch hakt, diskutieren wir gerne mit dir am Stand.

Ticket sichern

Tickets gibt es auf cloudnativeday.ch. Die Organisatoren bieten zudem vergünstigte Tickets für Personen an, die zur Diversität der Konferenz beitragen oder über ein tieferes Einkommen verfügen. Eine kurze Nachricht an tickets@cloudnativeday.ch genügt.

Wir sehen uns am 17. September auf dem Gurten. Halte Ausschau nach dem Uptown-Bereich, dem Kaffee und unserem Logo.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Liene am Open Source in Finance Forum London 2026

15. Juli 2026

Am Open Source in Finance Forum London 2026 bin ich auf die Bühne gegangen, um Lessons Learned aus dem Betrieb einer regulierten Digital-Asset-Plattform auf offener, cloud-nativer Infrastruktur zu teilen. Der Talk war Teil des Fluxnova & Platform Automation Tracks und fand am Donnerstag, 25. Juni 2026 statt.

Der Talk

Operating Digital Asset Platforms on Open Infrastructure: Lessons From Regulated Production

Digital-Asset-Plattformen laufen unter anspruchsvollen Bedingungen: strenge Sicherheitsanforderungen, hohe Verfügbarkeitserwartungen und wachsende regulatorische Kontrolle. Gleichzeitig müssen Engineering-Teams die Flexibilität behalten, ihre Systeme mit der Entwicklung des Digital-Asset-Ökosystems weiterzuentwickeln. Das war ein Real-Life Use Case: was bei uns funktioniert hat – und was nicht.

Hier findest du das vollständige Slide-Deck.

Die vollständige Aufzeichnung des Talks ist hier verfügbar.

Zwei Welten, die normalerweise nicht miteinander sprechen

Ich habe damit begonnen zu erklären, warum ausgerechnet ich diese Geschichte erzähle. Ich kenne dieselbe Spannung aus zwei verschiedenen Blickwinkeln: stark reguliertes Gesundheitswesen auf der einen Seite, fluide Open-Source-Ökosysteme auf der anderen. Digital-Asset-Plattformen sitzen genau an diesem Schnittpunkt – regulierte Disziplin trifft auf Open-Source-Tempo.

Warum digitale Assets eine andere operative Herausforderung sind

Drei Faktoren machen diesen Bereich anspruchsvoller als typische Cloud-native Infrastruktur:

  • Digitale Assets sind Inhaberinstrumente – Downtime bedeutet nicht nur eine schlechte SLA, sondern echtes Geld auf dem Spiel.
  • Der regulatorische Boden bewegt sich ständig: FINMA heute in der Schweiz, MiCA im Rollout across Europe.
  • Das Asset-Universum selbst wächst laufend – von Krypto über tokenisierte Wertpapiere bis zu NFTs und CBDCs – und die Plattform muss sich weiterentwickeln, ohne kaputtzugehen, was bereits live ist.

Wie es einer unserer Partner, Taurus, formuliert hat: „We run on OpenShift, they run on OpenShift – we speak the same language.“

Drei Muster, die wir in regulierter Finanzinfrastruktur sehen

Muster 1: Stabiler Kern, agiler Rand. Das klarste Beispiel ist die acrevis Bank, wo ein bewährtes, reguliertes Kernbankensystem (Finnova) unangetastet bleibt, während eine cloud-native Schicht auf APPUiO/OpenShift, gebaut mit Lagoon, am Rand schnell iteriert – verbunden über ein VPN/API-Gateway. Das ist kein Strangler-Fig-Pattern. Die Schnittstelle zwischen den beiden Schichten ist genau dort, wo Governance stattfindet. Eine Digital-Asset-Plattform ist per Design ein agiler Rand – deshalb verbinden alle 30+ Bankkunden von Taurus ihre Digital-Asset-Fähigkeiten am Rand eines stabilen Kerns.

Muster 2: Plattform-Betrieb delegieren, den eigenen Kern behalten. Jeder konzentriert sich auf seine eigene Schicht: Banken auf ihr Geschäft, Finnova auf Banking-Software, VSHN auf den Plattformbetrieb. Nachdem Taurus zu managed OpenShift gewechselt ist, waren sie in 30+ Institutionen, 9 Ländern und auf 3 Kontinenten aktiv, wobei mehrere freigewordene FTEs von der Plattformwartung in Richtung Produkt und globale Expansion umgeleitet wurden. Das Delegieren des Plattformbetriebs konzentriert auch die Compliance-Last auf jene, die sie am besten tragen können – deshalb hält VSHN ISO 27001 und ISAE 3402 Type 2 und arbeitet nach FINMA-Richtlinien.

Muster 3: Evolutionäre Migration statt Big Bang. Taurus ist nicht mit einer vollständig managed Enterprise-Plattform gestartet – sie sind in drei bewussten Etappen hineingewachsen: vanilla Kubernetes 2018, dann OKD (Community OpenShift), und heute managed Red Hat OpenShift bei VSHN. Jeder Schritt war für diese Wachstumsphase richtig. Die Lektion: Du brauchst nicht ab Tag eins den vollen managed Stack, aber du musst den Übergabepfad von Anfang an mitdenken.

Operative Praktiken, die Finanz-taugliche Infrastruktur real machen

Ein paar Praktiken haben sich in diesem Bereich als nicht verhandelbar herausgestellt: zweiwöchentliche Zero-Downtime-Upgrades als Policy, nicht als Wunschdenken – denn aufgeschobene Upgrades werden still und leise zu Security-Schulden und Compliance-Risiko. Selbstheilende Infrastruktur ist nicht nur eine Frage der Zuverlässigkeit, sondern auch ein Compliance-Prinzip. Und zertifizierte Operatoren schlagen DIY, selbst bei etwas so gut verstandenem wie Elasticsearch – ECK zu nutzen gibt dir einen sauberen Audit-Trail ohne unsupportete Anpassungen.

Die Ergebnisse sprechen für sich: Nach dem Wechsel ging Taurus von rund 12 kundenwirksamen Incidents pro Monat auf null zurück, mit einer SLA-Erreichung, die von 99 % auf 100 % gestiegen ist – getrieben durch 24/7 managed Ops, direkte Red-Hat-Eskalation und zertifizierte Operatoren.

Der ehrliche Teil: was nicht funktioniert hat

VSHN-typisch bin ich nicht bei der Erfolgsgeschichte stehen geblieben. Ein paar offene Fragen, die ich mit dem Wissen von heute härter hinterfragen würde: Kam die Migration von OKD zu managed OpenShift zu spät, und was hat diese Zwischenphase tatsächlich gekostet? Wie hältst du Konsistenz auf globaler Ebene, wenn Multi-Geo-Compliance unterschiedliche Partner in unterschiedlichen Regionen bedeutet? Wie balancierst du einen stabilen zweiwöchentlichen Plattform-Rhythmus gegen ein Ökosystem, das sich schneller bewegt als die meisten Enterprise-Software-Zyklen? Und wonach sollte ein RFP eigentlich screenen, über technische Specs hinaus – Agilität, Eskalationswege und die Bereitschaft, gemeinsam zu gestalten statt nur auszuführen?

Highlights vom Forum

Ein paar Dinge sind mir über die zwei Tage in London hinaus, über meinen eigenen Talk hinweg, in Erinnerung geblieben.

Plattformen sind wichtig, egal in welcher Branche. Ob du Infrastruktur für Finance, Healthcare oder ein ganz anderes Feld betreibst – die zugrunde liegenden Herausforderungen unterscheiden sich kaum. Sicherheit, Verfügbarkeit, Compliance und die Notwendigkeit, schnell zu bewegen ohne Production zu brechen – das sind dieselben Gespräche, egal was auf dem Briefkopf des Regulators steht.

Die Open-Source-Adoption in regulierten Branchen beschleunigt sich. Vor ein paar Jahren fühlten sich „Open Source“ und „regulierte Produktion“ noch wie zwei getrennte Welten an. Heute nicht mehr. Banken hatten früher Angst vor Open Source – heute läuft ihre kritischste Infrastruktur darauf. Der Appetit auf offene, auditierbare, vendor-unabhängige Infrastruktur im Finanzsektor wächst schnell, und die Fragen aus dem Publikum haben diesen Wandel widergespiegelt – die Leute fragen nicht mehr ob, sondern wie.

KI war überall, aber nicht alles. Wenig überraschend war KI in praktisch allen Sessions ein Thema. Aber das Forum hat mich daran erinnert, dass solides Tooling und ehrliche Gespräche zwischen Menschen immer noch das sind, was regulierte Infrastruktur tatsächlich in Production bringt. KI kann helfen, aber sie ersetzt nicht die Grundlagenarbeit.

Danke, London

Danke an die Linux Foundation und die Organisator:innen des Open Source in Finance Forum für zwei Tage mit scharfsinnigen, praxisnahen Gesprächen. Es ist ermutigend zu sehen, wie ernsthaft sich der Finanzsektor inzwischen mit Open Source und Cloud-native Ansätzen für wirklich kritische Infrastruktur auseinandersetzt.

Finanz-taugliche offene Infrastruktur bedeutet nicht, zu ersetzen, was funktioniert – sondern die richtige schnelle Schicht daneben zu bauen und die Plattform an Leute zu übergeben, die sie leben und atmen. Wenn du regulierte Plattformen betreibst und darüber nachdenkst, wie offene Infrastruktur in dieses Bild passt – lass uns reden.

Liene Luksika

Product Manager

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Open Source Presse Sovereignty

Souveräne Infrastruktur für den öffentlichen Gesundheitsdienst: Gesundheitsamt Frankfurt wird zur globalen Red Hat Success Story

7. Juli 2026

Eine deutsche Public-Sector-Geschichte mit globaler Reichweite

Wir haben grossartige Neuigkeiten: Red Hat hat eine neue globale Customer Success Story veröffentlicht – mit dem Gesundheitsamt Frankfurt am Main und VSHN als Platform-Engineering-Partner dahinter.

Nachdem HIN (Health Info Net) Anfang des Jahres zur globalen Red Hat Success Story wurde, ist dies nun bereits das zweite Mal innerhalb weniger Monate, dass ein VSHN-Kundenprojekt auf der globalen Bühne von Red Hat ausgezeichnet wird. Und wieder steht ein Thema im Zentrum: digitale Souveränität im Gesundheitswesen.

Diese Geschichte fügt aber eine neue Dimension hinzu: Sie zeigt, wie souveräne, cloud-native Open-Source-Infrastruktur im öffentlichen Sektor funktioniert – gebaut für eines der grössten Gesundheitsämter Deutschlands, finanziert mit EU-Mitteln und offen publiziert, damit andere sie ebenfalls nutzen können.

Warum dieses Projekt wichtig ist

Das Gesundheitsamt Frankfurt am Main ist eines der grössten Gesundheitsämter Deutschlands, mit 300 Mitarbeitenden in 8 Abteilungen. Sein Auftrag reicht von Schuleingangsuntersuchungen und Impfprogrammen über Hygieneinspektionen bis hin zu gesundheitlichen Notlagen.

Während der COVID-19-Pandemie wurde ein strukturelles Problem schmerzhaft sichtbar: Die 25 Gesundheitsämter im Bundesland Hessen arbeiteten mit heterogenen Systemen, Workflows und Konfigurationen. Der Datenaustausch zwischen den Organisationen war schwierig – und machte die Nachverfolgung von Infektionsketten komplizierter als nötig.

Die Antwort war kein weiteres isoliertes IT-Projekt. Mit Unterstützung des Gesundheitsamts Frankfurt am Main sicherte sich das hessische Gesundheitsministerium 24 Millionen Euro an EU-Fördermitteln, um die digitale Infrastruktur des öffentlichen Gesundheitsdienstes in Hessen zu modernisieren.

Das Ergebnis ist GA-Lotse: eine Open-Source-Plattform, entwickelt von der cronn GmbH und von VSHN als Managed Service auf Red Hat OpenShift betrieben.

Föderiert by Design: Souveränität bis auf Kommunalebene

Was GA-Lotse besonders macht, ist die Architektur. Statt 25 verschiedenen Behörden eine einheitliche Arbeitsweise aufzuzwingen, hat das Team ein föderiertes, mandantenfähiges System entworfen.

Jeder Landkreis in Hessen betreibt seine eigene, anpassbare Instanz der Plattform – mit voller Hoheit über die eigenen Anwendungen und sensiblen Daten. Private oder nicht autorisierte Daten werden nicht zwischen den Abteilungen geteilt. Gleichzeitig kann das Land anonymisierte, aggregierte Auswertungen für evidenzbasierte Entscheidungen erstellen.

„Wir verarbeiten die privatesten und sensibelsten Daten der Menschen – ihre individuellen Gesundheitsdaten. Das erfordert die strikte Einhaltung von Datenschutzgesetzen, deshalb haben wir sehr hohe Anforderungen an die Datensicherheit“,

sagt Bianca Kastl, Product Owner beim Gesundheitsamt Frankfurt am Main.

Die Plattform wurde mit einer Zero-Trust-Architektur und modularem Design gebaut:

  • 21 Module und 8 separate PostgreSQL-Datenbanken aus dem VSHN Marketplace
  • Redis für Caching und Keycloak für Identity und Access Management
  • Ein Service Mesh mit Standardanwendungen für Benutzerverwaltung, Kommunikation und Kalender
  • Passkeys statt Passwörtern und nicht rückverfolgbare IDs gegen unberechtigte Datenzugriffe
  • Hosting bei Exoscale, einem europäischen Cloud-Provider, für DSGVO-Konformität und Datensouveränität

Persönliche IDs sind von den medizinischen Daten getrennt, und alle für Auswertungen erhobenen Daten werden anonymisiert und verschlüsselt. Wer sich impfen lässt, kann sicher sein, dass das Team nicht die komplette Krankengeschichte einsehen kann.

Von der Ausschreibung in die Produktion in 3 Monaten

IT-Projekte im öffentlichen Sektor sind nicht gerade für ihr Tempo berühmt. Dieses hier war anders.

Der Zuschlag erfolgte im August 2024 – und die Plattform ging nur 3 Monate später live. Die Partnerschaft zwischen VSHN, Red Hat und Exoscale ermöglichte es dem Team, die Plattform in wenigen Tagen bereitzustellen und die verbleibende Zeit auf Deployment, Integration und Testing zu verwenden. Dieses Tempo war nicht nur nice-to-have: Die Lieferung innerhalb eines Jahres war eine harte Bedingung für die EU-Förderung.

„GA-Lotse und VSHN teilen ein gemeinsames Fundament: Offenheit, Transparenz, Zusammenarbeit, Open Source, Cloud-native-Technologie und höchste regulatorische Standards. Ich bin stolz, die digitale Transformation eines so wichtigen Teils unserer Gesellschaft gemeinsam mit unseren Partnern zu unterstützen.“

sagt Aarno Aukia, Co-Founder von VSHN.

Ein entscheidender Faktor: Die Gesundheitsämter mussten nicht selbst zu Kubernetes-Expertinnen und -Experten werden. VSHN betreibt die Plattform und übernimmt die Day-2-Operations, damit sich die Teams auf ihre eigentliche Arbeit konzentrieren können.

„Dank VSHN und Red Hat müssen wir unsere Teams nicht für komplexes Kubernetes-Infrastrukturmanagement ausbilden. Sie können sich auf ihre Abteilungen konzentrieren und Wartung und Weiterentwicklung den Experten überlassen.“

sagt Bianca Kastl.

Echte Wirkung für die öffentliche Gesundheit

GA-Lotse ist kein Pilotprojekt. Die Plattform ist produktiv und wird heute in mehreren Regionen Hessens genutzt.

Anwendungen wie das Modul für Schuleingangsuntersuchungen ersetzen papierbasierte Prozesse und helfen, 7’000 Untersuchungen und 45’000 zahnärztliche Screenings pro Jahr effizienter durchzuführen. Eltern können Schuleingangsuntersuchungen digital buchen. Hygieneinspektionen von klinischen und gewerblichen Einrichtungen werden auf der Plattform geplant und nachverfolgt.

„Statt zu verändern, wie Menschen arbeiten, haben wir eine Plattform gebaut, die für sie arbeitet. Diese praxisnahe Lösung bildet die Realität des öffentlichen Gesundheitswesens ab und macht es effizienter.“

sagt Kastl.

Und ein Aspekt ist aus unserer Sicht besonders bemerkenswert: Die Lösung wurde als Open Source veröffentlicht, unter anderem auf openCode.de – eine Premiere für den öffentlichen Gesundheitsdienst in Deutschland. Andere Gesundheitsämter können von derselben Plattform profitieren, ohne bei null anzufangen.

„Gemeinsam setzen wir neue Massstäbe für Innovation, digitale Transformation und digitale Souveränität im öffentlichen Gesundheitswesen“

sagt Prof. Dr. Peter Tinnermann, Leiter des Gesundheitsamts Frankfurt am Main.

Was das über Hessen hinaus bedeutet

Für uns bestätigt diese Success Story ein Muster, das wir in ganz Europa beobachten: Digitale Souveränität bewegt sich von der Theorie in die Praxis – und der öffentliche Sektor treibt einige der ambitioniertesten Projekte voran.

GA-Lotse zeigt, dass souveräne Infrastruktur für den öffentlichen Sektor heute machbar ist:

  • Open Source statt proprietärem Lock-in
  • Europäisches Cloud-Hosting statt Abhängigkeit von Hyperscalern
  • Föderierte Datenhoheit statt zentraler Datensilos
  • Managed Platform Operations statt knapper Kubernetes-Expertise in jeder einzelnen Behörde
  • Offen publizierter Code statt doppelt ausgegebener öffentlicher Gelder

Zusammen mit der HIN-Story aus der Schweiz zeigt das: Souveräne, cloud-native Infrastruktur im Gesundheitswesen ist kein Nischenexperiment mehr. Sie läuft produktiv, in zwei Ländern, und leistet jeden Tag einen Dienst für die Bürgerinnen und Bürger.

Ein grosses Dankeschön an das Gesundheitsamt Frankfurt am Main, die cronn GmbH, Red Hat und Exoscale für die hervorragende Zusammenarbeit – und an alle VSHNeers, die dieses Projekt möglich gemacht haben.

Case Study herunterladen

Public Health Authority of Frankfurt standardizes on Red Hat with VSHN (Englisch)

Mehr erfahren

👉 Red Hat Case Study

👉 HIN: Digital Sovereignty Made in Switzerland

👉 Was ist digitale Souveränität?

👉 VSHN Gesundheitsamt Frankfurt Success Story

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Sovereignty

Warum „Buy European“ nicht reicht: Was die Schweiz bei der digitalen Souveränität wirklich tun sollte

29. Juni 2026

Als die EU ihr Cloud Sovereignty Framework veröffentlichte und im April 2026 Cloud-Aufträge über 180 Millionen Euro an vier europäische Anbieter vergab, sah das nach einem klaren Sieg für die digitale Souveränität aus. Doch am Swiss Software Festival 2026 in Basel lieferte die UCL-Ökonomin Cecilia Rikap eine schärfere Analyse: Geografische Souveränität ist notwendig, aber nicht ausreichend. Das tiefere Problem nennt sie Epistemic Capture. „Epistemisch“ bedeutet: das Wissen und die Kategorien betreffend, mit denen wir die Welt ordnen. Die Idee ist einfach: Der Fuchs hat den Hühnerstall mitentworfen. Hyperscaler prägen die Regeln, Definitionen und Kategorien des Souveränitätsspiels, selbst wenn sie scheinbar verlieren.

Ich sprach am selben Anlass über die Engineering-Vorteile der Schweiz im KI-Zeitalter und möchte Rikaps akademisches Argument mit dem verbinden, was ich täglich beim Betrieb von Infrastruktur für regulierte Schweizer Unternehmen erlebe: die Lücke zwischen Souveränität als politischem Ziel und Souveränität als Engineering-Praxis.

Das Souveränitäts-Framework funktioniert. Einigermassen.

Das SEAL-Framework der EU bewertete Anbieter in acht Dimensionen. Drei rein europäische Anbieter erreichten SEAL-3. Proximus, dessen Konsortium Google Cloud (über das S3NS-Joint-Venture mit Thales) einschloss, erreichte nur SEAL-2. Das Framework bestrafte die Beteiligung von Hyperscalern korrekt. Wir haben das Framework analysiert und VSHN daran gemessen, eine nützliche Übung für jeden Anbieter, der Souveränität ernst meint.

Das Wichtigste an diesem Framework sind nicht die Ergebnisse selbst. Entscheidend ist, dass Souveränität nicht mehr eine binäre, emotionale Debatte ist („Sind wir souverän oder nicht?“). Sie ist jetzt messbar über acht Dimensionen, die man diskutieren, planen und priorisieren kann. Das verändert das Gespräch von Ideologie zu Engineering.

Aber Rikaps Argument lautet: Microsoft, Google und Amazon waren auf dieses Framework vorbereitet, bevor es veröffentlicht wurde. Sie hatten bereits Joint Ventures, lokale Tochtergesellschaften und Partnerschaftsmodelle aufgebaut, die darauf ausgelegt waren, bei Souveränitätsbewertungen gut abzuschneiden. Das Framework hat sie nicht überrascht. Sie haben die Rahmenbedingungen mitgestaltet, in denen es geschrieben wurde.

Das ist Epistemic Capture: Wenn die regulierten Unternehmen die Kategorien, Definitionen und Prioritäten der Regulierung selbst beeinflussen. Das Ergebnis sind Souveränitäts-Frameworks, die die Symptome behandeln (Datenstandort, Rechtsordnung), ohne die Grundursache anzugehen (die Kontrolle über den Technologie-Stack und seine Entwicklung).

Wie Epistemic Capture in der Praxis aussieht

Google, Amazon und Microsoft kontrollieren zusammen rund 65% des globalen Cloud-Marktes, dazu die Unterseekabel, die ihn verbinden. Rikap beschrieb KI als „Trojanisches Pferd“: Organisationen nutzen KI-Dienste, die auf Hyperscaler-Infrastruktur laufen, und schaffen Abhängigkeiten, die tiefer gehen als der Speicherort der Daten:

  • Black-Box-Modelle: Man nutzt die API, ohne Zugang zu den Modellgewichten, Trainingsdaten oder Architekturentscheidungen zu haben. Die eigene KI-Strategie hängt von einem Anbieter ab, den man nicht prüfen kann.
  • Ökosystem-Lock-in: Sobald Datenpipeline, ML-Training und Inferenz auf dem Stack eines Hyperscalers laufen, bedeutet ein Wechsel Neuaufbau, nicht bloss Migration.
  • Datengravitation: KI-Modelle brauchen Daten, Daten ziehen Services an, Services ziehen mehr Daten an. Dieser selbstverstärkende Kreislauf macht KI zu einer der grössten zentralisierenden Kräfte unserer Branche. Die Daten sind schon da, das Ökosystem der Tools ist schon da, und jede neue Integration macht die nächste schwerer anderswo zu platzieren.
  • Standards-Capture: Hyperscaler finanzieren und besetzen die Normierungsgremien, die Cloud-Native-Computing definieren. Die „neutralen“ Standards beinhalten oft Annahmen, die ihre Architekturen begünstigen.

Ein europäisches Unternehmen, das Mistral AI auf Azure betreibt, ist nicht souverän, nur weil Mistral französisch ist. Das KI-Modell sitzt in einem von Microsoft kontrollierten Ökosystem, unterliegt US-Recht und ist von Nvidias Hardware-Lieferketten abhängig.

„Buy European“ und „Buy Swiss“ greifen zu kurz

Rikap warnte ausdrücklich davor, US-Big-Tech durch europäische Big-Tech zu ersetzen. Dass SAP, Siemens und Mistral europäisch sind, macht sie noch nicht zu souveränen Alternativen. Sie betreiben dieselben Geschäftsmodelle (Plattformdominanz, proprietärer Lock-in, Rentenextraktion), einfach unter einer anderen Flagge.

Dieselbe Logik gilt für „Buy Swiss“. Die Schweiz hat echte strukturelle Vorteile für die Souveränität (dazu weiter unten mehr), aber eine Schweizer Flagge auf der Rechnung ist keine Souveränität. Ein Schweizer Unternehmen, das Azure mit lokalem Support weiterverkauft, bietet keine operative Unabhängigkeit. Ein Schweizer SaaS-Anbieter auf AWS eu-central-1 schützt nicht vor dem CLOUD Act. Die Frage ist nicht, wo der Anbieter seinen Hauptsitz hat. Die Frage ist, ob man den Anbieter wechseln kann, ohne die Technologie zu wechseln.

Chinas Ansatz (staatlich orchestrierte KI-Industrialisierung) ist ebenfalls kein Vorbild. Wie Rikap feststellte, „reproduziert er die Logiken US-geführter Raubtier-Ökosysteme, ohne sie in Frage zu stellen.“ Techno-Nationalismus ist keine Souveränität, egal ob die Nation die USA, China oder die Schweiz ist.

Was echte Souveränität erfordert

Wenn geografische Herkunft und nationale Champions nicht ausreichen, wie sieht echte Souveränität dann aus? Basierend auf Rikaps Analyse und meiner Erfahrung mit dem Betrieb von Produktionsinfrastruktur für Schweizer Banken, Gesundheitsdienstleister und Behörden sind drei Bedingungen entscheidend:

1. Open-Source-Grundlagen

Open Source ist das einzige Technologiemodell, bei dem man überprüfen kann, was die Software tut, sie an die eigenen Bedürfnisse anpassen und den Betreiber wechseln kann, ohne alles neu aufzubauen. Die Umfrage der Linux Foundation von 2025 ergab, dass 83% der Unternehmen Open Source als wertvoll für ihre Zukunft ansehen. Thomas Wüst (CEO von ti&m), ebenfalls Redner am SSF 2026, beschrieb, wie ti&m die eigenen Unternehmenssysteme auf einen Open-Source-Stack migriert hat, nachdem die Kosten durch Vendor-Lock-in eskalierten.

Das ist kein Idealismus. Es ist Risikomanagement. Als HashiCorp die Terraform-Lizenz änderte und an IBM verkaufte, spaltete die Community innerhalb von Monaten OpenTofu unter der Linux Foundation ab. Als Atlassian Jira-Kunden von Server über Data Center zu Cloud zwang, berichtete Wüst, dass die Lizenzkosten von ti&m zwischen 2023 und 2027 um rund 900% stiegen. Open Source macht solche erzwungenen Migrationen strukturell unmöglich.

EU und Schweiz bewegen sich beide in Richtung Open Source als Staatspolitik. Der Schweizer Ständerat hat im Juni 2026 eine Motion für ein Impulsprogramm zur digitalen Souveränität angenommen. Die Schweiz hat mit EMBAG bereits seit 2024 ein Bundesgesetz, das die Verwaltung verpflichtet, sämtliche Eigenentwicklungen als Open Source zu veröffentlichen, sofern kein spezifischer Grund dagegen spricht. Die Open-Source-Strategie der EU positioniert Open Source als zentral für die technologische Souveränität. Das sind keine Nischenpositionen. Es ist ein sich formierender Konsens.

2. Operative Kontrolle statt nur Datenstandort

Das EU-Framework trifft mit der Dimension „Operational Sovereignty“ (SOV-4) teilweise ins Schwarze. Aber die gängige Marktinterpretation lautet „europäisches Personal, das in europäischen Rechenzentren arbeitet.“ Das greift zu kurz.

Operative Kontrolle bedeutet: Kann man den Betreiber wechseln, ohne die Technologie zu wechseln? Wenn das verwaltete Kubernetes auf Red Hat OpenShift oder Upstream-Kubernetes mit dokumentierten APIs läuft, kann man den Betreiber wechseln. Wenn es auf Amazon EKS, Azure AKS oder Google GKE läuft, nutzt man eine proprietäre Steuerungsebene mit cloudspezifischen Integrationen, die nicht übertragbar sind. Die Kubernetes-API ist portabel. Die verwalteten Wrapper darum herum sind es nicht.

Das ist kein theoretisches Problem. Wer der FINMA-Regulierung untersteht, muss einen dokumentierten Prozess vorweisen, um innerhalb von 12 Monaten von jedem Anbieter weg migrieren zu können, sonst ist man nicht compliant. Portabilität ist für regulierte Schweizer Organisationen keine Option. Es ist eine gesetzliche Anforderung.

Das meine ich mit „Wer kontrolliert die Laufzeitumgebung?“, die Frage, die ich in meiner SSF-Keynote gestellt habe. KI macht die Codegenerierung nahezu kostenlos. Die Grenzkosten der Softwareentwicklung sinken rapide. Aber die Komplexität hat sich verschoben: hin zu Architektur, Plattformen und Sicherheit. Die Ebene, die über die eigene Unabhängigkeit entscheidet, ist nicht mehr der Anwendungscode. Es ist die Plattform darunter.

Die Schweiz hat hier einen strukturellen Vorteil. Die Kombination aus regulierten Branchen (die hybride Architekturen erfordern), Open-Source-Kompetenz und vertrauenswürdigen regionalen Cloud-Anbietern (Cloudscale, Exoscale) schafft ein praxistaugliches Multi-Cloud-Ökosystem, in dem operative Portabilität der Standard ist. Wir bauen diese Art von Infrastruktur bei VSHN seit 2014, nicht weil Souveränität modisch war, sondern weil unsere Kunden in Banken, Gesundheitswesen und Verwaltung sie brauchten.

3. Governance statt Geografie

Rikaps stärkstes Argument: Souveränität ist eine Frage der Governance und der demokratischen Rechenschaftspflicht, nicht des Territoriums oder der Nationalität. Wer bestimmt die Technologie-Roadmap? Wer hat Zugriff auf die Daten? Welche Möglichkeiten haben die Nutzer, wenn sich die Plattform ändert?

Für Organisationen, die Cloud-Anbieter evaluieren, übersetzt sich das in konkrete Fragen:

  • Ist der Quellcode des Anbieters prüfbar?
  • Kann man denselben Stack mit einem anderen Betreiber nutzen?
  • Was passiert mit den eigenen Daten und dem Betrieb, wenn der Anbieter übernommen wird?
  • Werden Preise und Konditionen von einem stabilen Rechtsrahmen (Schweizer Recht, EU-Recht) bestimmt oder vom Quartalsdruck eines Anbieters?

Das Schweizer Recht liefert auf mehrere dieser Fragen starke Antworten: kein CLOUD Act, EU-Angemessenheitsbeschluss für den Datenschutz, stabiles Handelsrecht. Aber Schweizer Recht allein reicht nicht, wenn der darunter liegende Technologie-Stack von einem US-Unternehmen kontrolliert wird. Governance erfordert sowohl rechtliche als auch technische Unabhängigkeit.

Die Schweizer Chance und die Schweizer Lücke

Die Schweiz ist gut positioniert, aber Positionierung ist nicht dasselbe wie Handeln. Am SSF 2026 zog sich ein Thema durch alle Keynotes: Die Schweizer IT versteht Souveränität, hat aber souveräne Alternativen noch nicht schnell genug skaliert.

Die Zahlen sprechen für sich. Über 70% der Schweizer Unternehmen investieren weniger als 5% ihres IT-Budgets in KI (ti&m/HSLU AI Maturity Study 2026). Gleichzeitig berichtete Penny Schiffer von UBS, dass die Bank bereits über 300 KI-Anwendungsfälle produktiv betreibt und ihren ersten Chief AI Officer ernannt hat. Die Kluft zwischen den Vorreitern und der Mehrheit wächst, und damit das Risiko, dass die Mehrheit standardmässig von Hyperscaler-KI-Diensten abhängig wird, statt sich bewusst dafür zu entscheiden.

Der nächste praktische Schritt ist nicht, auf Regulierung oder nationale Champions zu warten. Es geht darum, auf dem aufzubauen, was bereits existiert: Open-Source-Software, in der Schweiz betriebene Infrastruktur und Engineering-Teams mit der Erfahrung, Plattformen zu entwerfen, die kein einzelner Anbieter kontrolliert.

Die Schweiz baut seit Jahrhunderten Präzisionsmaschinen. Die nächste Maschine, die es zu bauen gilt, ist die souveräne Plattform: Open Source, Multi-Cloud, operativ portabel und dem Schweizer Recht unterstellt. Die Komponenten existieren. Das Engineering-Talent existiert. Was fehlt, ist die Entscheidung, sie zusammenzubauen.

Die Frage ist nicht, welche Cloud man wählt. Die Frage ist, ob die eigene Architektur einem diese Wahl auch morgen noch lässt. Wer abhängig ist, muss um Erlaubnis fragen. Wer souverän ist, kann liefern.


VSHN betreibt seit 2014 Open-Source-Infrastruktur für regulierte Schweizer Organisationen. Wir sind der erste CNCF Kubernetes Certified Service Provider der Schweiz, Red Hat Premier Partner und Linux Foundation Silver Member. Unsere Managed Services laufen auf Schweizer Cloud-Anbietern, unter Schweizer Recht, auf Open-Source-Basis und ohne Hyperscaler-Abhängigkeit. Vereinbare ein Beratungsgespräch, um eure Souveränitätsanforderungen zu besprechen.

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event Sovereignty

Switch Cloud Forward Forum Day 2026 Recap

Sovereign Cloud, konkrete Use Cases und ein Saal voller Entscheidungsträger aus der Schweizer Hochschulwelt

Am 23. Juni war VSHN am Cloud Forward Forum Day 2026 in Bern – einer Veranstaltung von Switch für IT-Verantwortliche, Beschaffungsspezialistinnen und Strateginnen aus Schweizer Hochschulen und Forschungsinstitutionen. Das Thema: Wie lässt sich Public Cloud für die Schweizer Hochschulwelt nutzbar machen – ohne auf Souveränität, Compliance oder Flexibilität zu verzichten?

VSHN war gleich zweimal präsent: mit einem Use Case aus dem Gesundheitssektor und mit einem Elevator Pitch auf der Bühne. Ein Rückblick auf den Tag.

Das grosse Bild: KI, Souveränität und der Druck zur Modernisierung

Den Auftakt machte eine Keynote von Marc Stampfli (NVIDIA), der den aktuellen Moment als industrielle Revolution durch Intelligenz beschrieb – und die Frage aufwarf, was Souveränität bedeutet, wenn KI-Infrastruktur in den Händen weniger globaler Anbieter konzentriert ist. Das setzte den Ton für alles, was folgte: Institutionen wollen schnell vorankommen – aber nicht auf Kosten der Kontrolle über ihre Daten.

Elevator pitches: klare Botschaften, knappe Zeit

In der Elevator-Pitch-Session am Vormittag hatten die Sprecherinnen und Sprecher je drei Minuten Zeit, ihren Standpunkt zu vertreten. VSHN’s Aarno Aukia trat mit einem einzigen, pointierten Argument an: Souveränität ist keine Philosophie mehr – sie ist ein Beschaffungskriterium mit echtem Preisschild.

Sein Ankerbeispiel: Ein EUR-180-Mio.-Cloud-Auftrag der EU-Kommission vom April 2026, bewertet anhand von acht Souveränitätsdimensionen – darunter Supply Chain (20%), Strategic (15%), Operational (15%) und Technology (15%) mit den höchsten Gewichtungen. Die Konsequenz in der Praxis: Das Joint Venture von Thales und Google kostete Proximus eine volle SEAL-Stufe gegenüber rein europäischen Mitbewerbern. Souveränität schlägt sich heute direkt in gewonnenen oder verlorenen Aufträgen nieder.

VSHN bewertet sich selbst mit SEAL-3 – demselben Niveau wie die drei stärksten Gewinner in dieser EU-Ausschreibung. Für ein Publikum aus Schweizer Hochschulen, das gerade über Cloud-Beschaffung nachdenkt, kam diese Botschaft zum richtigen Zeitpunkt.

HIN: Sovereign Cloud für Gesundheitsdaten, gebaut auf Exoscale und VSHN

Der Use-Case-Vortrag am Vormittag, der am stärksten mit VSHNs Arbeit resonierte, kam von Mohammad Alavi von Health Info Net (HIN). HIN ist einer der grössten Anbieter im Schweizer Gesundheitssektor. Mohammad schilderte eine Herausforderung, die viele Institutionen kennen: Wie baut man eine moderne, skalierbare Cloud-Plattform für sensible Daten, wenn regulatorische Vorgaben noch lückenhaft sind und der Einsatz hoch ist?

HINs Antwort war, die Regulierungslücke selbst zu schliessen – mit eigenen Grundsätzen für Sicherheit und Datenschutz, und einer souveränen Cloud-Plattform, die gemeinsam mit den Schweizer Partnern Exoscale und VSHN aufgebaut wurde. Das Ergebnis: eine Plattform, die nicht nur HINs eigene Services sicher betreibt, sondern auch HIN-Community-Mitgliedern ermöglicht, eigene Anwendungen auf derselben Infrastruktur zu betreiben.

Ein starkes Beispiel dafür, was Platform Engineering in regulierten Branchen leisten kann: nicht nur Compliance, sondern echte Befähigung anderer, darauf aufzubauen. Die ganze Geschichte findest du in unserer HIN Success Story.

Weitere Use Cases des Tages

Die Nachmittagssessions brachten weitere Perspektiven. AWS, Sparkle und Netcloud beleuchteten Privacy und Compliance als Enabler von Souveränität. SoftwareOne plädierte für Google Workspace als sinnvolle Ergänzung zu Microsoft 365 in Hochschulumgebungen. Und in der Switch-Cloud-Session berichteten FHNW und Swiss Learning Hub von ihren Erfahrungen beim Deployment von Evento – einem Campus-Management-System, das an vielen Schweizer Fachhochschulen eingesetzt wird – in die Switch Cloud, inklusive Stolpersteine und Early-Adopter-Lektionen.

Bechtle präsentierte ausserdem ein KI-gestütztes Datenzugriffsprojekt der Universitären Altersmedizin FELIX PLATTER in Basel: Mit Azure OpenAI Services und Microsoft Fabric können Forschende klinische Daten per natürlicher Sprache abfragen – ein Beispiel dafür, wie KI ihren Weg in sehr konkrete, regulierte Workflows findet.

Was wir mitnehmen

Cloud Forward ist ein fokussiertes Event – keine grosse Messe, sondern ein Raum, in dem Schweizer Hochschulinstitutionen echte Entscheidungen miteinander abgleichen. Das wiederkehrende Thema über alle Sessions hinweg: Souveränität ist kein Compliance-Haken, der abgehakt wird – sie ist ein Designprinzip, das Architektur, Partnerwahl und langfristige Flexibilität prägt.

Genau das ist die Art von Platform-Thinking, die VSHN zu Kunden wie HIN bringt – und das Gespräch, das wir mit Schweizer Institutionen weiterführen wollen, die vor denselben Herausforderungen stehen.

Neugierig, wie eine souveräne, Kubernetes-basierte Cloud-Plattform für deine Organisation aussehen könnte? Lass uns reden.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Swiss Software Festival Basel 2026 Recap

25. Juni 2026

Das Swiss Software Festival war zurück in Basel am 24.06.2026 – und die zweite Ausgabe hat alles gehalten, was die erste versprochen hat und noch vieles mehr. Rund 650 Personen versammelten sich im uptownBasel in Arlesheim, um über Software, Plattformen und die Kräfte zu sprechen, die unsere Branche gerade grundlegend verändern: AI und Sovereignty. VSHN war wieder als Matterhorn-Sponsor dabei und hat nicht nur teilgenommen, sondern auch das Programm wieder aktiv mitgestaltet.

Ein Festival, das seinen Rhythmus gefunden hat

Die zweite Ausgabe eines Events ist immer ein Lackmustest. Das erste Jahr läuft auf Begeisterung. Das zweite zeigt, ob dahinter wirklich etwas steckt. Das Swiss Software Festival 2026 hat diese Frage klar beantwortet: mehr Teilnehmende, mehr Energie und ein Programm, das sich wirklich durchdacht anfühlt. Im uptownBasel in Arlesheim war vom ersten Moment an Leben. Mit Gesprächen in den Gängen, die bis weit in den Abend hinein andauerten.

Draussen war es ungewöhnlich heiss für einen Juni in Basel. Wer sich abkühlen wollte, wusste, wo er hinmusste: der gemeinsame Stand von VSHN und Red Hat war der erfrischendste Ort im Gebäude. Ein guter Grund, vorbeizuschauen, ins Gespräch zu kommen und herauszufinden, was wir gerade bauen.

Aarno auf der Hauptbühne: digitale Souveränität ist keine Option

VSHN Gründer Aarno Aukia trat in der Plenar-Session auf, um für digitale Souveränität zu plädieren – nicht als Compliance-Pflicht, sondern als echte architektonische Entscheidung, vor der heute jedes Engineering-Team steht. In einer Welt, in der KI-Organisationen in Richtung Bequemlichkeit und Geschwindigkeit zieht, war Aarnos Keynote ein nüchterner Gegenpol: Die Frage, wo deine Plattform läuft, wer sie kontrolliert und ob du ihr vertrauen kannst, ist längst keine rein rechtliche Frage mehr. Sie ist eine Engineering-Frage.

Aarno war ausserdem Teilnehmer einer Panel-Diskussion, in der es noch etwas tiefer ging: um die Spannungsfelder zwischen offenen Ökosystemen und souveräner Infrastruktur. Die Fragen waren pointiert – ein Zeichen dafür, dass das Thema für die meisten Teams im Saal längst nicht mehr abstrakt ist.

Schau dir Aarno’s Keynote an:

Tech Track 2: Platform Engineering unter Druck

VSHN’s Markus Speth leitete Tech Track 2 – Platform Engineering and Software Architecture – gemeinsam mit den Co-Chairs Andreas von ti&m und Florian von Abacus Research. Der Track umfasste zwei vollständige Sessions zu den zwei Kräften, die Platform Engineering gerade in entgegengesetzte Richtungen ziehen: KI und Souveränität.

KI will Geschwindigkeit und Flexibilität. Digitale Souveränität will Kontrolle und Transparenz. Deine Plattform steckt mittendrin.

Die Morgen-Session widmete sich KI-nativen Plattformen: Was bedeutet es, wenn Software sich selbst umschreibt, wenn Agents Zugriff auf Infrastruktur erhalten, und wo wächst die Kompetenzlücke still und leise? Eficode, White Duck, Noser Engineering und Adobe brachten praxisnahe Erfahrungen aus Systemen mit, bei denen KI keine Funktion ist, sondern ein Teil des Fundaments. Beide Sessions schlossen mit offenen Diskussionsrunden, die das Publikum intensiv genutzt hat. An dieser Stelle nochmals ein Dankeschön an alle Teilnehmer und die vielen spannenden Fragen!

Der Nachmittag stellte Souveränität und Offenheit als echte architektonische Entscheidungen in den Mittelpunkt. Den Auftakt machte VSHN’s Tobias Brunner mit einem Talk, den man so schnell nicht vergisst: „Furniture, not lumber: what sausages, furniture and airplanes have to do with digital sovereignty.“ Die Analogie traf genau ins Ziel – eine einprägsame und überraschend präzise Art zu erklären, warum nicht alle Sovereignty-Versprechen gleich viel wert sind, und was es wirklich bedeutet, auf einer Infrastruktur aufzubauen, der man vertrauen kann. Speakers von PHOENIQS, Abacus Research und ti&m ergänzten die Session mit verschiedenen Perspektiven darauf, warum offene Infrastrukturentscheidungen Konsequenzen haben, die weit über Vendor-Lock-in hinausgehen.

Besonders gefreut hat uns der Auftritt von Mohammad Alavi von HIN (Health Info Net) – einem VSHN-Kunden – der im dedizierten Sovereignty Track des Festivals gesprochen hat. Einen Kunden auf der Bühne zu erleben, der über reale Souveränitätsfragen im Schweizer Gesundheitswesen berichtet, war eines der Highlights des Tages und eine Erinnerung daran, dass diese Diskussion für die Organisationen, mit denen wir arbeiten, alles andere als abstrakt ist.

Und das Lego geht an…

Kein VSHN-Messeauftritt ohne Lego-Verlosung. Dieses Mal stand ein Lego Harry Potter Set auf dem Spiel – und gewonnen hat Daniel Haß. Herzlichen Glückwunsch Daniel, viel Spass beim Bauen! 🧱

Bis nächstes Jahr

Das Swiss Software Festival etabliert sich auf dem Schweizer Tech-Kalender. Es will keine riesige Konferenz sein – es will eine gute sein. Mit 650 Teilnehmenden, einem sorgfältig kuratierten Programm, einer wirklich tollen Location und spannenden Gesprächen, gelingt das.

Danke an Swiss Made Software für eine grossartige zweite Ausgabe und an alle, die am Stand vorbeigeschaut, Tech Track 2 besucht oder Aarno und Tobias auf der Bühne erlebt haben.

Wir sehen uns 2027!

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Gewinne Tickets für das Swiss Software Festival 2026

15. Juni 2026

Das Swiss Software Festival geht in die zweite Runde – und wir verlosen Tickets. Wie du gewinnen kannst und was VSHN am 24. Juni 2026 nach Basel mitbringt, erfährst du hier.

Zurück in Basel: Das Swiss Software Festival geht in die zweite Runde

Als das Swiss Software Festival letztes Jahr zum ersten Mal stattfand, hat es sich sofort als eine der relevantesten Veranstaltungen für die Schweizer Softwarebranche etabliert – ein ganztägiges Event, das Ingenieurinnen und Ingenieure, Software-Architektinnen und -Architekten, Produktverantwortliche und Entscheidungsträger unter einem Dach versammelt. VSHN war von Anfang an als Matterhorn-Sponsor dabei und die erste Ausgabe hat gehalten, was sie versprochen hat: starke Talks, echte Gespräche und ein Publikum, das sich wirklich für die Zukunft der Software in der Schweiz interessiert.

In diesem Jahr kehrt das Festival für seine zweite Ausgabe nach Basel zurück – mit bis zu 700 erwarteten Besucherinnen und Besuchern und einem noch stärkeren Programm aus Plenarveranstaltungen, Leadership-Panels und dedizierten Tech-Tracks. Wir sind stolz, wieder als Matterhorn-Sponsor dabei zu sein und auch dieses Mal gestaltet VSHN nicht nur mit, was auf der Bühne passiert, sondern trägt aktiv zur inhaltlichen Ausrichtung des Festivals bei.

Tickets für das Swiss Software Festival 2026 gewinnen

Um die Vorfreude mit unserer Community zu teilen, verlosen wir 5 Festival-Tickets. Für eine Teilnahme an der Verlosung genügt ein Abonnement von VSHN News, unserem monatlichen Newsletter. Das war’s.

Die Gewinnerinnen und Gewinner werden am Mittwoch, 17. Juni um 16 Uhr CEST gezogen. Der Wettbewerb endet zu diesem Zeitpunkt – also rechtzeitig anmelden.

VSHN News abonnieren und gewinnen

Update: Die Gewinner wurden gezogen und sind informiert – herzlichen Glückwunsch!

Was VSHN am Festival macht

Über das Sponsoring hinaus ist VSHN in diesem Jahr wieder tief im Festival verankert – vom Advisory Board, in dem Aarno als Mitglied vertreten ist, bis hin zur Plenary-Bühne, den Tech-Tracks und der Track-Chair-Rolle.

Aarno Aukia – Keynote zu digitaler Neutralität

Aarno Aukia tritt bei der abschliessenden Plenarsitzung Digital Sovereignty: What’s next? auf die Bühne. Seine Keynote trägt den Titel Digital Neutrality: Switzerland’s Engineering Advantage in the AI Era. Digitale Souveränität hat sich von einem Nischenthema zu einer politischen und wirtschaftlichen Priorität entwickelt – und die Schweiz nimmt in dieser Debatte eine besondere Stellung ein. Aarno zeigt auf, was das in der Praxis bedeutet. Anschliessend diskutieren Vertreterinnen und Vertreter von Microsoft, BSI Software, DeepCloud, Xelon und dem Schweizer Nationalrat die Frage im Rahmen eines Leadership-Panels.

Tobias Brunner – Talk über Plattformen und Ökosysteme

Tobias Brunner spricht im Tech Track 2: Platform Engineering & Software Architecture. Sein Talk From platforms to ecosystems – why software innovation is a team sport zeigt, wie Platform-Thinking über reine Infrastruktur-Tooling hinauswächst. Eine Plattform zu bauen ist das eine – daraus ein lebendiges Ökosystem zu machen, in dem Teams, Partner und Produkte gemeinsam wachsen können, ist eine ganz andere Herausforderung. Genau das ist ein Kernthema bei VSHN.

Markus Speth – Track-Chair Tech Track 2

Markus Speth ist als Track-Chair für den Tech Track 2: Platform Engineering & Software Architecture verantwortlich. Der Track deckt das gesamte Spektrum modernen Platform Engineerings ab – von Kubernetes-basierten Control Planes und internen Developer Platforms bis hin zu verteilten KI-Workloads und Multi-Cloud-Strategien. Genau das Terrain, auf dem VSHN täglich unterwegs ist – weshalb wir uns gefreut haben, die inhaltliche Ausrichtung mitgestalten zu dürfen.

Über das Swiss Software Festival 2026

Das Swiss Software Festival wird von Swiss Made Software konzipiert und organisiert und findet in Basel statt. Jetzt in seiner zweiten Ausgabe hat sich das Festival schnell als fester Bestandteil des Schweizer Tech-Kalenders etabliert – ein Ort, an dem die Menschen, die die digitale Zukunft der Schweiz gestalten, Ideen austauschen, Annahmen hinterfragen und neue Kooperationen finden. Mit bis zu 700 Besucherinnen und Besuchern und einem Programm, das sowohl Leadership-Perspektiven als auch technischen Tiefgang bietet, ist es eine der wenigen Veranstaltungen, die für Ingenieurinnen und Ingenieure ebenso relevant ist wie für Führungskräfte.

Nutze deine Chance und abonniere VSHN News bis am 17. Juni um 16 Uhr – für die Chance, dein Ticket zu gewinnen.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Open Source Sovereignty

Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten

12. Juni 2026

Innerhalb weniger Wochen fielen zwei politische Signale, die sich gegenseitig verstärken. Die Europäische Kommission veröffentlichte eine neue Open-Source-Strategie, die Open Source ins Zentrum der technologischen Souveränität der EU stellt. Wenige Tage später nahm der Schweizer Ständerat eine Motion für ein Impulsprogramm zur digitalen Souveränität an, mit 30 zu 7 Stimmen, entgegen der Empfehlung des Bundesrats. Beide nennen denselben Hebel: Open-Source-Technologie als Infrastruktur für souveräne, unabhängige digitale Staaten.

Für Schweizer Organisationen, die Technologie-Stacks und Cloud-Anbieter evaluieren, ist die Richtung jetzt eindeutig.

Was die EU-Strategie sagt

Die Open-Source-Strategie der Kommission verfolgt vier Ziele:

  1. Technologische Souveränität durch Open Source: Skalierung europäischer offener Alternativen zu nicht-europäischen proprietären Lösungen, einschliesslich digitaler Identitäts-Wallets und öffentlicher Dienste.
  2. Ökosystem-Entwicklung: Unterstützung von Startups, Aufbau von Stewardship-Frameworks, Schaffung eines Wartungsinstruments für kritische Open-Source-Projekte und Investitionen in Kompetenzen.
  3. Führungsrolle der öffentlichen Verwaltung: Entwicklung von Open-Source-Beschaffungsrichtlinien und Stärkung des Open Source Programme Office (OSPO) der Kommission.
  4. Standards und internationale Zusammenarbeit: Integration von Open-Source-Communities in die EU-Standardisierung.

Die Strategie verfolgt einen Gesamtlebenszyklus-Ansatz: von der Forschung bis zur langfristigen Wartung. Sie benennt explizit das Ziel, die Abhängigkeit von nicht-europäischen Technologien zu reduzieren und die europäische Kontrolle über «kritische digitale Infrastruktur, einschliesslich Software- und Hardwaresysteme» zu erhöhen.

Das ist kein abstraktes Strategiepapier. Es folgt auf die 180-Millionen-Euro-Beschaffung für souveräne Cloud-Dienste im April, bei der Open-Source-Technologie eine von acht bewerteten Souveränitätsdimensionen war. Open Source wird vom «Nice to have» zum Beschaffungskriterium.

Was der Ständerat entschieden hat

Am 10. Juni nahm der Ständerat die Motion 22.3221 von Heidi Z’graggen (Die Mitte, Uri) an. Die Motion fordert ein Impulsprogramm zur Stärkung der digitalen Souveränität der Schweiz. Konkret verlangt sie Anschubfinanzierung für Pilotprojekte in vier Bereichen:

  • Digitale Infrastruktur
  • Open-Source-Technologien
  • Cybersicherheit
  • Künstliche Intelligenz

Z’graggen argumentierte, digitale Souveränität sei «ein zentraler Pfeiler sowohl staatlicher als auch wirtschaftlicher Handlungsfähigkeit». Sie betonte, es handle sich um zeitlich begrenzte Impulse, nicht um permanenten Staatsausbau: «Investitionen in offene, souveräne Technologien stärken unsere Innovationskraft, reduzieren Abhängigkeiten, schaffen Wertschöpfung.»

Die parlamentarische Gruppe Parldigi unterstützte die Motion mit Verweis auf die geopolitische Lage und das Einsparpotenzial von Open Source.

Bundespräsident Guy Parmelin empfahl die Ablehnung. Er verwies auf bestehende Strategien und Finanzierungsinstrumente, darunter das Programm «Digitale Schweiz 2026». Der Ständerat sah das anders: 30 zu 7.

Die Motion geht nun an den Nationalrat.

Die Schweiz hat die rechtliche Grundlage bereits

Was den Ständeratsentscheid bemerkenswert macht: Die Schweiz hat bereits eine Open-Source-Gesetzgebung. Das EMBAG (Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben), in Kraft seit dem 1. Januar 2024, legt fest:

  • Open Source by default: Die Bundesverwaltung muss selbst entwickelte Software als Open Source veröffentlichen.
  • Open Government Data: Verwaltungsdaten müssen zur freien Nutzung zugänglich gemacht werden.
  • Interoperabilität und offene Standards: Schnittstellen müssen dokumentiert und Standards verbindlich erklärt werden können.

Das EMBAG wurde von den Nationalräten Gerhard Andrey und Andri Silberschmidt sowie Ständerat Matthias Michel vorangetrieben. Mit der Verabschiedung wurde die Schweiz eines der ersten Länder weltweit, das die Open-Source-Veröffentlichung von Behördensoftware gesetzlich vorschreibt.

Aber ein Gesetz, das die Veröffentlichung von Behördensoftware vorschreibt, ist nicht dasselbe wie ein Programm, das neue souveräne Infrastruktur finanziert. Das EMBAG sagt: «Veröffentliche, was du baust.» Die Motion Z’graggen sagt: «Investiere, damit mehr gebaut wird.» Die beiden ergänzen sich: Der rechtliche Rahmen existiert, aber der Ständerat ist überzeugt, dass die Umsetzung einen Impuls braucht.

Zwei Signale, eine Richtung

Zusammen gelesen zeigen die EU-Strategie und der Schweizer Entscheid in dieselbe Richtung:

EU-Open-Source-StrategieMotion Ständerat
GeltungsbereichEU-weites Policy-FrameworkSchweizer Impulsprogramm
MechanismusBeschaffungskriterien, OSPOs, WartungsfinanzierungAnschubfinanzierung für Pilotprojekte
Rolle von Open SourceZentrales SouveränitätsinstrumentEiner von vier Schwerpunktbereichen
StatusVeröffentlichte StrategieStänderat angenommen (30:7), Nationalrat ausstehend
Rechtliche BasisAufbauend auf Cyber Resilience Act, Interoperable Europe ActAufbauend auf EMBAG (in Kraft seit 2024)

Die Konvergenz ist kein Zufall. Beide reagieren auf dieselben Herausforderungen: Abhängigkeit von US-Hyperscalern, den CLOUD Act, Lieferkettenrisiken durch geopolitische Verschiebungen und die Erkenntnis, dass digitale Souveränität mehr erfordert als Datenstandort. Es braucht Kontrolle über den Software-Stack.

Was das für Schweizer Organisationen bedeutet

Open Source wird zur Compliance-Erwartung, nicht bloss zur technischen Präferenz. Die EU bewertet es in der Cloud-Beschaffung. Die Schweiz schreibt es für Behördensoftware vor. Beide bewegen sich in Richtung Beschaffungsrahmen, die offene, überprüfbare Technologie gegenüber proprietärem Lock-in bevorzugen.

Die Nachfrage der öffentlichen Hand wird wachsen. Falls der Nationalrat die Motion Z’graggen annimmt, folgt Bundesfinanzierung für Open-Source-Pilotprojekte. Organisationen, die souveräne Open-Source-Infrastruktur liefern und Kunden der öffentlichen Hand bei der Einführung unterstützen können, haben einen strukturellen Vorteil.

Das EMBAG schafft Upstream-Angebot. Je mehr Open-Source-Software die Bundesverwaltung veröffentlicht, desto grösser wird das Ökosystem von in der Schweiz entwickelten und gewarteten Open-Source-Komponenten. Davon profitieren auch Unternehmen, die auf demselben Stack aufbauen.

Geopolitisches Risiko ist jetzt ein Thema auf Geschäftsleitungsebene. Z’graggens Kernargument (Abhängigkeit von ausländischen Technologieanbietern gefährdet die langfristige Wettbewerbsfähigkeit) ist dasselbe Argument, das regulierte Branchen seit zwei Jahren vorbringen. Der Ständeratsentscheid gibt ihm politische Legitimität über die Compliance-Abteilung hinaus.

Wo VSHN steht

VSHN operiert seit der Gründung auf der These, dass Open Source und Souveränität untrennbar sind. Jeder Service im VSHN Application Catalog läuft auf Open-Source-Software (PostgreSQL, MariaDB, Redis, Keycloak, GitLab, OpenBao, Forgejo), betrieben von einem Schweizer Team auf Schweizer Infrastruktur.

Die politische Richtung, die sowohl Brüssel als auch Bern bestätigen, validiert diesen Ansatz:

  • Technologische Souveränität: 100% Open-Source-Stack, aktive Beiträge zu CNCF-Projekten (K8up, Crossplane-Provider), Project Syn und APPUiO.
  • EMBAG-Konformität: Die gesamte Toolchain von VSHN ist Open Source und überprüfbar. Behördenkunden, die VSHN-Services einsetzen, bleiben EMBAG-konform ohne zusätzlichen Aufwand.
  • Operationelle Souveränität: Schweizer 24/7-Betriebsteam, infrastrukturunabhängiges Deployment (Kunde wählt Anbieter), keine Abhängigkeit von ausländischen Anbietern.

Für Organisationen, die ihren Technologie-Stack an der Richtung der EU- und Schweizer Politik ausrichten: Die Frage ist, ob Ihre Infrastruktur von der proprietären Plattform eines ausländischen Anbieters abhängt, oder ob sie auf offener, souveräner Technologie aufgebaut ist, die Sie kontrollieren.

Quellen:

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Event

Cloud Native Zürich 2026 Recap

Eine weitere grossartige Ausgabe der Cloud Native Zürich liegt hinter uns. An den beiden miteinander verbundenen Veranstaltungsorten Abaton und Soho Zürich kamen mehr als 400 Teilnehmende – darunter Platform Engineers, Kubernetes-Praktikerinnen und -Praktiker, Entwicklerinnen und Entwickler, Operatorinnen und Operator sowie Open-Source-Enthusiastinnen und -Enthusiasten – zusammen, um einen Tag voller Wissensaustausch, Networking und spannender Diskussionen in vier Tracks zu erleben.

Erstmals gab es dabei auch einen eigenen Sovereignty Track. VSHN war stolz darauf, erneut als Silver Sponsor dabei zu sein, während Servala den Sovereignty Track sponserte.

VSHN Stand mit Legos 🙂

Danke an alle, die an unserem Stand vorbeigekommen sind und mit uns über Kubernetes und OpenShift, Platform Engineering, digitale Souveränität, Servala, APPUiO, Codey und das europäische Cloud-Native-Ökosystem diskutiert haben. Und natürlich: Auch dieses Jahr haben unsere LEGO-Sets neue Besitzerinnen und Besitzer gefunden. 🙂

Auf der Bühne

Dieses Jahr waren wir nicht nur am Stand, sondern auch aktiv im Programm vertreten:

Tobias Brunner erzählte die Geschichte von Servala. Bei VSHN betreiben wir seit Jahren Managed Services für Schweizer Unternehmen – aber unseren Kundinnen und Kunden fehlte das, was sie von AWS und anderen Hyperscalern gewohnt waren: ein Marketplace, ein Self-Service-Portal, ein paar Klicks. Genau diese Lücke füllt Servala, und Tobias zeigte in seinem Talk, wohin sich Servala als wachsendes Ökosystem aus Cloud-Anbietern, Software-Herstellern, Managed Service Providern und Implementation Partnern entwickelt.

Aarno Aukia sprach darüber, wie sich LLMs Cloud-native betreiben lassen – mit einem Open-Source-Stack auf Kubernetes, bestehend aus Kubeflow, vLLM, LiteLLM und llm-d. Sein Punkt: Wer mehr Kontrolle über Kosten, Datenstandort, Modellwahl und Betrieb haben möchte, muss LLMs nicht zwingend über Hyperscaler-APIs konsumieren.

Und im neuen Sovereignty Track war Markus Speth Track Lead und durfte eine Podiumsdiskussion mit Perspektiven aus dem gesamten Ökosystem moderieren – vom Implementation Partner über Cloud-Anbieter und Managed Service Provider bis hin zu Software-Hersteller und der Zivilgesellschaft. Den ausführlichen Rückblick dazu gibt es hier: Digitale Souveränität – Perspektiven aus dem Ökosystem.

Eine starke Keynote

Ein besonderes Highlight war wie letztes Jahr die Keynote von Thomas Zurbuchen – es ist immer wieder beeindruckend, mit welcher Klarheit er den Bogen von der grossen Wissenschaft zu den Fragen schlägt, mit denen wir uns in der Cloud-Native-Welt täglich beschäftigen.

Rechenzentren im All?

Thomas Zurbuchen sprach auch kurz die Idee an, Rechenzentren im Weltraum zu betreiben. Dabei meinte er, dass sich die Wirtschaftlichkeit in den kommenden Jahren verschieben wird – auf der einen Seite durch steigende Energiekosten auf der Erde und auf der anderen Seite durch sinkende Kosten bzw. Effizienzgewinne beim „Payloads ins All bringen“.

Die Einschätzungen dazu gingen im Anschluss deutlich auseinander. Die Idee sorgte zwar für Aufmerksamkeit, wurde aber sowohl hinsichtlich der wirtschaftlichen Annahmen als auch der Aussage, dass solche Systeme im All „sicherer“ seien als auf der Erde, in weiteren Gesprächen am Apéro sehr kritisch eingeordnet.

Aber ganz ehrlich – lustig wäre es ja schon: Stell dir vor dein Kollege muss mal schnell “eine Disk tauschen” und dann siehst du dabei zu, wie der Engineer ins All geschossen wird… 🙂

Danke an die Organisatoren

Ein grosses Dankeschön an das Team von Cloud Native Zürich für eine rundum gelungene Veranstaltung – von der Programmgestaltung bis zur Location hat einfach alles gepasst, und das Niveau wird von Jahr zu Jahr höher. Wer nicht dabei sein konnte oder einen Talk verpasst hat: Die Aufzeichnungen werden über die offiziellen Kanäle von Cloud Native Zürich veröffentlicht – schaut dafür auf cloudnativezurich.ch vorbei.

Werdet Teil des Ökosystems

Interessieren euch digitale Souveränität, souveräne Managed Services oder das Servala-Ökosystem? Schaut bei Servala vorbei und meldet euch, wenn ihr Teil unseres wachsenden Netzwerks aus Cloud-Anbietern, Software-Herstellern und Implementation Partnern werden möchtet.

Bis zum nächsten Jahr!

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Sovereignty

Digitale Souveränität – Perspektiven aus dem Ökosystem

Gestern hatten wir am Cloud Native Zürich 2026 die Gelegenheit, eine Podiumsdiskussion im Sovereignty Track mit dem Titel „Digital Sovereignty – Perspectives from the Ecosystem“ zu moderieren. Fünf Panelisten, fünf sehr unterschiedliche Blickwinkel auf das gleiche Thema – und ein Raum voller Menschen, die sich für digitale Souveränität interessierten.

Der Rahmen

Das Panel fand nicht im luftleeren Raum statt. Es bildete den Abschluss eines Vormittags voller Inhalte zum Thema Souveränität: David Sterz eröffnete den Track mit der These, dass Europas Cloud-Zukunft von Beginn an verteilt gedacht werden sollte, statt das zentralisierte Hyperscaler-Modell zu kopieren. Unser Kollege Tobias Brunner folgte mit einem Vortrag, der Schweizer Würste („Cervelat“) mit Souveränität verband und überzeugend darlegte, warum „es ist ja eh alles Open Source“ nicht dasselbe ist wie Souveränität. Pascal Stöckli stellte anschliessend das Zentrum SDS vor, die neue Initiative „Souveräne Digitale Schweiz“, die 32 Gründungsorganisationen aus Bundesbehörden, Kantonen und Schweizer IT-Unternehmen vereint.

Als das Panel begann, hatte der Raum bereits gehört, dass digitale Souveränität verteilt, politisch, operativ ist – und offenbar etwas mit Cervelat zu tun hat. Die Aufgabe des Panels war es, diese Fäden aus der Perspektive jener zusammenzuführen, die dieses Ökosystem tatsächlich aufbauen, betreiben und gestalten.

Fünf Sitze, fünf Perspektiven

Wir haben das Panel bewusst so zusammengestellt, dass es das gesamte Ökosystem abdeckt:

  • Lena Fuhrimann (bespinian) – die Perspektive des Implementation Partners, die direkt mit Organisationen arbeitet, die auf Cloud-native-Technologien umsteigen und ihnen hilft, Innovation, Agilität und Kontrolle in Einklang zu bringen.
  • Roman Bachmann (Switch) – die Perspektive des Cloud-Anbieters. Switch betreibt digitale Infrastruktur für Schweizer Universitäten und Forschungsinstitutionen und gehört selbst den Institutionen, die es bedient – Souveränität by Design, in gewissem Sinne.
  • Tobias Brunner (VSHN) – die Perspektive des Managed Service Providers, der zeigt, was es tatsächlich braucht, um digitale Souveränität operativ zu machen: rund um die Uhr Produktionssysteme zu betreiben, statt nur darüber zu schreiben.
  • Simon Reber (Red Hat) – die Perspektive des Software-Anbieters und dazu, wie Open Source zu Flexibilität, Interoperabilität und Souveränität beiträgt – und wo die Grenzen dieses Arguments liegen.
  • David Sommer (Digitale Gesellschaft) – die Perspektive der Zivilgesellschaft, die das Gespräch von der Technologie hin zu demokratischen Rechten, politischem Willen und einer digitalen Gesellschaft erweitert, die für alle funktioniert.
  • Markus Speth (VSHN) – Moderation

Was wir besprochen haben

Bevor wir in die Diskussion eingestiegen sind, haben wir dem Publikum eine einfache Frage gestellt: Wer von euch hat den Begriff „digitale Souveränität“ in den letzten sechs Monaten verwendet? Wenig überraschend gingen fast alle Hände nach oben.

Danach haben wir jeden Panelisten nach seiner eigenen Definition gefragt und fünf wirklich unterschiedliche Antworten erhalten, die von technischen und operativen Sichtweisen bis hin zu Fragen von Kontrolle, Resilienz und demokratischen Werten reichten. Keine einzelne Definition hat sich durchgesetzt und genau das war der Punkt.

Die Diskussion ging dann in konkretere Bereiche über: wie sich Souveränität im Projektalltag mit Kunden zeigt, was es für einen Cloud-Anbieter bedeutet, „sovereign by design“ zu sein, was es braucht, um souveräne Infrastruktur tatsächlich produktiv 24/7 und nicht nur auf einer Folie zu betreiben, ob Open Source allein ausreicht oder nur ein Teil der Gleichung ist, und wo die eigentlichen Blocker liegen – bei der Technologie, beim Budget oder in der Art, wie Organisationen Entscheidungen treffen.

Wir sind auch vor einigen der härteren Zahlen rund um diese Debatte nicht zurückgeschreckt: der Lücke zwischen dem, was europäische IT-Verantwortliche angeben, in lokale Cloud-Alternativen investieren zu wollen und dem, was tatsächlich investiert wird, sowie dem schieren Grössenunterschied zwischen den Investitionen der Hyperscaler und den derzeit verfügbaren europäischen Alternativen.

Ein paar Dinge, die uns geblieben sind

Im Nachhinein sind uns ein paar Themen besonders im Gedächtnis geblieben:

Digitale Souveränität ist kein binärer Zustand. Es gibt kein Zertifikat, das eine Organisation von „nicht souverän“ zu „souverän“ macht – es ist ein Spektrum über mehrere Dimensionen und Frameworks wie das EU Cloud Framework entstehen gerade, um genau das zu messen.

Es geht auch um mehr als nur darum, wo Daten physisch liegen. Kontrolle, Portabilität, Transparenz, Skills, Governance und Rechtsprechung spielen alle eine Rolle – oft eine grössere als der Standort allein.

Vollständige Souveränität, im Sinne einer durchgängigen Kontrolle über alles, ist weder realistisch noch erstrebenswert. Verfolgt man eine Abhängigkeitskette weit genug, stösst man irgendwann auf Hardware, Rohstoffe und globale Lieferketten, die keine einzelne Organisation – oder kein einzelnes Land – vollständig kontrolliert. Das sinnvollere Ziel ist es, die eigenen Abhängigkeiten zu verstehen und bewusste Entscheidungen darüber zu treffen.

Und vielleicht am wichtigsten: Souveränität ist nichts, was ein einzelnes Unternehmen, ein einzelner Anbieter oder eine einzelne Regierung allein lösen kann. Es braucht das gesamte Ökosystem – Anbieter, Hersteller, Open-Source-Communities, öffentliche Institutionen und die Zivilgesellschaft – die zusammenarbeiten.

Das bringt uns zurück zu einer Frage, die wir am Anfang gestellt haben: Ist „Souveränität“ überhaupt das richtige Wort? Vielleicht geht es den meisten Organisationen eigentlich um Resilienz, um Autonomie oder Wahlfreiheit, oder einfach um die Fähigkeit, eigene Entscheidungen zu treffen, ohne jemand anderen um Erlaubnis fragen zu müssen.

Ein Satz aus unserer Vorbereitung für dieses Panel ist uns durchgehend im Kopf geblieben: „Souveränität ist eine Brücke, kein Bunker“. Es geht nicht um Isolation – es geht um die Freiheit, den eigenen Weg zu wählen und dabei mit einem grösseren Ökosystem verbunden zu bleiben.

Leider ist uns die Zeit auf der Bühne viel zu schnell ausgegangen. Es gab so viele weitere Aspekte, die wir hätten besprechen können und der Energie im Raum nach zu urteilen, ging es dem Publikum genauso.

Wir denken bereits über eine Folgeveranstaltung nach, um einige dieser Themen weiter zu vertiefen.

Schaut euch die ganze Diskussion an

Die Aufzeichnung der gesamten Podiumsdiskussion wird bald veröffentlicht werden – wir teilen den Link, sobald er verfügbar ist, damit ihr alle fünf Perspektiven direkt von den Panelisten selbst hören könnt.

Ein grosses Dankeschön an Lena, Roman, Tobias, Simon und David für eine wirklich spannende Diskussion.

Danke an die Organisatoren von Cloud Native Zürich

Ein grosses Dankeschön an die Organisatoren für eine weitere gelungene Ausgabe von Cloud Native Zürich. Wir freuen uns, wieder als Sponsoren dabei gewesen zu sein – VSHN als Silver Sponsor und Servala als Sponsor des Sovereignty Tracks am Cloud Native Zürich 2026.

Im Rahmen des Tracks hielt unser Kollege Tobias Brunner zudem einen Vortrag über Servala – auch diese Aufzeichnung werden wir bald veröffentlichen, bleibt also gespannt.

Wenn euch interessiert, was Servala ist und wie souveräne, Multi-Provider-Managed-Services auf Kubernetes in der Praxis aussehen können – schaut bei Servala vorbei und meldet euch gerne, wenn ihr Teil unseres wachsenden Ökosystems werden möchtet.

Lies auch unseren vollen Cloud Native Zürich 2026 Recap.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt
Allgemein Presse Servala Sovereignty

Switch tritt Servala als Cloud Service Provider bei und stärkt die digitale Souveränität der Schweiz

10. Juni 2026

Switch tritt Servala als Cloud Service Provider bei und stärkt die digitale Souveränität der Schweiz

Medienmitteilung: Zürich, Schweiz – 10. Juni 2026

VSHN und Switch freuen sich, eine neue Partnerschaft bekanntzugeben: Switch tritt Servala als Cloud Service Provider (CSP) bei und erweitert damit das Ökosystem souveräner Managed Services in der Schweiz.

Die Stiftung Switch ist eine tragende Säule der digitalen Souveränität der Schweiz. Als Betreiberin des Swiss National Research and Education Network (NREN) verbindet Switch Universitäten und Forschungseinrichtungen schweizweit und darüber hinaus. Neben dem Netzwerk-Backbone bietet Switch digitale Identitätslösungen, Cybersicherheit, Cloud-Dienste, Beschaffungs- und Kollaborationsdienstleistungen für Forschungs- und Bildungseinrichtungen an – ein Grundpfeiler der digitalen Innovation im Hochschulbereich.

Mit rund 180 Mitarbeitenden und jahrzehntelanger Erfahrung spielt Switch eine zentrale Rolle bei der Bereitstellung sicherer, zuverlässiger und leistungsstarker digitaler Plattformen und kritischer Infrastruktur für die Schweizer Bildungs- und Forschungsgemeinschaft.

Durch den Beitritt zu Servala erweitert Switch sein Cloud-Service-Portfolio um den Zugang zu einem wachsenden Ökosystem cloud-nativer Managed Services. Diese Services können standardisiert, automatisiert und produktionsreif bereitgestellt und betrieben werden – abgestimmt auf die Bedürfnisse von Universitäten und Forschungseinrichtungen, die Zuverlässigkeit, Skalierbarkeit, Compliance und langfristige Nachhaltigkeit benötigen.

ROMAN BACHMANN, Head of Cloud & IT, ad interim, Switch: „Mit der Integration von Servala reagieren wir auf den häufig geäusserten Wunsch unserer Kunden, auf Knopfdruck eine managed Database, einen Cache oder eine Queue bereitstellen zu können. Damit erweitern wir unser Service Portfolio von Switch Cloud um wichtige Services, die in der modernen Softwareentwicklung unverzichtbar sind.“

Die Partnerschaft kommt zu einem Zeitpunkt, in dem die Nachfrage nach souveräner digitaler Infrastruktur in der Schweiz zunimmt. Organisationen suchen nach Alternativen, die moderne Cloud-Fähigkeiten mit lokaler Kontrolle, Transparenz und Unabhängigkeit von globalen Hyperscalern verbinden.

Genau hier kommt Servala ins Spiel.

Servala verbindet Schweizer Cloud-Anbieter, Softwarehersteller und Service-Betreiber in einem kollaborativen Ökosystem. Dieses Modell ermöglicht mehr Flexibilität, Resilienz und Innovation – bei gleichzeitiger lokaler Kontrolle über Daten und Betrieb.

Servala schafft gemeinsamen Mehrwert für die gesamte Community:

  • Universitäten und Forschungseinrichtungen erhalten Zugang zu modernen, produktionsfertigen Services, die auf ihre Bedürfnisse zugeschnitten sind
  • Organisationen behalten die Wahlfreiheit und vermeiden Vendor-Lock-in
  • Schweizer Anbieter arbeiten zusammen und bündeln ihre Expertise, anstatt isoliert zu operieren
  • Der Schweizer Bildungsraum wird durch lokale Innovation und vertrauensvolle Partnerschaften gestärkt

TOBIAS BRUNNER, Product Manager & Partner, VSHN: „Was mich an dieser Partnerschaft am meisten begeistert, sind die gemeinsamen Werte. Switch und VSHN haben ihren Ruf auf Vertrauen, Zuverlässigkeit und einer langfristigen Perspektive aufgebaut – nicht auf Lock-in. Indem Switch Servala beitritt, hilft es uns zu zeigen, dass Schweizer Anbieter zusammenarbeiten und gemeinsam innovieren können – zum Nutzen des gesamten Ökosystems.“

Für Switch markiert diese Partnerschaft einen Schritt hin zur Weiterentwicklung seines Dienstleistungsangebots um cloud-native Plattformen und Managed Services. Für VSHN und das breitere Servala-Ökosystem ist Switch ein starker neuer Partner mit tiefen Wurzeln im Schweizer Bildungs- und Forschungssektor.

Beide Organisationen haben bereits mit der Entwicklung eines ersten Servala Minimum Viable Product (MVP) begonnen, das auf die Switch-Community zugeschnitten ist. Das frühe Interesse von Universitäten und Forschungseinrichtungen unterstreicht die Nachfrage nach souveränen, einfach zugänglichen Services.

Über Servala

Servala ist die souveräne Anwendungsplattform, die Cloud-Anbieter, Softwarehersteller, Managed Service Provider und Implementierungspartner verbindet, um cloud-native Services ohne Vendor-Lock-in bereitzustellen. Aufgebaut auf offenen Standards und ausgelegt auf Interoperabilität, ermöglicht Servala Organisationen die konsistente und automatisierte Bereitstellung und den Betrieb von Applikationen über mehrere Clouds und On-Premises-Umgebungen hinweg.

Im Kern ist Servala kein einzelner Anbieter, sondern ein Ökosystem. Es vereint Schweizer und europäische Partner, die ihre Infrastruktur, Software und operative Expertise bündeln, um vollständig verwaltete Services bereitzustellen. Dieses kollaborative Modell gewährleistet Transparenz, Flexibilität und langfristige Unabhängigkeit für Kundinnen und Kunden.

Mit einem starken Fokus auf digitale Souveränität ermöglicht Servala Organisationen, die volle Kontrolle über ihre Daten, Workloads und Technologieentscheidungen zu behalten und gleichzeitig von modernen Platform-Engineering-Praktiken, Automatisierung und skalierbarem Betrieb zu profitieren.

Servala wurde von VSHN initiiert und wird in enger Zusammenarbeit mit Ökosystempartnern weiterentwickelt. Die Plattform vereint Services, die von mehreren Anbietern betrieben werden, darunter VSHN und andere unabhängige Partner.

Über Switch

Switch ist der Digitalisierungspartner der Schweizer Hochschulen. Die Stiftung arbeitet mit Bildungs- und Forschungseinrichtungen zusammen, um sichere und zukunftsorientierte digitale Plattformen und kritische Infrastruktur zu entwickeln. Im Mittelpunkt stehen die Stärkung der Cybersicherheit, die flächendeckende Nutzung digitaler Identitäten und souveräne Cloud-Lösungen. Switch betreibt und schützt zudem seit den Anfängen des Internets Domainnamen mit den Endungen .ch und .li. Die gemeinnützige Stiftung beschäftigt rund 180 Mitarbeitende in Zürich und Lausanne.

Über VSHN

VSHN – The DevOps Company – verwandelt Software in zuverlässige Online-Services durch Automatisierung und den Betrieb von Applikations-Workloads. Als führender Managed Service Provider der Schweiz ist VSHN auf DevOps, Kubernetes, OpenShift und Cloud-Native-Betrieb spezialisiert und ermöglicht Organisationen den zuverlässigen, sicheren und skalierbaren Betrieb geschäftskritischer Anwendungen.

VSHN bietet Platform Engineering, 24/7-Betrieb und vollständig verwaltete Services über Public Cloud, Private Cloud und On-Premises-Umgebungen an – ohne eigene Infrastruktur zu betreiben. Mit Lösungen wie Managed OpenShift, APPUiO, Application Catalog und Servala hilft VSHN Organisationen, den Betrieb zu vereinfachen, Vendor-Lock-in zu vermeiden und die volle Kontrolle über ihre Workloads zu behalten.

Gegründet 2014 und zu 100 % selbstständig, betreut VSHN über 350 Kundinnen und Kunden sowie Partner auf 16 Cloud-Plattformen weltweit. Mit ISO-27001-Zertifizierung, FINMA-konformem Betrieb und ISAE-3402-Typ-2-Prüfungen gewährleistet VSHN höchste Sicherheits- und Compliance-Standards.

Markus Speth

Marketing, Communications, People

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt