IBM Support

API Connect Upgrade Central: Getting Started

News


Abstract

Customers are excited to upgrade to take advantage of the latest innovations in API Lifecycle Management. These pages are dedicated to making it easy for you to learn and plan your move to API Connect v10.


In order to move between major releases of software, one must: Learn about the new destination, create a plan, and execute your plan. Similar to physical moves, no two moves are the same, distance may vary as does complexity based on your intended goals. For instance, moving from an on-premise single data center deployment to a hybrid topology including cloud infrastructure will create a set of unique requirements.


Before starting your upgrade, you first need to understand which paths, approaches, and tools are required for your specific starting version. You will find general getting started materials below and specific pages for: v5, v2018, v10 currency, and migrating to IBM Cloud Pak for Integration.

Content

Moving between major versions of software requires the following steps:
Getting Starting four step process
Learn about migration and upgrade:
What is migration?  Migration is about "Movement".  It's defined as “The process of moving the product, data and or infrastructure from one platform or system to another." 
There are different types of migrations (As defined in IBM's migration waiver)
  1. Version migration
  2. Data center migration
  3. System replacement migration
  4. Trade-up migration (i.e. from IBM API Connect to IBM Cloud Pak for Integration) 
  5. Program evolution or program replacement
These pages will primarily focus on the first type, "version migration".
Definitions:
Version migration is a 2-step process where you install a new version of software and then move/load data from a previous version.   
This differs from Upgrade which is the act of applying software updates in-place, on its existing infrastructure.  Upgrades may first require system prerequisites to be updated.
Some moves to v10 are completed by performing a version migration.  Other moves are completed by performing an upgrade.  This will be explained on associated tabbed pages.
Learn about the destination:  v10
IBM API Connect v10 is a scalable multi-cloud API Management solution.  It is an award-winning, modern and intuitive platform to create, secure, manage and socialize APIs across clouds to power digital applications.  v10 can independently scale API Connect subsystems improving resiliency while managing cost by leveraging a cloud-native architecture and container orchestration.  
You can deploy API Connect virtually anywhere using the different deployment form factors supported.  Resources are provided below that help you learn about v10 and how it compares to v5. Without going into all the details, here are two notable differences important to planning your move to v10.  
  • Deployment flexibility:  Compared to v5, which was only available on-premise on VMware with OVAs, v10 can be deployed in many clouds and in hybrid deployments across clouds and on-premise.  This provides more flexibility to leverage the benefits of cloud and place API Gateways close to your backend applications and systems, whether they are on-premise or across multiple clouds.    
  • Lifecycle operations:  A key change in v10 is how it is operated.  APICUP continues to be provided for VMware OVA deployments, which abstracts some of the complexities of Kubernetes operations.  For deployment on OpenShift and other Kubernetes platforms, Kubernetes Operators are provided.  Use of K8s Operators and applying Custom Resources (CRs) is widely adopted as the standard for operating enterprise software compared to Helm used in v2018.  You will be introduced to these concepts during v10 installation or when upgrading from v2018. 
Learning Resources:
Why choose v10?  v10 is the latest version of API Connect, which delivers significant value for v5 and v2018 customers.  Additionally, v10 is the only version new innovations are being delivered.  As the latest version, v10 will provide support for a longer time compared to previous versions which have announced end of support dates.  See API Connect Lifecycle Policy.
What deployment form factors are available?
What gateway services are available when moving to v10?
The v5 gateway was replaced with a choice of two different gateway services for customers moving from v5.  Considerations for choosing are included below.
  1. v5c API Gateway Service - Choose when ease of migration & compatibility of existing APIs is most important.
  2. v10 native API Gateway Service (which includes an emulation mode) - Choose when performance is most important & development changes to the API assemblies can be performed by your API developers.
When migrating from v5, see the gateway considerations section below to help choose a gateway service.
For customers on v2018, you would have already selected a gateway service and you will be upgraded to the same choice when moving to v10.  
Decide:
You have a set of decisions to make when deploying v10.  This includes the following, which  are some key items that will help in your planning process. 
Decision points:
  • Location:  On-premise, cloud deployment, or a hybrid deployment
  • Deployment form factor: VMware OVAs, OpenShift Container Platform, or other Kubernetes platforms (see below)
  • Topology: Based on your availability requirements and assess licenses required for chosen topology (see below)
  • Gateway service: native API Gateway Service or v5c Gateway Service (see below)
  • Licensing: Consider upgrading to different product offerings with increased value or different cost models such as OpEx (see below)
  • Timeframe: Which may generate the need for a migration waiver: See details on the resources page
  • Migrate yourself or leverage services: Services augment skills for migration planning and execution, see details on the resource page
Considerations when choosing a deployment form factor:
VMware OVAs: Choose if you do not have OpenShift or other Kubernetes platforms and have no plans to deploy a Kubernetes platform.
  • Operate your API management solution without strong Kubernetes expertise.  Provides continuity in skills required and familiarity with VMware for operation teams.
  • Since each virtual appliance runs an embedded Kubernetes instance, this choice consumes a portion of resource capacity (and associated license entitlement) to run the container orchestration.  This topology can provide strong levels of availability but is not as flexible as stand-alone Kubernetes deployments for dynamic scaling of the system.  
OpenShift Container Platform: Choose when you have selected OpenShift or require an enterprise-ready fully supported Kubernetes platform.
  • Red Hat OpenShift is a market leading hybrid cloud platform that fulfills these requirements.
  • Available for on-premise deploy and managed OpenShift Services on public clouds.
  • When upgrading to IBM Cloud Pak for Integration, you receive entitlement to deploy Integration capabilities on OpenShift including API Management.
Other Kubernetes Platforms:  Choose when you have already selected a different Kubernetes platform or a public cloud Kubernetes service such as: IKS, AKS, EKS, GKE. 
  • Can be deployed on a certified Kubernetes platform (from the CNCF foundation) on a version of K8s that meets the system requirements as defined in the IBM Software Compatibility Reports.  Options commonly chosen by customers are:  on-premise with BYO K8s, public cloud K8s services and deploying K8s on public cloud infrastructure.
SaaS:  Choose when you prefer IBM to manage the lifecycle of your API Management Solution and the infrastructure it runs on.
Note:
Gateway deployment form factors:  The included gateway entitlement in your API Connect license can be deployed independently from the deployment chosen for the other components.  An example would be deploying API Connect components on OpenShift but deploying your gateways in a DMZ using virtual appliances.  Alternatively, you can leverage a separately licensed DataPower instance(s), physical appliances, virtual appliances or container-based, as part of an API Management topology.
You may choose among several topologies in order to best align to the business and/or IT goals for your API Management instance.   A primary aspect to consider when choosing your topology is the business availability requirements or the toleration of potential downtime.  Another aspect is where your applications (downstream systems) will reside in relation to the API Gateway Services:
  • Are downstream systems behind your firewall?
  • Are they deployed on a public cloud, multiple clouds?
  • Do you need your API Gateway Services close to your applications?
Please note that choices in your v10 topology may affect compute requirements, and licensed entitlement, especially when considering multiple data centers, regions, geographies, or hybrid multicloud topologies.
Gateway considerations:

Selecting v5c API Gateway Service provides the ability to run v5 assemblies with no modification required, simplifying migration. Use v5c when ease of migration and compatibility of existing APIs is most important.  You can expect a ~5-15% performance improvement over the gateway in API Connect v5.  

v10 native API Gateway Service  is also available, which is higher performing and optimized for API workloads. Development is required to change API assemblies of existing APIs and to use new capabilities. An emulation mode is available along with a porting function in the migration utility.  Together these help reduce development cost of migrating to this new gateway service.  Select the native API gateway to future proof and benefit from a significant ~5-10X performance improvement. 

Licensing Considerations:
IBM API Connect has flexible licensing options that include both processor-based and consumption based (API calls) models.  Consider the following data points when upgrading/migrating.
  • Customers with IBM API Connect Enterprise Edition licensed under a compute-based model (i.e. PVU / processor value units), may simply move forward to a newer version using their existing licensed entitlements.
  • If you are consuming (or plan to consume) multiple styles of integration (API integration, App Integration, Messaging, Events) you may want to consider upgrading from IBM API Connect Enterprise PVU licenses to a multi-style integration platform,  IBM Cloud Pak for Integration.  This provides a single license with deployment flexibility across multiple integration capabilities.
  • Customers seeking to move to consumption-based licensing (in place of existing compute capacity licenses) can upgrade from their PVU licenses to a Subscription based on API Call volumes. This can simplify planning for growth based on business metrics like API consumption. This approach may also be more cost effective for some highly available topologies, hybrid and multi-cloud deployments.
Plan and Act:  
  • See the unique pages per version for information, resources and tools to plan and execute your move.  
Engage with IBM:
  • Join, learn, and engage in the API Connect User Community. With over 1900 members, you can hold discussion threads, find articles, and attend webinars
  • Open a Support Case if needed with IBM API Connect Support
  • IBM experts are ready to help you plan and migrate your API Connect systems to the latest IBM API Connect version. Contact IBM Expert Labs (labs@us.ibm.com) to request details on upgrade offerings to guide you in automating your API environment. 

[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSMNED","label":"IBM API Connect"},"ARM Category":[{"code":"a8m50000000L0rvAAC","label":"API Connect"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]

Document Information

Modified date:
08 March 2023

UID

ibm16439537