Für Cloud-Souveränität reicht kein einfacher Schalter

Cloud-Souveränität ist möglich, aber nicht trivial.Melinda Nagy – Shutterstock.com



Souveränität, Datenlokalität und Strategien rund um eine „alternative Cloud“ werden oft so behandelt, als ließen sie sich mit wenigen Einstellungen in den Konsolen der Hyperscaler konfigurieren: Region auswählen, Compliance-Option aktivieren – fertig.



Dass es nicht ganz so trivial ist, eine typische, stark auf US-Anbieter ausgerichtete Startup-Infrastruktur durch einen „Made in the EU“-Stack zu ersetzen, beschreibt das IT-Beratungsunternehmen Coinerella in einem Blogbeitrag. Bei dem Projekt wird Souveränität nicht als Feature verstanden, sondern als Architekturprinzip und Betriebsmodell, das sogar Kosten sparen kann. Gleichzeitig bringe dieser Ansatz jedoch Reibung, Kompromisse und fordere mehr Verantwortung ein, als das Outsourcing an etablierte Cloud-Ökosysteme.



Das Ziel von Coinerella war es, bewusst zu verhindern, dass sich die Plattform schrittweise wieder in Richtung AWS oder anderer US-Hyperscaler entwickelt. Dahinter standen diverse praktische Gründe wie Datenresidenz, DSGVO-Compliance, die Verringerung von Konzentrationsrisiken, aber auch der Nachweis, dass europäische Infrastruktur ebenso operativ tragfähig ist.



Ein „Made in the EU“-Stack



Coinerella setzte bei seinem Souveränitätsansatz nicht auf völlig neue Architekturmodelle. Stattdessen baute das Unternehmen eine weitgehend typische, moderne Plattform auf – allerdings mit europäischen Anbietern und teilweise selbst gehosteten Diensten.



Für die Basisinfrastruktur verlagerte Coinerella Rechenleistung und zentrale Dienste zu Hetzner, darunter virtuelle Maschinen, Load Balancing und S3-kompatible Objektspeicher.



Wo Hetzner einen benötigten Managed Service nicht anbieten konnte, schloss Coinerella die Lücken mit Scaleway. Dazu gehörten etwa Transaktions-E-Mail-Dienste, eine Container-Registry, zusätzlicher Objektspeicher, Observability-Tools sowie Domain-Registrierung.



Für Edge-Dienste setzte das Unternehmen auf Bunny.net als Content Delivery Network. Dazu gehören auch Speicher, DNS, Bildoptimierung, Web-Application-Firewall und DDoS-Schutz.



Dem Blogbeitrag zufolge fühlte sich die Nutzung dieser Lösung relativ vertraut an – insbesondere für Teams, die bisher stark auf Cloudflare gesetzt haben.



Auch das Thema KI-Inferenz wurde unter dem Gesichtspunkt der digitalen Souveränität umgesetzt. Statt Standardlösungen in US-Regionen zu nutzen, griff Coinerella über Nebius auf europäische GPU-Kapazitäten zurück.



Für das Identitätsmanagement setzte das Unternehmen auf Hanko, einen europäischen Authentifizierungsanbieter. Dieser unterstützt moderne Verfahren wie Passkeys und bietet gleichzeitig Funktionen, die die Nutzer erwarten – etwa Social Logins.



Mehr Eigenbetrieb



Ein wichtiger Bestandteil der Architektur war außerdem das Self-Hosting mehrerer interner Dienste auf Kubernetes, mit Rancher als Management-Ebene.



Dort betreibt Coinerella unter anderem:




Gitea für Versionskontrolle,



Plausible für Webanalysen,



Twenty als CRM-System,



Infisical für Secret Management, und



Bugsink für Fehler-Tracking.




Wer schon einmal empfohlen hat, „im Unternehmen ein paar Dienste selbst zu hosten“, weiß, was das in der Praxis bedeutet: Man akzeptiert ein anderes Betriebsmodell, bei dem Kostenvorteile und mehr Kontrolle mit einer stärkeren Verantwortung für Betrieb und Lebenszyklus einhergehen.



Überraschungen und zusätzliche Hürden



Besonders aufschlussreich ist der Beitrag von Coinerella dort, wo das Unternehmen über Schwierigkeiten bei scheinbar „banalen“ Diensten schreibt – also genau jenen Bereichen, die in der Praxis oft über die Produktivität von Entwicklerteams entscheiden.



E-Mail etwa erwies sich als einer der größten Reibungspunkte. Im US-Ökosystem gibt es zahlreiche ausgereifte Lösungen für Transaktions-E-Mails, die sich leicht integrieren lassen und für die umfangreiche Community-Ressourcen zu Zustellbarkeit und Fehlerbehebung existieren.



