Migrationspfad von Red Hat 3scale API Management zu Red Hat Connectivity Link

Ausgangslage

Red Hat 3scale API Management befindet sich am Ende seines Produktlebenszyklus. Seit Mai 2023 wird es nur noch gewartet, ohne dass neue Features implementiert werden. Unternehmen, insbesondere im hochregulierten Bankenumfeld, stehen daher vor der Herausforderung, ihre voll genutzte 3scale-Plattform – inklusive API-Gateway, Traffic-Management, Authentifizierung, Traffic Analyse etc. – auf eine zukunftsfähige Lösung zu überführen. Mit Connectivity Link bietet Red Hat eine moderne, Kubernetes-native Alternative für API-Konnektivität in hybriden Cloud-Architekturen an.

In diesem Bericht werden folgende Aspekte betrachtet:

• Architekturunterschiede
• Migrationsstrategie in Phasen
• Funktionsvergleich (welche Features lassen sich direkt migrieren, wo besteht Anpassungsbedarf)
• Risiken und Empfehlungen zur Vorbereitung der Migration

Das Ziel ist eine sichere und nahtlose Migration ohne Verlust der API-Governance in einer Umgebung, die Cloud, On-Premises und Container-Plattformen (z. B. OpenShift) umfasst.

1. Architekturvergleich: Red Hat 3scale vs. Red Hat Connectivity Link

Red Hat 3scale API Management

• Klassische Architektur:
  3scale basiert auf einer zentralen API-Management-Architektur. Eine 3scale-Instanz besteht aus:
  • Zentralem API Manager: Mit Admin-Portal, Benutzerverwaltung mit SSO, Entwicklerportal und Datenbank.
  • API-Gateway-Instanzen (APIcast): Ein NGINX-basierter Dienst, der Richtlinien erzwingt und mit dem Backend kommuniziert.
• Trennung von Policy-Konfiguration und -Ausführung:
  Die Konfiguration erfolgt über das 3scale-Portal (oder die 3scale-API) und wird asynchron an die Gateways verteilt.
• Verwaltungsoberfläche für API-Provider:
  Es gibt ein grafisches Admin-Portal und ein Developer-Portal, über das API-Schlüssel, Zugänge und Nutzungsbewertungen zentral gesteuert werden.
  Quelle: Chapter 1. APIcast Overview | Red Hat Product Documentation

Red Hat Connectivity Link

• Kubernetes-nativer Ansatz:
  Connectivity Link verlagert die Funktionen direkt in den Kubernetes-Cluster. Die Kontrolle erfolgt über den Kubernetes Gateway API Standard und den Envoy Proxy.
• Infrastructure-as-Code:
  APIs und Richtlinien werden als Code (über YAML/CRDs) definiert. Wichtige Custom Resource Definitions (CRDs) sind z. B.:
  • AuthPolicy
  • RateLimitPolicy
  • TLSPolicy
  • DNSPolicy
• Integrierte Datenebene:
  Ein oder mehrere Ingress Gateways im Cluster (oft durch Envoy, integriert mit OpenShift Service Mesh/Istio) setzen die Regeln durch.
   
• Dezentrale Verwaltung:
  APIs werden über YAML/CRDs verwaltet, was eine konsistente Steuerung über Kubernetes ermöglicht. Gleichzeitig kommt Kubernetes-RBAC zur Absicherung der Zugriffe zum Einsatz.

Fazit

• 3scale: Zentralisiert mit externer Management-Komponente, separatem Gateway und grafischer Bedienung.
• Connectivity Link: Dezentral durch Envoy Cluster setup und cloud-native, wobei die API-Verwaltung als Code im Cluster erfolgt.
  Dies bedeutet einen Paradigmenwechsel in Betrieb und Zuständigkeiten. Teams müssen sich mit Kubernetes-Ressourcen wie Gateway, HTTPRoute und den spezifischen Policy-CRDs vertraut machen.

Migrationsstrategie und empfohlene Schritte

Die Migration sollte in wohlüberlegten Phasen erfolgen, um Betriebsunterbrechungen und Compliance-Probleme im Bankenumfeld zu vermeiden.

Schritt 1: Analyse und Planungsphase

