Einheit 8.1: Architektur-Entscheidungsrahmen

Einführung

An diesem Punkt im Kurs wurde jeder Primitive ausführlich untersucht. Diese Einheit wiederholt sie nicht. Sie ist ein Referenzdokument: eine Sammlung von Auswahlmatrizen, auf die Sie zurückgreifen, wenn ein FinCorp-Tier eine Entscheidung benötigt und Sie das unterscheidende Kriterium, die harte Einschränkung, die eine Wahl direkt disqualifizieren kann, und die Einheit, die die Begründung ableitet, an einem Ort benötigen.

Lesen Sie jede Matrix auf die gleiche Weise. Die unterscheidenden Kriterien verengen das Feld. Die harten Einschränkungen der Zulässigkeit sind absolut: eine einzelne fehlgeschlagene Einschränkung entfernt eine Option, unabhängig davon, wie gut sie an anderer Stelle abschneidet. Die Souveränität und der Geltungsbereich der Zertifizierung werden zuletzt über den gesamten Entwurf angewendet, da die Compliance die Auswahlmöglichkeiten eher einschränkt, als dass sie diese ursprünglich schafft. Die Einheit schließt mit den zwei Möglichkeiten ab, wie ein technisch einwandfreier Entwurf dennoch fehlschlagen kann: das Kombinieren von Primitiven, die sich nicht zusammensetzen, und das Platzieren eines funktional korrekten Dienstes außerhalb des Geltungsbereichs der Zertifizierung, den das Workload erfordert.

1. Auswahl der Compute-Klasse

Die Compute-Entscheidung ist eine vierachsige Aufteilung über die Kernisolierung, CPU-Familiensteuerung, Block-Speicheranbindung und das Betriebsmodell. Die Einschränkung, die am häufigsten disqualifiziert, ist die permanente: Ein Cubes-Template ist nach der Bereitstellung unveränderlich, daher wird eine Klasse, die rekonfiguriert werden kann, für eine Ebene entworfen, deren Form oder Skalierungsanforderungen sich ändern können. VM Auto Scaling selbst ist nur horizontal und erstellt neue Replikate aus einem Replikate-Template zur Entwurfszeit.

Das Muster ist Klasse-pro-Ebene: Eine staatlose Anwendungsebene, die sich ausdehnt, nimmt Dedizierten Kern, eine feste Größe der Utility-Node nimmt einen Cube, eine regulierte Single-Tenant-Workload nimmt Private Cloud. Standardisieren Sie keine Klasse über alle Ebenen hinweg.

2. Container Plattformauswahl

Die Container-Entscheidung hängt davon ab, wer die Kontroll-Plane-Lebensdauer und die Compliance-Last trägt. Nur eine Option legt diese Last auf IONOS.

Für FinCorps Container-Bestand ist der Unterschied der operationale Aufwand: Managed Kubernetes ist der Standard, da IONOS die Kontroll-Plane besitzt, und die kundenseitig bereitgestellten Alternativen werden nur dann gewählt, wenn bereits ein OpenShift- oder Rancher-Vertrag oder ein entsprechendes Fachwissen vorhanden ist.

3. Auswahl der Speichertier

Der Speicher wird dem Zugriffsmuster angepasst. Die wiederkehrende harte Einschränkung ist die SSD-Leistungsgrenze und die Zonenasymmetrie zwischen Rechenressourcen und Speicher.

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

4. Auswahl des Datenbank-Engines

Die Datenbankentscheidung wird durch das Datenmodell im Vordergrund und das Replikations- und Kontinuitätsmodell im Hintergrund getroffen. Bei jedem gemanagten Engine gilt die gleiche Grenze: Es gibt keine Lesereplikate und das Backup Service umfasst keine gemanagten Datenbanken, sodass Leseskalierung und Kontinuität zusammengesetzt und nicht gekauft werden.

