Architektur-Review in der Cloud

Architektur-Audits von IT-Systemen sind ein alter Hut: Man legt Ziele und Methodik des Audits fest, prüft den Code des Systems, validiert Design-Entscheidungen gegen die Systemziele und nichtfunktionale Anforderungen und führt Interviews mit Beteiligten, um das System zu verstehen. Das Ganze wird in einem Bericht zusammengefasst, der die Findings aus dem Audit für das Management abstrahiert. Im Idealfall werden Maßnahmen vorgeschlagen, die dabei helfen sollen, die Findings zu beheben oder gut genug abzuschwächen.

Review in der Cloud?

Jetzt steht das IT-System aber in der Cloud. Und eigentlich ist es kein einzelnes IT-System. Es besteht aus einer Vielzahl unabhängiger Services, die verteilt bei diversen Cloud-Anbietern betrieben werden. Genau genommen ist jeder dieser Services selbst ein IT-System. Wie soll man ein Architektur-Audit für 30, 40 oder 50 (Micro-)Services durchführen? Geht das überhaupt bei einer solchen Service-Landschaft? Ja, das geht. Am besten mit einem Perspektivwechsel. Wir begeben uns in die Wolken.

Perspektivwechsel 1: Methodik

ATAM & Co.

Klassische Architektur-Review-Methoden stammen aus einer Zeit, da existierte die Cloud – so wie wir sie heute kennen – bestenfalls als Idee in den Köpfen. Review-Methoden wie ATAM, SACAM, FAAM oder DoSAM sind aber ohnehin nicht auf die Größe oder den Umfang eines IT-Systems, das auditiert werden soll, fokussiert. Sie sind also prinzipiell auch für Services anwendbar.

Es geht aber noch passgenauer: Die Review-Methodik QUASAR basiert auf der Grundannahme, dass die Qualitätsmerkmale eines IT-Systems auch für seine Teilsysteme und Teil-Teilsysteme überprüfbar sind. Das gilt natürlich auch für die vielen verteilten Services unserer Service-Landschaft. Aus der Prüfung der einzelnen Elemente – hier den Services -, aus denen sich ein System zusammensetzt, lassen sich so also Rückschlüsse auf das Gesamtsystem treffen.

Twelve-Factor-App

Einen neuen Ansatz für die Architektur-Bewertung von Services liefert die Methodik Twelve-Factor-App. Die Twelve-Factor-App ist keine Architektur-Review-Methode, sondern ein Ansatz für die Erstellung und den Betrieb von cloudbasierten Services. Die namensgebenden zwölf Faktoren sind Kriterien, die jeder Service in der Cloud erfüllen bzw. jede Organisation, die Services für die Cloud bereitstellt, erfüllen sollte.

Das Service-Universum einer Organisation im Rahmen eines Reviews gegen die zwölf Faktoren zu prüfen, erscheint schon mal als vernünftige Idee. SaaS und IaaS sind implizit Bestandteil der zwölf Faktoren (siehe nächster Abschnitt).

Perspektivwechsel 2: SaaS und IaaS

Unsere verteilten Services neigen dazu weitere Services zu benutzen, die eine zusätzliche Fähigkeit bereitstellen, z.B. eine Datenbank, ein Messaging-System oder ein Monitoring Framework. Damit wird die Komplexität des eigenen Services verringert. Dieses Konstrukt – Software as a Service (SaaS) – erhöht andererseits die Komplexität der Kommunikationsbeziehungen unseres Services und potenziell auch die der zu auditierenden Service-Landschaft.

Zusätzlich laufen unsere Services in der Regel nicht mehr im eigenen Rechenzentrum, sondern auf der Hardware von Cloud-Anbietern wie AWS, Google, Microsoft … quasi irgendwo – Hauptsache die geltenden Datenschutzbestimmungen werden dort eingehalten und die Antwortzeiten stimmen … und die anderen nichtfunktionalen Anforderungen auch … doch dazu kommen wir besser später nochmal. Mit der Bereitstellung der Hardware durch die Cloud-Anbieter geht häufig auch die Bereitstellung von Tools zur Verwaltung der Infrastruktur einher. Unsere Services nutzen dann Infrastructure as a Service (IaaS).

IaaS erhöht die Verteiltheit – wenn es das Wort überhaupt gibt – unserer Services und damit unserer Service-Landschaft gegenüber SaaS noch weiter. In jedem Fall müssen wir beide Ansätze – SaaS und IaaS – beim Architektur-Audit berücksichtigen.

Run Costs spielen bei SaaS und IaaS eine wichtige Rolle. Wie teuer ist es eine IT-Lösung dauerhaft mit Hilfe von SaaS/IaaS zu betreiben, und wie kann man reagieren, wenn die Kosten deutlich steigen?

Perspektivwechsel 3: PaaS

