Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein Security Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

22. Okt. 2026

Heute fühlt sich an wie ein Katertag. Der Kopf ist schwer, der Kaffee stark und alle sind ein bisschen langsamer unterwegs. Nur haben wir letzte Nacht nicht gefeiert. Wir haben gepatcht – gleich dreimal. Am Morgen waren es kompromittierte Zertifikate, am Nachmittag PHP und spät in der Nacht GitLab.

Morgen: kompromittierte Zertifizierungsstellen

Jedes Mal, wenn du das Schloss-Symbol im Browser siehst, bestätigt eine Zertifizierungsstelle (Certificate Authority, CA), dass die Website wirklich die ist, die sie vorgibt zu sein. Kommt ein Angreifer an die Schlüssel einer CA, kann er sich als beliebige Website ausgeben.

Genau das ist bei eMudhra passiert. Laut Google hat ein Sicherheitsforscher gemeldet, dass die privaten Schlüssel von acht Zwischenzertifikaten (Intermediate CAs) von eMudhra mit unzureichender Zufälligkeit erzeugt wurden – womit es für jeden möglich war, vertrauenswürdige HTTPS-Zertifikate für beliebige Websites zu fälschen. Chrome hat die betroffenen CAs innerhalb weniger Stunden nach der Meldung blockiert, und Google wird das zugehörige Root-Zertifikat am 27. Oktober, also nächsten Dienstag, aus dem Chrome Root Store entfernen.

Browser konnten das schnell beheben. Alles andere nicht. Wie Cloudflare erklärt, prüft sehr viel Software Zertifikate gegen einen eigenen Trust Store – im Betriebssystem, in Laufzeitumgebungen von Programmiersprachen, in Container-Base-Images. All das muss aktualisiert, neu gebaut und neu gestartet werden. Genau diese Art von Arbeit landet bei einem Platform-Team, und am Morgen des 21. Oktober hat das ganze VSHN-Team am CA-Fix gearbeitet.

Nachmittag: PHP2Shell

Unsere Engineers waren also schon gut ausgelastet, als das nächste Problem auftrat. Am 21. Oktober haben die PHP-Entwickler Notfall-Sicherheitsupdates veröffentlicht für zwei kritische Schwachstellen im PHP-Kern-Interpreter, CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9.2 bewertet und erlauben es einem nicht authentifizierten Angreifer, auf einem betroffenen Webserver aus der Ferne Code auszuführen. Erschwerend kam hinzu, dass Details bereits am 20. Oktober online geleakt wurden – vor der koordinierten Veröffentlichung und bevor Patches verfügbar waren. Die Schwachstellen laufen inzwischen unter dem Namen “PHP2Shell”, und die Empfehlung der Sicherheitsbehörden war unmissverständlich: sofort patchen oder exponierte Anwendungen vom Netz nehmen. Die PHP Foundation hat einen eigenen Beitrag zum Release veröffentlicht und dazu, wie sie die Sicherheit von PHP künftig stärken will.

Das war kein theoretisches Risiko. Ein Hosting-Anbieter berichtete, dass Angreifer ab 08:44 UTC an jenem Morgen mit einem öffentlichen Proof-of-Concept-Exploit Anfragen an die von ihm gehosteten WordPress-Sites geschickt haben.

Was PHP ist und was darauf läuft

PHP ist eine Programmiersprache fürs Web. Sie läuft auf dem Server und baut Seiten im Moment des Aufrufs zusammen – holt Inhalte aus einer Datenbank, prüft, ob du eingeloggt bist, erzeugt das HTML und schickt es an deinen Browser. Rund 70% aller Websites laufen mit PHP. Einige der bekanntesten Anwendungen darauf:

WordPress, inklusive WooCommerce-Onlineshops
MediaWiki, die Software hinter Wikipedia
Drupal
Joomla
TYPO3
Magento und Shopware
Nextcloud

Der Fehler steckt in PHP selbst, nicht in einer dieser Anwendungen oder ihren Plugins. WordPress, TYPO3 oder Nextcloud aktuell zu halten, hat also nicht geschützt. Betroffen ist jede PHP-Version der letzten zehn Jahre, zurück bis Version 5.4.

Wie wir und unsere Kunden auf PHP2Shell reagiert haben

Es gibt viele Beiträge, die erklären, was in PHP kaputt war. Spannender finden wir, was in der Praxis passiert, wenn so etwas einschlägt – deshalb hier, wie der gestrige Tag bei uns aussah.

