Erfolgreiche Cloud-Transition: das Potenzial von Cloud Native

Sie planen gerade die Transition Ihrer Systeme und Applikationen in die Cloud? Dann sind Sie bei Ihren Recherchen sicher auf ein beliebtes IT-Buzzword gestoßen: „Cloud Native“. Wahrscheinlich sind Ihnen weitere Begriffe wie Kubernetes, Container, Microservices und DevOps begegnet. Und vielleicht fragen Sie sich, ob Sie Ihre bisher On-Premises betriebenen Systeme nicht einfach in die Cloud verschieben können. Erfahren Sie jetzt die Antwort auf diese Frage und wie Ihre Cloud-Migration mit dem Cloud-Native-Ansatz gelingt.

Der Cloud-Native-Ansatz basiert auf der Motivation, Applikationen primär für den Einsatz in einer Cloud zu konzeptionieren, zu entwickeln und schließlich zu betreiben. Dadurch lassen sich die Vorteile einer Cloud-Lösung so nutzen, dass sie zu einem echten geschäftlichen Vorteil werden. Für Unternehmen bedeutet eine solche Transition die Einführung neuer Technologien und einen Wechsel zu agilen Denkweisen und Methoden.

Mit Lift-and-Shift sind nicht alle Vorteile der Cloud nutzbar

Generell brauchen Unternehmen ein System oder eine Applikation nicht zwingend an alle Möglichkeiten einer Cloud-Lösung anzupassen, damit diese dort lauffähig sind. Für diverse Einsatzbereiche zählt die Cloud-Migration der Bestandsumgebung mit einem Lift-and-Shift-Ansatz zu den validen und pragmatischen Möglichkeiten. Beispielsweise, wenn es nur darum ginge, bestimmte Compliance-Anforderungen zu erfüllen. Managed Cloud Solution Provider wie Adacor bieten zusätzlich Managed Services an. Sie übernehmen ganz oder teilweise das Management der Server und der verbundenen Platform Services. Das entlastet Unternehmen, denen das Know-how und/oder die personellen Ressourcen für das Management im Haus fehlen.

Der Lift-and-Shift-Ansatz ist die einfachste Art und Weise für eine Cloud-Transition. Damit lassen sich jedoch nicht alle Vorteile einer nachhaltigen Cloud-Lösung nutzen. Nach Abwägung des Kosten-/Nutzenverhältnisses können Optimierungen realisiert werden, die über eine 1:1 Migration per Lift-and-Shift hinausgehen. Ein Klassiker ist die Verschiebung der persistent gespeicherten Daten auf der lokalen Festplatte des Systems hin zur Nutzung eines Shared Storage oder Object Storage Services. Diese werden auf speziell für den Einsatzzweck konzipierten Systemen und Hardware betrieben, sodass sich die Storage-Größe einfach und flexibel skalieren lässt sowie Performance und Verfügbarkeit größer werden.

Mit der Migration geht ein Kulturwandel einher

Die Möglichkeiten der Cloud können sich am besten entfalten, wenn nicht nur die Systeme und Applikationen verlagert, sondern neue Technologien und Vorgehensweisen eingeführt und genutzt werden. Um alle Vorteile nutzen zu können, kombiniert man die neuen Denkweisen, Methoden und Werkzeuge miteinander. Das Ziel ist, an die Entwicklung und den Betrieb von Applikationen sowie die gelebte Unternehmenskultur gesamtheitlich heranzugehen. Die Hürden sind dabei für jedes Unternehmen unterschiedlich. Sie hängen davon ab, ob es um vorwiegend langjährig betriebene Legacy-Applikationen geht, die mit wenigen Anpassungen „Cloud Ready“ gemacht werden oder um vor allem neue Applikationen, die von Grund auf für den Betrieb auf Cloud-Plattformen konzipiert und entwickelt wurden, also „Cloud Born“ sind.

Die 4 größten Vorteile des Cloud-Native-Ansatzes

Microservices, Container und Kubernetes bilden die Basis

Die Ausgangsbasis für die Transition mit dem Cloud-Native-Ansatz ist eine flexible und modulare Applikations-Architektur, die durch Aufteilung in Microservices erreicht wird. Jeder Microservice implementiert für sich einen Prozess oder eine Funktion und ist selbst lauffähig. Die Microservices kommunizieren untereinander über definierte APIs und Message Queues. Diese Aufteilung sorgt dafür, dass eigene, dedizierte Teams einen Teil der Applikation (einem Microservice) selbst verantworten und die Weiterentwicklung des Microservices unabhängig von anderen Teams vorantreiben.

