Moderne API-Konnektivität in hybriden Multi-Cloud-Architekturen

Red Hat Connectivity Link ist eine neue, Kubernetes-native Plattform für API-Konnektivität, die darauf abzielt, verteilte Anwendungen in komplexen Umgebungen einfacher, sicherer und einheitlicher zu verbinden. In modernen Architekturen spannen Applikationen häufig mehrere Kubernetes-Cluster, Rechenzentren und Cloud-Umgebungen. Traditionelle Ansätze erforderten hierfür meist mehrere separate Tools – etwa separate Lösungen für API-Sicherheit, Rate Limiting, Service Mesh etc. – was Integration und Betrieb erschwerte. Connectivity Link schlägt einen neuen Weg ein: Es konsolidiert Traffic-Routing, Sicherheits- und Policy-Management-Funktionen in einer einheitlichen Lösung direkt in Kubernetes. Dadurch sinkt die Komplexität spürbar, und sowohl Entwicklungs- als auch Plattform-Teams können Konnektivitätsregeln zentral definieren, verwalten und über alle Umgebungen hinweg einsehen.

Als Kubernetes-native Lösung setzt Connectivity Link auf aufstrebende Cloud-Native-Standards wie den Kubernetes Gateway API Standard und den bewährten Envoy-Proxy. Diese Basis ermöglicht es, Ingress-Gateways clusterübergreifend konsistent zu steuern. Policies für Authentifizierung, Autorisierung, DNS-Routing oder TLS-Verschlüsselung werden einfach als Kubernetes-Objekte definiert – anstatt wie früher in externen Systemen oder durch manuelle Konfiguration. So werden API-Gateways quasi zu Erweiterungen des Clusters, was insbesondere in hybriden Cloud-Szenarien eine durchgängige Kontrolle erlaubt. Connectivity Link adressiert damit die Herausforderungen moderner IT-Organisationen mit einer einzigen integrierten Lösung, statt eines komplexen Geflechts aus mehreren Produkten.

Vorteile für Multi-Cloud

Unternehmen in regulierten Sektoren legen grossen Wert auf Ausfallsicherheit und Flexibilität. Connectivity Link wurde von Anfang an für hybride und Multi-Cloud-Architekturen konzipiert. Es ermöglicht beispielsweise, Traffic dynamisch über mehrere Kubernetes-Cluster und Standorte zu verteilen – ob on-premises im eigenen Rechenzentrum oder in verschiedenen Public-Cloud-Regionen. Durch die Integration gängiger DNS-Provider können Ingress-Endpunkte automatisch in DNS registriert werden, inklusive Failover-Mechanismen über Cluster-Grenzen hinweg. Für Banken bedeutet dies, dass Dienste selbst bei Ausfall eines ganzen Standortes verfügbar bleiben und Nutzer transparent auf einen alternativen Cluster umgeleitet werden können. Zusätzlich kann der Datenverkehr anhand von geografischen Kriterien gelenkt werden. So lassen sich beispielsweise Abfragen von europäischen Kunden an einen EU-basierten Cluster schicken, um regulatorische Vorgaben zur Datenhaltung einzuhalten. Diese location-based routing Fähigkeit stellt sicher, dass Latenz optimiert und zugleich Compliance-Anforderungen (z. B. Datenregionalität) erfüllt werden.

End-of-Life von Red Hat 3scale: Auswirkungen auf Bankensysteme

Das Supportende von Red Hat 3scale API Management markiert einen entscheidenden Wendepunkt für Unternehmen, die bisher auf diese Lösung gesetzt haben. Laut Lifecycle-Informationen wurde der volle Produktsupport für 3scale bereits Mitte 2021 eingestellt, und seit Mai 2023 befindet sich 3scale in der finalen Maintenance-Phase ohne weitere Produktentwicklungen. Praktisch bedeutet dies: Es erscheinen keine neuen Features oder Versionen mehr, lediglich kritische Bugs werden noch eine begrenzte Zeit behoben. Für Banken, die 3scale in ihrer Integrationsarchitektur nutzen, stellt dies ein Risiko dar. Einerseits können sicherheitsrelevante Updates ausbleiben, was im hochregulierten Finanzsektor zu Compliance-Problemen führen kann. Andererseits fallen mit der Zeit Wettbewerbsnachteile ins Gewicht, da moderne Anforderungen – etwa nahtlose Cloud-Integration oder Kubernetes-Native-Operation – von 3scale nicht mehr adressiert werden. Red Hat ordnet im Rahmen einer strategischen Neuausrichtung einige Middleware-Produkte neu ein; 3scale gehört zu den Lösungen, deren Weiterentwicklung zugunsten neuer Ansätze depriorisiert wurde. Organisationen müssen daher planen, wie sie die Funktionalität von 3scale ablösen oder modernisieren.