Unser Team hat am Abend des 20. Oktober mit dem Monitoring begonnen, sobald das PHP-Projekt das anstehende Release angekündigt hatte. Die Kubernetes- und OpenShift-Plattformen, die wir für unsere Kunden betreiben, laufen selbst nicht auf PHP. Aber PHP taucht an vielen Stellen auf und rund um diese Plattformen auf, deshalb haben wir das als Major Incident über alle unsere Managed Services behandelt.

Kurz vor Mittag am 21. Oktober hat uns ein Kunde angerufen und gebeten, seine Website offline zu nehmen, bis der Fix da ist.

Auch unsere eigene Website vshn.ch war offline, vom 21. Oktober um 16 Uhr bis zum 22. Oktober um 4 Uhr morgens – 12 (!) Stunden Downtime. vshn.ch wird bei cyon.ch gehostet, einem der grössten Schweizer Webhoster, und cyon hat proaktiv alle PHP-Websites abgeschaltet, um sie zu schützen, bis PHP gepatcht war. Das sieht man nicht alle Tage – ein ganzer Hosting-Anbieter, der vorsorglich bei allen PHP-Sites gleichzeitig den Stecker zieht. Aber das könnten wir in Zukunft öfter sehen, wenn der nächste tief verborgene Fehler in einem gemeinsamen Fundament auftaucht und schnelles Patchen die einzige echte Verteidigung ist.

Sobald der Fix öffentlich war, haben wir alles andere aktualisiert. Auf virtuellen Maschinen mit PHP haben wir aktualisiert, sobald Ubuntu und Red Hat gepatchte Pakete bereitgestellt haben. Die Docker-Images, die wir pflegen, werden neu ausgerollt, sobald gepatchte Base-Images verfügbar sind. Und wo Kunden eigene PHP-Apps in Containern auf unseren Clustern betreiben, mussten auch diese Images gepatcht werden – deshalb haben wir diese Kunden gebeten, sie mit einer gepatchten PHP-Version neu zu bauen und neu auszurollen. Alle Details findest du auf unserer Statusseite.

mod_php vs. PHP-FPM: nicht jedes Setup hatte dasselbe Risiko

Alle gängigen Arten, PHP für Web-Anfragen zu betreiben, waren betroffen: Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Wie man PHP betreibt, war aber trotzdem wichtig. Laut den PHP-Entwicklern war das Risiko bei Setups mit Apache und mod_php am höchsten – dort haben sie einen Exploit demonstriert, der greift, bevor überhaupt Anwendungscode läuft. Bei uns kommt PHP-FPM zum Einsatz. PHP-FPM war allerdings ebenfalls betroffen, und Patchen war die einzige vollständige Lösung.

Nacht: GitLab

Als wäre der Tag nicht schon spannend genug gewesen: Spät in der Nacht hat GitLab Fixes für eine kritische Schwachstelle veröffentlicht – CVE-2026-110264, bewertet mit 10.0, dem Maximum. Damit kann ein Angreifer ohne Login Code auf einem selbst betriebenen GitLab-Server ausführen. Betroffen sind alle Versionen zurück bis 7.0 aus dem Jahr 2014, weil der Fehler in der Regex-Engine steckt, die GitLab seit jeher mitliefert. Unsere VSHNeers haben auch das gefixt.

Was wir daraus mitnehmen

Drei sehr unterschiedliche Probleme, ein gemeinsamer Nenner: Keines davon steckte in den Anwendungen, die man jeden Tag nutzt. Sie lagen in den Schichten darunter – in den Zertifikaten, die HTTPS vertrauenswürdig machen, in der Sprache, auf der der Grossteil des Webs läuft, in der Regex-Engine einer Entwicklerplattform. Jede Software, die wir betreiben, sitzt auf Schichten von Code, den jemand vor Jahren geschrieben hat und den die meisten von uns nie anschauen. Es ist leicht, jetzt mit dem Finger auf eMudhra, PHP oder GitLab zu zeigen. Bitte nicht. Heartbleed hat 2014 OpenSSL getroffen, Log4Shell 2021 die Java-Welt. Das kann jedem Fundament passieren, auf dem wir alle aufbauen.

Der KI-Aspekt

