Cloud-native Unternehmensarchitektur: Prinzipien und Governance
Cloud Native beschreibt eine automatisierte und wiederholbare Art, Workloads zu entwickeln und bereitzustellen. Die Unternehmensarchitektur legt Plattformstandards fest und verfolgt, was jede Anwendung nutzt.
Aktualisiert am
Die Definition der CNCF
Die Cloud Native Computing Foundation (CNCF) veröffentlicht eine Definition von Cloud Native, in Version 1.1. Danach helfen diese Praktiken Organisationen, Workloads in öffentlichen, privaten oder hybriden Clouds zu entwickeln, zu bauen und bereitzustellen. Sie erfüllen die Anforderungen der Organisation im großen Maßstab, programmatisch und wiederholbar.
Die betroffenen Systeme sind lose gekoppelt und arbeiten sicher, belastbar, steuerbar, nachhaltig und beobachtbar zusammen. Die Definition nennt, als offene Liste, Container, Service Meshes, Mandantenfähigkeit, Microservices, unveränderliche Infrastruktur, Serverless und deklarative APIs. Mit robuster Automatisierung erlauben diese Praktiken häufige und vorhersehbare Änderungen mit großer Wirkung.
Monolith und unabhängige Dienste
In einer monolithischen Anwendung werden die Komponenten gemeinsam ausgeliefert. Eine lokale Änderung erfordert eine neue Bereitstellung des Ganzen, Abhängigkeiten bremsen Aktualisierungen, und die Skalierung betrifft die gesamte Anwendung. Der Ausfall einer Komponente kann auch den Rest stoppen.
Cloud Native teilt das System in Dienste, die getrennt ausgeliefert und skaliert werden. Teams binden einen neuen Dienst schneller ein, doch jede Aufteilung fügt Schnittstellen und Abhängigkeiten hinzu, die gesteuert werden müssen.
Die zu beschreibenden Praktiken
Eine Cloud-native Architektur verbindet mehrere Praktiken:
- Microservices: Jeder Dienst wird unabhängig entwickelt, bereitgestellt und skaliert.
- Container: Dasselbe Paket läuft in jeder Umgebung gleich.
- Orchestrierung: Die Plattform automatisiert Bereitstellung, Skalierung, Wiederherstellung und Ressourcenzuteilung. Kubernetes ist eine Open-Source-Plattform dieser Art für containerisierte Workloads.
- DevOps und Continuous Integration: Auslieferungen erfolgen häufiger und werden automatisch geprüft, was das Risiko jeder einzelnen senkt.
- Infrastructure as Code: Netzwerke, Maschinen und Dienste entstehen aus versionierten Dateien, die wie Code geprüft werden.
- API first: Jeder Dienst veröffentlicht seinen Schnittstellenvertrag vor der Implementierung.
Die Rolle der Unternehmensarchitektur
Mit Cloud Native vervielfachen sich Dienste, Umgebungen und Anbieter. Die Unternehmensarchitektur legt Cloud-Standards fest und strukturiert die gemeinsamen Plattformen. Sie steuert außerdem die APIs, verfolgt Sicherheit und Compliance und begrenzt die Komplexität der Microservices.
Ohne diese Arbeit vermehren sich Cloud-Ressourcen ohne Verantwortlichen und ohne bekannte Nutzung: Das ist Cloud Sprawl.
Erwartete Vorteile und Einschränkungen
Ein Dienst skaliert mit seiner eigenen Last, und ein Ausfall kann auf einen Dienst begrenzt bleiben. Teams liefern häufiger und können die Technologie Dienst für Dienst wechseln. Die Kosten können der tatsächlichen Nutzung folgen, sofern jede Ressource einen Verantwortlichen hat.
Diese Vorteile haben Einschränkungen. Jeder Dienst bringt Schnittstellen, Identitäten, Protokolle und Kosten mit, die zu verfolgen sind. Die Sicherheit betrifft mehr Zugangspunkte, und die Teams brauchen Kenntnisse in Cloud-Plattformen, Kubernetes, DevOps und Automatisierung.
Eine schrittweise Einführung
Der Übergang kann Anwendung für Anwendung erfolgen. Ziel ist eine gemeinsame Plattform, auf der Teams schnell liefern und die Standards des Unternehmens einhalten.
- Bestehende Anwendungen modernisieren, deren Zielbild entschieden ist.
- Diese Anwendungen in Container überführen.
- Eine gemeinsame Kubernetes-Plattform einrichten.
- Die Auslieferung mit DevOps und Continuous Integration automatisieren.
- Die Governance der Cloud-Architektur festlegen: Regeln, Verantwortliche jeder Umgebung und Reviews.
Die Technologieplattform in ArchiLU
In ArchiLU ordnet der Technologiekatalog die Bausteine nach Typ, darunter Container-Plattformen, Infrastrukturdienste und Laufzeitumgebungen. Die Technologielandschaft verbindet Technologien über drei Beziehungen: hostet, hängt ab von und folgt auf.
Jede Anwendung zeigt ihren Technologie-Stack; 90 Tage vor einem Supportende öffnet sich ein Case: verlängern, migrieren, stilllegen oder das Risiko akzeptieren. Im freigegebenen Umfang erfasst der Discovery-Kollektor Linux-Maschinen, Docker-Container und deren TCP-Verbindungen; daraus entstehen Vorschläge zur Prüfung.
Verträge der Anbieter, auch Cloud-Verträge, werden den Anwendungen zugeordnet, die sie abdecken, mit ihrer Fälligkeit und einer erkannten automatischen Verlängerung.
Häufige Fragen
- Bedeutet Cloud Native nur Microservices?
- Nein. Die Definition der CNCF nennt Microservices neben anderen Techniken wie Containern, unveränderlicher Infrastruktur, Serverless und deklarativen APIs. Der Anwendungsstil wird für jede Anwendung gewählt.
- Was ist die erste Architekturpriorität?
- Eine gemeinsame Plattformbasis: Identität, Netzwerk, Beobachtbarkeit und Bereitstellungsstandards. Die Teams bauen ihre Dienste anschließend auf dieser Basis auf.
- Wie lassen sich Cloud-Kosten steuern?
- Mit FinOps-Leitplanken, der Kennzeichnung von Workloads und Kostenverantwortung je Domäne. Die FinOps Foundation beschreibt FinOps als operatives Rahmenwerk und kulturelle Praxis, die den Geschäftswert der Technologie maximiert.