Rückzug aus der Cloud?

Bestandsaufnahme

Jahrelang haben Unternehmen ihre Software in die Cloud verlagert, getrieben von den Versprechungen „Sicherheit“ und „Kostenersparnis“. Seit einiger Zeit fragen sich einige dieser Unternehmen, ob dieser Schritt richtig war oder ob es nicht besser wäre, Daten und Software wieder ins Unternehmen zurückzuholen, also „On-Premises“ oder kurz „On-Prem“.

Woher kommt die Enttäuschung über nicht oder nur teilweise eingehaltene Versprechen? Diese Fragen kläre ich in meinem Blog-Beitrag, zeige mögliche Lösungen auf und erkläre, wie adesso in diesem Kontext unterstützen kann.

Aspekte der Sicherheit

Gerade in den Bereichen „Finanzdienstleistungen“, „Health“ und bei Systemen der öffentlichen Hand besteht auf Grund des hohen Schutzbedarfs der Daten ein maximaler Anspruch an Sicherheit. Datenverlust oder Datendiebstahl bedeuten einen Verlust an Reputation, Firmengeheimnissen und letztlich auch Geld.

Die großen Hyperscaler, also Google, Amazon und Microsoft, haben alle ihren Firmensitz in den USA und auch wenn durch die angebotenen europäischen Serverstandorte suggeriert wird, dass die Daten sicher sind, gibt es doch einige US-Gesetze wie „RISAA“, „Cloud Act“ und „Patriot Act“, die den Geheimdiensten bei „begründetem Interesse“ den Zugriff auf Daten ermöglichen.

Angesichts des Wahlergebnisses in den USA im November 2024 ist nicht zu erwarten, dass sich hier etwas zum Besseren (aus Sicht der Datensicherheit) ändern wird.

Auch wenn es unwahrscheinlich ist, dass im konkreten Fall vertrauliche Daten im Namen der „nationalen Sicherheit der USA“ analysiert werden, bleibt dennoch ein ungutes Gefühl bei den Verantwortlichen für Datensicherheit.

Teilweise führt dies auch dazu, dass einzelne Teile der Applikation, etwa ein LDAP-Server mit Kundendaten, On-Prem im Unternehmen verbleiben, also ein Hybrid-Cloud-Ansatz verfolgt wird. Dieser Ansatz erhöht wiederum den Traffic zwischen den Komponenten in die Cloud - dazu später mehr.

Eine schematische Darstellung des Hybrid-Cloud-Ansatzes sieht wie folgt aus:

Kostenfaktoren in der Cloud

Was sind die Kostentreiber bei einer Cloud-Lösung? Hier sind im Wesentlichen folgende Punkte zu betrachten:

1. Verbrauchte CPU-Zeit

Beim Provider kann die Art der CPU nach Leistung gebucht werden. Leistungsstärke CPUs kosten im Verhältnis mehr, daher muss im Vorfeld für jeden Anwendungsfall individuell überlegt werden, ob es sinnvoller ist, mehr Service-Instanzen mit kleinerer CPU oder weniger Service-Instanzen mit großer CPU laufen zu lassen.

Diese Überlegungen sollten in der frühen Projektphase von der jeweiligen Architektin oder vom jeweiligen Architekten zusammen mit den Stakeholdern diskutiert, bewertet und entschieden werden.

2. Verbrauchter Hauptspeicher über Zeit (RAM-Sekunden)

Im Gegensatz zur CPU-Zeit gibt es hier kein „mehr oder weniger“, sondern nur ein „passt“. Ein Microservice mit einem Footprint von 500MB Footprint (inklusive Heap, falls es sich um eine JVM-Sprache handelt), benötigt 500MB+ (+ wegen eines Offsets für das OS) RAM.

Als Faustregel gilt, dass RAM relativ teuer ist, daher lohnt es sich, hier nach Sparmöglichkeiten zu suchen.

3. Storage (S3, Datenbank, Volumes, …)

Dabei ist zu beachten, dass in der Regel verschiedene Storage-Klassen angeboten werden, die sich in der Latenz/Verfügbarkeit unterscheiden. Je höher die Verfügbarkeit ist, desto höher ist auch der Preis. Man sollte also bei der Auswahl den eigenen Use Case genau im Blick haben.

4. Traffic

Damit ist der Datenverkehr von und nach Systemen außerhalb der Cloud gemeint. Also in der Regel http-Requests oder auch API-Calls. Bei hybriden Architekturen kommen hier zusätzlich die Kommunikation mit den On-Premise Services on top.

