Der Schritt in die Cloud macht Unternehmen von den Limitierungen ihrer eigenen Infrastrukturen unabhängiger. Gleichzeitig machen diese sich aber potenziell von Cloud-Anbietern abhängig. Containerisierung und Microservices helfen nicht nur beim strukturierten Übergang in die Cloud, sondern sind auch ein probates Mittel gegen den gefürchteten "Lock-In".
"Cloud first" ist der Titel der meisten IT-Strategien. Dieser Drang in die Cloud hat sich 2020 noch weiter beschleunigt. Eine Verlagerung von Anwendungen in die Cloud ist häufig ein Entwicklungsprojekt, wenn alle Vorteile der Cloud voll genutzt werden sollen. Es ist nicht damit getan, eine Anwendungsinfrastruktur eins zu eins auf eine vergleichbare Infrastruktur in der Cloud abzubilden. Meist muss die Anwendung in aktuelleren Programmiersprachen neu entwickelt werden.
Neue Umgebung, bekannte Herausforderungen
Herausforderungen (und Risiken) dieser Art 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-Premise-Infrastruktur abbildet, die in dieser Form in der Cloud gar nicht mehr vorhanden ist. Es ist durchaus möglich, Cloud-Anwendungen so zu realisieren. Aber das ist aufwendig und unflexibel und negiert damit einen der großen Vorteile der Cloud: die leichte Portierbarkeit. Ohne Portierbarkeit steigt wiederum die Bindung an einen einzelnen Cloud-Provider und damit die Abhängigkeit von einem externen Partner.
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.
Microservices statt Monolithen
State of the art ist heutzutage, Anwendungen auf möglichste 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 können aus Gesamtanwendungssicht "minimalinvasiv" vorgenommen werden, da in der Regel immer nur ein Microservice betroffen ist. Dies kommt agilen Entwicklungsmethoden und dem DevOps-Ansatz sehr zugute. Auch sehr große Anwendungen mit sehr vielen Nutzern können so während der Laufzeit "on the fly" aktualisiert werden. Große Anwendungen im Internet (wie z.B. Amazon, Ebay, Facebook, Google, Netflix, usw.) werden auf diese Weise mindestens einmal, aber auch bis zu einhundertmal 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 und ermöglichen so einen einfacheren verteilten Einsatz sowie eine einfache und schnelle Portierbarkeit: Das wiederum reduziert aus Sicht von Sourcing-Strategen die Abhängigkeit von einzelnen Herstellern (z.B. für Server und Betriebssysteme) oder aber die Abhängigkeit von einzelnen Hyperscalern (z.B. Microsoft, AWS, Google), da man seine Programme in den Containern schnell und meist ohne größere Abhängigkeiten von A nach B verschieben kann (die Migration der Daten mal außen vor gelassen).
Container (z.B. Docker, eine freie Software der "Apache Software Foundation“) passen somit nicht nur perfekt zu einem auf Microservices basierten Software-Architekturansatz, sondern mitigieren weitgehend den bei vielen IT- und Einkaufs-Organisationen gefürchteten Supplier- beziehungsweise Provider-Lock-In.
Für den Betrieb und die Verwaltung von Myriaden von Microservices benötigt man wiederum eine 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 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, realisiert man in Container-Umgebungen fabrikähnliche Verfahren von der Software-Entwicklung, über das Testing bis hin zum automatisierten Deployment von Software. 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.
Unabhängigkeit von Cloud-Anbietern und höhere Flexibilität
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.