Warum „Cloud-Native“?

Warum „Cloud-Native“? (Teil 2)

von Gastautorin/Gastautor 12. 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)

Schnellere Durchlaufzeiten als Ziel

Will ich als Unternehmen mit einem solchen Wettbewerber mithalten können, dann muss ich schneller werden, denn in einem hochdynamischen Marktumfeld wird sich schlussendlich derjenige durchsetzen, der schneller sich ständig wandelnde Kundenbedürfnisse erkennt und sich darauf einstellt – und das setzt kurze Durchlaufzeiten voraus.

Aber wie verkürze ich die Durchlaufzeiten?

Das ist ein großes Thema, das den Rahmen dieses Beitrags sprengen würde. Dafür reicht es nicht, nur die Durchlaufzeiten der IT zu verkürzen, sondern es betrifft alle Bereiche des Unternehmens. Hier wollen wir uns aber auf die IT beschränken. Wie stelle ich sicher, dass die IT nicht zum Flaschenhals wird bzw. wie beseitige ich den Flaschenhals, der ja in den meisten Unternehmen bereits Realität ist?

Auch das ist ein großes Thema, in das ziemlich viele Aspekte hineinspielen. In [1] habe ich z. B. einen kleinen Überblick über verschiedene Themen und Praktiken gegeben, die zur Beschleunigung der IT-Wertschöpfungskette beitragen. Der Aspekt, auf den ich hier eingehen möchte (und der in [1] nur am Rand adressiert wird), ist die Reduktion der IT-Fertigungstiefe.

Reduktion der Fertigungstiefe

Nun ist die Reduktion der Fertigungstiefe ein Thema, das periodisch immer wieder mit mehr oder weniger Verstand durch das IT-Dorf getrieben wird. Falls Sie jetzt also aufgrund schmerzhafter Erfahrungen mit dem Thema in der Vergangenheit direkt zusammenzucken, so kann ich das gut nachvollziehen, möchte Sie aber auch gleich beruhigen. Ich möchte keine der teilweise unsäglichen, (vorgeblich) kostensparenden Maßnahmen der Vergangenheit wieder aufwärmen, die unter dem Begriff angepriesen worden sind. Ich möchte mich dem Begriff in seiner allgemeinsten Form nähern und sehen, welche Auswirkungen das auf die Durchlaufzeiten haben kann.

Reduktion der Fertigungstiefe heißt zunächst einmal nichts anderes, als dass man in der Regel elementare, nicht differenzierende Teile der Produktion nicht mehr selber macht, sondern diese entweder an einen Zulieferer auslagert oder aber (standardisierte) vorgefertigte Teile bzw. Teilleistungen einkauft.

In der Vergangenheit wurde IT als Ganzes häufig als nicht differenzierend und nicht für den Geschäftserfolg relevant eingestuft, befeuert von Artikeln wie z. B. [2] und den daraus resultierenden Diskussionen. Entsprechend war die Idee zur Reduktion der Fertigungstiefe der IT meistens, diese komplett an einen Outsourcing-Partner auszulagern. Dass das in der Form unter den von mir beschriebenen Rahmenbedingungen eines post-industriellen Markts keine Option mehr ist, sollte selbsterklärend sein.

Aber auch das Insourcing der IT zurück in das Unternehmen löst die Probleme mit zu langen Durchlaufzeiten nicht auf magische Weise. Wie zuvor beschrieben, müssen die meisten Unternehmen noch deutlich kürzere Durchlaufzeiten erreichen, um mit den Besten im Markt auch nur ansatzweise mithalten zu können.
Wie in [1] beschrieben, gibt es dafür auch keine einzelne Wunderwaffe, sondern es müssen verschiedene Maßnahmen so miteinander verknüpft werden, dass sich ihre Effekte am Ende multiplizieren. Aber wie passt die Reduktion der Fertigungstiefe in das Bild und wie kann man sie so implementieren, dass sie die anderen Maßnahmen sinnvoll ergänzt?

Die typische IT-Lösung heute

