Einheit 1.3: Entwurf um Plattformgrenzen herum: Das Native-Substitutionsmodell

Einführung

Der häufigste Fehler, den ein erfahrener Architekt bei IONOS begeht, ist die Suche nach einem gemanagten Produkt, das nicht existiert, nichts zu finden und daraus zu schließen, dass die Plattform eine Funktion vermissen lässt. Die genauere Interpretation ist, dass die Plattform bewusst Primitive ausliefert und von Ihnen erwartet, die Fähigkeit zu komponieren. Es gibt kein gemanagtes API Gateway, keine Read-Replica-Funktion, kein gemanagtes Failover-Produkt, keinen Datenbank-Change-Data-Capture-Service, keinen OVF/OVA-Import-Assistenten und kein Policy-Sprache-Identitätssystem. Keiner dieser Punkte ist ein Versäumnis, das entschuldigt werden muss, sondern vielmehr eine Fähigkeit, die die Plattform von Ihnen erwartet, aus den Teilen zu erstellen, die sie Ihnen zur Verfügung stellt. Diese Einheit nennt die Substitute für jeden, denn sobald Sie das Modell verstehen, hören die offensichtlichen Lücken auf, Überraschungen zu sein, und werden zu bekannten Entwurfsmustern. Jedes Substitute gibt einen Vorgeschmack auf das Modul, das es vollständig aufbaut.

1. Die Ersetzungsmenge

Das Muster ist immer das gleiche: Eine Fähigkeit, die ein Hyperscaler als ein verwaltetes Bedienungselement verkaufen könnte, ist bei IONOS eine Zusammensetzung von zwei oder drei Primitiven, die Sie zusammen verbinden. Stellen Sie die Grenze ehrlich dar, dann greifen Sie auf das native Muster zu.

Inhaltsrouting anstelle eines verwalteten API Gateway. Es gibt kein IONOS API Gateway-Produkt. Das native Muster routet auf Inhalte mit Managed ALB-Weiterleitungsregeln am Rand (host- und pfadbasiert, da die ALB Anwendungsebenenverkehr auf benutzerdefinierten Richtlinien routet) und einem in-Cluster-Ingress-Controller für feinere Routing innerhalb von Kubernetes. Die ALB übernimmt die grobe öffentliche Routing; Ingress übernimmt das feine interne Routing. Beachten Sie, dass die ALB keine IP-Zulassungsliste und keine Sicherheitsgruppe hat, sodass die Anfragefilterung auf den Zielen liegen muss. Dies wird in Modul 3 (Layer-7-Lastverteilung) aufgebaut.

Leseskalierung anstelle von Lese-Replikaten. Verwaltete Datenbanken auf IONOS haben keine Lese-Replikate und keine native Replikation auf eine andere verwaltete Instanz. Sie skalieren Lesen mit einem In-Memory DB-Cache vor der relationalen Ebene plus Verbindungspooling, um die Datenbank-RAM-abgeleitete Verbindungsobergrenze zu respektieren. Der Cache absorbiert den lesintensiven Datenverkehr; der Pooler hält die Verbindungszahl überlebensfähig. Dies wird in Modul 5 (relationale und In-Memory-Datenbank-Einheiten) aufgebaut.

Automatischer Failover anstelle eines verwalteten Failover-Produkts. Es gibt keinen verwalteten Failover-Service. Die native Ersetzung kombiniert Lastenausgleich-Health-Checks, die den Datenverkehr von einem ungesunden Ziel innerhalb des Load Balancer-Back-end-Pools umleiten, mit einem kundenorchestrierten, niedrigem TTL-Cloud DNS-Eintrag, den ein externer Health-Check für den Failover zwischen Zonen umleitet. Cloud DNS selbst ist nicht gesundheitsbewusst; es dient jedem Eintrag, den Sie setzen. Da DNS nur neue Verbindungen umleitet und durch die Eintrag-TTL begrenzt ist, muss die Anwendungsebene zustandslos sein, damit dies sauber ist. Dies wird in Modul 3 (DNS und Failover) aufgebaut und in Modul 7 (Widerstandsfähigkeit) nochmals besprochen.

Anwendungsebenen-Ereignisse anstelle von Datenbank-Änderungsdaten-Erfassung. Es gibt keinen verwalteten Änderungsdaten-Erfassungsstrom von den Datenbanken. Die native Ersetzung ist, Ereignisse von der Anwendung selbst zu veröffentlichen, typischerweise auf Managed Kafka, wo ein Thema die Änderungsergebnisse erfasst und nachgelagerte Verbraucher sie lesen. Die Erfassung bewegt sich in den Anwendungscode hinein, anstatt den Datenbank-Log anzuzapfen. Dies wird in Modul 5 (Ereignis-Streaming) aufgebaut.

