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, je 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 Googles Kubernetes im Zusammenspiel mit gemanagten Lösungen für Datenbank, Datei-/Blob-Speicherung und Paketfilter / Layer-7-LoadBalancer / HTTPS-Proxy. Die weite Verbreitung von Kubernetes (auch im Kombination mit einem C#/.Net-Stack), die gleichzeitige Nutzbarkeit als cloudbasierte Plattform für andere, im Unternehmen existierende onpremise-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 konzipierte Lösungen müssen „anbieterunabhängig“ sein 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 seinen 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. In der praktischen Umsetzung ist das aber nur mit überraschend hohem Zusatzaufwand realisierbar, was – in der Realität des Mittelstandes – regelmäßig aus ökonomischen Gründen ausscheidet.
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.
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 Deutschland im Rahmen der DSGVO einen besonderen Schutz, der weit über das vorgeschriebene Schutzniveau regulärer personenbezogener Daten hinaus geht. Beispielsweise das BMWK hat dazu eine gut verständliche Erläuterung veröffentlicht, die inhaltlich auf verschiedene Formen sensibler Daten übertragbar ist.
Im Rahmen der Privacy Shield-Initiative (Wikipedia erklärt das leichter verständlich), bzw. des EU-Angemessenheitsbeschlusses dazu, ist eine Verarbeitung personenbezogener Daten bei US-(Cloud-)Anbietern grundsätzlich durchaus möglich. Das gilt – in gewissen, engen Grenzen – sogar für besonders geschützte, sensible Daten, wie z.B. Gesundheitsdaten.
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 erfüllen stand auch in diesem Projekt an oberster Stelle. Deshalb und weil es alles andere als sicher ist, ob Privacy Shield juristisch überhaupt dauerhaft Bestand hat (entsprechende Klagen dagegen sind bereits angekündigt und nicht wenige Juristen sprechen ihnen sehr gute Chancen zu) war schnell klar, dass in diesem Fall auf eine Infrastruktur ohne US-Bezug gesetzt werden sollte. Einen solchen 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 (§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. Es ist daher (Stand heute) kein einziger Dienstleister zertifiziert, so dass das keine Orientierungshilfe bei der Anbieterauswahl geben kann. 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-Cloud-Act unterliegen) sind– allen Gaia-X-Initiativen zum Trotz – nicht gerade in überwältigender Zahl am Markt zu finden. Das BMWI 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 (der 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) 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 ist 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 betreibt seine Rechenzentren für dieses Angebot ausschließlich in der EU (Deutschland und optional Niederlande). 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. 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 ein wesentlicher Zulieferer und damit letztendlich Technologielieferant der Deutschen Telekom ist.
Erfahrungen mit der Open Telekom Cloud
Das Leistungs-Angebot der OTC ist merklicher weniger breit, als das der US-Hyperscaler und auch teurer. Verwaltet werden kann das Angebot per Web-GUI oder REST-API. Eigene Kommandozeilen- oder Skript-Werkzeuge (wie sie Azure oder AWS bieten) fehlen. Für dieses Projekt stellte das aber keine Hinderungsgründe 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-To‘s“) 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 beio 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.
