Einheit 8.1: Architektur-Entscheidungsrahmen

Einführung

Bis zu diesem Punkt im Kurs wurde jeder Primitive gründlich 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 differenzierende 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 differenzierenden 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. Souveränität und Attestationsumfang werden zuletzt über den gesamten Entwurf angewendet, da Compliance die Auswahlmöglichkeiten einschränkt, anstatt sie zu erstellen. Die Einheit endet mit den zwei Möglichkeiten, 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 Attestationsumfangs, den die Workload erfordert.

1. Auswahl der Compute-Klasse

Die Compute-Entscheidung ist eine vierachsige Aufteilung über Core-Isolation, CPU-Familiensteuerung, Block-Storage-Anbindung und das Betriebsmodell. Die Einschränkung, die am häufigsten disqualifiziert, ist die permanente: Ein Cubes-Template ist nach der Bereitstellung unveränderlich, so dass eine Klasse, deren Form oder Skalierungsanforderungen sich ändern können, auf eine Klasse entworfen wird, die neu konfiguriert werden kann. VM Auto Scaling selbst ist horizontal-only und erstellt neue Replikate aus einem Designzeit-Replikat-Template.

Das Muster ist Klasse-pro-Tier: Eine stateless-Anwendungsebene, die sich horizontal skalieren lässt, nimmt Dedicated Core, ein festes Diensteknoten-Utility nimmt ein Cube, eine regulierte Einzelmandanten-Workload nimmt Private Cloud. Standardisieren Sie keine Klasse über alle Ebenen hinweg.

2. Auswahl der Container-Plattform

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

Für das Container-Anwesen von FinCorp ist der Unterschied der operativen Aufwand: Managed Kubernetes ist die Standardoption, da IONOS CLOUD die Steuerungsebene besitzt, und die kundenbasierten Alternativen werden nur dann gewählt, wenn bereits ein OpenShift- oder Rancher-Vertrag oder eine entsprechende Fachkompetenz besteht.

3. Auswahl der Speichertier

Der Speicher wird dem Zugriffsmuster zugeordnet. Die wiederkehrende harte Einschränkung ist die Leistungsgrenze der SSD 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 und das Replikations- und Kontinuitätsmodell bestimmt. Bei den relationalen Engines gibt es keine Lesereplikate, und der Backup Service deckt keine verwaltete Datenbank ab, sodass die Leseskalierbarkeit und Kontinuität zusammengesetzt und nicht gekauft werden.

Für den transaktionalen Kern von FinCorp beantwortet PostgreSQL mit streng synchronisierter Replikation die Anforderung eines niedrigen RPO, die In-Memory DB-Schicht beantwortet die Lese-Skalierbarkeit, da es keine Lesereplikate gibt, und Kafka überträgt Änderungsereignisse, da es keinen verwalteten Datenbank-Änderungsstrom gibt.

5. Auswahl der Netzwerkprimitiven

Jede Netzwerkprimitive beantwortet eine andere Schicht oder Richtung des Datenverkehrs. Die harten Einschränkungen hier sind die häufigste Quelle inkompatibler 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; sie verengen die Menge der Plätze, die ein bereits korrektes Design verwenden darf. Die rechtliche Souveränität der EU ist eine Eigenschaft der Betreibergerichtsbarkeit, nicht allein der Region: Eine EU-Region eines US-amerikanischen Anbieters ist immer noch von der US-Cloud-Act-Exposition betroffen, während IONOS CLOUD EU-geführt wird.

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

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

Für FinCorp unter GDPR und BSI ist die Residenz eine Platzierungsentscheidung, die vor jeder Workload 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 irgendetwas anderes berücksichtigen.
3. Wenden Sie den Souveränitäts- und Attestationsfilter zuletzt über das gesamte Design an.

7. Die Zwei Zusammensetzungsfehler

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 Network Security Group "vor" einem Managed ALB oder NLB hat keinen Effekt, da NSGs an Server-NICs und nie an den gemanagten Lastenausgleich gebunden sind; die Filterung muss auf den Zielen erfolgen. Die Erwartung von eingehendem Datenverkehr durch ein NAT-Gateway schlägt fehl, da NAT nur SNAT-only ist; die Veröffentlichung von eingehendem Datenverkehr gehört zu einem Lastenausgleich oder einer 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 der gleichen Region und des gleichen Vertrags möglich ist. Jedes ist ein korrektes Primitiv, das an einem Ort verwendet wird, an dem seine harte Einschränkung es verbietet.

Eine funktional korrekte Wahl außerhalb des erforderlichen Nachweisspektrums. Ein Dienst kann die Aufgabe perfekt erfüllen und dennoch die falsche Wahl für eine regulierte Arbeitslast sein, da er außerhalb des Nachweises liegt, den diese Arbeitslast erfordert. Die Ausführung von FinCorps regulierter containerisierter Verarbeitung auf Managed Kubernetes ist funktional einwandfrei, aber Managed Kubernetes liegt nicht im C5-Nachweisspektrum, sodass eine Arbeitslast, die vertraglich C5 erfordert, auf einem C5-abgedeckten Dienst wie Compute Engine platziert werden muss. Die Wahl ist nicht technisch falsch; sie ist falsch gegenüber dem Spektrumfilter, der genau deshalb als letzter über das gesamte Design angewendet wird.

Zusammenfassung

Architektur-Entscheidungen bei IONOS CLOUD lassen sich auf einen wiederholbaren Prozess reduzieren: Eingrenzung durch das differenzierende Kriterium, Eliminierung durch die harten Einschränkungen und Anwendung der Souveränität und Attestationsscope zuletzt über das fertige Design. Die Matrizen in dieser Einheit sammeln diese Kriterien und Einschränkungen für Compute, Container, Speicher, Datenbanken und Netzwerk, so dass 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 horizontal-only und erstellt neue Replikate aus einem Designzeit-Replikat-Vorlage; die relationalen Motoren haben keine Lesereplikate; der Backup Service deckt keine verwaltete Datenbank ab. Diese Grenzen entscheiden die Ebenen im Voraus.
• Der Souveränitäts- und Attestationsfilter wird zuletzt angewendet, da die Compliance ein bereits abgeschlossenes Design einschränkt, anstatt es zu initiieren.
• C5 und IT-Grundschutz-Bereiche unterscheiden sich pro Service: Cubes ist in C5, aber nicht in IT-Grundschutz; Backup und Managed Kubernetes sind in IT-Grundschutz, aber nicht in C5. Nie verallgemeinern zu "die Plattform ist zertifiziert".
• Die zwei Zusammensetzungsfehler sind Paarung von Primitiven, deren Einschränkungen die Paarung verbieten, und Platzierung einer funktional korrekten Dienstleistung außerhalb des Attestationsscope, den die Workload erfordert.

Wichtige Begriffe:

• Harte Eignungseinschränkung: ein absoluter Disqualifikator (zum Beispiel ein unveränderliches Template eines Würfels oder das Fehlen von Skalierbarkeit bei Managed Kubernetes), der eine Option entfernt, bevor irgendein gewichteter Kriterium berücksichtigt wird.
• Attestationsscope: die exakte Menge an Dienstleistungen, die ein Credential abdeckt; bei IONOS CLOUD decken C5 und IT-Grundschutz unterschiedliche Dienstleistungen ab, und ein Anspruch muss immer an den benannten Dienst, 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 Entwurf 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 Gestaltungsparameter
• Einheit 8.2 Die Referenz-Unternehmensarchitektur