Einheit 8.1: Architekturentscheidungsrahmen

Einführung

An diesem Punkt des Kurses wurde jedes Primitiv bereits eingehend untersucht. Diese Einheit lehrt sie nicht erneut. Sie ist ein Referenzdokument: eine Sammlung von Auswahlmatrizen, auf die Sie zurückgreifen, wenn eine FinCorp-Ebene eine Entscheidung erfordert und Sie das Unterscheidungskriterium, die harte Einschränkung, die eine Option sofort ausschließen kann, sowie die Einheit, aus der die Begründung abgeleitet wird, an einem einzigen Ort benötigen.

Lesen Sie jede Matrix auf dieselbe Weise. Die Unterscheidungskriterien schränken das Feld ein. Die harten Zulässigkeitsbedingungen sind absolut: Eine einzige nicht erfüllte Bedingung schließt eine Option aus, unabhängig davon, wie gut sie in anderen Bereichen abschneidet. Souveränität und Attestierungsumfang werden zuletzt angewendet, über das gesamte Design hinweg, da Compliance die Auswahl einengt, statt sie zu begründen. Die Einheit schließt mit den zwei Wegen, auf denen ein technisch solides Design dennoch scheitert: die Kombination von Primtiven, die nicht zusammenwirken, und die Platzierung eines funktional korrekten Dienstes außerhalb des Attestierungsumfangs, den die Workload erfordert.

1. Auswahl der Compute-Klasse

Die Compute-Entscheidung gliedert sich in vier Dimensionen: Kernisolierung, Steuerung der CPU-Familie, Anbindung von Block Storage und das operative Modell. Die häufigste Ausschlusskriterium ist die permanente Einschränkung: Das Template eines Cubes ist nach der Bereitstellung unveränderlich. Daher werden Ebenen, deren Struktur oder Skalierungsbedarf sich ändern kann, auf eine Klasse ausgelegt, die neu konfiguriert werden kann. VM Auto Scaling ist ausschließlich horizontal und erzeugt neue Replikate aus einer zur Design-Zeit definierten Replikatvorlage.

Das Muster ist Klasse pro Ebene: Eine zustandslose Anwendungsebene, die horizontal skaliert, nutzt Dedicated Core. Ein Utility-Knoten fester Größe nutzt einen Cube. Ein regulierter Single-Tenant-Workload nutzt Private Cloud. Standardisieren Sie nicht eine Klasse über alle Ebenen hinweg.

2. Auswahl der Container-Plattform

Die Entscheidung für eine Container-Plattform hängt davon ab, wer den Lebenszyklus der Steuerungsebene und die Compliance-Verantwortung trägt. Nur eine Option überträgt diese Verantwortung auf IONOS CLOUD.

Für das Container-Umfeld von FinCorp ist der operative Aufwand das entscheidende Kriterium: Managed Kubernetes ist die Standardwahl, da IONOS CLOUD die Steuerungsebene besitzt. Die vom Kunden deployten Alternativen werden nur dann gewählt, wenn bereits ein OpenShift- oder Rancher-Vertrag oder eine entsprechende Fachkompetenz vorhanden ist.

3. Auswahl der Storage-Ebene

Storage wird dem Zugriffsmuster zugeordnet. Die wiederkehrende harte Einschränkung ist die Leistungsgrenze von SSD und die Zonenasymmetrie zwischen Compute und Storage.

Beachten Sie die Zonenasymmetrie als Platzierungseinschränkung: Block Storage bietet Zone 1, 2, 3 und Auto, während Compute nur Zone 1, 2 und Auto bietet. Ein redundantes Paar, das an "Zone 3 Compute" festgelegt ist, ist nicht möglich, da Compute Zone 3 nicht existiert.

4. Auswahl der Datenbank-Engine

Die Entscheidung für eine Datenbank wird primär durch das Datenmodell und sekundär durch das Replikations- und Kontinuitätsmodell gesteuert. Bei den relationalen Engines gibt es keine Lese-Replikate, und der Backup Service deckt keine verwaltete Datenbank ab. Daher werden Skalierung für Lesezugriffe und Kontinuität selbst aufgebaut und nicht als fertige Lösung bezogen.