Cloud-Anbieter wie Google, Microsoft oder AWS bieten neben Infrastruktur auch Lösungen an, die speziell in ihrer jeweiligen Cloud laufen, z.B. Google Big Query, AWS Lambda oder Azure Stream Analytics. Diese plattformspezifischen Lösungen (Platform as a Service – PaaS) erzeugen unter Umständen ein Vendor Lock-In. Basierend auf den Plattformen der großen Provider werden z.B. von Instaclustr, ObjectRocket oder Aiven Instanzen für Datenbank-, Messaging- oder Caching-Lösungen angeboten – praktisch eine weitere Ausprägung von SaaS (siehe oben).

Wer sein Geschäft auf eine solche Plattform/Lösung fokussiert, hat – wenn sich die Rahmenbedingungen bei einem der Cloud-Anbieter ändern (z.B. der Preis deutlich erhöht wird) – unter Umständen Schwierigkeiten, sich wieder von diesem Anbieter zu lösen.

Vendor Lock-in ist zugegeben kein Kind der Cloud. In klassischen IT-Systemen konnte der Vendor Lock-in praktisch mit jedem eingekauften Produkt passieren. In der Cloud geschieht der Lock-in aber bereits mit der genutzten Plattform. Grund genug im Architektur-Review genauer auf diesen Aspekt zu schauen.

AWS bietet ein eigenes Framework zur Architektur-Bewertung für Lösungen seiner Kunden. Leider reduziert sich der Fokus des Well Architected Framework darauf zu bewerten, ob ganzheitlich AWS-Lösungen eingesetzt wurden. Der Mehrwert dieses Ansatzes mag damit grundsätzlich eingeschränkt sein. Für Organisationen, die sich bewusst in diese Abhängigkeit zu AWS begeben, bietet das Framework hingegen eine angemessene Validierung der Umsetzung ihrer Plattform-Strategie.

Run Costs spielen auch bei PaaS eine Rolle. Kann ein Vendor Lock-in in eine Kostenfalle führen, wenn sich die Gebühren für die Plattform meiner Wahl signifikant erhöhen?

Perspektivwechsel 4: Nichtfunktionale Anforderungen für die Cloud

Nichtfunktionale Anforderungen spielen bei klassischen IT-Systemen genau wie bei einer verteilten Service-Landschaft eine große Rolle. Allerdings verschiebt sich bei Cloud Services der Fokus stark hin zu

• Sicherheit

• Zuverlässigkeit (Reliability)

• Robustheit

• Fehlertoleranz

• Skalierbarkeit

während für die (klassischen) IT-Systeme eher

• Durchsatz

• Konsistenz

• Ressourcen-Verbrauch

relevant sind. Beide Listen sind mit hoher Sicherheit unvollständig. Relevant ist die Ambivalenz zum Beispiel zwischen Skalierbarkeit (Cloud) und Ressourcen-Verbrauch (IT-System).

Das Paradigma Eventual Consistency (zeitnahe Konsistenz) ist ebenfalls ein Kind der Cloud und bei klassischen IT-Systemen eher ungewöhnlich. Das CAP-Theorem ist ebenfalls eher cloudspezifisch: Es besagt, dass in einem verteilten System Verfügbarkeit, Konsistenz und Ausfallsicherheit nie alle gleichzeitig erfüllbar sind, sondern maximal zwei dieser Eigenschaften.

Im Architektur-Review erscheint es also eher wenig zielführend, klassisch-geprägte nichtfunktionale Anwendungen auf verteilte Services anzuwenden. Eine gute Anregung bietet wieder die Twelve-Factor-App.

Perspektivwechsel 5: Rahmenbedingungen

Die Bewertung einer IT-Lösung mit Blick auf geltende Rahmenbedingungen für Services in der Cloud sind im Architektur-Review-Kontext ebenfalls spannend. Die nachfolgende Liste zeigt nur einen kleinen Ausschnitt relevanter Rahmenbedingungen auf.

Time2Market

Eine cloudbasierte Lösung muss den Kunden schnell bereitgestellt werden können? Änderungen an der Lösung müssen noch schneller produktiv genommen werden? Also spielt Time2Market eine Rolle – auch wieder eine Rahmenbedingung. Passende nichtfunktionale Eigenschaften, die sich in diesem Kontext für den Architektur-Review eignen, sind Konfigurierbarkeit, Anpassbarkeit, Testbarkeit oder Wartbarkeit. Stabilität wäre in diesem Kontext eine Eigenschaft, die im Zusammenhang mit der Architektur der Lösung eine Rolle spielt: Wie gut eignet sich der gewählte Architekturansatz, um Änderungen/Erweiterungen schnell umsetzen und liefern zu können? Wie leicht können getroffene (Architektur-)Entscheidungen geändert werden, wenn sich fachliche Anforderungen ändern?

Business Continuity

Die Verteiltheit von Cloud-Services bietet für die Sicherstellung von Business Continuity erweiterte Lösungsmuster gegenüber IT-Lösungen außerhalb der Cloud. Fällt der Zugriff auf ein Rechenzentrum aus, ist der Service noch über die verbleibenden sechs Rechenzentren erreichbar. Spielt Business Continuity für unseren Service eine Rolle, muss sie auch im Review untersucht und bewertet werden.

