Cloud-native Entwicklung mit überschaubarem Risiko

Autor: Dominik Keusch

Beim Aufbau einer Cloud-native-Lösung steht man zu Beginn vor der Entscheidung, in welchem Umfang man die proprietären Funktionalitäten des Cloud Providers verwenden will. Moderne Applikationen bestehen aus einer Vielzahl unterschiedlicher Komponenten: Nebst der eigentlichen Entwicklung braucht man Lösungen zum Konfigurieren, Orchestrieren, Überwachen und Loggen der Applikation. Man benötigt Speicher, Datenbanken, Messaging- oder Streaming-Services, Sicherheits- und Netzwerk-Funktionalität, Laufzeit-Umgebungen und vieles mehr. Die modernen Cloud Provider bieten innerhalb ihres Ökosystems eigene, integrierte Lösungen an, um die Funktionen dieser Zusatzkomponenten zu erfüllen. 

Die Macht des Ökosystems

Die Vorteile eines solchen Ökosystems basieren hauptsächlich auf den Faktoren Geschwindigkeit, Kompatibilität und Einfachheit. 

Mit geringem Aufwand lassen sich die Cloud-Services zum Leben erwecken. Man kann sie bequem in einer Web-Oberfläche konfigurieren oder über automatisierte Scripts provisionieren. 

Hinzu kommt, dass die Services darauf ausgelegt sind, perfekt zusammenzupassen - it just works! Dieses gewandte, nahtlose Zusammenspiel kann ein gigantischer Innovationstreiber sein. 

Die Leichtigkeit, wie die komplexen Services zusammenspielen, fasziniert und macht Appetit auf mehr. Die Cloud Provider scheuen keinen Aufwand die Bequemlichkeiten des Ökosystems aktiv zu verstärken. Die Funktionalitäten sind bestens dokumentiert, es gibt zahlreiche zur Verfügung gestellte Code-Beispiele in allen möglichen Programmiersprachen. 

Dazu kommen eigene Konferenzen, attraktive Zertifizierungsangebote, Webinars, Online-Kurse, etc. Man fühlt sich schnell wohl innerhalb eines Ökosystems. 

Dieses Wohlfühlen, diese Leichtigkeit ein innovatives Produkt innert kürzester Zeit auszurollen, hat einen hohen Preis. Je mehr die Vorzüge dieser nahtlos integrierten Komponenten ausgekostet werden, umso höher die Abhängigkeit von diesem Provider. 

Der Leim, mit der die Applikation «zusammengehalten» wird, funktioniert nur innerhalb des Ökosystems. Wenn man nicht aufpasst, ist die ganze Architektur auf diesen Provider ausgerichtet und die Portabilität nicht mehr gewährleistet. 

Die Alternative: Portierbare, Provider-unabhängige Entwicklung

Welche Möglichkeiten gibt es, um die Abhängigkeit von einem einzelnen Provider zu reduzieren und die Portabilität zu erhöhen? 
Man entscheidet sich von Beginn an für eine Provider-neutrale Architektur und stellt sein Tech-Stack aus Services seiner Wahl zusammen. Dadurch profitiert man vom grossen Vorteil der Flexibilität. Man kann aus dem breiten Angebot die beste Lösung pro Teilaufgabe auswählen oder eine Komponente in Zukunft einfacher austauschen. 

Die Cloud Native Foundation bietet dazu eine gute Übersicht, welche Komponenten zur Verfügung stehen. Als Teil der non-profit Linux Foundation setzt sich die CNCF zum Ziel, einen Überblick über die Open-Source Projekte innerhalb der Cloud Native Landscape zu bieten und die Zusammenarbeit zwischen den Projekten zu fördern. 

Die Vorteile der Portabilität kommen nicht umsonst. Es bedarf einer aktiven architektonischen Entscheidung, diesen Weg zu gehen. Die Auswahl der Services ist komplex, denn die Projekte entwickeln sich rasant weiter und die Kompatibilität ist trotz Docker und Kubernetes nicht selbstsprechend. 

Es braucht einiges an Engineering-Aufwand bis alles nahtlos zusammen funktioniert – das notwendige Fachwissen vorausgesetzt. Bei Support-Fällen kann man sich nicht an einen einzelnen verantwortlichen Ansprechpartner wenden. Dies erhöht die Komplexität weiter. 

Was ist wichtig bei der Entscheidung der Cloud-native Architektur?

Beide vorgestellten Cloud-native Ansätze haben Vor- und Nachteile. Wie entscheidet man sich also am besten? Dabei geht es nicht um richtig oder falsch, sondern um das Abwägen und die bewusste Auseinandersetzung. Überlegen Sie sich zum Beispiel folgende Fragestellungen: 

• Welche Applikations-Entwicklungsstrategie verfolgen Sie und aus welchen Gründen? Gibt es Prinzipien, regulatorische Auflagen oder Rahmenbedingungen, die zu berücksichtigen sind?
• Wie stark abhängig will ich mich von einem Cloud-Anbieter machen? Wie gewichtet man die Faktoren Geschwindigkeit vs. Unabhängigkeit?
• Architektur-Strategie des Cloud-Providers: Setzt der Cloud-Provider viele Open Source Technologien ein oder setzt er vermehrt auf proprietäre eigene Werkzeuge?
• Welche Technologien / Produkte setzen Sie schon ein und verfügen über Know-how?
• Wie ist das Projekt-Setup: Welche Teams stehen zur Verfügung? Wie sind die Mitarbeiter ausgebildet? Welches sind die Beweggründe für den Wechsel zur Cloud?
• Oft hilft es auch schon beim Beginn einer Cloud-Partnerschaft über deren Ende nachzudenken. Dies ermutigt Architekten dazu, die Portabilität ihrer Systeme und Applikationen höher zu gewichten.
• Wie wurden vergangene Projekte umgesetzt, welche Strategien haben sich als vorteilhaft erwiesen? Ob eine Entscheidung gut oder schlecht rauskommt hängt sehr stark von Ihrer Unternehmenskultur ab, Ihrem digitalen Erfahrungsschatz, Ihrer Agilität und Ihren Mitarbeitern. Es gibt keine Strategie, die in allen Fällen die Richtige ist. Was hat in der Vergangenheit nicht gut funktioniert?

Fazit

Beide hier vorgestellten Ansätze der Cloud-native Entwicklung haben Vor- und Nachteile. Je nach Anwendungsfall muss man diese sorgfältig abwägen und entscheiden auf welche Faktoren man setzen will. Die Entscheidung ist keineswegs schwarz-weiss und es bietet sich ein breites Spektrum zwischen den Extremen. Zudem ist es unerlässlich, dass Ihr Unternehmen eigene Erfahrungen sammelt und zum Beispiel im Rahmen eines Proof of Concept und in Real-Life erlebt, wie sich die entsprechende Entscheidung anfühlt. Fail fast – learn fast!