Für den transaktionalen Kern von FinCorp erfüllt PostgreSQL mit strikt synchroner Replikation die Anforderung an einen niedrigen RPO, die In-Memory DB-Ebene deckt die Lese-Skalierung ab, da keine Lese-Replikate existieren, und Kafka überträgt die Änderungsereignisse, da kein verwalteter Datenbank-Change-Stream vorhanden ist.

5. Auswahl der Netzwerkprimitiven

Jedes Netzwerkprimitiv beantwortet eine andere Ebene oder Richtung des Datenverkehrs. Die harten Einschränkungen sind hier die häufigste Ursache für inkompatible Kombinationen (siehe Abschnitt 7).

6. Der Souveränitäts- und Attestationsfilter

Wenden Sie diesen Filter zuletzt auf das fertige Design an. Souveränität und Compliance begründen keine Architektur; sie schränken den Bereich der Platzierungen ein, die ein bereits korrektes Design nutzen darf. Die rechtliche Souveränität der EU ist eine Eigenschaft der Jurisdiktion des Betreibers, nicht allein der Region: Eine EU-Region eines von den USA betriebenen Anbieters unterliegt weiterhin dem US CLOUD Act, während IONOS CLOUD von einem EU-Betreiber betrieben wird.

Die Attestationsbereiche unterscheiden sich je nach Dienst und dürfen niemals verallgemeinert werden zu „Die Plattform ist zertifiziert“. Die beiden BSI-Anerkennungen, beide für deutsche Rechenzentren, decken unterschiedliche Dienstesets ab:

IONOS CLOUD ist der erste deutsche Cloud-Anbieter, der sowohl das C5-Testat als auch die IT-Grundschutz-Zertifizierung hält, aber die beiden Bereiche sind nicht austauschbar. C5 ist ein Testat, Typ 1, keine Zertifizierung und nicht Typ 2. Rechenzentrumsebene-Zertifizierungen (zum Beispiel ISO 27001 an einem Standort, PCI-DSS, Uptime Tier IV) werden vom Rechenzentrumsbetreiber gehalten und variieren je nach Standort; Produktzertifikatslisten im Marketing sind nicht vertraglich bindend. NIS2 ist eine regulatorische Verpflichtung, keine gehaltene Zertifizierung.

Für FinCorp unter DSGVO und BSI ist die Datenresidenz eine Platzierungsentscheidung, die vor dem Einbringen jeder Workload getroffen wird: Deutsche Rechenzentren, EU-Betreiber und jeder im Geltungsbereich liegende Dienst, validiert gegen das genaue Testat, das seine Datenklasse erfordert.

Zusammenfassung der Entscheidung

Verwenden Sie die oben genannten Matrizen als das zentrale Ergebnis dieser Einheit. Die Leseordnung ist festgelegt:

1. Filtern Sie anhand des Unterscheidungskriteriums für die jeweilige Ebene.
2. Schließen Sie alle Optionen aus, die eine harte Zulässigkeitsbedingung nicht erfüllen, bevor Sie andere Faktoren berücksichtigen.
3. Wenden Sie den Filter für Souveränität und Attestierung zuletzt auf das gesamte Design an.

7. Die zwei Kompositionsfehler

Ein Design kann jede Matrix für einzelne Bausteine bestehen und dennoch fehlschlagen. Zwei Fehler machen fast alle dieser Fälle aus.

Kombination inkompatibler Bausteine. Zwei Entscheidungen, die jeweils für sich genommen korrekt sind, lassen sich nicht kombinieren. Die Platzierung einer Network Security Group „vor" einem Managed ALB oder NLB bewirkt nichts, da NSGs an Server-NICs gebunden werden und niemals an den verwalteten Load Balancer; die Filterung muss auf den Zielen erfolgen. Die Erwartung, eingehenden Verkehr über ein NAT Gateway zu leiten, schlägt fehl, da NAT ausschließlich SNAT unterstützt; die Veröffentlichung eingehenden Verkehrs obliegt einem Load Balancer oder einer reservierten öffentlichen IP. Der Versuch, zwei VDCs in verschiedenen Regionen über ein Cross-Connect zu verbinden, schlägt fehl, da Cross-Connect nur innerhalb derselben Region und desselben Vertragsverhältnisses verfügbar ist. Jeder dieser Bausteine ist korrekt, wird aber dort eingesetzt, wo seine harte Einschränkung dies verbietet.