• Bestandsaufnahme:
  Identifizieren aller vorhandenen APIs und der genutzten 3scale-Komponenten (z. B. API-Schlüsselverwaltung, OAuth, Rate Limits).
• Mapping:
  Für jedes Feature ist festzulegen, ob es direkt in Connectivity Link migriert oder durch ein ergänzendes Tool ersetzt wird.
• Erstellung eines Migrationsfahrplans:
  Festlegen, welche APIs wann migriert werden und welche Vorarbeiten nötig sind.

Schritt 2: Vorbereitung der Zielumgebung

• Installation und Konfiguration:
  Red Hat Connectivity Link wird in der Kubernetes/OpenShift-Umgebung installiert – idealerweise zunächst in einer Staging-Umgebung über den offiziellen Operator.
• Integrationen einrichten:
  • Identity-Provider: Anbindung von Keycloak/Red Hat SSO für OAuth2/JWT-Token.
  • DNS und TLS: Einrichtung der DNSPolicy- und TLSPolicy-CRDs.
  • Monitoring: Deployment von Prometheus/Grafana und Import der Dashboard-Templates.
  • Pilot-Service: Erste API exemplarisch in Connectivity Link definieren, um die Funktionsfähigkeit zu validieren.
• Schulung:
  Das Operations-Team wird im Umgang mit Kubernetes-basiertem API-Management (z. B. Definition von Gateway-Ressourcen und Policies) geschult.

Schritt 3: Parallelbetrieb und schrittweises Onboarding

• Parallelbetrieb:
  Starten Sie einen Parallelbetrieb beider Plattformen, sodass neue oder weniger kritische APIs direkt auf Connectivity Link bereitgestellt werden, während kritische Services vorerst bei 3scale verbleiben.
• Traffic-Steuerung:
  Beide Gateways (3scale APIcast und Connectivity Link Gateway) laufen parallel, und der Traffic wird per DNS- oder Routing-Entscheidung verteilt.

Schritt 4: Iterative Migration der bestehenden APIs

• Schrittweise Umstellung:
  Nach erfolgreichem Onboarding der ersten Services werden sukzessive alle API-Endpunkte auf Connectivity Link umgezogen – basierend auf Kritikalität oder Domänen.
• Testen:
  Vor jeder Umschaltung erfolgt ein intensiver Test (z. B. Policy-Parität, Routen- und Backend-Integrationen).
  Ein Fallback-Plan (z. B. DNS-Rollback) muss bereitstehen.

Schritt 5: Umfassendes Testing & Compliance-Checks

• Tests:
  Durchführung von Sicherheitstests, Last- und Performance-Tests sowie Failover-Szenarien.
• Compliance:
  Einbindung von Security- und Compliance-Teams zur Überprüfung der Policy-as-Code-Definitionen.

Schritt 6: Produktiver Cut-over und Abschaltung von 3scale

• Cut-over:
  Planung eines Wartungsfensters für den endgültigen Umschaltpunkt, in dem der verbleibende Traffic umgeleitet wird.
• Abschaltung:
  Nach finalen Verifikationen wird die 3scale-Installation ausser Betrieb genommen. Die alte Datenbank sollte im Read-only-Modus verbleiben, um historische Daten abrufen zu können.

Schritt 7: Nachbereitung

• Post-Mortem-Analyse:
  Dokumentation von Erfahrungen, Problemen und Lösungen.
• Optimierung:
  Überprüfung, ob weitere Funktionen von Connectivity Link (z. B. Multi-Cluster-Loadbalancing, Geo-Routing, erweiterte Observability) genutzt werden können.

Funktionen: Direkt migrierbar vs. neu zu implementieren

Nicht sämtliche Funktionen von Red Hat 3scale lassen sich eins-zu-eins in Connectivity Link übertragen:

• Direkt migrierbar:
  Kernfunktionen der API-Gateway-Schicht (Traffic-Steuerung, Authentifizierungs-/Autorisierungsregeln, Rate Limiting) können durch entsprechende CRDs in Connectivity Link abgebildet werden.
  Beispielsweise lässt sich eine OAuth2-Policy durch die Kombination aus Kubernetes AuthPolicy und einem angebundenen Identity-Provider (z. B. Keycloak) umsetzen.
