Uncategorised

Cloud Strategie

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 24x7 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

 

Preise

Bare Metal Cloud(MaaS)

  • Automatische Erkennung und Registrierung jedes Netzwerk-Devices
  • Deployment von Ubuntu, CentOS, Windows, RHEL und SuSE auf Knopfdruck
  • Konfiguration der Netzwerkinterfaces mit Bridges, VLANs, Bonds und mehr
  • Integration mit DevOpsTools
  • Komplettpreis für bis zu 10 Server
  • Preis: 7.500€
 

Containerisierte private Cloud

  • Private Cloud basierend auf Container Clusterplattform Kubernetes
  • Verwaltungsinterface Rancher
  • Aufbau einer schlüsselfertigen, skalierbaren  Containerplattform mit bis zu 10 Ser vern
  • Preis: 10.000€
 

OpenStack private Cloud

  • OpenStack Cloud basierend auf Modulen für Networking, Storage und Compute
  • Basierend auf MaaS als Bare Metal Orchestrierung
  • Block- und Object-Storage basierend auf Ceph
  • Komplettpreis für bis zu 10 Server
  • Preis: 17.500€
 

PaaS Plattform auf OpenStack

  • OpenShift PaaS basierend auf OpenStack Cluster
  • Alternativ: CloudFoundry PaaS on OpenStack
  • Aufbau der PaaS und Integration der Java CI/CD
    • Automatisches Jenkins Deployment in Cloud
  • OpenStack muss vorhanden sein
  • Preis: 17.500€
 

Cloud Management

  • Wir betreiben Ihre private Cloud
  • Monitoring, Backup und Restore, Reporting
  • Provisionierungvon VMs
  • Integration in Ihre CI/CD Chains
  • Wartung und Patching
  • Preis: 1.200€ Tagessatz / 150€ Stundensatz
 

Cloud Schulung

  • Wir schulen Sie in allen Cloudtechnologien
    • Metal as a Service
    • Kubernetes
    • OpenStack
    • CloudFoundry
    • OpenShift
    • Cloudify
    • Ter raform
  • Preis: 1.200€ Tagessatz / 150€ Stundensatz

Kontaktieren Sie uns per E-Mail und erfahren Sie mehr !  E-Mail: bmueller [at] adartis.de

Terraform

Ter raform ist so wie Cloudify ein Orchestrierungswerkzeug. Der Unterschied zu Cloudify liegt darin dass Terraform rein über die Befehlszeile und über textbasierte Konfigurationsdatei en konfiguriert und bedient wird. Der Vorteil von Terraform gegenüber Cloudify liegt in der Vielzahl der unterstützten Clouds und Softwarepakete. Mit Hilfe von Terraform kann man so gut wie alles orchestrieren.

Der Nachteil gegenüber Cloudify sind der mangelnde Bedienungskomfort und der Umstand dass Terraform Skripte sehr spezifisch für die jeweilige Umgebung sind und daher für andere Umgebungen kaum wiederverwendet werden können. Tools wie Cloudify haben hier eine höhere Abstraktionsebene und sind dadurch universeller wiederverwendbar.

Ein Terraform Skript für den Aufbau einer Installation in einer AWS Cloud muss für eine Azure oder GCP Cloud fast komplett neu geschrieben werden.

Ein Cloudify Design für AWS ist jedoch mit wenig Aufwand an ein Azure oder GCP Design anzupassen.

Terraform wird daher vor allem dort eingesetzt wo man sich auf eine spezifische Cloud spezialisiert hat oder wo man eine sehr granulare Konfiguration der Cloudfeatures benötigt.

Kontaktieren Sie uns per E-Mail und erfahren Sie mehr !  E-Mail: bmueller [at] adartis.de

Cloud Migration

Wir migrieren Ihre Anwendungen in die Cloud

Wenn Sie den Weg in die Cloud antreten wollen, müssen Sie Ihre Anwendungen in die Cloud migrieren. Das Problem ist jedoch, viele Anwendungen sind per se nicht cloudfähig.

Um Anwendungen in die Cloud zu bringen gibt es verschiedene Ansätze:

  • Re-Host
    Die Anwendung wird einfach in der Cloud in einer VM mit dem gleichen Betriebssystem neu installiert. Sie wird eventuell minimal umkonfiguriert, nutzt aber nicht die besonderen Vorteile der Cloud.
  • Re-Platform
    Die Anwendung wird in der Cloud in einer VM neu installiert, es werden aber z.B. Betreibssystem oder die Datenbank verändert. Dadurch können eventuell Cloudvorteile genutzt werden, wie verteilte und skalierbare Datenbanken.
  • Re-Factor
    Die Anwendung wird in der Cloud in einer VM installiert und an die Cloud Services angepasst. Das kann neben der Datenbank auch das Monitoring, Backup und Restore oder Containerisierung sein.
  • Re-Engineer
    Die Anwendung wird architekturell im Code verändert um sie an die Cloud anzupassen. Stateful Anwendungen werden stateless, Persistierung geht in eine Datenbank und nicht mehr ins Filesystem, die Anwendung wird von einer monolithischen zu einer Microservice-basierten umgebaut.
  • Re-Purchase
    Die Altanwendung ist nicht cloudfähig zu machen und wird in einer cloudfähigen Version neu beschafft.

 

adARTIS Cloud Migration Factory

Wir führen mit Ihren Anwendungen ein Application-Assessment durch und klassifizieren Ihre Anwendungen in die oben beschriebenen Anwendungsklassen. Dann bestimmen wir die Maßnahmen und Zeiträume bzw. Kosten um die Anwendungen in die Cloud zu migrieren.

Die eigentliche Migration unterstützen wir mit den von uns in jahrelanger Erfahrung erarbeiteten Orchestrierungsworkflows. Denn viel schneller und effektiver als von Hand kann man Migrationen mitt els Tools wie Terraform oder Cloudify durchführen. Dadurch sind wir wesentlich schneller und effektiver als andere Anbieter.

Standardmäßig migrieren wir in die Clouds von Amazon (AWS), Microsoft (Azure) und Google (GCP). Durch den Einsatz unserer standardisierten Tools sind wir aber in der Lage in jede beliebige Cloudplattform mit minimalem Aufwand Anwendungen zu migrieren.

Kontaktieren Sie uns per E-Mail und erfahren Sie mehr !  E-Mail: bmueller [at] adartis.de