Was PHP2Shell besonders macht, ist, wie die Schwachstelle gefunden wurde. Der verwundbare Code war seit über zehn Jahren vorhanden, aber ihn auszunutzen erforderte eine aussergewöhnlich komplexe Kette von Schritten – am Rand dessen, was menschliche Forschende praktisch leisten können. Moderne KI-Modelle haben diese Hürde deutlich gesenkt. Laut den Forschenden von Wiz hat ein einzelner Forscher in einer Woche geschafft, wofür früher ein Weltklasse-Team Monate gebraucht hätte.

Das ist zugleich beängstigend und eine gute Nachricht. Beängstigend, weil “zu kompliziert zum Ausnutzen” kein Sicherheitsnetz mehr ist – Angreifer haben dieselben Werkzeuge. Gut, weil auch die Verteidiger solche tief vergrabenen Fehler jetzt schneller finden und beheben können, bevor jemand anderes sie ausnutzt. Wir sind ziemlich sicher, dass Tage wie gestern nicht selten bleiben. Rechne mit mehr davon, in mehr Sprachen, öfter. Damit zählt eines mehr denn je: wie schnell du patchen kannst.

Und an dieser Stelle möchten wir Danke sagen. Unsere VSHNeers waren schnell beim Patchen, und einige von ihnen könnten heute wirklich etwas Schlaf gebrauchen. Wenn dir also im nächsten Call jemand etwas müde vorkommt, weisst du jetzt, warum.

Was du tun solltest

Zu den Zertifikaten: Wenn deine Website ein Zertifikat nutzt, das auf emSign ECC Root CA – G3 zurückgeht, solltest du es laut Google sofort durch eines einer anderen CA ersetzen, bevor die Root am 27. Oktober aus Chrome entfernt wird. Über Browser hinaus: Aktualisiere die Trust Stores in Betriebssystemen, Laufzeitumgebungen und Container-Base-Images, baue die Images neu und starte die betroffenen Systeme neu. Und falls nach dem Patchen Zertifikatsfehler auftauchen: Behebe sie nicht, indem du die Zertifikatsprüfung abschaltest.

Zu PHP: Aktualisiere auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wenn du eine ältere Version nutzt: PHP 8.1 und älter erhalten möglicherweise keinen Fix – kläre das mit deinem Anbieter und plane das Upgrade jetzt. Wenn dein Server über ein Hosting-Panel wie cPanel verwaltet wird, kommen die gepatchten PHP-Versionen über die Updates des Panels – aktualisiere also das Panel, nicht nur deine Anwendung. Wenn du PHP in Containern betreibst, baue deine Images auf einer gepatchten Basis neu und rolle sie neu aus. Und denk daran: Ein Patch entfernt keine bereits erfolgte Kompromittierung – wirf also auch einen Blick in deine Logs.

Zu GitLab: Wenn du eine selbst betriebene Instanz hast, aktualisiere auf die gefixte Version für deinen Release-Branch.

Wenn du nicht sicher bist, ob etwas in deinem Stack betroffen ist, melde dich bei uns. Wir sind heute etwas müde, aber wir sind da.

Und jetzt: mehr Kaffee.

Markus Speth

Marketing, Communications, People

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

Kontaktiere uns

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

Kontakt

Kostenlose Bestandsaufnahme buchen

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.

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:

MariaDB by VSHN: Leistungsbeschreibung, unterstützte Versionen und Servicestufen
Open Source als Staatspolitik: Was die EU-Strategie und der Ständeratsentscheid für IT-Entscheider bedeuten: VSHN-Blog, Juni 2026
Aufzeichnung des Webinars MariaDB x VSHN vom 1. Oktober 2026: „MariaDB x VSHN: Engineered for What’s Next“, mit Jonas Schwegler und Aarno Aukia
Open Source im grossen Massstab: Warum Schweizer Organisationen eine souveräne Datenbankstrategie brauchen: Ankündigung des Webinars und des gemeinsamen Estate Health Checks
Technischer Hands-on-Workshop, Zürich, 19. Oktober 2026: Programm, Gastgeber und Anmeldung
Adobe in Venezuela: Adobe’s Venezuela ban, Adobe to refund Venezuelan users affected by US sanctions
Internationaler Strafgerichtshof: Why it matters that the ICC embraced open-source software, Microsoft dementiert Mail-Blockade beim Internationalen Strafgerichtshof
CentOS Linux 8: The future is CentOS Stream, Red Hat zur Umstellung auf CentOS Stream
VMware unter Broadcom: VMware by Broadcom simplifies its offer lineup and licensing model, Support abgelaufen: VMware-Nutzer mit Dauerlizenz sollen Updates entfernen
Oracle Java SE: Java SE Universal Subscription FAQ, Oracle per-employee Java pricing causes concern
Eingestellte Managed Services: What’s happening to Azure Database for MariaDB, AWS to kill QLDB, Google Cloud to shut down IoT Core, Microsoft drops Azure Blockchain
Abschaltung bei fehlender Verbindung: Azure Local FAQ, Was geschieht mit meinen Daten und meinem Zugriff, wenn mein Microsoft 365 Business-Abonnement endet, Apple server outage makes Mac apps hang on launch