• Neu zu implementieren:
  Zusätzliche Funktionen wie das Developer-Portal, API-Katalogisierung oder Abrechnungslogik fehlen aktuell und müssen entweder durch Drittanbieter-Lösungen oder Eigenentwicklungen ersetzt werden.

Die nachfolgende Tabelle vergleicht zentrale Funktionen:

Bewertung:
Authentifizierungs-/Autorisierungsregeln und Traffic-Kontrollen können weitgehend direkt migriert werden. Funktionale Zusatzdienste wie das Developer-Portal und die Abrechnungslogik müssen jedoch entweder durch Drittanbieter-Lösungen ersetzt oder intern neu entwickelt werden.

Potenzielle Gefahren und Risiken der Migration

Bei einer Migration in einem kritischen Umfeld wie dem Finanzsektor müssen diverse Risiken aktiv gemanagt werden:

• Betriebsunterbrechung (Downtime):
  Mögliche Ausfälle während oder nach der Umstellung, bedingt durch Konfigurationsfehler oder Verzögerungen bei DNS-Umschaltungen.
  Mitigation: Parallelbetrieb und ein getesteter Fallback-Plan (Traffic-Rückschaltung) minimieren dieses Risiko.
• Authentifizierungs-/Autorisierungsbrüche:
  Fehlerhafte Migration von API-Schlüsseln, Tokens oder Nutzerkonten könnten legitime Zugriffe blockieren oder Sicherheitslücken öffnen.
  Mitigation: Lückenlose Übernahme aller Zugriffsschlüssel und –regeln sowie detaillierte Tests vor dem Abschalten von 3scale.
• Verlust von API-Governance/Visibility:
  Der Wechsel kann temporär zu einem Verlust zentraler Kontroll- und Compliance-Funktionen führen.
  Mitigation: Frühzeitige Implementierung eines Konzepts für Kunden-/Consumer-Management (z. B. mit Keycloak) und Reporting über Kubernetes-Monitoring.
• Leistungs- und Skalierungsprobleme:
  Unerwartete Performance-Unterschiede oder Latenzen bei falscher Konfiguration des neuen Gateways.
  Mitigation: Lasttests, A/B-Tests und gezieltes Tuning von Envoy in enger Abstimmung mit Red Hat.
• Komplexität und Know-how-Risiko:
  Die Einführung neuer Technologien bringt eine Lernkurve mit sich, die zu Anfang Fehler provozieren kann.
  Mitigation: Umfassende Schulungen und – ggf. Workshops mit Red Hat oder erfahrenen Partnern.
• Unreife oder unbekannte Fehler im neuen Produkt:
  Da Connectivity Link erst 2024 (GA ab Ende 2024) eingeführt wurde, können in der Praxis noch Bugs oder fehlende Features auftreten.
  Mitigation: Enge Zusammenarbeit mit Red Hat und Nutzung von Pilotprojekten zur Validierung.
• Zeit- und Ressourcenrisiko:
  Die Migrationsprojekte dieser Größenordnung können unvorhergesehene Aufwände mit sich bringen.
  Mitigation: Realistische Projektplanung mit ausreichend Puffern und schrittweise Mehrwertlieferungen, um den Druck eines Verbleibs mit 3scale zu vermeiden.

Insgesamt lassen sich viele Risiken durch sorgfältige Vorbereitung, umfassende Tests und einen Parallelbetrieb entschärfen. Eine strukturierte Migrationsstrategie sowie ein transparenter Kommunikationsfluss mit dem Management sind dabei essenziell.

Zusammengefasst:
Nutzen Sie die Expertise von ONLU, um offene Punkte zu adressieren, und legen Sie gemeinsam die Weichen für eine erfolgreiche Migration – sodass Ihre Firma langfristig über eine flexible, sichere und Cloud-fähige API-Management-Landschaft verfügt.

Quellen

• Red Hat Connectivity Link – Innovation und End of Life von 3scale – ONLU AG
• Chapter 1. APIcast Overview | Red Hat Product Documentation
• Red Hat transforms application connectivity for the hybrid cloud with Red Hat Connectivity Link

 [CL1]ONLU Link korrekt?