Coinerella konnte zwar eine europäische Alternative einsetzen, doch die Erkenntnis ist eindeutig: Die lange Liste an Integrationen, Vorlagen und Community-Knowhow ist nicht gleichmäßig über alle Regionen verteilt. Das bedeutet nicht, dass der Dienst nicht funktioniert – sondern dass man möglicherweise häufiger selbst die Rolle eines Integrationsteams übernehmen muss.



Eine weitere Herausforderung war die Versionsverwaltung. Der Abschied von GitHub bedeutet nicht nur, einen Git-Remote zu wechseln, sondern ein ganzes Ökosystem zu verlassen: Standard-CI/CD-Pipelines, Actions, Marketplace-Integrationen und die operative Routine vieler Entwickler, die sich an die GitHub-Arbeitsweise gewöhnt haben. Gitea kann zwar eine solide Grundlage darstellen, bringt aber nicht automatisch die komplette Entwicklungs-Pipeline mit, die man auf der dominierenden Plattform quasi gratis erhält.



Hinzu kamen einige Kostenanomalien. Laut dem Autor waren bestimmte Top-Level-Domains über europäische Registrare teilweise deutlich teurer, ohne dass es dafür eine überzeugende Erklärung gab. Das ist zwar kein architektonischer Showstopper, aber ein gutes Beispiel dafür, dass solche Projekte keine Übungen im Reinraum sind. Man stößt auf unerwartete Unterschiede in Marktstrukturen und muss entscheiden, wie stark diese ins Gewicht fallen.



Unvermeidbare Abhängigkeiten



Wer auf eine Erfolgsgeschichte hofft, in der sämtliche US-Abhängigkeiten vollständig eliminiert werden, wird allerdings nicht fündig. Auch bei Coinerella räumt man ein, dass manche Abhängigkeiten strukturellbedingt sind.



So erfordere die Nutzerakquise möglicherweise das Werbe-Ökosystem von Google, und mobile Vertriebswege müssten eventuell über das Entwicklerprogramm von Apple laufen. Social-Login-Funktionen wiederum hingen häufig von Google- oder Apple-Infrastruktur ab, und deren Entfernung könne die Conversion-Rate beeinträchtigen. Auch KI-Dienste machen laut dem Blogbeitrag Probleme: Wer Zugriff auf bestimmte führende Modelle haben möchte, muss möglicherweise die APIs US-basierter Anbieter nutzen.



Die sinnvollere Strategie, die der Blog implizit empfiehlt, lautet daher:




Minimieren, was möglich ist,



isolieren, was unvermeidbar ist, und



die Kompromisse offen anerkennen.




Die Erfahrungen von Coinerella spiegeln wider, was viele Unternehmen lernen, wenn sie sich mit alternativen Cloud-Modellen beschäftigen – etwa souveränen Clouds, Private Clouds oder anderen Plattformen außerhalb der Standard-Hyperscaler.



Die wichtigste Erkenntnis des Unternehmens: Die Wirtschaftlichkeit solcher Ansätze könne attraktiv sein, gerade weil mehr Eigenarbeit erforderlich sei. Niedrigere Infrastrukturkosten gingen mit mehr Integrationsaufwand, stärkerem Plattform-Engineering und höheren Anforderungen an die operative Reife einher.



Mehr operative Verantwortung



Allerdings funktioniert dieser Ansatz nur mit neuen Arbeitsweisen, wie die Experten von Coinerella nahelegen. Demnach:




werde FinOps wird zu einer Engineering-Disziplin, die mehrere Anbieter, selbst betriebene Plattformen und Kapazitätsplanung umfasst. Diese Aufgaben habe man zuvor an Hyperscaler delegieren müssen.



entwickele sich auch Observability zu einer zentralen Designanforderung, weil die Plattform über verschiedene Anbietergrenzen hinweg aufgebaut ist und Komponenten umfasst, die vollständig selbst betrieben werden. Dafür brauche es konsistente Metriken, Logs, Traces, Service-Level-Objectives und Incident-Response-Prozesse, die auch dann funktionieren, wenn Tools und APIs zwischen Anbietern variieren.



müssten Unternehmen, die mehr selbst betreiben, stärker auf Patch-Management, Sicherheit, Backups, Recovery-Tests und operative Runbooks achten.




Der Punkt ist nicht, dass dies unmöglich oder zu schwierig wäre. Vielmehr ist es auf vorhersehbare Weise anspruchsvoll. Oder wie Coinerella im Blog argumentiert: „Der Aufwand kann sich lohnen – aber nur, wenn Unternehmen die Realität akzeptieren.“ (mb)