Einheit 1.3: Designen um Plattformgrenzen: Das Native-Ersatzmodell

Einführung

Der häufigste Fehler, den ein erfahrener Architekt auf IONOS CLOUD begeht, besteht darin, nach einem verwalteten Produkt zu suchen, das nicht existiert, nichts zu finden und daraus zu schließen, dass der Plattform eine Funktion fehlt. Die genauere Einordnung lautet, dass die Plattform bewusst Primitiven bereitstellt und davon ausgeht, dass Sie die gewünschte Fähigkeit selbst zusammenstellen. Es gibt kein verwaltetes API Gateway, keine Read-Replica-Funktion, kein verwaltetes Failover-Produkt, keinen Datenbank-Change-Data-Capture-Dienst, keinen OVF/OVA-Import-Assistenten und kein Identitätssystem auf Basis einer Policy-Sprache. Keines dieser Elemente ist ein zu entschuldigender Übersehen; jedes davon ist eine Fähigkeit, die die Plattform davon ausgeht, dass Sie sie aus den bereitgestellten Bausteinen selbst zusammenbauen. Diese Einheit benennt für jedes Element den jeweiligen Ersatz, denn sobald Sie das zugrunde liegende Modell verinnerlicht haben, sind die scheinbaren Lücken keine Überraschungen mehr, sondern bekannte Designmuster. Jeder Ersatz gibt einen Ausblick auf das Modul, das die jeweilige Fähigkeit vollständig aufbaut.

1. Der Substitutions-Satz

Das Muster ist immer dasselbe: Eine Fähigkeit, die ein Hyperscaler möglicherweise als eine verwaltete Einstellung verkauft, ist auf IONOS CLOUD eine Zusammensetzung aus zwei oder drei Bausteinen, die Sie miteinander verdrahten. Definieren Sie die Grenze ehrlich und greifen Sie dann zum nativen Muster.

Inhaltsbasierte Routing-Steuerung anstelle eines verwalteten API Gateways. Es gibt kein IONOS CLOUD API Gateway-Produkt. Das native Muster routet basierend auf dem Inhalt über Managed ALB-Forwarding-Regeln an der Kante (host- und pfadbasiert, da der ALB Anwendungsebenen-Traffic anhand benutzerdefinierter Richtlinien routet) und einem In-Cluster-Ingress-Controller für feinere Routing-Steuerung innerhalb von Kubernetes. Der ALB übernimmt das grobe öffentliche Routing; der Ingress übernimmt das feine interne Routing. Bedenken Sie, dass der ALB keine IP-Zulassungslisten und keine Security Groups unterstützt, daher gehört die Anfragefilterung zu den Zielen. Dies wird in Modul 3 (Lastverteilung auf Ebene 7) aufgebaut.

Read-Skalierung anstelle von Read-Replikaten. Verwaltete Datenbanken auf IONOS CLOUD haben keine Read-Replikate und keine native Replikation zu einer anderen verwalteten Instanz. Sie skalieren Lesevorgänge mit einem In-Memory DB-Cache vor der relationalen Ebene plus Verbindungspooling, um die von der Datenbank-RAM abgeleitete Verbindungsgrenze einzuhalten. Der Cache nimmt den leseintensiven Traffic auf; der Pooler hält die Verbindungszahl im vertretbaren Rahmen. Dies wird in Modul 5 (die Einheiten zu relationalen und In-Memory-Datenbanken) aufgebaut.

Automatisches Failover anstelle eines verwalteten Failover-Produkts. Es gibt keinen verwalteten Failover-Dienst. Der native Ersatz kombiniert Load-Balancer-Health-Checks, die Traffic von einem ungesunden Ziel innerhalb des Backend-Pools des Load Balancers wegsteuern, mit einem von der Kundenseite orchestrierten Cloud DNS-Eintrag mit niedriger TTL, den ein externer Health-Check für das Cross-Zone-Failover neu ausrichtet. Cloud DNS selbst ist nicht Health-bewusst; es liefert den Eintrag, den Sie gesetzt haben. Da DNS nur neue Verbindungen steuert und durch die TTL des Eintrags begrenzt ist, muss die Anwendungsebene zustandslos sein, damit dies sauber funktioniert. Dies wird in Modul 3 (DNS und Failover) aufgebaut und in Modul 7 (Resilienz) erneut aufgegriffen.

Anwendungsebenen-Ereignisse anstelle von Datenbank-Change-Data-Capture. Es gibt keinen verwalteten Change-Data-Capture-Stream aus den Datenbanken. Der native Ersatz besteht darin, Ereignisse von der Anwendung selbst zu veröffentlichen, typischerweise auf Managed Kafka, wobei ein Topic die Änderungseignisse erfasst und nachgelagerte Konsumenten sie lesen. Die Erfassung wandert in den Anwendungscode, anstatt das Datenbankprotokoll anzuzapfen. Dies wird in Modul 5 (Event Streaming) aufgebaut.