5. Betrieb / Support

Es gibt Kosten für den Support der Infrastrukturkomponenten. Je nach Servicelevel, also der gewünschten Reaktionszeit und Verfügbarkeit, wird hier ein gewisser Betrag fällig. Hinzu kommen die Kosten für den Applikationssupport, der meist vom Personal des Unternehmens gestellt werden muss.

Die Gründe für eine zu hohe Kostenentwicklung können direkt diesen Punkten zugeordnet werden:

• 1. CPU-Zeit: Die Architektur ist unter Umständen nicht für den Cloud-Betrieb optimiert. Die Services könnten falsch geschnitten sein oder Komponenten könnten im Dauerbetrieb laufen, aber nur für den Batch-Betrieb einmal am Tag oder bei der Datenlieferung benötigt werden.
• 2. RAM-Sekunden: Der Memory-Footprint der Microservices könnte unnötig hoch sein, etwa durch ein schlecht gewähltes Docker-Basisimage oder durch die Nutzung eines Programmierframeworks, das nicht für Cloud Native gedacht ist.
• 3. Storage: Hier gibt es deutliche Unterschiede zwischen direkt verfügbarem Storage („online“) oder Storage, der für die Archivierung vorgesehen ist und längere Latenzzeiten beim Zugriff hat, dafür aber preisgünstiger ist.
• 4. Traffic: Die Hyperscaler lassen sich den Traffic von außen recht gut bezahlen. Während der „normale“ Traffic aus Interaktion der User mittels http relativ überschaubar ist, kann sich der Datenaustausch beim Hybrid-Cloud-Ansatz schnell summieren.
• 5. Betrieb / Support: Oft wird bei Migrationsprojekten in die Cloud vergessen, dass die fertige Lösung in der Produktion auch kompetent betreut werden muss. Vorhandenen Betriebsteams, die sich bisher nur mit der Server- und Applikationsbetreuung „On Premise“ beschäftigt haben, fehlt oft das Expertenwissen für die Cloud-Lösung. Dazu gehört auch die schnelle Skalierung oder gezielte Eingriffe in die Produktionsumgebung bei Störungen.

Lösungsansätze

Zunächst sollten man bei Migrationsprojekten immer erfahrene Architektinnen und Architekten an Bord haben, die vorab nichtfunktionale Anforderungen (NFA) erarbeiten und diese für die Festlegung der Architektur, insbesondere den Serviceschnitt und die Serviceverfügbarkeit, nutzen.

Unsere Expertinnen und Experten im Bereich Software Architektur bei adesso bringen sowohl diese technische Erfahrung als auch das fachliche Wissen mit, um den für das jeweilige Business des Kunden passenden Architekturvorschlag zu erarbeiten und umzusetzen.

Auch bei Bestandsprojekten können eine Architekturreview und ggf. ein Refactoring helfen. Genauso kann auch die verwendente Storage-Klasse überprüft werden. Wie bereits oben erwähnt, benötigt ein Archivierungsservice keinen Online-Storage.

Die folgende Abbildung stellt (stark vereinfacht) ein Problem mit dem Serviceschnitt dar:

Zum Thema „RAM“: Für einen kleinen Footprint der Services und damit geringen Ressourcenverbrauch sollte zunächst das Docker Basisimage klug gewählt werden. Hier kann auch bei Bestandsprojekten oft ein Quick-Win erzielt werden, indem dieses Image ausgetauscht wird - ein Einzeiler pro Container-Definition, meist ohne weitere Anpassungen am Service selber.

Viel wichtiger ist aber die Wahl eines Frameworks mit dem Label „Cloud Native“. Prominente Vertreter dieser Kategorie sind Quarkus und Micronaut, die beim Kompilieren auf die native Zielplattform sehr kleine Images erzeugen du die Container unglaublich schnell starten.

Hier geht es wohlgemerkt nicht um ein paar Prozent, die man einsparen kann, sondern um einen Faktor zehn oder mehr Unterschied im Footprint. Ähnliche Vorteile gibt es auch bei Startup-Zeiten, was sich auch auf die Geschwindigkeit bei der Softwareentwicklung auswirkt.

Leider werden sehr oft Frameworks verwendet, die im Unternehmen bekannt und verbreitet sind, aber „fette“ Deployment-Artefakte und in der Folge auch hohe Kosten bei RAM-Sekunden erzeugen. Hier ist eine nachträgliche Migration auf eines der genannten Frameworks aufwändig und teuer, kann sich aber auf lange Sicht lohnen. Denn RAM-Sekunden sind einer der Haupttreiber bei den Cloud-Kosten.

