Foto: AurelioaPhoto - shutterstock.com
"Cloud first" ist heutzutage in aller Regel fester Bestandteil jeder IT-Strategie. Dieser Trend hat sich 2020 noch weiter beschleunigt. Eine Verlagerung von Anwendungen in die Cloud entpuppt sich häufig als ein Entwicklungsprojekt, wenn alle Vorteile der IT-Wolke voll genutzt werden sollen. Es ist nicht damit getan, eine bereits bestehende Anwendungsinfrastruktur einfach eins zu eins auf eine vergleichbare Infrastruktur in der Cloud abzubilden. Meist müssen die entsprechenden Applikationen in aktuelleren Programmiersprachen neu entwickelt werden.
Alles neu macht die Cloud
Herausforderungen dieser Art und die damit verbundenen Risiken sind in der Unternehmens-IT nicht neu. Viele Verantwortliche werden sich zum Beispiel an die Anwendungsportierungen von IBM Mainframes auf verteilte "Open-Systems"-Server-Infrastrukturen anderer Hersteller erinnern. In den Anfängen der IT wurden Anwendungen monolithisch entwickelt. Alle Eingabe-, Verarbeitungs- und Ausgabefunktionalitäten waren in einem Programmcode abgebildet. Insbesondere im Zuge der genannten Portierungen ging man dazu über, die Schnittstelle zum Anwender, die Verarbeitung der Anwendung und die Datenhaltung voneinander zu trennen ("Three-Tier-Modell").
Die Ausläufer dieser Softwarearchitektur sind heute noch aktuell – aber für einen Betrieb in der Cloud wenig passend. Das liegt unter anderem daran, dass sie eine On-Premises-Infrastruktur abbildet, die in dieser Form in der Cloud gar nicht mehr vorhanden ist. Es ist zwar durchaus möglich, Cloud-Anwendungen auch als On-premises-Abbild zu realisieren. Aber das ist aufwendig, unflexibel und negiert damit einen der großen Vorteile der Cloud: die leichte Portierbarkeit. Ohne diese Portierbarkeit steigt wiederum die Bindung der Anwender an einen einzelnen Cloud-Provider und damit die Abhängigkeit von diesem externen Partner.
Lesen Sie mehr zum Thema Microservices und Container-Techniken:
Deshalb denken Unternehmen im Zuge der Migration in die Cloud intensiv über neue Architekturprinzipien für ihre Softwarelandschaft nach – falls diese monolithisch oder nach dem herkömmlichen Three-Tier-Modell implementiert wurde. Das kommt dann einem Redesign von Anwendungen gleich – ein sogenannter "Full-rebuild"-Ansatz.
- Robin Parr, Neos
"Wie stark der Impact von Cloud-native ist, sieht man auch an Themen wie DevOps: Während Entwicklung und Betrieb in traditionellen Umgebungen möglichst nah zusammenwachsen, existiert diese Trennung bei Cloud-native schon gar nicht mehr: „Dev" und „Ops" sind dort ein und dieselbe Person." - Heinz Bruhn, Rackspace
"Cloud-native bedeutet mehr Freiheit, die gleichzeitig mit gestiegenen Ängsten bei den Unternehmen einher geht – auf prozessualer, auf technologischer und nicht zuletzt auf organisatorischer Ebene. Um diese zu adressieren, braucht es die Bereitschaft der Geschäftsführung, auf jeder dieser Ebenen die notwendigen Veränderungen anzustoßen." - Matthias Kranz, Red Hat
"In der Diskussion mit Kunden treten wir häufig ganz bewusst einen Schritt zurück und fragen: Warum soll es überhaupt die Cloud sein? Auf der Basis dieser Frage gilt es dann, eine klare Strategie zu formulieren und nicht einfach „Lift and Shift” zu betreiben. Das gilt auch und vor allem für die kulturelle Ebene: Gerade in großen Unternehmen führt eine allzu schnelle Migration zu Unsicherheit und auch zu Widerstand. Erst wenn der Nutzen klar wird, verschwinden die Ängste." - Rene Funk, Maturity
"DevOps ist grundsätzlich der richtige Ansatz, wenn es von der Organisation entsprechend konsequent umgesetzt wird –- strukturell und kulturell. Vergleiche mit traditionellen Methoden belegen, dass dann die Abstimmung zwischen Angebot und Nachfrage schneller läuft, Fehlerquoten sinken und unter dem Strich die Applikations-TCO reduziert wird." - Marcus Flohr, Delphix
"Wir können uns Prozesse und Technologien ausdenken, wie wir wollen: Wenn die richtige kulturelle Basis nicht da ist, dann laufen wir gegen Wände. Diese Voraussetzungen schaffen wir aber nur in einem kontinuierlichen Prozess, der die gesamte Organisation betrifft. Eine Ausgründung in Form eines Start-ups kann oft auch ein Entwicklungshemmer sein, da die generierten Innovationen es nicht in die Mitte des Unternehmens schaffen." - Simon Fleischer, ConSol
"An die Stelle von technischem Know-how tritt in Cloud-native-Umgebungen das Business-Know-how, das den Nutzen einer Technologie in den Vordergrund stellt. Vor allem mit Blick auf den Fachkräftemangel ergeben sich für viele Unternehmen so auch Chancen. Sie können sich fragen, welches Wissen sie wirklich im Haus benötigen." - Benjamin Treichel, Brockhaus
"Die gewissenhafte Analyse von Prozessen ist ein wesentliches Erfolgskriterium bei der Überführung von Unternehmensinfrastrukturen in die Cloud. Wenn von oben einfach nur die Ansage „Wir machen ab jetzt Cloud” kommt, dann kommt lediglich „Lift and Shift“ dabei heraus. Erst wenn Unternehmen verstehen, dass die Migration ein langwieriger, aber lohnenswerter Prozess ist, schaffen sie den Sprung. Ein großer Hemmschuh ist außerdem nach wie vor die Security. - Dominic Lindner, ownCloud
"Gerade in mittelständischen Unternehmen besteht häufig eine hohe Unsicherheit, ob sich die hohen Kosten und Aufwendungen der Integration von Daten in die Cloud lohnen und wo man genau ansetzen kann. Hier gilt es, mithilfe von klaren Use-Cases, erste Ansätze der Nutzung von Cloud kostengünstig zu erproben."
Container statt Monolithen
State of the Art ist heutzutage, Anwendungen auf möglichst kleine Funktionsblöcke aufzuteilen und diese gut separierbaren Funktionen als Microservices zu betreiben. Eine Vielzahl solcher Microservices kann von unterschiedlichsten Anwendungen genutzt werden, und Änderungen beziehungsweise Fehlerbehebungen lassen sich aus Gesamtanwendungssicht "minimalinvasiv" vornehmen, da in der Regel immer nur ein Microservice betroffen ist. Dies kommt agilen Entwicklungsmethoden und dem DevOps-Ansatz sehr zugute. Auch umfangreiche Anwendungen mit sehr vielen Nutzern können so während der Laufzeit "on the fly" aktualisiert werden. Große Anwendungen im Internet (wie zum Beispiel Amazon, eBay, Facebook, Google, Netflix usw.) werden auf diese Weise mindestens einmal, aber auch bis zu 100 Mal pro Tag aktualisiert.
Ein wesentlicher weiterer Vorteil von Microservices ergibt sich, wenn diese in betriebssystemunabhängigen Containern betrieben werden. Container stellen alle für die Verarbeitung von Programmcode erforderlichen Ressourcen unabhängig von physischen Servern und deren Betriebssystemplattformen zur Verfügung. Diese Architektur ermöglicht so einen einfacheren verteilten Einsatz sowie eine unkomplizierte und schnelle Portierbarkeit: Das wiederum reduziert aus Sicht von Sourcing-Strategen die Abhängigkeit von einzelnen Herstellern (zum Beispiel für Server und Betriebssysteme) oder aber die Abhängigkeit von einzelnen Hyperscalern (zum Beispiel Microsoft, AWS, Google), da man seine Programme in den Containern schnell und meist ohne größere Abhängigkeiten von Cloud A nach Cloud B verschieben kann (die Migration der Daten mal außen vor gelassen).
Lesen Sie mehr über die Sicherheit in Container-Umgebungen:
Container wie beispielsweise Docker, eine freie Software der Apache Software Foundation, passen somit nicht nur perfekt zu einem auf Microservices basierten Software-Architekturansatz, sondern wirken auch weitgehend einem bei vielen IT- und Einkaufsorganisationen gefürchteten Supplier- beziehungsweise Provider-Lock-in entgegen.
Microservices brauchen eine gute Verwaltung
Für den Betrieb und die Verwaltung von Myriaden von Microservices benötigt man allerdings eine Management-Software, die hilft, den Überblick zu behalten und die Microservices zu orchestrieren. Bekanntester und beliebtester Vertreter ist derzeit Kubernetes der Cloud Native Computing Foundation. Diese Open-Source-Software unterstützt durch Automatisierung den Microservices-Betrieb – vom Einrichten, Starten, Überwachen bis hin zum Skalieren sowie der Sicherstellung von Hochverfügbarkeit.
Wird das Ganze auch noch mit einer sogenannten CI/CD-Pipeline (Continuous Integration, Continuous Delivery und Continuous Deployment) kombiniert, lassen sich in Container-Umgebungen fabrikähnliche Verfahren von der Software-Entwicklung über das Testing bis hin zum automatisierten Deployment von Software realisieren. Die Bereitstellung und der Betrieb von verteilten und plattformunabhängigen Anwendungen wird also zukünftig stark erleichtert, indem manuell installierte Server, Betriebssysteme, Storages usw. durch automatisch erzeugte und bereitgestellte Instanzen ersetzt und automatisch verwaltet werden.
Microservices und ihre Bündelung in Containern haben also nicht nur aus technischer und betrieblicher Sicht hohe Effizienzpotenziale bei der Migration in die Cloud. Sie helfen auch dabei, dass sich Unternehmen nicht in Abhängigkeiten von Cloud-Anbietern begeben müssen und ihre Cloud-Sourcing-Strategien erheblich flexibler gestalten können – Voraussetzung hierfür ist jedoch, dass man sich von den zum Teil stark proprietären funktionalen Angeboten der Cloud-Anbieter (zum Beispiel aus dem KI-Bereich) nicht verführen lässt. (ba)