Bildkonvertierung anstelle von nativer OVF/OVA-Import. Es gibt keinen nativen OVF/OVA-Import-Assistenten. Die Migration einer bestehenden virtuellen Maschine ist ein konstruierter Schritt: Konvertieren und Hochladen des Disk-Images, mit installierten VirtIO-Treibern und vorbereiteter UEFI-Übergabe, nach dem das Bild in der Region nutzbar ist, in die es hochgeladen wurde (Bilder sind regiongebunden). Dies wird in Modul 7 (Migration und Hybrid-Cutover) aufgebaut.

Gruppieren und Berechtigen anstelle von Policy-sprachlichem IAM. Es gibt kein fein granulares, policybasiertes Identitätssystem. Die Zugriffskontrolle ist gruppenbasiert mit ressourcenspezifischen Berechtigungen: Sie weisen einer Gruppe Berechtigungen zu und gewähren dieser Gruppe Zugriff auf bestimmte Ressourcen, und es gibt keine Verweigerungsregel, daher bedeutet geringste Berechtigung einfach, nichts zu gewähren. Dies wird in Modul 2 (Identität und RBAC) aufgebaut.

Die folgende Tabelle ist das Modell auf einer Seite; behandeln Sie sie als Index für den Rest des Kurses.

Für FinCorp rahmt das Modell das gesamte Engagement neu. Seine regulierte relationale Workload erhält kein verwaltetes Read-Replikat, daher plant das Design bereits einen Cache-und-Pooler-Lese-Pfad. Sein VMware-Umfang wird nicht als OVF/OVA importiert, daher geht der Migrationsplan bereits von einer Bildkonvertierung aus (neben den später behandelten VMware-nativen Pfaden). Sein Zugriffsmodell wird keine Verweigerungsrichtlinie durchsetzen, daher wird Governance als bewusste, minimale Berechtigungsvergabe gestaltet. Keines dieser Elemente ist ein Workaround, der spät unter Druck entdeckt wurde; jedes ist ein bekanntes Muster, das von Anfang an ausgewählt wurde, weil der Architekt das Substitutionsmodell von Beginn an im Griff hatte.

Zusammenfassung der Entscheidung

Wenn eine Anforderung eine Funktion benennt, die Sie nicht als Produkt finden, nehmen Sie nicht an, dass die Plattform diese Funktion nicht bietet. Führen Sie stattdessen diese Überprüfung durch:

Die Disziplin besteht darin, niemals eine Funktion aus einem Produktnamen oder einem Analogon eines Hyperscalers abzuleiten. Formulieren Sie die Grenze klar und setzen Sie das Muster zusammen.

Zusammenfassung

IONOS CLOUD setzt Funktionen aus Bausteinen zusammen, anstatt sie als einzelne verwaltete Features anzubieten. Daher werden mehrere Komponenten, die ein Architekt als eigenständige Produkte erwarten würde, wie ein API-Gateway, Lese-Replikate, verwaltetes Failover, Change-Data-Capture, OVF/OVA-Import und Policy-IAM, als native Alternativen bereitgestellt: ALB-Regeln plus Ingress, Cache plus Pooling, LB-Health-Checks plus DNS-Umleitung mit niedriger TTL, anwendungsebene Ereignisse, Bildkonvertierung und Group-and-Grant. Dieses Modell zu verstehen, verwandelt scheinbare Lücken in bekannte Muster und macht den Rest des Kurses zum Ort, an dem jede dieser Alternativen aufgebaut wird.

Wichtige Punkte:

• Die Plattform liefert Bausteine und erwartet deren Zusammensetzung; ein fehlendes verwaltetes Produkt ist ein Entwurfsinput, kein Defekt.
• Die sechs zentralen Alternativen sind Inhaltsrouting (ALB + Ingress), Lese-Skalierung (Cache + Pooling), Failover (LB-Health-Checks + kundenseitig orchestrierte DNS-Umleitung), Change-Data-Capture (Anwendungsebene Ereignisse), VM-Import (Bildkonvertierung) und Zugriffskontrolle (Group-and-Grant).
• Jede Alternative bringt eine Einschränkung mit sich, die bei der Planung berücksichtigt werden muss, und jede gibt einen Vorgeschmack auf das spätere Modul, in dem sie aufgebaut wird.
• Leiten Sie niemals eine Funktion aus einem Produktnamen oder einem Hyperscaler-Analogon ab; klären Sie die Grenze und setzen Sie dann das native Muster zusammen.