Was bedeutet das konkret? Bestehende API-Programme, die auf 3scale laufen (z. B. Partner-APIs, Open Banking-Schnittstellen oder interne Microservice-APIs), sollten frühzeitig auf eine zukunftsfähige Plattform migriert werden. Ohne Hersteller-Support ist ein weiteres produktives Betreiben von 3scale mittelfristig nicht tragbar – nicht zuletzt, weil interne Security- und Compliance-Richtlinien der Banken dies verbieten könnten. Zudem steigt der Integrationsaufwand, wenn neuere Technologien (wie Service Meshes oder Cloud-native Ingress Controller) nicht mehr mit dem alten System harmonieren. Die Einführung von Red Hat Connectivity Link ist vor diesem Hintergrund ein strategischer Wechsel in Red Hats API-Portfolio, der Kunden einen modernen Ersatz für 3scale bietet. Connectivity Link deckt viele der Kernanforderungen an API-Konnektivität und -Sicherheit ab, allerdings mit einem anderen architektonischen Zuschnitt als der klassische 3scale API Manager. Im folgenden Abschnitt wird betrachtet, wie diese Lösung in Kubernetes-Umgebungen – einschliesslich OpenShift – zum Einsatz kommt und warum sie cloud-agnostisch ist.

Kubernetes- und OpenShift-Integration ohne Cloud-Lock-in

Red Hat Connectivity Link wurde für den Betrieb in containerisierten Umgebungen entwickelt und ist cloud-agnostisch formuliert – das heisst, es kann auf beliebigen Kubernetes-Plattformen laufen, sei es in der Private Cloud eines Rechenzentrums, in OpenShift-Containerplattformen oder in Public-Cloud-Kubernetes-Services. Entscheidend ist, dass kein spezifischer Cloudanbieter vorausgesetzt wird. Für Schweizer Banken, die oft auf OpenShift als strategische Container-Plattform setzen, ist dies ideal: Connectivity Link fügt sich nahtlos in OpenShift-Cluster ein, beispielsweise über einen Operator, und nutzt die standardisierten Kubernetes-APIs. Dadurch können Banken ihre API-Gateway- und Policy-Infrastruktur in-house betreiben und behalten die volle Datenhoheit – ein wichtiger Punkt in streng regulierten Umgebungen.

Die Konfiguration von Connectivity Link erfolgt deklarativ über Custom Resource Definitions (CRDs) im Kubernetes-Cluster. Beispielsweise kann ein Plattform-Team eine Ingress-Gateway-Instanz definieren (gemäss Gateway API Standard) und dann mittels Policy-Attachments verschiedene Regeln daran knüpfen – von TLS-Zertifikatsmanagement bis Rate Limiting. All dies geschieht innerhalb der Kubernetes-Konfiguration und kann via GitOps verwaltet werden. Es werden keine externen Appliances oder separaten Management-Server benötigt, was den Betrieb über Cloud-Grenzen hinweg vereinfacht. So lassen sich identische Policies in mehreren Clustern ausrollen, ohne an einen bestimmten Cloud-Loadbalancer gebunden zu sein.

Ein weiterer Vorteil ist die Integration mit Service Mesh-Technologien: Connectivity Link unterstützt gängige Mesh-Orchestratoren wie Istio bzw. Red Hat OpenShift Service Mesh. Dadurch können Finanzunternehmen, die bereits Service Mesh zur Microservice-Kommunikation einsetzen, Connectivity Link an deren Ingress-Punkten nutzen. Man profitiert von einer konsistenten Sicherheits- und Traffic-Management-Schicht – vom Edge des Clusters bis tief ins Service Mesh hinein – ohne proprietäre, cloud-spezifische Tools. Mit diesem universellen Ansatz erfüllt Connectivity Link die Anforderungen von Multi-Cloud-Strategien, wie sie in vielen Banken verfolgt werden.

