Migration path from Red Hat 3scale API Management to Red Hat Connectivity Link

Initial situation

Red Hat 3scale API Management is at the end of its product lifecycle. Since May 2023, it has only been maintained without any new features being implemented. Companies, especially in the highly regulated banking environment, are therefore faced with the challenge of migrating their fully utilized 3scale platform – including API gateway, traffic management, authentication, traffic analysis, etc. – to a future-proof solution. With Connectivity Link, Red Hat offers a modern, Kubernetes-native alternative for API connectivity in hybrid cloud architectures.

The following aspects are considered in this report:

• Architectural differences
• Migration strategy in phases
• Function comparison (which features can be migrated directly, where is there a need for adaptation)
• Risks and recommendations for preparing for migration

The goal is a secure and seamless migration without loss of API governance in an environment that includes cloud, on-premises and container platforms (e.g. OpenShift).

1. Architecture comparison: Red Hat 3scale vs. Red Hat Connectivity Link

Red Hat 3scale API Management

• Classic architecture:
  3scale is based on a central API management architecture. A 3scale instance consists of:
  • Central API Manager: With admin portal, user administration with SSO, developer portal and database.
  • API gateway instances (APIcast): An NGINX-based service that enforces policies and communicates with the backend.
• Separation of policy configuration and execution:
  Configuration takes place via the 3scale portal (or the 3scale API) and is distributed asynchronously to the gateways.
• Management interface for API providers:
  There is a graphical admin portal and a developer portal that centrally controls API keys, access, and usage ratings.
  Source: Chapter 1. APIcast Overview | Red Hat Product Documentation

Red Hat Connectivity Link

• Kubernetes-native approach:
  Connectivity Link transfers the functions directly to the Kubernetes cluster. It is controlled via the Kubernetes Gateway API standard and the Envoy proxy.
• Infrastructure-as-Code:
  APIs and guidelines are defined as code (via YAML/CRDs). Important Custom Resource Definitions (CRDs) are e.g:
  • AuthPolicy
  • RateLimitPolicy
  • TLSPolicy
  • DNSPolicy
• Integrated data layer:
  One or more ingress gateways in the cluster (often through Envoy, integrated with OpenShift Service Mesh/Istio) enforce the rules.
  
• Decentralized management:
  APIs are managed via YAML/CRDs, which enables consistent control via Kubernetes. At the same time, Kubernetes-RBAC is used to secure access.

Conclusion

• 3scale: Centralized with external management component, separate gateway and graphical operation.
• Connectivity Link: Decentralized through Envoy Cluster setup and cloud-native, with API management as code in the cluster.
  This means a paradigm shift in operations and responsibilities. Teams need to familiarize themselves with Kubernetes resources such as gateway, HTTP route and the specific policy CRDs.

Migration strategy and recommended steps

The migration should be carried out in carefully considered phases in order to avoid business interruptions and compliance problems in the banking environment.

Step 1: Analysis and planning phase

• Inventory:
  Identify all existing APIs and the 3scale components used (e.g. API key management, OAuth, rate limits).
• Mapping:
  For each feature, you must specify whether it is to be migrated directly to Connectivity Link or replaced by a supplementary tool.
• Creation of a migration roadmap:
  Determine which APIs are to be migrated when and what preparatory work is required.

Step 2: Preparing the target environment

• Installation and configuration:
  Red Hat Connectivity Link is installed in the Kubernetes/OpenShift environment – ideally initially in a staging environment via the official operator.
• Set up integrations:
  • Identity provider: Connection of Keycloak/Red Hat SSO for OAuth2/JWT tokens.
  • DNS and TLS: Setting up the DNS policy and TLS policy CRDs.
  • Monitoring: Deployment of Prometheus/Grafana and import of dashboard templates.
  • Pilot service: Define the first API as an example in Connectivity Link to validate functionality.
• Training:
  The operations team is trained in the use of Kubernetes-based API management (e.g. definition of gateway resources and policies).

Step 3: Parallel operation and step-by-step onboarding

• Parallel operation:
  Start parallel operation of both platforms so that new or less critical APIs are provided directly on Connectivity Link, while critical services remain on 3scale for the time being.
