Digitale Souveränität durch Multi-Cloud stärken

Im Kontext der digitalen Souveränität stehen Organisationen der deutschen Verwaltung vor drei wesentlichen Herausforderungen. Um die erste Herausforderung zu entdecken, reicht es oft im Amtsgebäude die Treppe zu nehmen und in den Keller zu gehen. Denn dort befindet es sich – das eigene Rechenzentrum. In diesem Rechenzentrum werden verschiedene, historisch gewachsene Legacy-Systeme betrieben, die zwar ihre Aufgaben noch erfüllen, jedoch oft in Entwicklung, Betrieb und Innnovation nicht mehr dem aktuellen Stand der Technik entsprechen. Hinzu kommt, dass die IT betreffenden Prozesse oftmals von der starren und hierarchischen Arbeitsweise einer deutschen Verwaltung geprägt sind. Diese Arbeitsweise ist nicht zufällig entstanden, sondern resultiert aus zwei weiteren wesentlichen Herausforderungen, denen sich die Verantwortlichen stellen müssen. 

Die nächste Herausforderung betrifft den Datenschutz. Werden Daten in die Cloud ausgelagert, übernimmt nicht mehr das eigene Betriebsteam die Verwaltung, sondern externe Dienstleister. Viele Entscheidungsträger bevorzugen es daher, den sichereren Weg zu gehen und die Daten auf eigenen Festplatten im eigenen Rechenzentrum zu speichern und verwalten. Dabei wird die Kontrolle über die potenzielle Leistungsfähigkeit priorisiert. Die genaue Kenntnis darüber, auf welcher Maschine die Software läuft und wer das Rechenzentrum betreibt, bietet eine nahezu unvergleichliche Kontrolle

Weiterhin ist der Respekt vor geopolitischen Abhängigkeiten bisweilen sehr ausgeprägt. Viele Entscheider machen sich Gedanken über Abhängigkeiten zu Unternehmen, die weder aus Deutschland noch der EU kommen. Denn es gibt keine Garantie, dass ein Hyperscaler seine Dienste auch in zehn Jahren noch zur Verfügung stellt. Dabei spielt neben dem Datenschutz, auch undurchsichtige Wertschöpfungsketten eine Rolle. 

Betrachten wir diese drei Herausforderungen aus der Perspektive der digitalen Souveränität, wird deutlich, dass stets eine Abwägung zwischen Leistungsfähigkeit und Kontrolle getroffen werden muss. Ein eigenes Rechenzentrum bietet kurzfristig eine gewisse Leistungsfähigkeit und ein hohes Maß an Kontrolle. Bei Betrachtung der Beschaffungszeiträume während des KI-Booms sowie der Innovationsfähigkeit von Verwaltungsverfahren wird deutlich, dass das eigene Rechenzentrum an die Grenzen seiner Leistungsfähigkeit kommt.

Eine vielversprechende Alternative, die es ermöglicht, das eigene Rechenzentrum weiterhin zu nutzen und vorhandene Ressourcen effizient einzusetzen, ist die Multi-Cloud- oder Hybrid-Strategie. Im Rahmen dieser Strategie versuchen Organisationen das eigene Rechenzentrum und Clouddienstleistungen integriert und strategisch zu nutzen. In der Praxis werden dabei die bestehenden eigenen Rechenzentrumskapazitäten um die modernen und innovativen Angebote von Private, Community- oder Public Clouds erweitert, wie z.B. Microsoft Azure, AWS, Google Cloud oder Delos Cloud.

Es wird ein Serviceportfolio aufgebaut, das für jeden Anwendungsfall das richtige Maß an Leistungsfähigkeit, aber auch Kontrolle bietet. So kann im Prozess der Systementwicklung entschieden werden, ob die hohe Kontrolle des eigenen Rechenzentrums benötigt wird oder die höhere Leistungsfähigkeit des Cloud-Anbieters genutzt werden soll.

Die erfolgreiche Umsetzung einer Multi-Cloud-Strategie erfordert die Etablierung einer umfassenden Governance. Diese Governance bietet einen technologie-neutralen Rahmen, der auf die verschiedenen Plattformen angewendet wird. Typische Bestandteile der Governance umfassen:

Auf Basis einer guten Governance stellen Verwaltungen ihren Cloud-Architekten einen großartigen Werkzeugkasten zur Verfügung. Ihre Mitarbeitenden werden die notwendigen Werkzeuge auswählen, um Lösungen auf dem entsprechenden Souveränitätsniveau zu implementieren.

Dabei hat sich folgender Prozess etabliert:

