Warum „Cloud-Native“? (Teil 3)

Warum „Cloud-Native“? (Teil 3)

von Gastautorin/Gastautor 18. Dezember 2018

Wie veränderte Treiber zu neuen Paradigmen führen

Ein Gastbeitrag von Uwe Friedrichsen

(Dieser Artikel ist zuerst erschienen in Softwerker. Mehr Infos unter https://info.codecentric.de/softwerker-cloud-native)

Langsamer und schlechter

Wenn man sich anschaut, wie die „agilen DevOps-Teams“ mit diesem Zoo an Themen, Tools und Technologien umgehen, dann stellt man fest, dass diese sich um praktisch alle genannten Themen selber kümmern – sowohl in der Entwicklung als (sofern echte DevOps-Teams) auch in der Produktion: Da werden Continuous Delivery Pipelines komplett selber aufgebaut und betrieben, ebenso Cassandra/MongoDB/PostgreSQL, Kafka, Kubernetes, ELK, Keycloak, usw., häufig bis hin zu Git und Artifactory bzw. Nexus. Dazu kommen natürlich noch die ganzen Tools und Frameworks wie Spring Boot/Cloud, Kong, Istio/Linkerd, Docker usw., die auch beherrscht werden müssen.

Dem unbedarften Beobachter stellen sich dabei spontan erst einmal zwei Fragen:

  1. Können die Teams die Komplexität überhaupt noch beherrschen?
  2. Was davon trägt eigentlich zur Wertschöpfung des Unternehmens bei?

Nicht beherrschte Komplexität

Zur ersten Frage lässt sich beobachten, dass viele Teams diese Komplexität nicht mehr wirklich beherrschen. Das beginnt mit einem lückenhaften Verständnis von Microservices und insbesondere den Konsequenzen der Verteilung, die man damit erzeugt – was häufig zu sehr fragilen Ergebnissen in Produktion führt.

Das setzt sich mit einem vielfach fragmentarischen Wissen über all die eingesetzten Tools fort. Insbesondere auf der Betriebsseite ist das Wissen häufig sehr dünn – verstärkt durch ein falsches DevOps-Verständnis, bei dem „DevOps“ mit „NoOps“, also der Abwesenheit von Betriebsexperten, gleichgesetzt wird und irrigerweise angenommen wird, dass Entwickler das notwendige Wissen „mal nebenbei“ auf der „Getting started“-Seite der eingesetzten OSS-Lösung erwerben könnten.

Das endet häufig in Architekturen und Vorgehensmodellen, die fernab von dem sind, was für das jeweilige Vorhaben von Wert wäre, weil sich mangels tieferen Verständnisses keiner traut, irgendetwas vorzuschlagen, was gerade nicht auf der „IT-In-Liste“ steht – und das Fehlen von tieferem Verständnis häufig gerne einmal durch ein Mehr an Dogmatismus wettgemacht wird.

Die Tatsache, dass jede Woche irgendwo ein neues Tool auftaucht, das „man kennen muss“ und der Zoo größer und größer wird, macht es nur noch schlimmer. Immer mehr Entwickler schrecken vor der Komplexität zurück, sei es, dass sie es explizit sagen oder dass sie einfach Teile der Komplexität ausblenden, sprich ignorieren.

Als Ergebnis entstehen fragile Lösungen, die ihr Wertversprechen weder in der Entwicklung noch in der Produktion halten können. Die Entwicklung wird langsamer als noch zu Zeiten der Application Server und die Zuverlässigkeit in Produktion leidet auch – das Ergebnis ist also häufig das Gegenteil dessen, was man ursprünglich erreichen wollte.

Ungewollte Komplexität ohne Wertschöpfung

Und um auf die zweite Frage zurückzukommen: Das Schlimmste daran ist, dass eigentlich nichts davon zur Wertschöpfung des Unternehmens beiträgt. Das ist von außen betrachtet nur eine IT, die sich mit sich selbst und ihren „Spielzeugen“ beschäftigt, ohne irgendeinen Mehrwert zu stiften, während von innen betrachtet die zu handhabende Komplexität immer weiter wächst.

Damit können wir an vielen Stellen eine unerfreuliche Entwicklung beobachten:

  • Die Fachbereiche werden immer unzufriedener, weil die IT ihnen zwar (mal wieder) versprochen hat, dass jetzt alles viel schneller und günstiger funktionieren würde, sie aber faktisch immer langsamer (und teurer) wird und sich immer weniger um die drängenden Probleme der Fachbereiche kümmern kann.
  • Gleichzeitig ertrinkt die IT in einer immer weiter steigenden Komplexität, die beherrscht werden soll, und die Beteiligten resignieren ohnmächtig vor den stetig wachsenden Anforderungen.

Aber wie kann man diese Entwicklung durchbrechen?

Managed Services und FaaS (a. k. a. „Serverless“)

Diese Frage bringt uns zurück zur Reduktion der Fertigungstiefe. Die Frage ist: Können wir Teile des gesamten Ökosystems auf eine Weise zukaufen, dass

  • man sich mit der inhärenten Komplexität der zugekauften Teile in Entwicklung und insbesondere auch Betrieb nicht mehr befassen muss,
  • bei gleichzeitig akzeptablen Kosten, sprich: dass die Kosten der Kauflösung die Kosten für Entwicklung und Betrieb der selbstgebauten Lösung beim erwarteten Nutzungsprofil nicht übersteigen.

Cloud heute

Wenn man sich die Entwicklung der letzten Jahre im Cloud-Umfeld ansieht, dann ist die Antwort ein klares Ja.
Auch wenn es gerade in Deutschland viele Unternehmen noch nicht verstanden haben: Cloud ist schon lange nicht mehr eine Art „VMWare light“, also ein simples Bereitstellen von Compute, Storage und Network, nur gefühlt unsicherer und mit weniger Einflussmöglichkeiten. Cloud ist heute viel, viel mehr.

Schaut man etwa auf das Produktangebot der großen Cloud Provider, so gibt es praktisch keinen querschnittlichen Dienst, den man dort nicht kaufen könnte, seien es verschiedenste Data Stores, Kommunikationskanäle, Analysewerkzeuge, Processing Frameworks, alles rund um Continuous Delivery, über Identity Management und Security bis hin zu Machine Learning, AI, IoT-Anbindung und mehr.

Und schaut man noch etwas weiter, dann findet man auch jede Menge an Anwendungs-Services, die man per API in seine Lösungen integrieren kann – etwa Groupware, CMS, Kontaktmanagement bis hin zum vollumfänglichen CRM, Finanzen, Rechnungswesen und noch sehr viel mehr.

All das wird heute als SaaS (Software-as-a-Service) bzw. BaaS (Backend-as-a-Service) angeboten. Wichtig ist dabei, dass es sich um Managed Services handelt, also Dienste, um deren Betrieb, Sicherheit und Evolution sich andere kümmern. Als Nutzer dieser Services muss man im Vergleich zu einer Eigenentwicklung nur noch verstehen, was der Service leistet und ihn per API integrieren. Um alles andere kümmert sich der Anbieter des Managed Services. Das bedeutet eine starke Entlastung der Service-Nutzer, weil sie die gesamte Komplexität bzgl. Erstellung, Pflege, Härtung und insbesondere auch Betrieb des Services nicht mehr durchdringen müssen.

Entschärfte Integrationsfalle

„Integration per API“ bedeutet aber zunächst einmal Integrationsaufwand. Und wer schon einmal mit Integrationen zu tun hatte, der weiß auch, dass Integrationen sehr aufwändig sein können und den Vorteil einer Kauflösung schnell zunichte machen können. Hier spielen einem bei Serverless zwei Dinge in die Hände:

  1. Kleinteilige und vielfältige Managed-Service-Angebote
  2. FaaS (Function-as-a-Service)

Zunächst einmal ist ein großer Unterschied zu den Kauflösungen früherer Zeiten, dass die Angebote an Managed Services sehr vielfältig sind, so dass man in der Regel nicht nur eine Option für eine Problemstellung hat, sondern eine ganz Reihe ernsthafter Alternativen, was der Qualität und Nutzbarkeit der Lösungen (gerade auch mit Blick auf Integrationen) zugutekommt.
Dann erfolgt der primäre Zugriff auf nahezu alle Managed Services per API. Im Gegensatz zu früheren Kauflösungen, die in sich abgeschlossen waren und für die jede Art der Integration eine potentielle Bedrohung des Geschäftsmodells darstellte (was eine Erklärung für das mangelnde Interesse an guter Integration ist), leben Managed Services von der Integration, d. h. eine schlechte Integrationsfähigkeit per API bedroht ihr Geschäftsmodell. Das hilft in Bezug auf eine leichte Integrationsfähigkeit natürlich ungemein.

Zusätzlich sind viele der Lösungen relativ kleinteilig, d. h. sie machen im Sinne der Unix-Philosophie eine Aufgabe gut, anstatt den Nutzer mit einer unüberschaubaren Menge an Funktionalität zu überschütten. Auch das hilft in Bezug auf einfache und zielgerichtete Integrationen.

Und letztlich gibt es mit FaaS eine gut dazu passende und relativ leichtgewichtige Integrationstechnologie. Event-basiert werden Funktionen ausgelöst, die auf Events aus einem Managed Service auf beliebige Weise reagieren können, wie z. B. Verarbeitungen in anderen Services anstoßen, leichtgewichtige Zwischenverarbeitungen durchführen oder aber auch neue Events erzeugen. Natürlich kann man auch andere Dinge mit FaaS machen, aber gerade der „Glue“, d. h. eine dünne, aber dennoch leistungsstarke Integrationsschicht zwischen Managed Services, kann damit sehr gut abgebildet werden.

Diese Kombination aus Managed Services, die sich via FaaS integrieren und orchestrieren lassen – auch gerne „Serverless“ genannt, weil man sich nicht mehr selber um die „Server“ kümmern muss, sondern alle Leistungen als Services bezieht – machen einen großen Teil der Leistungsfähigkeit der heutigen Cloud-Native-Landschaft aus. Und damit kann man massiv die eigene Fertigungstiefe (und damit auch die benötigte Lernkurve) reduzieren.


Im nächsten Teil dieser Reihe: Cloud-Native-Anwendungen.

Teil 1: Warum „Cloud-Native“? – Wie veränderte Treiber zu neuen Paradigmen führen.

Teil 2: Warum „Cloud-Native“? – Schnellere Durchlaufzeiten als Ziel.

Unser Gastautor

Uwe Friedrichsen Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als Fellow und CTO der codecentric AG ist erstets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit, Resilience und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und natürlich gerne auch im direkten Gespräch.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Ähnliche Beiträge