• Traffic control:
  Both gateways (3scale APIcast and Connectivity Link Gateway) run in parallel and the traffic is distributed by DNS or routing decision.

Step 4: Iterative migration of the existing APIs

• Gradual migration:
  Once the first services have been successfully onboarded, all API endpoints are gradually migrated to Connectivity Link – based on criticality or domains.
• Testing:
  An intensive test is carried out before each switchover (e.g. policy parity, route and backend integrations).
  A fallback plan (e.g. DNS rollback) must be available.

Step 5: Comprehensive testing & compliance checks

• Tests:
  Execution of security tests, load and performance tests and failover scenarios.
• Compliance:
  Involvement of security and compliance teams to review the policy-as-code definitions.

Step 6: Productive cut-over and shutdown of 3scale

• Cut-over:
  Planning of a maintenance window for the final switching point, in which the remaining traffic is redirected.
• Shutdown:
  After final verification, the 3scale installation will be decommissioned. The old database should remain in read-only mode so that historical data can be retrieved.

Step 7: Follow-up

• Post-mortem analysis:
  Documentation of experiences, problems and solutions.
• Optimization:
  Check whether further Connectivity Link functions (e.g. multi-cluster load balancing, geo-routing, extended observability) can be used.

Functions: Direct migration vs. new implementation

Not all functions of Red Hat 3scale can be transferred one-to-one to Connectivity Link:

• Directly migratable:
  Core functions of the API gateway layer (traffic control, authentication/authorization rules, rate limiting) can be mapped using corresponding CRDs in Connectivity Link.
  For example, an OAuth2 policy can be implemented using a combination of Kubernetes AuthPolicy and a connected identity provider (e.g. Keycloak).
• New to be implemented:
  Additional functions such as the developer portal, API cataloging or billing logic are currently missing and must either be replaced by third-party solutions or in-house developments.

The following table compares key functions:

Evaluation:
Authentication/authorization rules and traffic controls can largely be migrated directly. However, additional functional services such as the developer portal and the billing logic must either be replaced by third-party solutions or redeveloped internally.

Potential dangers and risks of migration

When migrating in a critical environment such as the financial sector, various risks must be actively managed:

• Downtime:
  Possible outages during or after the changeover due to configuration errors or delays in DNS switchovers.
  Mitigation: Parallel operation and a tested fallback plan (traffic switchback) minimize this risk.
• Authentication/authorization breaches:
  Incorrect migration of API keys, tokens or user accounts could block legitimate access or open security gaps.
  Mitigation: Seamless transfer of all access keys and rules as well as detailed tests before shutting down 3scale.
• Loss of API governance/visibility:
  The change can temporarily lead to a loss of central control and compliance functions.
  Mitigation: Early implementation of a concept for customer/consumer management (e.g. with Keycloak) and reporting via Kubernetes monitoring.
• Performance and scaling problems:
  Unexpected performance differences or latencies due to incorrect configuration of the new gateway.
  Mitigation: Load tests, A/B tests and targeted tuning of Envoy in close coordination with Red Hat.
• Complexity and know-how risk:
  The introduction of new technologies involves a learning curve, which can provoke errors at the beginning.
  Mitigation: Comprehensive training and – if necessary – workshops with Red Hat or experienced partners.
• Immature or unknown bugs in the new product:
  As Connectivity Link was not launched until 2024 (GA from the end of 2024), bugs or missing features may still occur in practice.
  Mitigation: Close cooperation with Red Hat and use of pilot projects for validation.
• Time and resource risk:
  Migration projects of this size can entail unforeseen expenses.
  Mitigation: Realistic project planning with sufficient buffers and gradual value-added deliveries to avoid the pressure of staying with 3scale.

Overall, many risks can be mitigated through careful preparation, comprehensive testing and parallel operation. A structured migration strategy and a transparent communication flow with management are essential.

To summarize:
Use ONLU’s expertise to address open issues and set the course for a successful migration together – so that your company has a flexible, secure and cloud-capable API management landscape in the long term.

Sources

• Red Hat Connectivity Link – Innovation and End of Life from 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 correct?