Die Microservices werden als Container ausgeliefert, damit sie portabel in unterschiedlichen Umgebungen und Cloud-Plattformen lauffähig sind. Ein Container umfasst, neben dem Microservice selbst, alle weiteren Komponenten, die zur Ausführung notwendig sind. Dazu zählt auch die Laufzeitumgebung der genutzten Programmiersprache. Als das gängige Plattform- und Orchestrierungswerkzeug für containerisierte Applikationen hat sich Kubernetes etabliert. Deshalb ist die Software fester Bestandteil im Angebot der großen Public Clouds sowie von Cloud- und Hosting-Anbietern wie Adacor.

Mit Cloud Agnostic Vendor-Lock-in-Effekt vermeiden

Weitere für die Gesamtarchitektur erforderliche Services (Datenbanken, Loadbalancer, Monitoring usw.) können Unternehmen als direkt nutzbare Cloud-Dienste aus dem Servicekatalog eines Anbieters beziehen. Das ist ein wichtiger Punkt, denn mit der intensiven Nutzung der Cloud Services geht eine Abhängigkeit zum gewählten Cloud-Anbieter (Vendor-Lock-in-Effekt) einher. Das liegt daran, dass sich die technischen Implementierungen der Cloud Services in der (häufig proprietären) API oder den besonderen Eigenheiten (wie ein unterschiedliches Feature-Set bei Datenbanken) voneinander unterscheiden. Den Anbieter zu wechseln, bedeutet dann, dass der Applikations-Code oder die Gesamtarchitektur umfassend angepasst werden müssen, um die Services des neuen Anbieters korrekt nutzen zu können.

Soll dies bei der Konzeption berücksichtigt werden, so spricht man von einem Cloud-Agnostic-Ansatz. Die Gesamtarchitektur wird auf Basis von Cloud Services konzipiert, die unter dem Gesichtspunkt der Kompatibilität und Portabilität ausgewählt wurden. Nachteilig ist dabei eine reduzierte Anzahl an Möglichkeiten sowie ein zwangsläufiger Verzicht auf spezifische Features und Vorzüge bestimmter Implementierungen. Zudem lassen sich Cloud Services – wie die Applikation selbst – in Kubernetes als Container implementieren. Durch die Abstraktion von Kubernetes, wird die Portabilität erhöht. Da der Kunde dafür verantwortlich ist, den Service innerhalb von Kubernetes zu implementieren und zu betreiben, sind die Vor- und Nachteile in Bezug auf die künftige IT-Strategie abzuwägen: Bietet die Nutzung spezieller für den Einsatzzweck optimierten, innovativen und meist günstigen Varianten eines Anbieters mehr Vorzüge oder der Einsatz von Cloud Services, die auf den größten, gemeinsamen Nenner heruntergebrochen werden und für Unabhängigkeit und Souveränität sorgen.

Cloud-Native-Maturity-Modell: technischer Reifegrad von Applikationen

Um zu beurteilen, wo Unternehmen mit ihrer Applikation auf dem Weg zu einer Cloud-Native-Applikation technologisch stehen, bietet ein Cloud-Native-Maturity-Modell eine gute Orientierung. Es zeigt aus technischer Sicht die einzelnen, erreichbaren vier Stufen auf.

Das Cloud-Native-Maturity-Modell (ausführliche Darstellung)

Cloud Ready (Stufe 1)

• Die Applikation wird in einem paketierten und lauffähigen Zustand bereitgestellt (Container/Image).
• Sie ist nicht an ein zugrunde liegendes Dateisystem gebunden. Der Storage wird über eine Abstraktionsschicht oder API (zum Beispiel S3) angesprochen.
• Die Applikation kann netzseitig flexibel über beliebige Adressen und Ports erreichbar gemacht werden …
• … und sie konsumiert über das Netzwerk angebundene Cloud Services (Datenbank, E-Mail, Caching, Message Queues etc.).

Cloud Friendly (Stufe 2)