Migration von 3scale zu Connectivity Link: Herausforderungen und Strategien

Der Übergang von einer etablierten Lösung wie 3scale zu einer neuen Kubernetes-nativen Architektur will gut geplant sein – insbesondere im regulierten Finanzumfeld, wo Stabilität, Sicherheit und Compliance oberste Priorität haben. Zu den zentralen Herausforderungen bei einer Migration gehören:

Architekturwechsel:
3scale basierte auf einem zentralisierten API-Manager mit eigener Verwaltungsoberfläche, Benutzerverwaltung und einem API-Gateway (APIcast). Connectivity Link dagegen verteilt Funktionen ins Kubernetes-Cluster (CRDs, Ingress-Controller, Service Mesh). Dieser Paradigmenwechsel erfordert ein Umdenken bei Betriebsprozessen und Zuständigkeiten. APIs werden nicht mehr über das 3scale-Portal konfiguriert, sondern als Code (Infrastructure as Code) im Cluster definiert. Teams müssen sich mit Kubernetes-Ressourcen wie HTTPRoute, Gateway und Policy-CRDs vertraut machen.

Funktionale Abdeckung:
Ein 1:1-Ersatz aller 3scale-Features ist unter Umständen nicht sofort verfügbar. Beispielsweise bot 3scale ein Developer-Portal für externe Konsumenten, Abrechnungsfunktionen und fein granular planbare Nutzungspläne. Connectivity Link konzentriert sich zunächst auf Konnektivität, Sicherheit und Steuerung des Datenverkehrs. Funktionen für API-Design und -Katalogisierung sind zwar angedacht (via Integration von Apicurio in Developer Preview), befinden sich jedoch noch in der Entwicklung. Unternehmen sollten prüfen, welche 3scale-Komponenten sie tatsächlich genutzt haben (z. B. Rate Limits, Authentifizierung, Analytics) und sicherstellen, dass diese mit Connectivity Link oder ergänzenden Tools (wie Apicurio Registry, Keycloak etc.) umgesetzt werden können.

Daten- und Nutzer-Migration:
Falls externe Entwickler oder Anwendungen 3scale nutzen (z. B. API Keys, OAuth-Clients, Verträge), müssen diese in die neue Plattform migriert werden. Da Connectivity Link Policies direkt auf Infrastruktur-Ebene durchsetzt, können existierende API-Schlüssel und Zugriffsregeln in eine neue Form (z. B. Keycloak Identity oder JWT Tokens für Authorino) überführt werden. Dieser Schritt muss sorgfältig geplant werden, um keine laufenden Integrationen zu unterbrechen. In Banken empfiehlt sich oft ein Parallelbetrieb: Neue API-Endpunkte werden bereits über Connectivity Link angeboten, während alte Endpunkte noch auf 3scale laufen. Schrittweise können dann Dienste migriert werden, wobei intensive Tests und User Acceptance Tests sicherstellen, dass die Policy-Parität gewährleistet ist.

Compliance und Testing:
Jede Änderung in einer Bankenumgebung verlangt strenge Tests und Freigaben. Bei der Migration sollte ausreichend Zeit für Security Audits und Performance-Tests eingeplant werden. Ein Vorteil von Connectivity Link ist, dass Regeln wie OAuth/OIDC-Authentifizierung, Verschlüsselungsvorgaben oder Transaktionslimits zentral als Code vorliegen – dies erleichtert Reviews durch Sicherheitsabteilungen. Dennoch müssen Unternehmen nachweisen, dass die neue Lösung mindestens das gleiche Sicherheitsniveau bietet wie bisher. Geeignete Migrationsstrategien können unter anderem ein schrittweises Onboarding von weniger kritischen APIs, ein Fallback-Plan (Re-Routing auf 3scale im Notfall) sowie Schulungen für das Operations-Team im Umgang mit Kubernetes Policies beinhalten.

