Cloud-Computing

Zwischen „Lift and Shift“ und Cloud-native

26. April 2022, 16:00 Uhr | Autor: Björn Pritzel / Redaktion: Sabine Narloch

Fortsetzung des Artikels von Teil 1

Cloud-Native-Maturity-Modell

Um zu beurteilen, wo Unternehmen mit ihrer Applikation auf dem Weg zu einer Cloud-Native-Applikation technologisch stehen, kann man sich an einem Maturity-Modell orientieren. Technisch gesehen lässt sich das Modell sinnvoll in vier Stufen unterteilen.

  1. Stufe 1: Cloud Ready
    Die Applikation wird in einem paketierten und lauffähigen Zustand bereitgestellt (Container/ Image) und ist nicht an ein Dateisystem gebunden. Storage wird über eine Abstraktionsschicht oder API angesprochen. Die Applikation kann netzseitig flexibel über beliebige Adressen und Ports erreichbar gemacht werden und nutzt über das Netzwerk angebundene-Cloud Services.
  2. Stufe 2: Cloud Friendly
    Konfigurationen und Credentials sind losgelöst vom Applikationscode, die Build-, Release- und Run-Prozesse werden strikt voneinander getrennt. Die Applikation kann schnell gestartet und gestoppt werden, sie lässt sich elastisch skalieren, schnell bereitstellen und macht den Produktionsbetrieb robuster.
  3. Stufe 3: Cloud Resilient
    Die Applikation wird fehlertolerant konzeptioniert, um kaskadierende Fehlerketten und Single-Point-of-Failures (SPOF) zu vermeiden. Sie liefert Status- und Performance-Werte sowie dazugehörige Logmeldungen und wird proaktiv auf Fehler/Ausfälle getestet. Zudem ist die Applikation möglichst Cloud-agnostisch konzipiert.
  4. Stufe 4: Cloud Native
    Die Applikation ist vollständig basierend auf Microservices umgesetzt und die Entwicklung erfolgt mit einem API-First-Design-Ansatz. Sicherheit ist fester Bestandteil des Applikationsdesign und der CI-/CD-Pipeline, Aktualisierungen werden permanent ausgeliefert.

 

Cloud Native versus Wasserfall-Prinzip

Ähnlich wie DevOps handelt es sich auch bei Cloud Native um mehr als nur ein technologisches Konzept. Die Entwicklung und Kultur eines Unternehmens muss im Gesamtkontext mit betrachtet werden, was eine organisatorische Transformation des Unternehmens notwendig machen kann. Ohne diese Neuausrichtung auch auf organisatorischer Ebene kommt es schnell zu einem Konflikt der eingesetzten Technologien und der gelebten Unternehmenskultur (siehe Matrix zu den Eigenschaften der beiden Ansätze).

Anbieter zum Thema

zu Matchmaker+
Charakteristika Wasserfall-Modell Charakteristika Cloud-Native-Ansatz
Kultur/Team:
Streng hierarchische Organisation (Top-down) innerhalb und zwischen den Teams.

Kultur/Team:
Crossfunktionale Teams übernehmen die gesamte Verantwortung über den kompletten Lifecycle einer Applikation/ von Microservices.

Produkt/ Service/Design:

Die Produkt- und Release-Planung erfolgt langfristig mit langen Zeitabständen zwischen einzelnen Veröffentlichungen (1/2 - 1 Jahr oder länger), die Realisierung erfolgt in detailliert geplanten, aufeinander folgenden Schritten.

Produkt/ Service/Design:

High-Level-Ziele werden langfristig definiert, die Realisierung erfolgt dynamisch mit kleinen, häufigen und kurzfristigen Zwischenzielen.

Delivery/Betrieb

Das Go-live eines neuen Releases ist aufgrund einer Vielzahl von Abhängigkeiten und Code-Änderungen mit Unsicherheiten und Risiken verbunden.

Delivery/Betrieb:

Änderungen können mitunter täglich auf Produktion released werden, das eröffnet Räume für Experimente und Innovationen.

Wartung:

Prozesse sind nicht oder nur wenig automatisiert – sowohl auf Entwicklungs- als auch auf Betriebsseite. Die Provisionierung neuer Systeme dauert von Stunden bis hin zu Tagen und Wochen.

Wartung:

Applikationen werden als Container mit allen Abhängigkeiten von den verantwortlichen Teams zusammengestellt und standardisiert ausgeliefert. Systeme sind beliebig in kurzer Zeit vollständig ersetz- bzw. erneuerbar.

 

Zusammengefasst lässt sich feststellen: Unternehmen können eine Applikation mit dem Lift-and-Shift-Ansatz in der Cloud lauffähig machen. Sie nutzen damit jedoch nur einen Bruchteil des Potentials und der vielfältigen Möglichkeiten. Ein Cloud-Native-Maturity-Modell hilft bei der Beurteilung des Cloud-Reifegrads und bei der Ermittlung notwendiger Schritte zum Erreichen der nächsten Stufe.

Björn Pritzel ist Solution Architekt im Service-Design-Team bei Adacor


  1. Zwischen „Lift and Shift“ und Cloud-native
  2. Cloud-Native-Maturity-Modell

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu ADACOR Hosting GmbH

Weitere Artikel zu Public Cloud

Matchmaker+