Lesezeit: 2 Minuten

Teil 4: Eigenschaften einer Cloud-native Architektur
 

Brave New World

“Innovation is the only insurance against irrelevance” - Gary Hamel

Cloud-Technologien liefern Softwarearchitekten neue Möglichkeiten, Dinge zu tun, die mit bisherigen Mitteln in den eigenen Rechenzentren häufig nicht mit vertretbaren Aufwänden (Dauer, Kosten) umsetzbar bzw. mit zusätzlichen Risiken verbunden waren (z.B. fehlende Erfahrung im Betrieb von kritischer Infrastruktur, NoSQL Datenbanken, usw.).

Zu den neuen Möglichkeiten zählen folgende Aspekte:

• Self-Healing bei Störungen und Fehlerfällen,
• automatisierte Skalierung (in beide Richtungen)
• Elastizität, um bei Lastspitzen automatisch, bedarfsgerecht reagieren zu können
• Reduzierung der Tätigkeiten im Bereich Infrastruktur für DevOps-Teams
• Autonomie und Flexibilität durch Self-Services und Automatisierungslösungen
• Transparenter und kosteneffizienter Betrieb der (geteilten) Infrastruktur
   

Zielsetzungen

Darüber hinaus bringen Cloud-native Architekturen eine eigene Philosophie und Arbeitsweise mit sich, die sich u.a. durch folgende Zielsetzungen beschreiben lässt:

• Arbeitserleichterung durch Nutzung von Services/Abstraktionen des Cloud-Anbieters
• Bessere Systemqualität durch hohen Automatisierungsgrad
• Überblick und kontinuierliche Überwachung der Systemlandschaft mittels Monitoring und geeigneten Alerting-Mechanismen
• Vermeidung von Flaschenhälsen (z.B. durch Einsatz stark skalierender Persistenzsysteme, Nutzung von Serverless Frameworks und Implementierung von zustandslosen Diensten)
• Behandlung von Schnittstellen/APIs als Produkte (API Lifecycle Management für HTTP/RESTful APIs aber auch für asynchrone APIs wie z.B. Kafka, AMQP, MQTT)
• Kontinuierliche Überprüfung der Sicherheit aller Komponenten und Härtungsmaßnahmen und verteiltes Verantwortungsmodell zwischen Cloud Service Provider und Nutzer
• Ausrichtung der Architektur auf Veränderung (Evolutionäre Architekturen)

Vergleichen wir unsere Ziele mit der Definition der CNCF (http://www.cncf.io) für Cloud-native Systeme:

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

Break the Chains

Ein weiteres Ergebnis der genannten Zielsetzung sind neue Möglichkeiten, Daten- und Wissenssilos aufzubrechen. Durch die Entkopplung und Vereinheitlichung von Serviceschnittstellen bildet sich eine unternehmensweite Service-Landschaft. Unter Einsatz von Governance-Maßnahmen und zentralen API-Management-Plattformen werden Services und Teams stärker vernetzt. Gateways und Adapter bieten Möglichkeiten, Daten zwischen verschiedenen Netzwerkzonen auszutauschen. Kombiniert mit einem tief integrierten Authentifizierungs- und Autorisierungsmodell über die Cloud-Plattform hinweg lassen sich so neue Muster zur Enterprise Application Integration verfolgen.

Abwägung: Agnostik vs. Vendor Lock-In

Ein häufig genanntes Ziel von Unternehmen ist auch die Agnostik von Anwendungen gegenüber dem Cloud Service Provider. Es soll also ermöglicht werden, jederzeit zwischen Cloud-Plattformen zu wechseln.

Hier muss beachtet werden, dass solche Architekturen zwar möglich sind, dann aber die Verwendungsmöglichkeit vieler Services der einzelnen Cloud Service Provider einschränken. Eine Anwendung lässt sich also portabel gestalten, dann muss aber auf bestimmte Vorteile verzichtet werden, die eine spezifische Plattform bieten könnte.

Beispielsweise lässt sich eine containerisierte Anwendungskomponente vergleichsweise leicht von Plattform zu Plattform verschieben. Anders verhält es sich allerdings bei der Integration dieser Komponente in eine größere Anwendungslandschaft. So lässt sich zum Beispiel die Authentifizierung und Autorisierung zwischen Anwendungen unter Einsatz von Mechanismen der Betriebsplattform relativ leicht und vor allem einheitlich realisieren.
Soll die Anwendung allerdings Provider-agnostisch funktionieren, muss diese Authentifizierung und Autorisierung entweder für die nächste Plattform neu implementiert, oder es muss auf eine portable Lösung gesetzt werden. Diese Trade-offs gilt es zu beachten und mit den Unternehmenszielen abzugleichen.

Ausblick: Wie beeinflussen die genannten Eigenschaften einer Cloud-native Architektur die Arbeit eines Architekten? Welche Werkzeuge gibt es und wie sind diese in den Architekturalltag eingebettet?

Diese Fragen beantworten wir in unserem nächsten Blogbeitrag mit dem Titel "Einfluss von Cloud-native auf die Architekturarbeit" am 22. Dezember 2022.

Noch Fragen? Wir helfen Ihnen gerne!