Strategisch gesehen bietet die Migration die Chance, Altlasten abzubauen und die API-Landschaft auf zukunftsfähige Beine zu stellen. Red Hat Connectivity Link ist mehr als nur ein Ersatz für 3scale – es ist eine Neuausrichtung hin zu Cloud-nativen Prinzipien. Das Upstream-Projekt Kuadrant, auf dem Connectivity Link basiert, wird als „Re-Architecture of API Management using Cloud Native concepts“ beschrieben. Es entkoppelt bisher monolithische API-Management-Komponenten und nutzt stattdessen Kubernetes-Features, Envoy/Istio und CRDs, um flexible und erweiterbare API-Services bereitzustellen. Eine erfolgreiche Migration bedeutet somit, die Organisation für diese neue Denkweise fit zu machen – ein Investment, das sich langfristig in höherer Agilität und besserer Skalierbarkeit bezahlt macht.

Zentrale Funktionen von Red Hat Connectivity Link im Überblick

Einheitliches Policy-Management und Zugangskontrolle
Connectivity Link bietet ein flexibles Policy-Attachment-Modell, bei dem Sicherheits- und Verkehrsrichtlinien direkt an Kubernetes-Gateways oder Routen angehängt werden. So können Authentifizierungs- und Autorisierungs-Policies zentral definiert und durchgesetzt werden – beispielsweise über eine AuthPolicy, die den Zugriff auf bestimmte API-Routen nur mit gültigem OAuth2/JWT Token erlaubt. Dabei kommt eine externe Auth-Komponente zum Einsatz, die gängige Standards wie OIDC und API-Keys unterstützt. Plattform-Teams können globale Default-Policies setzen, während Entwicklungsteams bei Bedarf granularere Regeln für einzelne Services definieren. Durch Role-Based Access Control (RBAC) in Kubernetes wird zudem geregelt, wer welche Policies erstellen oder ändern darf – was in regulierten Umfeldern wichtige Audit-Anforderungen erfüllt.

Granulares Rate Limiting und Quoten
Um Missbrauch oder Überlastung von APIs zu verhindern, bietet Connectivity Link eine granulare Rate-Limiting-Kontrolle. Über RateLimitPolicy-CRDs lassen sich Schwellenwerte für API-Aufrufe definieren, beispielsweise „maximal 100 Requests pro Minute pro Kunde“ oder „10 Requests pro Sekunde global“. Die Limits können auf verschiedenen Ebenen ansetzen – etwa global am Gateway oder spezifisch pro HTTPRoute. Dank der Kubernetes-Integration können mehrere verteilte Instanzen eines API-Dienstes gemeinsam eine globale Quote teilen. Technisch wird dies über Envoys integrierten Rate Limit Service umgesetzt. Ein einfaches YAML-Snippet veranschaulicht, wie eine RateLimitPolicy als Kubernetes-Ressource definiert wird:

In diesem Beispiel wird für die API-Route ein Limit von 100 Anfragen pro Minute festgelegt. Solche Policies sind versionierbar und automatisierbar, was insbesondere in Banken die Nachvollziehbarkeit erhöht – im Gegensatz zu 3scale, wo Rate Limits über ein Admin-Portal konfiguriert wurden.

Zentrale Steuerung über Cluster- und Cloud-Grenzen hinweg
Ein wesentlicher Vorteil von Connectivity Link ist die Möglichkeit, über mehrere Cluster und Clouds hinweg zentral zu steuern. Über ein zentrales Control Plane, realisiert durch den Connectivity Link Operator im Cluster, können Administratoren einheitliche Regeln in allen Kubernetes-Umgebungen durchsetzen. Beispielsweise lässt sich ein unternehmensweiter Sicherheitsheader oder eine Compliance-Policy global definieren und automatisch auf alle Gateways anwenden. Dies vereinfacht die Governance erheblich und minimiert Fehlkonfigurationen. Für Banken, die eine Multi-Cluster-Strategie verfolgen, bedeutet dies konsistente Sicherheitsrichtlinien sowie vereinfachte Audit- und Reporting-Prozesse.