1. Risikoszenarien konkretisieren
   Am Anfang der Systementwicklung sollten die exakten Souveränitätsrisiken identifiziert werden, um sie als Anforderungen in den Entwicklungsprozess zu integrieren. Dabei sollte ein besonderer Fokus auf die Abstimmung der Kontrollanforderungen gelegt werden, um die Transparenz, Effizienz und Flexibilität des Systems sicherzustellen.
2. Daten und Anwendungen identifizieren
   Die umgesetzten fachlichen Anforderungen und die dabei verwendeten Daten geben oftmals ein Mindestmaß an Datenschutz, IT-Security und Souveränität vor. Deren Identifikation hilft dabei, die richtige Plattform für die Komponenten zu finden. Diese Erkenntnisse werden als Rahmenbedingungen in den Implementierungsprozess gegeben.
3. Architekturen entwerfen
   Die Ergebnisse der ersten beiden Schritte werden im Design des Zielsystems berücksichtigt. Dabei können sowohl die zur Verfügung stehen Plattformen als auch die darauf verfügbaren Services genutzt werden, um eine effiziente Lösung zu erstellen. Dabei kann sich ein Lösungsdesign auf eine Plattform konzentrieren oder in einem interoperablen Design verschiedene Vorteile heben. 
4. Umsetzen
   Dank der etablierten Governance und der Nutzung bekannter Verfahren zur Softwareentwicklung, können Developer und Architekten selbstbestimmt und effizient Anwendungen implementieren. Essenzieller Aspekt dieser Phase ist die Nutzung von Standards sowohl auf den Plattformen als auch in den Workloads sowie Best Practices aus der Branche und den Technologien.
5. Testen
   Sowohl die gesetzten Rahmenbedingungen als auch die definierten Nicht-Funktionalen Anforderungen an das System können getesteten werden. Das hilft vor Release einer neuen Anwendung die Souveränität zu attestieren. 

Auf Basis der entwickelten und etablierten Governance können im Anschluss zielgerichtete Lösungen entwickelt werden.

Erstes Szenario: Moderne Web-Oberfläche und sichere Datenverwaltung im Multi-Cloud-Umfeld

Im ersten Szenario haben wir sensible Daten, die mit großen Lastspitzen abgefragt werden. Dabei soll den Anwendenden eine moderne Web-Oberfläche zur Verfügung gestellt werden, die laufend weiterentwickelt wird, um ein zeitgemäße User-Experience zu schaffen. In einem ersten Schritt wird der Fokus für die Anwendung für die Datensouveränität gelegt. Dabei geht es insbesondere um die Daten „at Rest“ – also die Persistenzebene. Diese sind die "Gold-Nuggets" der Anwendung. Weiterhin unterliegen sie bestimmten gesetzlichen Anforderungen, die einer Speicherung in der Public-Cloud unmöglich machen. Die Anwendung zur Anzeige der Daten soll aufgrund der Lastspitzen jedoch kosteneffizient skalierbar sein. Weiterhin soll die Oberfläche über Canary-Tests spezifisch ausgerollt und getestet werden. Im Architekturdesign der Anwendung werden die Vorteile des Multi-Cloud-Ansatzes genutzt, um eine zielführende Lösung zu entwickeln. Es werden die hohen Sicherheitsmerkmale des On-Premise Rechenzentrums genutzt, um die Daten zu speichern. Dank der Governance ist die Interoperabilität des Rechenzentrums mit der Public Cloud bereits definiert und umgesetzt. Um die Anforderungen an Skalier- und Testbarkeit der Oberfläche zu erfüllen, wird sich hier für die Nutzung von Serverless-Anwendungen und statischen Webseiten in der Public Cloud entschieden. Im Rahmen der Implementierung und des Testens können sich die Datenbankadministratoren und Softwareentwickler auf ihre etablierten Prozesse verlassen. 

Zweites Szenario: Optimierung von Betriebskosten durch Nutzung der Public-Cloud

Im zweiten Szenario soll eine Anwendung, die einen Unterstützungsprozess abbildet, aber hohe Nutzendenzahlen aufweist, modernisiert werden. Der Fokus der Zielarchitektur liegt auf geringen Betriebskosten. Insbesondere auf Personalkosteneben soll gespart werden. Die Datenklassifikation ergibt, dass es sich nicht um besonderes schützenswerte Daten handelt, die auch in der Public Cloud verarbeitet werden können. Beim Architekturdesign wird entschieden, sich im Betrieb vollständig auf die Leistungsfähigkeit der Public-Cloud zu fokussieren. Um sich jedoch nicht vollständig von der Public-Cloud abhängig zu machen, wird entschieden, die Datensicherung der Anwendung im eigenen Rechenzentrum zu organisieren. Sowohl in der Implementierungsphase, hier insbesondere in der Plattformintegration, als auch im Testen, können sich die beteiligten Techniker auf die etablierten Prozesse verlassen.