Cloud-native im Aufwind: der richtige Architektur-Ansatz für mein Unternehmen

Autor: Daniel Albisser

Für Unternehmen, welche digitale Leader sind, ist die Präsenz und Differenzierung auf den online Kanälen ein Muss. Die Grundlage dafür ist die massgeschneiderte Entwicklung individueller Software-Lösungen. Diese werden von Produkte-Teams entwickelt, die aus Business-Vertretern und Technikern bestehen. Diese Teams stehen unter grossem Druck, schnelle Ergebnisse auf der Basis von soliden Applikations- und Integrations-Architekturen zu definieren. Diese müssen erweiterbar und skalierbar sein, aber auch schnell auf künftige Business-Anforderungen angepasst werden können. Software-Lösungen waren noch nie so einflussreich und gleichzeitig komplex wie heute.

Deshalb habe ich mir folgende Frage gestellt: Wie können sich Produkte-Teams die heute verfügbaren Cloud-native Technologien in der Software-Entwicklung zu Nutze machen und was ist der richtige Architekturansatz?

Cloud-native verspricht mehr Speed und Agilität, bessere Skalierung und Resilienz sowie die Unterstützung modularer Software-Architekturen. Das klingt vielversprechend und ist genau das, was agile Produkte-Teams für die Entwicklung moderner Software-Lösungen brauchen, um diese hinsichtlich Time-to-Market und Kosteneffizienz auf den nächsten Level zu hieven.

Soweit so gut. Doch nun stellen sich die Fragen, was ist der richtige Cloud-native Technologie-Mix / Architekturansatz und wo in der Organisation wird was bewerkstelligt? Diese Fragen schwirren schon länger in meinem Kopf umher. Deshalb habe ich mir verschiedene Cloud-native Projekte bei unseren Kunden etwas genauer unter die Lupe genommen und meine Erkenntnisse nachfolgend zusammengetragen.

• Was sind die Best Practices aus technischer Sicht: Serverless-Functions, Custom-Code in Kubernetes, managed PaaS Services, oder sogar Low-/No-Code Plattformen?

• Und aus organisatorischer Sicht: welche Aufgaben sollen zentralisiert in Shared-Services- oder Plattform-Teams bewerkstelligt werden und was übernehmen die dezentralen Produkte-Teams?

Technisch: gibt es den richtigen Cloud-native Architekturansatz?

Wie einleitend geschrieben, müssen moderne Software-Architekturen erweiterbar und skalierbar sein, aber auch schnell auf künftige Business-Anforderungen angepasst werden können. Cloud-native Technologien unterstützen das. 

Aufgrund der Anforderungen im Enterprise-Umfeld bei der Entwicklung individueller Software-Lösungen haben sich modulare Ansätze durchgesetzt: Microservices-Architekturen auf Basis Cloud-native Plattformen. Low-Code oder No-Code Plattformen kommen für individuelle Software-Lösungen im Enterprise-Umfeld weniger zum Einsatz; nachfolgend wird darauf nicht mehr weiter eingegangen.

Die Ausprägung von Microservices-Architekturen auf Cloud-native Plattformen kann sehr unterschiedlich sein. Für eine Gegenüberstellung werden nachfolgende Aspekte der Cloud-native Plattform genauer betrachtet:

• Frontend: Web-App oder Mobile-App auf Basis von Cloud-Diensten mit Hosting, Build-Prozess, CDN, usw.
• Business-Logik/Backend: Custom-Code (Java, C#, …) in Containern oder Serverless-Functions
• Integration: APIs, EAI, ETL, Event-Streaming
• Persistenz: Datenbanken, Storage
• Querschnitts-Funktionalitäten: Monitoring, Logging, Key-Management, IAM, Automatisierung (CI/CD, IaC), DevOps, usw.

Um das Optimum aus der individuellen Softwareentwicklung herauszuholen und effizient Lösungen zu implementieren, bedingt es den richtigen Mix aus managed Cloud-native Services, 3rd-Party Frameworks und Custom-Code. Wo und mit was kann ich als Entwickler/Engineer geschäftlichen Nutzen erbringen? Auf welchem Abstraktionslevel setze ich mit Custom-Code auf? Was kann ich fixfertig fully-managed aus der Cloud beziehen und muss mich nicht darum kümmern? 

Der Fokus sollte ganz klar bei der Umsetzung von Business-Anforderungen entlang der Unternehmensstrategie liegen: Frontend, Business-Logik und bei der nahtlosen Integration mit Umsystemen. Dort geschieht die Differenzierung und wird geschäftlicher Nutzen erbracht - und nicht beim Engineering der Basis-Infrastruktur. Diese sollte zu einem hohen Grad ab Stange, fully-managed vom Hyperscaler bezogen werden.

Doch was sind die Möglichkeiten und Ausprägungen für die Implementation der Business-Logik in einer Microservices-Architektur?

• Microservices als Serverless-Functions werden nativ auf Azure, AWS, GCP, usw. implementiert.
• Microservices im Container auf
  • nativem K8s auf AWS, Azure, GCP, u.a.
  • OpenShift als unabhängiges K8s

• Microservices auf einem plattform-agnostischen Cloud-native Applikationsframework, wie z.B. Knative, Dapr, Spring Cloud, VMWare Tanzu. Solche Frameworks sind teils auch fully-managed auf AWS, Azure, GCP, u.a. verfügbar.

Weitere Details dazu können den Blogs Container und Serverless mit Azure und  Microservice-Entwicklung leicht gemacht - Azure Container Apps entnommen werden.

Nachfolgende Abbildung zeigt an einem konkreten Beispiel eine stark vereinfachte Cloud-native Architektur auf Basis von Azure:

Als Antwort auf die einleitende Frage, ob es den richtigen Cloud-native Architekturansatz gibt, kann folgendes zusammenfassend gesagt werden: Cloud-native Architekturen sind ein Mix aus Microservices als Serverless-Functions (A), in Containern (B) und auf Basis eines Cloud-native Applikationsframeworks (C). Bei Containern / K8s in der Public Cloud liegt die Tendenz klar in Richtung nativem K8s-Dienst der unterliegenden Plattform.

Organisatorisch: Applikationszentrisch vs. Plattformzentrisch - wohin mit der Cloud-native Plattform?

Wie im vorhergehenden Abschnitt beschrieben kommen für die Entwicklung von Cloud-nativen Software-Lösungen Cloud-native Plattformen zum Einsatz. Die automatisierte Plattform-Bereitstellung mit Hilfe Infrastructure-as-Code (IaC) ist individuell auf die Unternehmen zugeschnitten und erfordert einiges an Customizing, z.B. Netzwerk, IAM, Security, Governance, CI/CD. Diese Bereitstellung kann

• applikationszentrisch in den Produkte-Teams, oder
• plattformzentrisch für das gesamte Unternehmen in einem Shared-Platform-Team

gemacht werden.

Hier muss man sich die Frage stellen, was für die eigene Organisation der richtige Ansatz ist? Die einfache Antwort: Es gibt kein richtig oder falsch, beide Ansätze haben ihre Daseinsberechtigung - mit Vor- und Nachteilen, die jedes Unternehmen für sich individuell abwägen muss. 

Betrachtet man die Effizienz und Wiederverwendung von Know-how sowie die Standardisierung bringt ein plattformzentrischer Ansatz mit einem Shared-Platform-Teams verschiedene Vorteile. Dadurch können sich die Produkte-Teams zu 100% auf die Business-Anforderungen konzentrieren und werden durch die Shared-Platform-Teams von der Bereitstellung der Plattform (IaC, Netzwerk, Security, Governance, ...) und deren Komplexität entlastet. Es werden aber ebenfalls zentrale Vorgaben und die Standardisierung gefördert, welche Produkte-Teams jedoch auch einschränken und bremsen können. 

Durch einen applikationszentrischen Ansatz erlangen Produkte-Teams zwar mehr Flexibilität, Unabhängigkeit sowie Gestaltungsspielraum, doch sogleich steigen auch die Verantwortung, die Komplexität und der Engineering-Aufwand. Viel Verantwortung wird in die dezentralen Produkte-Teams übertragen, dies bedingt weitere Plattform-Engineering-Skills. 

Nachfolgend die Vor- und Nachteile beider Ansätze nochmals gegenübergestellt:

Wie erwähnt, gibt es kein richtig oder falsch bei beiden Ansätzen. Jedes Unternehmen muss für sich entscheiden, was für sie am besten passt. Doch aufgrund der oben beschrieben Vor- und Nachteilen entscheiden sich die meisten Unternehmen für einen plattformzentrischen Ansatz.

Fazit & Empfehlung

Die Ausgangslage dieses Blogs war die Frage, was der richtige Ansatz für die individuelle Software-Entwicklung mit Cloud-native Technologien ist? Und gibt es diesen? Wie im Blog beschrieben, bin ich der Meinung ja. Diese Fragen wurden in diesem Blog aus einer technischen sowie organisatorischen Sicht beleuchtet. Hier nochmals die Erkenntnisse aus unseren verschiedenen Cloud-native Projekten zusammengefasst:

• Maximale Verwendung von fully-managed Cloud-native Dienste aus der Cloud für Frontend (Hosting, CI/CD, CDN), Integration (APIM, EAI, ETL, Event-Streaming), Persistenz (DB, Storage) sowie Querschnitts-Funktionalitäten (IAM, Automatisierung, Monitoring, Logging).
• Business-Logik in Microservices als Serverless-Functions, in Containern und auf Basis eines Cloud-native Applikationsframeworks. Bei Containern / K8s in der Public Cloud liegt die Tendenz klar in Richtung nativem K8s-Dienst der unterliegenden Plattform aufzusetzen.
• Die Cloud-native Plattform Bereitstellung nach einem plattformzentrischen Ansatz in einem Shared-Platform-Team erhöht die Effizienz sowie Wiederverwendung von Know-how und fördert die Standardisierung. Gleichzeitig werden die Produkte-Teams von Plattform-Themen entlastet und können sich auf Business-Anforderungen konzentrieren.

Quellen:

www.ipt.ch - Blog Speed der Entwicklung Dank Cloud Native

www.gartner.com - How to Navigate the Application Platforms Market Including Cloud-Native, Low-Code and SaaS

www.gartner.com - Application Architecture and Integration for Technical Professionals Primer for 2022

www.gartner.com - Emerging Technologies: Kubernetes and the Battle for Cloud-Native Infrastructure