Für den transaktionalen Kern von FinCorp beantwortet das PostgreSQL mit strenger synchroner Replikation die Anforderung für den niedrigen RPO, die In-Memory DB-Schicht beantwortet die Leseskalierung, da Lesereplikate nicht existieren, und das Kafka überträgt Änderungsereignisse, da es keinen gemanagten Datenbank-Änderungsstrom gibt.

5. Auswahl von Netzwerkprimitiven

Jede Netzwerkprimitiv beantwortet eine andere Schicht oder Richtung des Datenverkehrs. Die harten Einschränkungen hier sind die häufigste Quelle von inkompatiblen Paarungen (siehe Abschnitt 7).

6. Die Souveränität und Attestationsfilter

Wenden Sie diesen Filter zuletzt auf das fertige Design an. Souveränität und Compliance entstehen nicht aus einer Architektur, sondern verengen die Menge der Placements, die ein bereits korrektes Design verwenden darf. Die EU-rechtliche Souveränität ist eine Eigenschaft der Betreibergerichtsbarkeit und nicht allein der Region: Eine EU-Region eines US-amerikanischen Anbieters ist immer noch von der US-Cloud-Act-Exposition betroffen, während IONOS EU-geführt ist.

Die Attestationsscope unterscheiden sich pro Dienst und dürfen nie auf "die Plattform ist zertifiziert" verallgemeinert werden. Die beiden BSI-Anerkennungen, beide für deutsche Rechenzentren, decken unterschiedliche Dienstesätze ab:

IONOS ist der erste deutsche Cloud-Anbieter, der sowohl die C5-Attestation als auch die IT-Grundschutz-Zertifizierung besitzt, aber die beiden Umfänge sind nicht austauschbar. C5 ist eine Attestation (Testat), Typ 1, und keine Zertifizierung und kein Typ 2. Rechenzentrumsebene-Anmeldeinformationen (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 und keine gehaltene Zertifizierung.

Für FinCorp unter GDPR und BSI ist die Residenz eine Platzierungsentscheidung, die vor jeder Workload-Landung getroffen wird: Deutsche Rechenzentren, EU-Betreiber und jeder im Umfang liegende Dienst wird gegen die exakte Attestation validiert, die seine Datenklasse erfordert.

Entscheidungszusammenfassung

Verwenden Sie die oben genannten Matrizen als Ergebnisartefakt der Einheit. Die Lesereihenfolge ist festgelegt:

1. Eingrenzen durch das differenzierende Kriterium für die Stufe.
2. Eliminieren Sie jede Option, die eine harte Zulassungsbeschränkung nicht erfüllt, bevor Sie andere Aspekte berücksichtigen.
3. Wenden Sie den Souveränitäts- und Attestationsfilter zuletzt auf das gesamte Design an.

7. Die Zwei Kompositionsfehler

Ein Design kann jede primitive Matrix bestehen und dennoch fehlschlagen. Zwei Fehler sind für fast alle dieser Fälle verantwortlich.

Das Kombinieren inkompatibler Primitiven. Zwei Auswahlmöglichkeiten, die jeweils in Isolation korrekt sind, komponieren sich nicht. Das Platzieren einer Netzwerksicherheitsgruppe "vor" einem Managed ALB oder NLB hat keinen Effekt, da NSGs an Server-NICs und nie an die gemanagte Load Balancer gebunden sind; die Filterung muss auf den Zielen leben. Die Erwartung von eingehendem Datenverkehr durch ein NAT-Gateway schlägt fehl, da NAT nur SNAT ist; die Veröffentlichung von eingehendem Datenverkehr gehört zu einem Load Balancer oder einem reservierten öffentlichen IP. Der Versuch, eine Cross-Connect-Verbindung herzustellen, um zwei virtuelle Rechenzentren in verschiedenen Regionen zu verbinden, schlägt fehl, da Cross-Connect nur innerhalb derselben Region und desselben Vertrags möglich ist. Jedes ist ein korrekt verwendetes Primitiv, das durch seine harten Einschränkungen verboten wird.

Eine funktional korrekte Wahl außerhalb des erforderlichen Zertifizierungsbereichs. Ein Dienst kann die Aufgabe perfekt erfüllen und dennoch die falsche Wahl für ein reguliertes Workload sein, da er außerhalb der Zertifizierung liegt, die Workload erfordert. Das Ausführen von FinCorps regulierter containerisierter Verarbeitung auf Managed Kubernetes ist funktional einwandfrei, aber Managed Kubernetes liegt nicht im Zertifizierungsbereich von C5, sodass ein Workload, das vertraglich C5 erfordert, auf einem C5-abgedeckten Dienst wie Compute Engine platziert werden muss. Die Wahl ist nicht technisch falsch; sie ist falsch im Hinblick auf den Bereichsfilter, der genau deshalb als letzter über das gesamte Design angewendet wird.

Zusammenfassung

Architektur-Entscheidungen bei IONOS lassen sich auf einen wiederholbaren Prozess reduzieren: Eingrenzen durch das differenzierende Kriterium, Eliminieren durch die harten Einschränkungen und Anwenden des Souveränitäts- und Attestations-Umfangs zuletzt über das fertige Design. Die Matrizen in dieser Einheit sammeln diese Kriterien und Einschränkungen für Compute, Container, Speicher, Datenbanken und Netzwerke, sodass eine Entscheidung getroffen und gerechtfertigt werden kann, mit den zwei Zusammensetzungsfehlern als letzte Überprüfung.

Wichtige Punkte:

• Harte Eignungseinschränkungen disqualifizieren sofort: Eine einzelne fehlgeschlagene Einschränkung entfernt eine Option, unabhängig davon, wie gut sie an anderer Stelle abschneidet.
• VM Auto Scaling ist nur horizontal und erstellt neue Replikate aus einem Designzeit-Replikat-Vorlage; es gibt keine Lesereplikate; die Backup Service deckt keine gemanagten Datenbanken ab. Diese Grenzen entscheiden die Ebenen im Voraus.
• Der Souveränitäts- und Attestations-Filter wird zuletzt angewendet, da die Compliance ein bereits abgeschlossenes Design einschränkt, anstatt es zu initiieren.
• C5 und IT-Grundschutz-Umfänge unterscheiden sich pro Service: Cubes ist in C5, aber nicht in IT-Grundschutz; Sicherung und Managed Kubernetes sind in IT-Grundschutz, aber nicht in C5. Nie verallgemeinern zu "die Plattform ist zertifiziert".
• Die zwei Zusammensetzungsfehler sind die Paarung von Primitiven, deren Einschränkungen die Paarung verbieten, und die Platzierung eines funktional korrekten Services außerhalb des Attestations-Umfangs, den der Workload erfordert.

Wichtige Begriffe:

• Harte Eignungseinschränkung: ein absoluter Disqualifizierer (zum Beispiel ein unveränderliches Template eines Würfels oder Managed Kubernetes's Fehlen von Skalierbarkeit auf Null), der eine Option entfernt, bevor ein gewichteter Kriterium berücksichtigt wird.
• Attestations-Umfang: die exakte Menge an Services, die ein Credential abdeckt; bei IONOS decken C5 und IT-Grundschutz unterschiedliche Services ab, und ein Anspruch muss immer an den benannten Service, den deutschen Rechenzentrum-Standort, das Credential, seinen Typ und sein Datum gebunden werden.

Weitere Lektüre

• Einheit 4.1 Auswahl der Compute-Klasse, Einheit 4.4 Private Cloud (Dedicated VMware)
• Einheit 6.1 Kubernetes-Plattform-Design, Einheit 6.4 Container-Registrierung und Plattform-Auswahl
• Einheit 5.7 Datensicherheit und Lebenszyklus
• Einheit 1.4 Souveränität und Compliance als Design-Eingaben
• Einheit 8.2 Die Referenz-Unternehmensarchitektur