Eine funktional korrekte Wahl außerhalb des erforderlichen Attestierungsbereichs. Ein Dienst kann die Aufgabe perfekt erfüllen und dennoch die falsche Wahl für einen regulierten Workload sein, weil er außerhalb der Attestierung liegt, die dieser Workload erfordert. Die Ausführung der regulierten, containerbasierten Verarbeitung von FinCorp auf Managed Kubernetes ist funktional einwandfrei, aber Managed Kubernetes liegt nicht im Attestierungsbereich von C5, sodass ein Workload, der vertraglich C5 erfordert, auf einem von C5 abgedeckten Dienst wie Compute Engine platziert werden muss. Die Wahl ist technisch nicht falsch; sie ist falsch im Hinblick auf den Bereichsfilter, weshalb genau dieser Filter am Ende über das gesamte Design angewendet wird.

Zusammenfassung

Architekturentscheidungen auf IONOS CLOUD reduzieren sich auf einen wiederholbaren Ablauf: Eingrenzung anhand des Unterscheidungskriteriums, Ausschluss anhand der harten Constraints und abschließende Anwendung des Souveränitäts- und Attestierungsumfangs auf das fertige Design. Die Matrizen in dieser Einheit bündeln diese Kriterien und Constraints für Compute, Container, Storage, Datenbanken und Networking, damit eine Entscheidung an einem Ort getroffen und begründet werden kann, wobei die beiden Kompositionsfehler als letzte Querkontrolle dienen.

Wichtige Punkte:

• Harte Eignungsconstraints führen zum sofortigen Ausschluss: Ein einzelner nicht erfüllter Constraint eliminiert eine Option, unabhängig davon, wie gut sie bei anderen Kriterien abschneidet.
• VM Auto Scaling ist ausschließlich horizontal und erzeugt neue Replikate aus einer Replikatvorlage, die zur Designzeit festgelegt wird; die relationalen Engines bieten keine Lese-Replikate; der Backup Service deckt keine verwaltete Datenbank ab. Diese Grenzen bestimmen die Ebenen im Voraus.
• Der Souveränitäts- und AttestierungsfILTER wird zuletzt angewendet, da Compliance ein bereits vollständiges Design eingrenzt, anstatt es zu begründen.
• Die Umfänge von C5 und IT-Grundschutz unterscheiden sich je nach Service: Cubes ist in C5, aber nicht in IT-Grundschutz; Backup und Managed Kubernetes sind in IT-Grundschutz, aber nicht in C5. Vermeiden Sie pauschale Aussagen wie „die Plattform ist zertifiziert“.
• Die beiden Kompositionsfehler bestehen darin, Primitiven zu kombinieren, deren Constraints diese Kombination verbieten, sowie einen funktional korrekten Service außerhalb des Attestierungsumfangs zu platzieren, den die Workload erfordert.

Wichtige Begriffe:

• Harter Eignungsconstraint: ein absoluter Ausschlussgrund (zum Beispiel die unveränderliche Vorlage eines Cubes oder das Fehlen von Scale-to-zero bei Managed Kubernetes), der eine Option eliminiert, bevor gewichtete Kriterien berücksichtigt werden.
• Attestierungsumfang: der genaue Satz an Services, den eine Zertifizierung abdeckt; auf IONOS CLOUD decken C5 und IT-Grundschutz unterschiedliche Services ab, und eine Aussage muss stets auf den benannten Service, den deutschen Rechenzentrumsstandort, die Zertifizierung, deren Typ und deren Datum bezogen werden.

Weitere Lektüre

• Einheit 4.1 Auswahl der Compute-Klasse, Einheit 4.4 Private Cloud (dediziertes VMware)
• Einheit 6.1 Design der Kubernetes-Plattform, Einheit 6.4 Container Registry und Plattformauswahl
• Einheit 5.7 Datensicherung und Lebenszyklus
• Einheit 1.4 Souveränität und Compliance als Entwurfsparameter
• Einheit 8.2 Die Referenz-Unternehmensarchitektur