Mein Auftraggeber für dieses Projekt war ein mittelständisches Dienstleistungsunternehmen mit Sitz in Deutschland. Entwickelt werden sollte, im weiteren Kontext eines Post-Merger-Integration-Projektes, eine Software zur Automatisierung der internen Prozesse und Verwaltung der Kunden-Daten.
In diesem Artikel möchte ich einen kleinen Teil-Aspekt des Projektes beleuchten: die Auswahl eines geeigneten Public-Cloud-Providers und warum das für die Software-Architektur relevant ist.
IT-Strategie und Anforderungen
Ziel war es, eine Lösung zu konzipieren, die der Kunde langfristig wirtschaftlich selbst warten und betreiben kann. Als mittelständischer Dienstleister kann das Unternehmen dabei nur auf ein kleines IT-Team zugreifen, das mit einer breiten Palette sehr unterschiedlicher Aufgaben betraut ist. Es galt daher, eine Infrastruktur aufzubauen, die mit wenig Aufwand für das System-Engineering betrieben werden kann und zu der ein breites Angebot an externer Unterstützung am Markt verfügbar ist. Es sollte dazu auf möglichst weit verbreitete Standards, Technologien und Tools gesetzt werden. Das Unternehmen entwickelt mit dem Microsoft C#/.NET-Stack. Auf dieses Know-how galt es aufzubauen.
Um die laufenden Aufwände und das für den Betrieb erforderliche System-Engineering-Fachwissen im Rahmen, Sicherheit und Verfügbarkeit hingegen auf hohem Niveau zu halten, ist es Teil der definierten IT-Strategie des Kunden, auf PaaS-/SaaS-Lösungen in Public-Cloud-Angeboten aufzubauen.
Eine solche PaaS-/SaaS-Strategie setzt auf eine „niedrigere Fertigungstiefe“. Anstatt beispielsweise selbst Server aufzusetzen und darauf die erforderliche Software zu installieren und zu betreiben, kauft man betriebsfertige Lösungsbausteine ein, die der Lieferant verwaltet und betreibt. Aktuelle Beispiele für solche SaaS-Bausteine sind betriebsfertige KI-Systeme, die man in eigene Software-Lösungen integrieren kann. Ihr Einsatz erfordert wenig Spezialwissen aus dem jeweiligen Bereich und erlaubt so eine Fokussierung der internen Ressourcen auf das Kerngeschäft. Eines der Risiken einer solchen Strategie ist ein „Vendor-Lock-in“, also die Abhängigkeit von einem einzelnen Lieferanten. Je mehr man fertige PaaS- oder SaaS-Bausteine nutzt, desto größer ist die Gefahr, dass eine solche Abhängigkeit von einem bestimmten Produkt und damit Anbieter entsteht. Konzepte, die anbieterunabhängig sind („Multi-Cloud“), sind in der Umsetzung oft erheblich aufwändiger. Hier gilt es, einen Mittelweg zwischen Abhängigkeit und wirtschaftlicher Umsetzung zu finden.
Als Basis-Infrastruktur für die neue Software fiel die Entscheidung auf ein verwaltetes Kubernetes im Zusammenspiel mit gemanagten Lösungen für Datenbank, Datei-/Blob-Speicherung und Paketfilter / Layer-7-Load-Balancer / HTTPS-Proxy. Die weite Verbreitung von Kubernetes (auch in Kombination mit einem C#/.NET-Stack), die gleichzeitige Nutzbarkeit als cloudbasierte Plattform für andere, im Unternehmen existierende On-Premise-Lösungen und die einfache Anpassbarkeit hinsichtlich Performance und Ausfallsicherheit waren einige der Aspekte, die den Ausschlag dazu gegeben haben. Der gesuchte Provider musste also mindestens diese Produkte anbieten.
Multi-Cloud gegen den Vendor-Lock-in
Die – durchaus sinnvolle – Anforderung, dass konzipierte Lösungen „anbieterunabhängig“ sein müssen, steht regelmäßig in neuen Projekten auf der Agenda. In Entwicklerkreisen hört man dazu nicht selten, Kubernetes-Lösungen ließen sich problemlos von einem Provider zu einem anderen transferieren und seien daher per Definition „Multi-Cloud“.
In der Praxis stimmt das nur, wenn man ausschließlich auf selbst gehostete – und damit selbst verwaltete – Infrastrukturen setzt („IaaS“). Bei der Umsetzung eines solchen – in der Praxis seltenen – Szenarios kann beispielsweise OpenShift Unterstützung bieten. Trotzdem erfordern derartige Infrastrukturen viel Fachwissen aus dem System-Engineering und sind im Aufbau, aber auch in Betrieb und Unterhalt zeitaufwändig. Für kleinere, allgemein ausgerichtete IT-Teams ist das eher selten ein sinnvoller Lösungsansatz.
Setzt man stattdessen auf verwaltete Kubernetes-Angebote („PaaS“ bzw. „SaaS“), erzwingen die Provider den Einsatz providerspezifischer Ressourcen an verschiedenen Stellen der Kubernetes-Konfiguration (z. B. im Ingress, der Netzwerkkonfiguration oder zur Verwaltung der TLS-Zertifikate). Dadurch lassen sich solche Konfigurationen nicht ohne Änderungen von einem Cloud-Anbieter zu einem anderen übertragen. Auch die in einem solchen Projekt fast unabdingbar genutzten Produkte des Providers außerhalb von Kubernetes (z. B. Datenbanken, Vaults, Backups) unterscheiden sich deutlich zwischen den Anbietern.
In der Folge lassen sich größere, auf Kubernetes aufbauende Anwendungen in der Praxis nur mit erheblichen Änderungen von einem Cloud-Anbieter zu einem anderen überführen. Ein – nicht zu unterschätzender – Vendor-Lock-in-Effekt besteht daher auch beim Einsatz von Kubernetes.
Beispielsweise Google versucht dem in seinem eigenen Cloud-Angebot entgegenzuwirken („Google Multi Cloud“). Das funktioniert technisch gar nicht mal schlecht – bindet einen aber an die Google-Cloud-Plattform und verschiebt daher das Vendor-Lock-in-Problem nur.
Mit Orchestration-Lösungen wie Terraform, Ansible oder Spacelift lassen sich rein technisch durchaus echte Multi-Cloud-Lösungen erstellen. Diese Werkzeuge vereinheitlichen aber primär die Beschreibungssprache und nicht die technischen Dienste zur Realisierung. In der praktischen Umsetzung ist Multi-Cloud deshalb nur mit überraschend hohem Zusatzaufwand realisierbar und scheidet daher – in der Realität des Mittelstandes – regelmäßig aus ökonomischen Gründen aus.
Nicht zu unterschätzen ist auch das mit der Infrastruktur des eigenen Providers aufgebaute Know-how im IT-Team. Erst das macht die tägliche Arbeit wirklich effizient. Gesammelte Erfahrung aus der praktischen Anwendung und das Wissen über das Verhalten der Infrastruktur unter Last oder bei Problemen lassen sich aber eben nur sehr begrenzt von einem Anbieter auf einen anderen übertragen.
In der täglichen Umsetzungs-Praxis mittelständischer Unternehmen rückt man daher – aus rein wirtschaftlichen Gründen – oft wieder zu einem gewissen Maß von der Multi-Cloud-Anforderung ab. Der sorgfältigen Auswahl des Hosters sollte gerade deshalb besonders viel Aufmerksamkeit gewidmet werden.
Fragen zu Cloud-Auswahl und DSGVO? Gesprächstermin buchen, anrufen (+49 211 97 26 55 44) oder Anfrage senden.
Auswahl eines Hosting-Anbieters
Unter den skizzierten Anforderungen an den Provider mag es naheliegend scheinen, das hier vorgestellte Projekt auf einen der großen Hyperscaler wie Microsoft Azure oder Amazon Web Services aufzusetzen. Diese haben (nicht nur) im Zusammenspiel mit .NET-Stacks aus guten Gründen weite Verbreitung in der Entwicklergemeinde. Hohe Leistung zu günstigen Preisen, ein riesiges Produktangebot und Millionen von Anwendern sprechen für diese Lösungen.
In der hier zu konzipierenden Software waren aber sehr sensible Kunden-Daten zu verwalten. Besonders sensible Daten (wie Gesundheitsdaten oder Informationen über beispielsweise religiöse oder politische Ansichten) genießen in der EU (und damit auch in Deutschland) im Rahmen der DSGVO einen besonderen Schutz, der weit über das vorgeschriebene Schutzniveau regulärer personenbezogener Daten hinausgeht. Beispielsweise das BMWK hat dazu eine gut verständliche Erläuterung veröffentlicht, die inhaltlich auf verschiedene Formen sensibler Daten übertragbar ist.
Eine Verarbeitung personenbezogener Daten bei US-(Cloud-)Anbietern lässt sich grundsätzlich auf einen Angemessenheitsbeschluss der EU-Kommission stützen. Das gilt – in gewissen, engen Grenzen – sogar für besonders geschützte, sensible Daten, wie z. B. Gesundheitsdaten. Der bis dahin geltende „Privacy Shield“ (Wikipedia erklärt das leichter verständlich) war allerdings 2020 vom Europäischen Gerichtshof für ungültig erklärt worden, sein Nachfolger zum Zeitpunkt der Konzeption erst in Vorbereitung. In der Konsequenz hätte die Nutzung von Diensten mit US-Bezug in diesem Projekt untragbar hohe rechtliche Komplexität und Unsicherheit mit sich gebracht.
Ein Unternehmen sollte dem Schutz der ihm von seinen Kunden anvertrauten Daten besondere Sorgfalt widmen, um dem Vertrauen seiner Kunden gerecht zu werden. Dieses Vertrauen zu rechtfertigen, stand auch in diesem Projekt an oberster Stelle. Deshalb und weil alles andere als sicher war, ob die Nachfolgeregelung juristisch dauerhaft Bestand haben würde (entsprechende Klagen waren bereits angekündigt und nicht wenige Juristen sprachen ihnen sehr gute Chancen zu), war schnell klar, dass in diesem Fall auf eine Infrastruktur ohne US-Bezug gesetzt werden sollte. Eine solche galt es zu finden.
Die DSGVO sieht die Möglichkeit vor, Dienstleister (wie Cloud-Infrastruktur-Anbieter) beispielsweise für die „DSGVO-konforme Verarbeitung von Gesundheitsdaten“ zu zertifizieren (Art. 42 DSGVO). Das würde Entscheidern in Unternehmen eine hohe Rechtssicherheit geben. Leider hat der Gesetzgeber in Deutschland bis heute die Voraussetzungen für diese Zertifizierung nicht ausdefiniert bzw. Prüfstellen und -verfahren noch nicht etabliert. Für Cloud-Dienste in Deutschland war daher keine Zertifizierung nach Art. 42 DSGVO verfügbar, sodass das keine Orientierungshilfe bei der Anbieterauswahl geben konnte. Im Rahmen von Projekten wie „Auditor“ wird daran gearbeitet, das zukünftig zu ändern.
Anbieter mit einer gewissen Mindestgröße, die sich schon eine gewisse Zeit lang am Markt bewiesen haben, georedundante Public-Cloud-Lösungen mit passenden PaaS-/SaaS-Produkten in Deutschland anbieten und keinen Mutterkonzern oder beherrschenden Gesellschafter in den USA haben (und damit dem US-Recht unterliegen), sind – allen Gaia-X-Initiativen zum Trotz – nicht gerade in überwältigender Zahl am Markt zu finden. Das BMWK hat eine Liste zusammengestellt, die einen Ausgangspunkt für eigene Recherchen bilden kann.
Die Recherche bei europäischen Anbietern, wie beispielsweise der französischen OVHcloud (die aus verschiedenen Gründen alles andere als unumstritten ist), zeigt, dass einige der EU-Anbieter die Anforderungen der deutschen DSGVO-Auslegung in wesentlichen Punkten durchaus erfüllen würden. Für die Anbieter aus dem EU-Ausland sind allerdings durchweg speziell deutsche Auslegungen der DSGVO (wie beispielsweise die Kriterienkataloge oder Mindestanforderungen des deutschen BSI) oder deutsche gesetzliche Regelungen (wie § 35 SGB I) nicht Gegenstand der Konzeption ihrer Angebote. Entsprechende Selbstverpflichtungen oder Erklärungen dazu waren daher von EU-Anbietern in diesem Projekt nicht zu erhalten. Entsprechende Zertifizierungen liegen nicht vor. Das an sich war zwar alles juristisch noch kein Ausschlusskriterium, verkomplizierte die rechtliche Bewertung dieser Angebote aber in letzter Instanz derart, dass sie für dieses Projekt ausschieden.
Ein noch recht neuer deutscher Anbieter in diesem Segment war die Schwarz-Gruppe mit ihrem Produkt „STACKIT“. Deren Angebot war zum Zeitpunkt der Konzeption gerade erst im Aufbau, das Produktangebot noch sehr schmal. Mit dem Angebot lagen auch noch keine belastbaren Erfahrungen über längere Zeit im Markt vor. Daher schied auch STACKIT aus.
Die Wahl fiel schließlich auf die Open Telekom Cloud („OTC“) von T-Systems, hinter dem die Deutsche Telekom steht. Der Konzern ist nicht von einem US-Unternehmen beherrscht und der Betreiber seiner Rechenzentren für dieses Angebot (Deutschland und optional Niederlande) unterliegt ausschließlich EU-Recht. Neben den üblichen Zertifizierungen für Rechenzentrumsbetreiber (wie z. B. ISO 27001) hat sich die Telekom beispielsweise auch vom BSI nach „Kriterienkatalog C5“ (Cloud Computing Compliance Criteria Catalogue) zertifizieren lassen. Weiterhin verpflichtet man sich selbst auf die Einhaltung der Anforderungen für die Verarbeitung von Daten im Rahmen von § 203 StGB und § 35 SGB I. Das ist zwar rein rechtlich keine Garantie (sondern nur eine Selbstverpflichtung) – mehr scheint im deutschen Markt aktuell aber nicht zu finden zu sein.
Nicht verschwiegen werden soll an dieser Stelle, dass mit Huawei ein politisch sehr umstrittener chinesischer Partner der wesentliche Plattform- und Technologielieferant der Deutschen Telekom für das OTC-Angebot ist. Für die rein juristische Bewertung ist das an dieser Stelle aber unerheblich, da die Telekom der alleinige Betreiber ist.
Erfahrungen mit der Open Telekom Cloud
Das Leistungs-Angebot der OTC ist merklich weniger breit als das der US-Hyperscaler und auch teurer. Verwaltet werden kann das Angebot per Web-GUI oder REST-API. Eigene Kommandozeilen-Werkzeuge (wie sie Azure oder AWS bieten) fehlen. Für dieses Projekt stellte das aber keinen Hinderungsgrund dar.
Wer Projekte auf der Open Telekom Cloud umsetzt, sollte anfangs etwas mehr Zeit einplanen. Das initiale Onboarding war ein überraschend langwieriger Prozess. Dafür gab es ein großzügiges Frei-Budget zum Testen vor der produktiven Inbetriebnahme.
Die OTC-Dokumentation ist nicht gerade überwältigend gut, und durch den – im Vergleich zu Azure oder AWS – kleinen Anwenderkreis sind konkrete Hilfen oder Anleitungen aus der Community (z. B. in Form von „How-tos“) oft nicht verfügbar. Den OTC-Support habe ich als kompetent und hilfsbereit erlebt – aber auch als vergleichsweise langsam. Es gibt auch eine eigene Online-Community der Anwender, die versucht, Hilfestellung zu bieten. Am Ende muss man oft selbst etwas herumprobieren. Insgesamt war die Umsetzung aber problemlos.
Die konzipierte Lösung ist zwischenzeitlich realisiert und bereits einige Zeit im produktiven Betrieb. Neben Kubernetes werden in diesem Projekt auch verwaltete Datenbanken, Image-Repositories, Blob-Storage, VPN-Endpunkte, verschiedene verwaltete Backup-Lösungen und diverse Security-Produkte aus der OTC genutzt. Neben der in diesem Projekt neu konzipierten Software laufen auf den Kubernetes-Clustern des Kunden bei der Telekom zwischenzeitlich auch eine ganze Reihe anderer Anwendungen, die früher lokal gehostet wurden.
Nicht nur die eingesetzte Infrastruktur hat sich dabei in der Praxis bis heute gut bewährt. Auch Performance und Zuverlässigkeit sind auf hohem Niveau.
Vor dem Hintergrund, eine tatsächlich DSGVO-konforme Infrastruktur zu haben, sind die überschaubar höheren Kosten gegenüber US-Anbietern und der etwas höhere Umsetzungsaufwand sehr gut zu vertreten.
Update 2026
Der hier beschriebene Stand von Anfang 2023 hat sich in mehreren Punkten verändert:
Der Angemessenheitsbeschluss zum EU-U.S. Data Privacy Framework ist am 10.07.2023 in Kraft getreten. Die erwarteten Klagen kamen – das Gericht der Europäischen Union hat die Klage des französischen Abgeordneten Latombe am 03.09.2025 jedoch abgewiesen, das Rechtsmittel liegt beim Europäischen Gerichtshof. Die Erwartung, solchen Klagen seien gute Chancen einzuräumen, hat sich damit bisher nicht bestätigt. Die Abhängigkeit von einer politisch getragenen Regelung besteht allerdings fort.
Die Zertifizierungslücke ist geschlossen: AUDITOR ist seit Juni 2024 als Datenschutz-Zertifizierung nach Art. 42 DSGVO anerkannt, erste Zertifizierungsstellen sind akkreditiert. Was dieser Beitrag als offenes Vorhaben beschreibt, steht heute zur Verfügung.
Die Open Telekom Cloud firmiert seit 2026 als „T Cloud Public“. STACKIT hat sich in der Zwischenzeit zu einem ernst zu nehmenden Anbieter entwickelt und betreibt sieben Rechenzentren in Europa. Microsoft hat die EU Data Boundary im Februar 2025 abgeschlossen – am grundsätzlichen Problem des CLOUD Act ändert das nichts.