To Cloud or not to Cloud…
dies ist heute keine Frage mehr. Alle wollen in die Cloud und zwar so schnell wie möglich. Die Cloud ist sexy, die Cloud ist 30% billiger und alles ist besser in der Cloud.
Aber, stimmt das auch?
Natürlich nicht! Zumindest nicht ohne dass man seinen bisherigen Modus Operandi signifikant ändert. Aber betrachten wir die Cloud einmal nüchtern und spielen eine typische Cloudmigration durch.
Der erste und einfachste Ansatz ist „Lift-and-Shift“, d.h. dass möglichst 1:1 transferieren der bestehenden Umgebung in die Cloud. Ist das möglich? Ja, meistens. zumindest teilweise. Ist das sinnvoll? Nein, eher nicht.
Lift & Shift
Bei einer Lift & Shift Migration soll die bisherige Umgebung möglichst so belassen werden wie sie ist. Keine strukturellen Veränderungen, kein Redesign. Im Grunde eine Migration wie von einer bare-metal auf eine VM-basierte Umgebung. Der Grund hierfür ist dass man möglichst wenig Arbeit in ein Redesign stecken will (oder dafür keine Zeit hat) und auch ein Redesign für zu fehleranfällig hält. Am Ende des Tages ist eine Cloud ja auch nur eine virtualisierte Laufzeitumgebung.
All diese Argumente stimmen und eine solche Migration kann auch gelingen, jedoch sind mehrere Randbedingungen zu beachten. Erstens können meist nicht alle Elemente in die Cloud migriert werden. Das kann daran liegen dass bestimmte Elemente in der Cloud nicht verfügbar sind, wie z.B. eine Hostumgebung, oder dass für bestimmte Dinge die Lizenzsituation so ungünstig ist dass eine Migration sich nicht rechnet, wie z.B. bestimmte Datenbanken (Oracle, DB/2, …)
Daraus ergibt sich dass Teile der Arbeitsumgebung on premise bleiben während andere Teile in die Cloud gehen und das wiederum bedeutet hohe Bandbreitenanforderungen für die Verbindungen zwischen on premise und Cloud sowie größere Latenzzeiten. Dies können in manchen Situationen schon Showstopper sein. Aber es geht noch weiter. Wenn man die Kosten der bisherigen virtualisierten Umgebung on premise ansieht und diese mit einem 24×7 Betrieb in der Cloud vergleicht sind die Kosten in der Cloud deutlich höher. Selbst wenn man die wegfallenden Betriebskosten dagegenrechnet. Dies bringt uns zum 1. Axiom:
Cloudbetrieb rechnet sich nur wenn die Betriebszeiten sinken!
Wenn man in einer Cloud wirklich Geld sparen will, muss man sich die Vorteile der Cloudumgebung gegenüber der traditionellen IT zu nutze machen. Und der Hauptvorteil ist: dynamische Skalierbarkeit.
Dynamische Skalierbarkeit
Traditionelle Umgebungen müssen immer auf den maximalen Lastfall skaliert werden. D.h. wenn man das ganze Jahr über nur die Leistung von 1-2 Servern braucht, zu Weihnachten oder zum Jahreswechsel jedoch 5 Server, dann muss man 5 Server anschaffen und betreiben und zwar das ganze Jahr. Dies nennt man Skalierung auf das Lastmaximum. Natürlich laufen die Server fast das ganze Jahr mit Minimallast und kosten dabei viel Geld, aber anders ist das traditionell nicht zu machen. Anders in der Cloud! Hier skaliert man seine Umgebung auf die Minimallast und baut eine dynamische, lastabhängige Skalierung ein. D.h. die Anzahl Server wächst oder fällt mit der abzuwickelnden Last. Dadurch kann man sehr viel Geld sparen, was uns zum 2. Axiom bringt:
Cloudbetrieb rechnet sich nur bei minimaler und dynamischer Skalierung
Self-Service
Neben der technischen Komponente gibt es allerdings auch noch eine organisatorische. Ein Kernkonzept von Cloudumgebungen ist der Self-Service Gedanke. D.h. Benutzer sollen über ein Portal in die Lage versetzt werden Cloudkomponenten, VMs, Router, usw. eigenhändig zu bestellen. Dies kann in in-house Workflowsysteme wie ServiceNow integriert werden. Dadurch verringern sich die Bereistellungszeiten drastisch und der organisatorische Aufwand sinkt beträchtlich. Somit sind wir beim dritten Axiom:
Cloudbetrieb rechnet sich nur wenn die Organisationskosten und -zeiten durch Self-Service sinken
Aber noch weitere Einsparungen lassen sich durch einen intelligenten Cloudbetrieb erreichen. Die nächste Automatisierungsstufe besteht in der Aufspaltung der klassischen monolithischen Anwendungen in Microservices die wiederum containerisiert und in Container-Orchestrierungsumgebungen wie Kubernetes ausgeführt werden. Der Vorteil hierbei liegt darin dass sich die Anwendungen nun feingranulärer skalieren lassen und somit nur die Teile der Software im laufenden Betrieb dupliziert werden die auch gebraucht werden. Dies bedeutet weitere Kosteneinsparungen. Also lautet das vierte Axiom:
Cloudbetrieb erreicht weitere Kostenvorteile bei feingranulärem Anwendungsbetrieb mittels Containern und Kubernetes
Aber auch hier sind die Einsparungsmöglichkeiten noch nicht ausgeschöpft! Im klassischen Kubernetes Betrieb skaliert man die Container von 1 bis n, d.h. man muss mindestens einen Container von jedem Microser vice am laufen halten, selbst wenn dieser nichts tut. Es gibt jedoch auch im Bereich Container den sogenannten „serverless“ Betrieb, d.h. man kann die Container bis auf 0 zurückskalieren wenn keine Last vorhanden ist. Dies setzen wir in unseren Kubernetes Projekten zur weiteren Kostensenkung für unsere Kunden ein. Also heißt das nächste Axiom:
Cloudbetrieb lässt sich im serverless Modus nochmals günstiger gestalten
Damit ist man schon sehr weit mit den dynamisch erzielbaren Kosteneinsparungen. Aber längst noch nicht am Ende. Es gibt im Cloudbetrieb eine Art von virtuellen Servern die nochmals 60% – 90% billiger sind als die normalen virtuellen Server: sogenannte Spot Instanzen. Diese Spot Instanzen werden quasi zu einem Bietpreis versteigert und haben keine garantierte Ver fügbarkeit, d.h. können jederzeit gestoppt werden. Es tritt also sozusagen ein „erwarteter Desaster Fall“ ein. Da man Kubernetes Cluster, z.B. einen AWS EKS Kubernetes Cluster, mittels Autoscaler automatisch an Lasten anpassen kann bzw. Knoten die gestorben sind automatisch neu aufsetzen kann, kann man hierzu auch Spot Instanzen verwenden. Wir empfehlen einen Mix aus regulären und Spot Instanzen, damit eine minimale Clusterverfügbarkeit immer garantiert ist. Aber auch dann kann man immer noch Kostenvorteile von 30% bis 50% erzielen. Das nächste Axiom lautet also:
Cloudbetrieb lässt sich nochmals drastisch durch Einsatz von Spot Instanzen verbilligen
Wenden wir uns nun wieder der Anwendungsseite zu. Große Geschwindigkeits- und Kostenvorteile lassen sich in der Anwendungsentwicklung in der Cloud erzielen. Das Stichwort heißt hierbei DevOps. DevOps steht für Developer Operations, d.h. die Entwickler übernehmen auch Betriebsaufgaben, die Klassischerweise in einer anderen Betriebsabteilung aufgehängt waren. Hierzu ein Beispiel: Vor DevOps lief der Betrieb typischerweise so: Die Entwicklungsabteilung entwickelte ca. alle 2-3 Monate ein neues Release der Software und übergab diese dann einschließlich Betriebshandbuch, Installationsanleitung und Testverfahren an den Betrieb. Dieser benötigte dann 1-2 Stunden um die Software in Betrieb zu nehmen und diese Inbetriebnahme zu dokumentieren. D.h. der Releasezyklus betrug eine neue Version ca. alle 2-3 Monate. Mit DevOps sieht die Sache so aus: Der Entwickler checkt eine neue Version seiner Software in das Softwarerepository ein, automatisch wird ein Build angestoßen, die Software in einen Container deployed und dieser dann automatisch auf dem Kubernetes Cluster installiert und getestet. Dieser ganze Vorgang dauert ca. 2-5 Minuten, je nach Softwareumfang. Das bedeutet heute ist es möglich 30 bis 50 mal am Tag ein neues Release einzuspielen und auch automatisch zu testen. Dies beschleunigt zum einen die Softwareentwicklung enorm, zum anderen kann Betriebspersonal eingespart und anderswo eingesetzt werden. Dieser automatische Vorgang wird auch durch die Kürzel CI/CD beschrieben: Continuous Integration / Continuous Deployment.
Das nächste Axiom ist somit:
Cloudbetrieb verbilligt und beschleunigt die Softwareentwicklung durch Einsatz von DevOps und CI/CD drastisch