Übergang zu Cloud-nativen Systemen noch 2017 Wie geht „cloud native“?

So wie schon Ticketmaster, Huawei Technologies und IBM (s.u.) nutzen heute immer mehr Unternehmen Cloud-native Architekturen, definiert als in Container verpackte, dynamisch verwaltete und auf Microservices ausgelegte Architekturen, für die Modernisierung ihrer Infrastruktur. Doch was gehört tatsächlich zur Umsetzung einer Cloud-nativen Strategie?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Der Autor Richard Rummelt definiert eine Strategie als „einen Ausweg aus einer schwierigen Situation, eine Herangehensweise zum Überwinden eines Hindernisses, eine Antwort auf eine Herausforderung“. Cloud-native Computeranwendungen zeigen einen Weg durch schwierige Herausforderungen – wie die Steigerung der unternehmerischen Agilität, die Verringerung der Hardware-Kosten oder die Freistellung von Mitarbeitern für höherwertige Arbeiten.

Der Umstieg auf „Cloud-native“ ist deshalb fast immer eine strategische Entscheidung. Dabei sind folgende drei Fragen für Unternehmen entscheidend:

• 1. Verläuft die Veränderung quer über organisatorische Grenzen?

• 2. Benötigen wir für die Veränderung Qualifikationen, die wir derzeit noch nicht haben?

• 3. Wird die Veränderung Gewinner und Verlierer schaffen, und damit Widerstand erzeugen?

Falls die Antwort auf alle diese Fragen „nein“ ist, dann ist ein Plan und ein wenig gesunder Menschenverstand wahrscheinlich ausreichend. Falls jedoch die Antwort auf mindestens eine dieser Fragen „ja“ ist, dann muss eine Strategie her.

Viele Unternehmen verstehen das nicht. Sie verstehen Cloud-native als eine rein technische Veränderung. Deshalb verlassen sie sich auf bekannte Management-Praktiken – also gesunden Menschenverstand und Planung –, obwohl sie etwas viel Umfassenderes bräuchten, nämlich eine Strategie.

Cloud-native Computing: Ein Problem mit vielen Facetten

Für die meisten Unternehmen hat Cloud-native Computing drei Seiten. Auf der einen Seite steht die Anwendungsentwicklung. Auf der zweiten Seite steht die Infrastruktur. Und auf der dritten Seite stehen schließlich Fragen der Organisation.

Wer verstehen will, warum das Problem drei Seiten hat, muss genauer analysieren, was ein Cloud-natives System eigentlich ist. Cloud-native Systeme sind „dynamisch verwaltet“, „in Container verpackt“ und „auf Microservices ausgelegt“. Diese drei Eigenschaften machen es möglich, dass Cloud-native Systeme „für moderne verteilte Systemumgebungen optimiert sind, die auf Zehntausende selbstheilender mehrfach mandantenfähiger Knoten skaliert werden können“.

Gerade aufgrund der selbstheilenden Natur Cloud-nativer Systeme ist es für Unternehmen heute viel einfacher, eine Notfall-Wiederherstellung (Disaster Recovery) durchzuführen oder neue Funktionen zu testen – und all das mit kleineren Teams und weniger Hardware.

Also hat Cloud-native Computing einerseits drei Seiten und ist andererseits aus den folgenden Gründen strategisch:

• Dynamisch verwaltete Systeme werden durch programmierbare Infrastruktur ermöglicht. Programmierbare Infrastruktur erlaubt es, die Effizienz der Maschinen zu verbessern und gleichzeitig die Betriebskosten zu senken. Bei den meisten Organisationen werden jedoch derzeit Anwendungen nicht so verwaltet. Mit anderen Worten: In der Cloud-nativen Welt funktionieren Anwendungen anders.

• Microservice-orientierte und in Container verpackte Anwendungen tragen ihren Teil zu Agilität und dynamischer Verwaltung bei. „Kubernetes“ verwaltet zum Beispiel Anwendungen in Containern und gibt dem IT-Personal mehr Zeit für höherwertige Arbeiten. Mit anderen Worten: Da die Anwendungen anders funktionieren, entwickeln wir sie auch anders.

• Und schließlich: Die Struktur eines Computersystems spiegelt fast immer auch die Struktur der Organisation wider. Mit anderen Worten: Die meisten Unternehmen können sich nicht in Richtung von Microservices bewegen (beispielsweise können sie ihre IT-System-Struktur nicht ändern), ohne zuerst ihre Organisationsstrukturen zu ändern. Mit anderen Worten: In der Cloud-nativen Welt werden Anwendungen anders entwickelt, und deshalb müssen die Unternehmen sich auch anders aufstellen.

Der Weg zum Ziel

Da jedes Unternehmen sich mit anderen Herausforderungen konfrontiert sieht, braucht auch jedes Unternehmen eine andere Strategie. Sowohl ING in den Niederlanden als auch Holiday Check in Deutschland haben Cloud-native Systeme implementiert oder sind gerade dabei). Ihr Ansatz, die gewählten Werkzeuge und der Ablauf der Implementierung waren jedoch unterschiedlich. Der Unterschied in der Strategie hängt vom Standort, von der jeweiligen Branche und von den Geschäftszielen ab.

Unternehmen mit einer vernünftigen Cloud-nativen Strategie hatten zunächst ein grobe Vorstellung dessen, was sie erreichen wollten. Im Hinblick auf die sehr facettenreiche und komplexe Natur sowohl der Cloud-nativen Systeme als auch des täglichen Unternehmensbetriebs bauten sie in ihre Strategie Freiräume zum Lernen ein.