Aarno Aukia

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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:

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

Download

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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.

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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 eine technische Roadshow 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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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.

Jetzt anmelden

Markus Speth

Marketing, Communications, People

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Bewegt sich mein Preis mit den Stunden, die ihr aufwendet, oder mit dem Service, den ich erhalte?
Wenn ihr euren Aufwand auf meinem Konto nächstes Jahr halbiert, wer behält die Differenz?
Was messt ihr ausser der Verfügbarkeit und der Wiederherstellungszeit? Irgendetwas zur Vermeidung?
Bekomme ich beim Weggang meine Daten, oder meine Daten und die Automatisierung, die sie betrieben hat?
Ist diese Automatisierung Open Source oder eure?
Welche Entscheidungen verlangen bei euch immer einen benannten Menschen, und welche bei mir?
Welche Teile davon sind ein abgegrenztes Projekt und welche sind laufender Betrieb? Werden sie unterschiedlich bepreist?
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?
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:

ADM 2030: When Applications Manage Themselves. Dr. Daniel Gerster, ISG, 28. Juli 2026
VSHN Service Levels und Support Plans. VSHN Produktdokumentation
Project Syn und AppCat, BSD-3-Clause, und K8up, Apache-2.0. Lizenzen am 4. September 2026 auf GitHub geprüft

Aarno Aukia

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

Kontaktiere uns

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

Kontakt

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

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

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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.

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

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:

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.
Ökosystem-Entwicklung: Unterstützung von Startups, Aufbau von Stewardship-Frameworks, Schaffung eines Wartungsinstruments für kritische Open-Source-Projekte und Investitionen in Kompetenzen.
Führungsrolle der öffentlichen Verwaltung: Entwicklung von Open-Source-Beschaffungsrichtlinien und Stärkung des Open Source Programme Office (OSPO) der Kommission.
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-Strategie	Motion Ständerat
Geltungsbereich	EU-weites Policy-Framework	Schweizer Impulsprogramm
Mechanismus	Beschaffungskriterien, OSPOs, Wartungsfinanzierung	Anschubfinanzierung für Pilotprojekte
Rolle von Open Source	Zentrales Souveränitätsinstrument	Einer von vier Schwerpunktbereichen
Status	Veröffentlichte Strategie	Ständerat angenommen (30:7), Nationalrat ausstehend
Rechtliche Basis	Aufbauend auf Cyber Resilience Act, Interoperable Europe Act	Aufbauend 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:

Open Source Strategy – Europäische Kommission, 2026
Motion 22.3221: Impulsprogramm zur Stärkung der digitalen Souveränität – Schweizer Parlament
Ständerat will ein Impulsprogramm für digitale Souveränität – Netzwoche, 10. Juni 2026
Ständerat will digitale Souveränität stärken – Inside IT, 10. Juni 2026
EMBAG: Ja zu Open Source Software und Open Government Data – Parldigi
180 Millionen Euro für Souveräne Cloud – VSHN-Blog, April 2026

Aarno Aukia

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

Allgemein
Event
Tech

Ein Tag mit Open-Source-Legenden: Technical Roadshow MariaDB & VSHN mit Michael “Monty” Widenius & Anders Karlsson

Allgemein
Security
Tech

Katertag: eMudhra, PHP2Shell und GitLab – drei kritische Fixes an einem Tag

Allgemein
Sovereignty

Wer kann es abschalten

Allgemein
Event

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

Allgemein
OpenShift
Tech

OpenShift 4.22 lets your pods mount container images as volumes

Allgemein
Event

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

Allgemein
Event

Rückblick Cloud Native Computing Meetup September 2026

Allgemein
Event
Sovereignty
Tech

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

Allgemein
Event

Wieder dabei: VSHN an der DINAcon 2026

Kontaktiere uns

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

Kontakt