Um diese Frage zu beantworten, muss man betrachten, wie eine typische moderne IT-Lösung heute aussieht. In Zeiten von Microservices etc. sieht eine IT-Lösung häufig so aus:

  • 〈 Als Frontend kommt eine JavaScript-basierte Single Page Application zu Einsatz, typischerweise unter Nutzung von Angular, React oder Vue realisiert.
  • Die Datenkommunikation zwischen dem Frontend und Backend erfolgt per AJAX (oder eigentlich eher AJAJ, da üblicherweise kein XML, sondern JSON verschickt wird), WebSockets oder einer vergleichbaren Technologie.
  • Die Backend-Logik ist in Form von Microservices realisiert, unter Nutzung von Frameworks wie z. B. Spring Boot/Cloud im Java-Bereich.
  • Je nach Struktur und Komplexität der Service-Landschaft werden spezielle BFF-Services (Backend For Frontend) als Fassaden-Services zu den verschiedenen Frontends eingesetzt.
  • Als Proxy für IAM (Identity and Access Management), Rate-Limiting, standardisiertes Logging am Endpunkt und weitere querschnittliche Funktionen wird ein API Gateway wie z. B. Kong eingesetzt.
  • Damit das IAM auch ordentlich funktioniert, heutzutage üblicherweise unter Nutzung von OAuth2 und JWT, wird ein IAM-Tool wie z. B. Keycloak eingesetzt.
  • Natürlich werden die Services nicht „roh“ deployt, sondern in Docker-Container gepackt.
  • Und diese Container werden nicht von Hand oder per Skript in Produktion gestartet, sondern unter Verwendung eines Schedulers wie Kubernetes.
  • Um querschnittliche Themen, die für die Kommunikation zwischen Services relevant sind (z. B. Latenz-Überwachung inklusive Retries, Request Routing, Request Correlation usw.) nicht in jedem Service einzeln implementieren zu müssen, werden ergänzend Service Meshes wie Istio oder Linkerd eingesetzt.
  • Für eine zentrale Verwaltung von Konfigurationsparametern wird ein Konfigurations-Management-Tool wie z. B. Consul eingesetzt.
  • Um diese verteilte Systemlandschaft zu überwachen, wird eine vernünftige Monitoring-Lösung mit Unterstützung von Metriken, Events und Alerting wie z. B. Prometheus oder Graphite eingesetzt (die allerdings beide in der Basis-Installation erst einmal kein Alerting unterstützen).
  • Ergänzend wird eine Log-Aggregation mit flexiblen Such- und Auswertungsmöglichkeiten z. B. ELK verwendet, um Ad-hoc-Anfragen und Post-Mortem-Analysen nach Fehlern zu unterstützen.
  • Für die Datenspeicherung kommt nicht mehr einfach „nur“ eine relationale Datenbank zum Einsatz. Da muss es in der Regel schon eine MongoDB, Cassandra oder ähnliches sein (egal ob eine relationale Datenbank wie MySQL oder PostgreSQL die angemessenere Lösung gewesen wäre oder nicht).
  • Und da man als zeitgemäßer Architekt nicht mehr ohne CQRS auskommt und Events sowieso viel besser sind, muss auch noch ein Event-Bus her. Meistens wird dafür derzeit dann auf Kafka zurückgegriffen. Das ist zwar eigentlich kein Event-Bus, sondern ein verteiltes Log, aber derzeit deutlich angesagter als z. B. ein RabbitMQ. Außerdem kann man es auch gleich als Event-Store mitverwenden, den man ja bei den meisten CQRS-basierten Architekturen vorfindet.
  • Da man das alles nicht mehr manuell in Build, Test und Deplyoment verwalten kann (und auch bitte auf keinen Fall versuchen sollte!), muss noch eine Continuous Delivery Pipeline her, meistens basierend auf Jenkins.
  • Dazu kommt für die Sourcen ein Git-Repository, plus weitere Repositories für Artefakte und Container wie z. B. Artifactory oder Nexus.
  • Letztlich müssen die ganzen Rechner aufgesetzt werden, auf denen die ganzen Kubernetes-Instanzen sowie Data Stores und die Continuous Delivery Pipeline laufen sollen. Auch das gehört automatisiert mit Tools wie z. B. Ansible oder Puppet.
  • Die Teams sind natürlich „DevOps“, d. h. sie kümmern sich sowohl um die Entwicklung als auch den Betrieb der Lösung.
  • Damit muss das Wissen um alle genannten Themen inkl. eingesetzter Tools und Technologien in den Teams sein.
  • 〈 Erwähnte ich eigentlich bereits Security? Ach nein, ist ohnehin viel zu schwierig. Lasst uns das mit einigermaßen schlechtem Gewissen ausblenden und hoffen, dass alles gut geht …

Das mag jetzt überspitzt klingen, aber das ist leider die Realität, die ich derzeit in vielen Projekten antreffe – häufig getrieben von einem falschen Verständnis von Microservices und DevOps. Dazu kommt ein dogmatischer Hang zu OSS (Open Source Software) aufgrund eines komplett falschen Make-or-Buy-Verständnisses auf Entscheiderseite sowie ein ausgeprägter Hang zu DIY („Do It Yourself“) auf Entwicklerseite (massiv befeuert von den ganzen „Developer Advocates“, die von den Tool- und Framework-Herstellern ausgesandt werden), die sich gegenseitig verstärken. Und auch dort, wo man (noch) nicht auf den Microservices- und DevOps-Zug aufgesprungen ist, sind die Lösungen häufig ähnlich komplex.


Im nächsten Teil dieser Reihe: Langsamer und schlechter – Nicht beherrschte Komplexität.

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

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