Genau in diesen Freiräumen können dann neue Ideen entstehen. Im Laufe der Zeit werden so aus vergangenen Strategien Pläne für die Zukunft. Mit anderen Worten: Die Implementierung Cloud-nativer Systeme verläuft erfolgreich, wenn Unternehmen eine gewachsene Strategie (emergent strategy) einsetzen.

Die gewachsene Strategie

Eine Möglichkeit, wie man aus der Vergangenheit Schlüsse ziehen kann, die man dann in der Zukunft anwendet, besteht darin, einfach einmal eine Sache (oder ein Team) anzustoßen und zum Laufen zu bringen. Hier ein Beispiel: Man nimmt den Cloud-nativen Ansatz und implementiert ihn zunächst nur in einem Teil der Organisation. Man lernt aus den Fehlern und Herausforderungen und kann in einem zweiten Schritt das Gelernte im einem weiteren Teil der Organisation umsetzen, also in einem größeren Maßstab anwenden (skalieren).

Genau durch diesen Prozess des Skalierens kleiner Teile bilden sich Strategien heraus – wie in Abbildung 2 dargestellt. Erst nachdem dieses Vorgehen eine Zeit lang verfolgt wird, kristallisiert sich langsam die Strategie heraus.

Ein anderes Gedankenmodell hierfür ist die J-Kurve. Viele Unternehmen verstricken sich in (meist nutzlosen) Diskussionen darüber, was als nächstes getan werden sollte. Sie streiten sich über die Auswahl des Orchestrators (orchestrator), bevor sie überhaupt Container richtig verstanden haben.

Sie überlegen schon, wie 100 Entwickler ihren Code umsetzen können, wenn sie es noch nicht einmal geschafft haben, ein einziges Team darauf anzusetzen. Man kann diese Art von Blockade überwinden, indem man Veränderungen als kleine Investitionen betrachtet.

Sobald ein Team das Modell der gewachsenen Strategie verstanden hat und weiß, dass man etwas experimentieren muss, wenn man neues Wissen erwerben möchte, können die Entwickler mit Blick auf die J-Kurve über ihre nächsten Schritte nachdenken. Die J-Kurve veranschaulicht einen einfachen Gedanken.

Die vertikale Achse stellt die Kosten dar. Anfangs kostet das Ausprobieren und Herumexperimentieren Geld. Da Organisationen nicht zu viel Geld nutzlos verbrauchen wollen, wird am Anfang ein Maximalbetrag festgelegt. So darf ein Team beispielsweise eine Woche für die Containerisierung seiner Anwendung aufwenden. Wenn dieses Experiment eine adaptive Veränderung auslöst, wenn es also zu einer besseren Arbeitsweise führt, dann beginnt die Investition, sich für die Organisation zu lohnen. Sobald die J-Kurve die horizontale Achse schneidet, ist die Gewinnzone erreicht. Danach lohnt sich die Investition.

Falls ein Experiment „fehlschlägt“, so wurde doch etwas gelernt, nämlich das, was nicht funktioniert. Genau diese Fehlschläge oder Misserfolge zeigt auf, was als Nächstes zu probieren ist. Nur wenige Organisationen bekommen ihre Cloud-native Strategie ohne jeglichen Misserfolg hin.

Der Weg mit all seinen Misserfolgen führt auf die richtige Strategie, und jeder Misserfolg muss als eine Gelegenheit zum Lernen betrachtet werden. Eine gewachsene Strategie beruht also auf vielen kleinen Experimenten, von denen jedes einzelne in Richtung des nächsten Schritts zeigt.

Der Autor Jamie Dobson ist CEO von Container Solutions sowie Mitglied der Cloud Native Computing Foundation.

Es steht ein Strategiewechsel an

Für viele Organisationen sind Cloud-native Computersysteme eine Herausforderung mit vielen Facetten. Diejenigen, die Cloud-native Computing erfolgreich implementieren, schaffen das, weil sie es als einen Strategiewechsel verstehen. Das bedeutet, sie sehen zwar das Gesamtbild, aber auch die Details.

Sie erkennen auch, was sie gerade getan haben, und bringen es fertig, das Gelernte auf den noch vor ihnen liegenden Weg anzuwenden. Sie begrüßen Erfolge und Misserfolge, weil sie wissen, dass ihre Handlungen mit der Zeit zu neuen, „gewachsenen“ Strategien führen.

Und weil Strategie schließlich auf Handlungen beruht, führen sie es zu Ende. Durch ihr implizites oder explizites Verständnis der J-Kurve ziehen sie das, was sie angefangen haben, auch bis zum Ende durch, lernen dabei Neues und nähern sich ihrer eigenen Cloud-nativen Strategie immer mehr an.

Der Autor und Veranstaltungshinweis

Jamie Dobson ist CEO von Container Solutions und Mitglied der Cloud Native Computing Foundation. In Dobsons aktuellem Webinar finden Sie mehr zur Cloud-nativen Strategie.

Organisationen wie die Cloud Native Computing Foundation, und quelloffene (open-source) Projekte wie Kubernetes und „Prometheus“ bieten eine sehr gute Community-Unterstützung, Botschafter-Programme, Referenzanwendungen, Online-Kurse und Konferenzen wie die CloudNativeCon/KubeCon in Berlin am 29. und 30. März 2017.

(ID:44570812)