To Cloud or not to Cloud\u2026<\/p>\n\n\n\n
dies ist heute keine Frage mehr. Alle wollen in die Cloud und zwar so schnell wie m\u00f6glich. Die Cloud ist sexy, die Cloud ist 30% billiger und alles ist besser in der Cloud.<\/p>\n\n\n\n
Aber, stimmt das auch?<\/p>\n\n\n\n
Nat\u00fcrlich nicht! Zumindest nicht ohne dass man seinen bisherigen Modus Operandi signifikant \u00e4ndert. Aber betrachten wir die Cloud einmal n\u00fcchtern und spielen eine typische Cloudmigration durch.<\/p>\n\n\n\n
Der erste und einfachste Ansatz ist \u201eLift-and-Shift\u201c, d.h. dass m\u00f6glichst 1:1 transferieren der bestehenden Umgebung in die Cloud. Ist das m\u00f6glich? Ja, meistens. zumindest teilweise. Ist das sinnvoll? Nein, eher nicht.<\/p>\n\n\n\n
Lift & Shift<\/p>\n\n\n\n
Bei einer Lift & Shift Migration soll die bisherige Umgebung m\u00f6glichst so belassen werden wie sie ist. Keine strukturellen Ver\u00e4nderungen, kein Redesign. Im Grunde eine Migration wie von einer bare-metal auf eine VM-basierte Umgebung. Der Grund hierf\u00fcr ist dass man m\u00f6glichst wenig Arbeit in ein Redesign stecken will (oder daf\u00fcr keine Zeit hat) und auch ein Redesign f\u00fcr zu fehleranf\u00e4llig h\u00e4lt. Am Ende des Tages ist eine Cloud ja auch nur eine virtualisierte Laufzeitumgebung.<\/p>\n\n\n\n
All diese Argumente stimmen und eine solche Migration kann auch gelingen, jedoch sind mehrere Randbedingungen zu beachten. Erstens k\u00f6nnen meist nicht alle Elemente in die Cloud migriert werden. Das kann daran liegen dass bestimmte Elemente in der Cloud nicht verf\u00fcgbar sind, wie z.B. eine Hostumgebung, oder dass f\u00fcr bestimmte Dinge die Lizenzsituation so ung\u00fcnstig ist dass eine Migration sich nicht rechnet, wie z.B. bestimmte Datenbanken (Oracle, DB\/2, \u2026)<\/p>\n\n\n\n
Daraus ergibt sich dass Teile der Arbeitsumgebung on premise bleiben w\u00e4hrend andere Teile in die Cloud gehen und das wiederum bedeutet hohe Bandbreitenanforderungen f\u00fcr die Verbindungen zwischen on premise und Cloud sowie gr\u00f6\u00dfere Latenzzeiten. Dies k\u00f6nnen 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\u00f6her. Selbst wenn man die wegfallenden Betriebskosten dagegenrechnet. Dies bringt uns zum 1. Axiom:<\/p>\n\n\n\n
Cloudbetrieb rechnet sich nur wenn die Betriebszeiten sinken!<\/p>\n\n\n\n
Wenn man in einer Cloud wirklich Geld sparen will, muss man sich die Vorteile der Cloudumgebung gegen\u00fcber der traditionellen IT zu nutze machen. Und der Hauptvorteil ist: dynamische Skalierbarkeit.<\/p>\n\n\n\n
Dynamische Skalierbarkeit<\/p>\n\n\n\n
Traditionelle Umgebungen m\u00fcssen immer auf den maximalen Lastfall skaliert werden. D.h. wenn man das ganze Jahr \u00fcber 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\u00fcrlich 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\u00e4ngige Skalierung ein. D.h. die Anzahl Server w\u00e4chst oder f\u00e4llt mit der abzuwickelnden Last. Dadurch kann man sehr viel Geld sparen, was uns zum 2. Axiom bringt:<\/p>\n\n\n\n
Cloudbetrieb rechnet sich nur bei minimaler und dynamischer Skalierung<\/p>\n\n\n\n
Self-Service<\/p>\n\n\n\n
Neben der technischen Komponente gibt es allerdings auch noch eine organisatorische. Ein Kernkonzept von Cloudumgebungen ist der Self-Service Gedanke. D.h. Benutzer sollen \u00fcber ein Portal in die Lage versetzt werden Cloudkomponenten, VMs, Router, usw. eigenh\u00e4ndig zu bestellen. Dies kann in in-house Workflowsysteme wie ServiceNow integriert werden. Dadurch verringern sich die Bereistellungszeiten drastisch und der organisatorische Aufwand sinkt betr\u00e4chtlich. Somit sind wir beim dritten Axiom:<\/p>\n\n\n\n
Cloudbetrieb rechnet sich nur wenn die Organisationskosten und -zeiten durch Self-Service sinken<\/p>\n\n\n\n
Aber noch weitere Einsparungen lassen sich durch einen intelligenten Cloudbetrieb erreichen. Die n\u00e4chste Automatisierungsstufe besteht in der Aufspaltung der klassischen monolithischen Anwendungen in Microservices die wiederum containerisiert und in Container-Orchestrierungsumgebungen wie Kubernetes ausgef\u00fchrt werden. Der Vorteil hierbei liegt darin dass sich die Anwendungen nun feingranul\u00e4rer 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:<\/p>\n\n\n\n
Cloudbetrieb erreicht weitere Kostenvorteile bei feingranul\u00e4rem Anwendungsbetrieb mittels Containern und Kubernetes<\/p>\n\n\n\n
Aber auch hier sind die Einsparungsm\u00f6glichkeiten noch nicht ausgesch\u00f6pft! 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 \u201eserverless\u201c Betrieb, d.h. man kann die Container bis auf 0 zur\u00fcckskalieren wenn keine Last vorhanden ist. Dies setzen wir in unseren Kubernetes Projekten zur weiteren Kostensenkung f\u00fcr unsere Kunden ein. Also hei\u00dft das n\u00e4chste Axiom:<\/p>\n\n\n\n
Cloudbetrieb l\u00e4sst sich im serverless Modus nochmals g\u00fcnstiger gestalten<\/p>\n\n\n\n
Damit ist man schon sehr weit mit den dynamisch erzielbaren Kosteneinsparungen. Aber l\u00e4ngst 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\u00fcgbarkeit, d.h. k\u00f6nnen jederzeit gestoppt werden. Es tritt also sozusagen ein \u201eerwarteter Desaster Fall\u201c 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\u00e4ren und Spot Instanzen, damit eine minimale Clusterverf\u00fcgbarkeit immer garantiert ist. Aber auch dann kann man immer noch Kostenvorteile von 30% bis 50% erzielen. Das n\u00e4chste Axiom lautet also:<\/p>\n\n\n\n
Cloudbetrieb l\u00e4sst sich nochmals drastisch durch Einsatz von Spot Instanzen verbilligen<\/p>\n\n\n\n
Wenden wir uns nun wieder der Anwendungsseite zu. Gro\u00dfe Geschwindigkeits- und Kostenvorteile lassen sich in der Anwendungsentwicklung in der Cloud erzielen. Das Stichwort hei\u00dft hierbei DevOps. DevOps steht f\u00fcr Developer Operations, d.h. die Entwickler \u00fcbernehmen auch Betriebsaufgaben, die Klassischerweise in einer anderen Betriebsabteilung aufgeh\u00e4ngt 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 \u00fcbergab diese dann einschlie\u00dflich Betriebshandbuch, Installationsanleitung und Testverfahren an den Betrieb. Dieser ben\u00f6tigte 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\u00dfen, 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\u00f6glich 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\u00fcrzel CI\/CD beschrieben: Continuous Integration \/ Continuous Deployment.<\/p>\n\n\n\n
Das n\u00e4chste Axiom ist somit:<\/p>\n\n\n\n
Cloudbetrieb verbilligt und beschleunigt die Softwareentwicklung durch Einsatz von DevOps und CI\/CD drastisch<\/p>\n","protected":false},"excerpt":{"rendered":"
To Cloud or not to Cloud\u2026 dies ist heute keine Frage mehr. Alle wollen in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-231","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.adartis.de\/index.php?rest_route=\/wp\/v2\/pages\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.adartis.de\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.adartis.de\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.adartis.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.adartis.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.adartis.de\/index.php?rest_route=\/wp\/v2\/pages\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.adartis.de\/index.php?rest_route=\/wp\/v2\/pages\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.adartis.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}