Die folgende Abbildung zeigt die Größenordnung des RAM-Footprint:

Wenn man nicht nativ kompilieren kann oder will, kann ein weiterer Quick-Win in Sachen Speicherverbrauch die Nutzung moderner Laufzeitumgebungen sein, etwa eines JDK ab Version 21. Ein Highlight dieser Version ist die Implementierung der „Virtual Threads“, die eine Erzeugung einer enormen Anzahl von Threads ohne signifikanten Speicherverbrauch ermöglichen.

Dies ist gerade für Frontend-Komponenten interessant, bei denen der Userzugriff per http einen eigenen Thread eröffnet und daher immer in einem Container mit reichlich Speicherreserve betrieben wurde. Diese Reserve kann durch den Umstieg auf ein modernes Java deutlich reduziert werden.

Zum Thema „Betrieb“: Das Betriebsteam muss in der Lage sein, die eingesetzte Technik zu beherrschen und bei Bedarf Probleme schnell zu beheben. Expertenkenntnisse sind hier Trumpf, lassen sich aber nicht kurzfristig aufbauen und „Learning in Production“ sieht bestimmt kein IT-Verantwortlicher gerne.

Unsere Software Architektinnen und Architekten sowie unsere Entwiclerinnen und Entwickler bei adesso beherrschen verschiedene Sprachen und Frameworks und sind gerne bereit, Kunden bei der Auswahl zu unterstützen.

Hohe Sicherheit und geringere Kosten?

Ihr habt sicherlich bemerkt, dass das Thema Sicherheit im letzten Abschnitt nicht beleuchtet wurde. Wie bereits dargelegt, gibt es keine hundertprozentige Garantie, dass die Hyperscaler keine Daten an Geheimdienste weitergeben, da sie alle dem jeweils geltenden US-Recht unterliegen.

Das Angebot an Cloud-Anbietern in Deutschland beziehungsweise Europa ist überschaubar, aber es gibt sie trotzdem. Einige setzen auf die OpenSource Software „OpenStack“ die eine Reihe von standardisierten Cloud-Diensten bereitstellt, zum Beispiel OVHCloud, ElastX, OpenTelekom Cloud oder FugaCloud. Andere Unternehmen verfolgen den Ansatz, nur virtuelle Server anzubieten, bei denen der Kunde dann eigenständig Deployments der Infrastrukturkomponenten organisieren muss – also recht Low Level.

Eine Variante, die zwischen diesen beiden Ausbaustufen liegt, ist „Managed Services“, wo Kubernetes und Datenbanksysteme vom Provider administriert werden.

Einen dieser Anbieter aus der letzten Kategorie möchte ich gerne – zugegeben nicht ohne Eigeninteresse, aber auf jeden Fall aus Überzeugung – herausheben: Die adesso Business Cloud, kurz ABC.

„Okay, aber was ist daran besser?“ wird jetzt sicher als Frage kommen. Hier die wesentlichen Merkmale, die ABC gerade für Anwendungen und Daten mit hohem Schutzbedarf interessant machen:

• C5-testiert
• Erfüllt die ISO-Norm 2700
• Georedundanz: Verteilung auf zwei Lokationen (Frankfurt und Karlsruhe) mit guter Anbindung der Rechenzentren
• Die Daten bleiben definitiv in Deutschland
• Kostenvorteil für CPU / RAM / Storage. Die Kosten bleiben deutlich unter dem Angebot der Hyperscaler
• Für Traffic werden keine Kosten berechnet
• Managed Kubernetes werden unterstützt
• Support für Managed Services und Applikations

Fazit

Die Entscheidung für eine Public-Cloud-Lösung ist in der Regel vorteilhaft, muss aber gut vorbereitet und geplant werden. Insbesondere Architekturentscheidungen sowie die Wahl des richtigen Frameworks sind für die Performance und die Kosten von großer Bedeutung.

Auch bei bereits existierenden Anwendungen lassen sich durch die oben beschriebenen Maßnahmen weitere Einsparungen bei den laufenden Kosten erzielen.

Wenn man mit einer auf Containern und Kubernetes basierenden Architektur zufrieden ist, kann die adesso Business Cloud, eine interessante, sichere und kostengünstige Alternative zu den Hyperscalern sein.