Bildkonvertierung anstelle von nativer OVF/OVA-Import. Es gibt keinen nativen OVF/OVA-Import-Assistenten. Die Migration einer vorhandenen virtuellen Maschine ist ein konstruierter Schritt: Konvertieren und Hochladen des Datenträgerbildes, wobei VirtIO-Treiber installiert und ein UEFI-Übergang vorbereitet sind, nach dem das Bild in der Region, in die es hochgeladen wurde, verwendbar ist (Bilder sind regionsspezifisch gesperrt). Dies wird in Modul 7 (Migration und Hybrid-Übergang) aufgebaut.

Gruppe-und-Gewährleistung anstelle von Richtliniensprache-IAM. Es gibt kein feingranulares, richtlinienbasiertes Identitätssystem. Zugriffskontrolle ist gruppenbasiert mit ressourcenbasierten Gewährleistungen: Sie weisen Privilegien einer Gruppe zu und gewähren dieser Gruppe Zugriff auf bestimmte Ressourcen, und es gibt keine Ablehnungsregel, sodass das Prinzip der geringsten Privilegien einfach bedeutet, dass nichts gewährt wird. Dies wird in Modul 2 (Identität und RBAC) aufgebaut.

Die folgende Tabelle ist das Modell auf einer Seite; behandeln Sie es als Index des REST des Kurses.

Für FinCorp ändert das Modell die gesamte Einbindung. Seine regulierte relationale Workload-Datenbank wird kein verwaltetes Lese-Replikat erhalten, sodass der Entwurf bereits einen Cache- und Pooler-Lesepfad plant. Sein VMware-Anwesen wird nicht als OVF/OVA importiert, sodass der Migrationsplan bereits eine Bildkonvertierung annimmt (neben den VMware-nativen Pfaden, die später abgedeckt werden). Sein Zugriffsmodell wird keine Ablehnungsrichtlinie durchsetzen, sodass die Governance als bewusste, minimale Gewährleistung entworfen wird. Keiner dieser Punkte ist eine Ausweichlösung, die unter Druck spät entdeckt wird; jeder ist ein bekanntes Muster, das von Anfang an ausgewählt wird, weil der Architekt das Ersetzungsmodell von Anfang an hatte.

Entscheidungszusammenfassung

Wenn eine Anforderung eine Fähigkeit nennt, die Sie als Produkt nicht finden können, sollten Sie nicht annehmen, dass die Plattform diese Fähigkeit nicht besitzt. Führen Sie stattdessen diesen Check durch:

Die Disziplin besteht darin, nie eine Funktion aus einem Produktname oder einem Hyperscaler-Analogon abzuleiten. Stellen Sie die Grenze einfach dar und komponieren Sie das Muster.

Zusammenfassung

IONOS kombiniert Fähigkeiten aus Primitiven, anstatt sie als einzelne gemanagte Funktionen zu verkaufen, sodass mehrere Dinge, die ein Architekt als Produkte erwarten könnte, ein API Gateway, Lesereplikate, gemanagtes Failover, Change-Data-Capture, OVF/OVA-Import und Richtlinien-IAM, als native Substitute geliefert werden: ALB-Regeln plus Ingress, Cache plus Pooling, LB-Health-Checks plus low-TTL-DNS-Umleitung, Anwendungsebenenereignisse, Bildkonvertierung und Gruppen- und Rechtezuweisung. Durch die Verwendung dieses Modells werden offensichtliche Lücken in bekannte Muster umgewandelt und der REST des Kurses wird an dem Ort, an dem jedes Substitute erstellt wird.

Wichtige Punkte:

• Die Plattform liefert Primitiven und erwartet die Kombination; ein fehlendes gemanagtes Produkt ist ein Design-Eingabe und kein Defekt.
• Die sechs Kernsubstitute sind Inhaltsswitching (ALB + Ingress), Leseskalierung (Cache + Pooling), Failover (LB-Health-Checks + kundenseitig orchestrierte DNS-Umleitung), Change-Data-Capture (App-Ereignisse), VM-Import (Bildkonvertierung) und Zugriffskontrolle (Gruppen- und Rechtezuweisung).
• Jedes Substitute trägt eine Einschränkung, die geplant werden muss, und jedes gibt einen Vorgeschmack auf das spätere Modul, das es erstellt.
• Nie eine Fähigkeit aus einem Produktname oder einem Hyperscaler-Analogon ableiten; die Grenze bestätigen, dann das native Muster kombinieren.