Sicherheit

Sicherheit ist für unseren Cloud-Service zum einen eine nichtfunktionale Anforderung, hat aber auch Bedeutung als Rahmenbedingung, da die Daten unserer Services häufig per Definition sicher transportiert und aufbewahrt werden müssen. Gerade durch ihre Verteiltheit erscheinen Cloud-Services angreifbarer.

Komplexität

Komplexität ist eine Eigenschaft, die beim Vergleich zwischen klassischer IT- und Cloud-Lösung stark adressiert wird. Zuerst einmal ist Komplexität keine wünschenswerte Eigenschaft von IT-Systemen. Erstrebenswert ist eher das Gegenteil – eine Mischung aus Einfachheit, Testbarkeit und Modularität – willkommene, nichtfunktionale Eigenschaften wohl jeder Software. Und genau diese sind beim Architektur-Review Untersuchungs- und Bewertungskriterien für die Komplexität jeder Lösung.

Der fachliche Prozess, der in einer Software abgebildet wird, kann per se komplex sein. Wird der Prozess mit einer cloudbasierten Lösung abgebildet, wird er wahrscheinlich in kleinere Module oder Services zerschnitten, in deren Kommunikationsbeziehungen untereinander die Komplexität des Prozesses abgebildet ist.

In der klassischen IT-Lösung desselben Fachprozesses besteht die Wahlmöglichkeit¹ zwischen den gleichen bzw. ähnlichen Modulen und Services oder einer monolithischen Lösung, bei der die Komplexität im Code selbst liegt.

Eine monolithische Cloud-Lösung wäre eher ungewöhnlich.

Self-Containment

Self-Containment – die vollständige Unabhängigkeit eines Services von seiner Umwelt – nimmt unter den hier betrachteten Rahmenbedingungen eine Sonderstellung ein. Erstens, handelt es sich eigentlich um einen Architektur-Stil für cloud- oder besser webbasierte Systeme. Zweitens, stellt sie an Services, für die Self-Containment gilt, Anforderungen jenseits der Architektur: Ein Self-contained System soll beispielsweise von einem einzelnen Team entwickelt werden. Drittens soll ein SCS über eine eigene Oberfläche verfügen, über die sie in bestehende Systeme integriert werden kann. Und da wäre viertens noch der erforderliche fachliche Schnitt, der dafür sorgt, dass ein Self-contained System keinen Code mit anderen Services teilt.

Self-Containment bringt also viele eigene Bedingungen mit sich, die im Rahmen eines Architektur Reviews separat betrachtet werden müssen.

Perspektivwechsel 6: Schnittstellen

Je mehr Services meine Service-Landschaft umfasst und je intensiver diese Services genutzt werden, desto mehr Schnittstellen mit echten Schnittstellen-Definitionen und potenziell echten SLAs liegen vor. Es drängt sich geradezu auf, die APIs der Service-Landschaft zu untersuchen und zu bewerten. Die eine API-Review-Methode, die alle Fragen beantwortet, haben wir leider nicht gefunden, aber mit der folgenden Liste eine erste Näherung erhalten, welche Aspekte relevant sind:

• API Design Review: http://work.haufegroup.io/api-style-guide/api-design-review-process/api-design-review-process.html

• API Design Review at Scale: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/45294.pdf

• API Benutzbarkeit: https://www.drdobbs.com/windows/measuring-api-usability/184405654

• API Design Guidelines: https://swagger.io/blog/api-design/api-design-guidelines/

Perspektivwechsel 7: Vorgehensmodell/Entwicklungsprozess

Gegenstand von Architektur-Audits sind in aller Regel auch der Entwicklungsprozess, die Qualitätssicherung und der Build-Prozess der Organisation, die Services für die verteilte Service-Landschaft zur Verfügung stellt, wartet und weiterentwickelt. Agiles Vorgehen oder ein hoher Automatisierungsgrad sollten dabei keine Besonderheit von cloudbasierten Services sein.

Spannender ist da schon der Build-Prozess: Wie häufig wird deployt? Wie lange dauert es, eine neue Version zu deployen? Wer ist für die Services verantwortlich: ein dediziertes Operations-Team oder haben wir DevOps-Teams, die für den gesamten Lebenszyklus der Services verantwortlich sind?

Zusammenfassung

Architektur-Reviews in der Cloud können mit einem Perspektivwechsel mit Blick auf die Bewertungs-Methodik und ihre -kriterien, auf cloudrelevante nichtfunktionale Anforderungen, auf *aaS und mit einem besonderen Fokus auf Schnittstellen gelingen. Besonderes Augenmerk gilt dabei den Kriterien der Twelve-Factor-App, die einen guten Ausgangspunkt für nichtfunktionale Anforderungen und Rahmenbedingungen für Service-Landschaften in der Cloud bieten.

 

¹ Monolithische Lösungen sind nie erstrebenswert. Doch mangelnde Erfahrung, mangelnder Wille oder mangelnder Bedarf sind nach wie vor direkte Zufahrtsstraßen zum Monolithen.