The IBM Cloud API Gateway service is deprecated and will be shut off on 31 August 2022. Here are the migration options you have as a Functions user.

Previously, IBM Cloud Functions and IBM Cloud Foundry users have been able to take advantage of the IBM Cloud API Gateway service for traffic limiting, splitting and authentication. Unfortunately, the API Gateway service is deprecated and will be shut off on 31 August 2022. Existing API Gateway endpoints will no longer route to their respective Cloud Function actions or Cloud Foundry apps come September 1, 2022. This means that any workload invoking Functions actions via API Gateway endpoints needs to be modified.

All API Gateway endpoints are associated with a secured web action. The require-whisk-auth annotation is set to a random string and this string must be passed in the header of the action invocation for authentication to succeed. You can inspect your actions in the ibmcloud command line to see what the unique key value is for each action:

~ $ ibmcloud functions action get hello2
ok: got action hello2
{
    "namespace": "e6928f1d-8b5d-xxxx-9xxx-4cd0ca7b8c31",
    "name": "hello2",
    "version": "0.0.1",
    "exec": {
        "kind": "python:3.9",
        "binary": false
    },
    "annotations": [
        {
            "key": "exec",
            "value": "python:3.9"
        },
        {
            "key": "web-export",
            "value": true
        },
        {
            "key": "final",
            "value": true
        },
        {
            "key": "require-whisk-auth",
            "value": "d56ba43b-xxxx-xxxx-f2f241b5d71b"
        }
    ],
    "limits": {
        "timeout": 60000,
        "memory": 256,
        "logs": 10,
        "concurrency": 1
    },
    "publish": false,
    "updated": 1651699400594
}

No matter what solution you migrate to from API Gateway, you will likely need to pass this key in the HTTP header when you invoke the web action, so it is best you make a table of your API endpoints, web actions and authentication key. For example, the above would pass d56ba43b-xxxx-xxxx-f2f241b5d71b in the header for the X-Require-Whisk-Auth parameter value.

Here are some recommended options for migrating your API Gateway endpoints

Do not replace API Gateway

Note that this isn’t the same as “do nothing.” You must migrate away from API Gateway; the service is being shut down. But you don’t need to replace it with another API gateway, necessarily. You could decide to just invoke the Functions web actions directly. Depending on how you were using API Gateway —e.g., for rate limiting, OAuth, etc. — you might need to make a change or two in your action itself. But if your usage was light, you can just invoke the action directly, passing in the whisk-auth secret in the HTTP header.

API Connect Reserved

The recommended migration path from IBM Cloud API Gateway is to a reserved instance of API Connect. The IBM® API Connect Reserved Instance offers a dedicated API Connect instance that runs on IBM-managed infrastructure. Reserved Instance provides value by balancing the flexibility of a shared infrastructure with the isolation of an API Connect Reserved Instance. It is a single-tenant deployment that is based on the topology and functionality of the API Connect service on IBM Cloud Public.

Once you have your own instance of API Connect, you can export the API Gateway definitions, modify them and then import the new definitions to your API Connect Reserved instance. The API Gateway Migration Guide covers how to set up an API Connect Reserved instance and import your existing API definitions into it. The Migrating Cloud Functions APIs provides specific instructions on exporting and modifying your Cloud Functions API Gateway endpoints.

API Management within IBM Cloud Pak for Integration

IBM Cloud Pak for Integration® is a hybrid integration platform with an automated, closed-loop approach that supports multiple styles of integration within a single, unified experience. Unlock business data and assets as APIs, connect cloud and on-premises applications, reliably move data with enterprise messaging, deliver real-time event interactions, transfer data across any cloud and deploy and scale with cloud-native architecture and shared foundational services — all with end-to-end enterprise-grade security and encryption.

To install Cloud Pak for Integration, you would first provision a Red Hat OpenShift cluster in IBM Cloud and follow the installation guide for Cloud Pak for Integration.

API Gateway endpoints can be migrated to API Management within IBM Cloud Pak for Integration using the same export-clean up-import workflow outlined above for migrating to API Connect Reserved.

Kong

Kong bills itself as “The world’s most popular API gateway. Built for hybrid and multicloud, optimized for microservices and distributed architectures.” While we can’t verify that statement, we can say that Kong is a very popular open-source API gateway solution built on NGINX and Lua that supports a large ecosystem of partners and plugins. Kong can be installed as a Docker container image or natively on virtual machines or Kubernetes clusters, such as Red Hat OpenShift.

While you can install Kong as a Docker container image or on a single virtual machine, production installations should use an HA architecture like you would get with deploying the IBM Cloud Kubernetes Service or our managed OpenShift service.

The open-source version of Kong does not have an out-of-the-box way to import OpenAPI (“swagger”) specifications. Thankfully, there are a number of open-source packages that address this need, such as openapi-2-kong and the Swagger to Kong container image.

KrakenD

KrakenD is an “ultra-performant open-source Gateway that can transform, aggregate or remove data from multiple services, with linear scalability.” KrakenD goes beyond typical proxy and API gateway solutions that mainly (just) forwards clients to backend services. KrakenD implements a rich middleware plugin architecture as well and common cloud-native patterns like backend for frontend and micro-frontend. This minimizes the number of REST backends a client needs to integrate with and simplifies overall architecture.

KrakenD Enterprise supports import and export of OpenAPI specifications, but the base open-source project does not. API Gateway users will have to manually enter their API specifications into the KrakenD UI or CLI unless they have an enterprise license for KrakenD.

KrakenD is available as a Docker container image, can run native on virtual machines or can be deployed in a Kubernetes cluster. As with our advice using Kong, production installations of KrakenD should use an HA architecture like you would get with deploying the IBM Cloud Kubernetes Service or our managed OpenShift service.

Next steps

IBM Cloud Functions actions can benefit from API management. An API gateway can act as a proxy to web actions and provides them with additional features, including HTTP method routing, client id/secrets, rate limiting and CORS. Unfortunately, with the deprecation of IBM Cloud API Gateway you must modify any workload using API Gateway endpoints.

IBM’s recommendation is to use an IBM® API Connect Reserved Instance, but you do have other open-source and commercial options as outlined in this article.

Click here for more information on how to migrate your IBM Cloud API Gateway endpoints.