• Die Konfigurationen und Credentials (Berechtigungen wie Passwörter oder Keys) sind losgelöst vom Applikationscode und werden getrennt voneinander gepflegt und gespeichert.
• Die Build-, Release- und Run-Prozesse werden strikt voneinander getrennt. Es werden keine Änderungen direkt zur Laufzeit durchgeführt.
• Die Applikation kann parallelisiert ausgeführt werden.
• Die mehrstufigen Umgebungen (Dev, Test, Stage, Prod) werden einheitlich betrieben und die Applikation konsistent in jeder Umgebung auf dieselbe Art und Weise bereitgestellt.
• Die Applikation kann schnell gestartet und gestoppt werden, um elastisch zu skalieren, schnell zu deployen und den Produktionsbetrieb robuster zu machen.
• Administrative Tasks (wie Änderungen im Datenbankschema im Zuge eines neuen Releases) werden als einmalige Prozesse implementiert.

Cloud Resilient (Stufe 3)

• Die Applikation wird fehlertolerant konzeptioniert, um kaskadierende Fehlerketten und Single-Point-of-Failures (SPOF) zu vermeiden sowie spezifische Fehlerszenarien gesondert zu behandeln (etwa durch Default-Werte).
• Die Applikation liefert Status- und Performance-Werte sowie dazugehörige Logmeldungen.
• Das Testing auf Fehler/Ausfälle erfolgt proaktiv (Chaos Engineering).
• Die Konzeption wird möglichst cloud-agnostisch aufgesetzt, damit die Applikation in jeder Cloud betrieben werden kann.

Cloud Native (Stufe 4)

• Die Applikation ist vollständig in einer auf Microservices basierenden Architektur umgesetzt.
• Das Development erfolgt mit einem API-First-Design-Ansatz.
• Sicherheit ist fester Bestandteil des Applikationsdesign und der CI-/CD-Pipeline.
• Die Applikation wird durch Continous Delivery automatisiert ausgeliefert und in kurzen Intervallen stetig aktualisiert.

Der Großteil der Maßnahmen deckt sich mit den technischen Richtlinien der Zwölf-Faktoren-App. Die populäre Methode unterstützt die Programmierung von Software-as-a-Service-Applikationen.

Cloud Native vs. Wasserfall-Prinzip: was ist effizienter?

Wie bei DevOps handelt es sich bei Cloud Native nicht nur um einen technologischen Umstieg, sondern die Entwicklung und Kultur des Unternehmens muss im Gesamtkontext betrachtet werden. Daher ist die Sichtweise möglicherweise mit einer organisatorischen Transformation verbunden. Ein solcher Wandel ist einzigartig und lässt sich nicht in einem schnellen (Neben-)Migrationsprojekt realisieren. Wird auf die Neuausrichtung verzichtet, kommt es schnell zu Konflikten zwischen den eingesetzten Technologien und der gelebten Unternehmenskultur.

Die folgenden Beispiele zeigen die Eigenschaften der beiden Extremen Cloud Native vs. Wasserfall-Modell:

Fazit: Nur Cloud-Native vereint alle Vorteile einer Cloud-Nutzung

Generell können Unternehmen eine Applikation mit dem Lift-and-Shift-Ansatz in der Cloud lauffähig machen (Cloud Ready). Damit nutzen sie aber nur einen Bruchteil des Potenzials und der vielfältigen Möglichkeiten einer Cloud-Lösung. Ein Cloud-Native-Maturity-Modell hilft den aktuellen Cloud-Reifegrad einer Applikation zu beurteilen und die erforderlichen Schritte zu ermitteln, um die nächste Stufe zu ermitteln. Dabei wird der Einsatz von Kubernetes Gegenstand der Diskussion werden.

Damit Kubernetes nutzbar wird, brauchen Unternehmen nicht alle Aspekte des cloud-nativen Ansatzes vollständig zu erfüllen und stringent umzusetzen. Alle Vorzüge hinsichtlich Agilität, Effizienz und Geschwindigkeit lassen sich jedoch nur nutzen, wenn die Unternehmenskultur dies unterstützt und nicht behindert. Eine vollständig auf DevOps und CI/CD ausgerichtete Entwicklung sowie ein Betrieb mit automatisierten Provisionierungs- und Configuration-Management-Prozessen ist hochgradig effizient und reagiert schnell auf unvorhersehbare Begebenheiten. Aufgrund der Behändigkeit mancher Organisationen bleibt dieser Vorteil ungenutzt und die technische Schnelligkeit verpufft. Wenn Unternehmen in langen Release-Zyklen und festen Roadmaps denken, werden sich die getätigten Investitionen (Know-how-Aufbau, Schulungen, Personalaufbau, Migration usw.) nicht auszahlen.