Integrierte TLS-Zertifikatsverwaltung und verschlüsselte Kommunikation
Sichere Kommunikation ist im Finanzsektor obligatorisch. Connectivity Link integriert das TLS-Management direkt ins Gateway. Über Anbindungen an Cert-Manager und ACME können TLS-Zertifikate für Ingress-Endpunkte automatisiert ausgestellt und erneuert werden – etwa mit Let’s Encrypt. So kann ein neues API-Gateway automatisch ein gültiges Zertifikat erhalten, ohne dass manuelles Eingreifen nötig ist. Zudem werden mTLS (mutual TLS) und Service Mesh-Integrationen unterstützt, um eine Ende-zu-Ende-Verschlüsselung zwischen Verbraucher und Backend-Service sicherzustellen. Dies vereinfacht das Zertifikatsmanagement erheblich.

Observability und Monitoring für APIs
Ein oft unterschätzter Aspekt ist die Observability – also die Überwachbarkeit und Sichtbarkeit der API-Nutzung. Connectivity Link liefert umfassende Metriken und vorkonfigurierte Dashboards, die je nach Rolle (Plattform-Ingenieure, Entwickler, Fachbereiche) zugeschnitten sind. Plattform-Ingenieure erhalten Einblicke in Compliance, Gateway-Auslastung, Fehlerraten und Latenzen, während Entwickler vor allem dienstespezifische Kennzahlen wie Response-Zeiten verfolgen. Dank der tiefen Kubernetes-Integration fliessen viele dieser Metriken automatisch in bekannte Tools wie Prometheus und Grafana ein. Ergänzt werden die Dashboards durch Logs und Traces – etwa via OpenTelemetry Integration – was insbesondere für 24/7-Monitoring, Incident Response und Reporting in stark regulierten Umfeldern entscheidend ist.

Fazit: Zukunftssichere API-Konnektivität für Banken

Mit Red Hat Connectivity Link vollzieht sich ein Innovationssprung im Bereich der API-Konnektivität. Für Banken und andere regulierte Unternehmen bietet die Lösung die Möglichkeit, ihre API-Infrastruktur in die Kubernetes-Welt zu überführen – mit all den Vorteilen standardisierter, deklarativer Verwaltung und Multi-Cloud-Fähigkeit. Das End-of-Life von 3scale mag zunächst als Herausforderung erscheinen, erweist sich aber als Chance, auf eine modernere Architektur umzusteigen, die besser zu Cloud-Strategien und DevOps-Praktiken von heute passt. Kubernetes-natives API-Management bedeutet weniger Silos, mehr Automatisierung und eine engere Verzahnung von Security und Netzwerkkontrolle direkt in der Plattform.

Gerade im Finanzsektor, wo Stabilität und Compliance zwingend sind, punktet Connectivity Link durch zentrale Richtliniendurchsetzung, hohe Ausfallsicherheit über Cluster hinweg und erweiterte Sicherheitsfunktionen. Wichtig ist, den Übergang sorgfältig zu managen – mit gezielten Migrationstools, ausreichenden Tests und gegebenenfalls Unterstützung durch erfahrene Red Hat Partner. Die Open-Source-Basis des Kuadrant-Projekts sowie die offene Dokumentation ermöglichen es, früh Know-how aufzubauen und die Lösung bei Bedarf an eigene Bedürfnisse anzupassen.

Schlussendlich ist Red Hat Connectivity Link ein Beispiel dafür, wie Innovationsdruck (Cloud, Microservices, DevOps) und konkrete Produktentscheidungen (3scale-Abkündigung) zusammenwirken, um neue Wege zu beschreiten. Für Banken heisst das: Diese Entwicklung proaktiv anzugehen. Eine gut geplante Migration und Adoption von Connectivity Link wird die API-Landschaft für die kommenden Jahre rüsten – flexibel, sicher und bereit für Multi-Cloud.

Referenzen

Red Hat Developer & Produktdokumentation

Kuadrant.io

Red Hat Pressemitteilungen (Jan. 2025)

The Register (Mai 2024)

Eigene Projekterfahrungen

Red Hat Releases Kubernetes-Native Connectivity… » ADMIN Magazine

Red Hat Introduces Red Hat Connectivity Link, A Unified Solution that Simplifies and Enhances Application Connectivity – Database Trends and Application