Referenzarchitektur / Gesamtbeispiel

Praxis: Enterprise-Referenzarchitektur von Portal bis Datenbank

Dieses Kapitel verbindet alle Bausteine: Ein Kundenportal nutzt APIs, Messaging, Datenbanken, Batch, Observability, Security, GitOps und DR über eine moderne Enterprise-Infrastruktur.

Szenario

Ein Unternehmen betreibt ein Kundenportal, eine Order API, Billing, Partner-Schnittstellen, Reporting und Batchverarbeitung. Teile laufen auf VMs, neue Services auf OpenShift/Kubernetes, Datenbanken auf spezialisierten Plattformen, Integration über Messaging und APIs.

Fachlicher Ablauf

Kunde bestellt im Portal. Das Portal ruft die Order API auf. Die Order API validiert, schreibt in eine Datenbank, publiziert ein Event, Billing verarbeitet später die Abrechnung, Reporting liest konsolidierte Daten.

Technische Abbildung

DNS und Load Balancer veröffentlichen das Portal. Firewall und API-Gateway kontrollieren Zugriffe. OpenShift betreibt Portal und Order API. Messaging entkoppelt Billing. Datenbanken nutzen Gold-Storage und Backup. Observability korreliert jeden Checkout. GitOps hält Manifeste versioniert.

Migrationsgedanke

Legacy-Komponenten werden nicht blind ersetzt. Stabil laufende Datenbanken können zunächst bleiben. Neue APIs werden um alte Systeme gelegt. Netzwerk, IAM, Monitoring und Backup werden schrittweise harmonisiert.

Entscheidungsmatrix

VM eignet sich für klassische Middleware, Datenbanken oder lizenzgebundene Produkte. Kubernetes eignet sich für horizontal skalierbare Services. Bare Metal eignet sich für spezielle Performance- oder Lizenzanforderungen. SaaS kann sinnvoll sein, wenn Fachlichkeit nicht differenziert.

Ausführliche Beispiele

Gesamtarchitektur als Datenfluss

Client -> DNS -> Load Balancer -> WAF/API Gateway -> OpenShift Route -> Portal Pod
Portal Pod -> Order API Service -> Order API Pods -> DB
Order API -> Event Broker -> Billing Worker
Alle Komponenten -> Metrics/Logs/Traces -> Observability Platform
Git -> Pipeline -> Registry -> GitOps Controller -> Cluster
Backup -> Immutable Storage -> DR Site

Kombinierte Infrastruktur-Entscheidung

workloads:
  customer-portal:
    platform: openshift
    reason: stateless, scalable, frequent releases
  order-api:
    platform: openshift
    reason: container-ready, needs autoscaling and GitOps
  billing-engine:
    platform: vm
    reason: legacy library, scheduled processing, stable release cycle
  order-database:
    platform: managed-db-or-vm
    reason: stateful, strict backup and performance requirements
  event-broker:
    platform: operator-on-openshift-or-dedicated-vm
    reason: depends on enterprise standard and ops maturity

Minimaler Runbook-Ausschnitt

## Checkout-Störung

Symptom: Fehlerrate Checkout > 3% für 10 Minuten.

Prüfen:
1. Dashboard Order Journey öffnen.
2. Trace-ID aus einem fehlerhaften Request nehmen.
3. Order API, Payment Client, DB und Event Broker prüfen.
4. Letzte Deployments im GitOps-Controller prüfen.
5. Bei Deployment-Korrelation Rollback starten.
6. Fachbereich informieren, wenn mehr als 15 Minuten Impact.

Typische Stolperfallen

Alle Workloads werden aus Prinzip in dieselbe Plattform gedrückt.
Legacy wird modernisiert, ohne Daten- und Betriebsrisiko zu verstehen.
Netzwerk- und Security-Teams werden zu spät eingebunden.
Observability endet an Plattformgrenzen.
DR betrachtet nur neue Services, nicht abhängige Altkomponenten.

Prüf- und Verständnis-Checkliste

Für jeden Workload ist die Plattformentscheidung begründet.
Datenfluss ist dokumentiert.
Security-Flüsse sind genehmigt.
Monitoring deckt Ende-zu-Ende-Journey ab.
Migration hat Zwischenzustände und Rollback-Punkte.

Merksatz

Eine Infrastrukturkomponente ist erst enterprise-tauglich, wenn sie geplant, automatisiert, überwacht, geschützt, wiederherstellbar und fachlich begründet ist.