What's New in WSO2 API Manager 3.2.0?

WSO2 API Manager 3.2.0 the third release of the API Manager 3.x series, simplifies integrating with other ecosystems while reducing complexity of large scale deployments.

By simplifying integration with other IAM solutions, version 3.2.0 allows itself fit into existing deployments without major changes. And with the help of reduced dependencies on KeyManager, File-less artifact deployment and support for Publisher initiated Microgateway deployments, rough edges with large scales deployments have been ironed out and usability and manageability has been improved to a great extent.

Due to the simplicity and extensibility offered, I thought of discussing those among  all other features.

3.2.0 makes integrating with different IAM solutions seamless. This is useful when the organisation’s Identity and Access Management is centrally handled through a single IAM solution.  In such a scenario Consumers and Consumer Applications are centrally managed and the organisation prefers issuing and managing tokens centrally.

In these situations, the ability to extend Key Manager support becomes quite handy, which allows using an Organisation's IAM solution to work with the API Manager. In a standard deployment it’s through the Key Manager profile OAuth Consumer Applications are created and tokens are obtained from. While the token passes through Gateway, Key Manager is called to validate the key. Now with the ability to extend Key Manager support, different IAM solutions like Okta, KeyCloak, Auth0, PingIdentity,etc.. can be used in place of the default Key Manager.

This support is not entirely new since some of these changes were first introduced as early as in APIM 1.9.0. But in those versions integrating a different Key Manager was only possible through a custom implementation. Moreover, only a single Key Manager was allowed for the entire APIM distribution. The latest release addresses these limitations by allowing to 

One challenge present in the previous releases was Application Creation UI in Developer Portal remaining static regardless of the Key Manager used. This would hide different options provided by the connected IAM solution and would force to mold certain options into existing UI elements. The new release solves this by rendering the Application Creation UI with the attributes provided by the IAM connected. 

Now using the New Key Manager Configuration UI, you can simply connect with Okta (or with other supported IAMs) by populating different fields (or by using the well known configuration url).

For more information you can refer this document.

The new release gives the ability to deploy a Microgateway through the Publisher UI. Previously this was only possible through API Controller.

When deployed through Publisher UI, a Microgateway gets spawned up exclusively for a microservice and is deployed between the ingress controller and the microservice. With this, external traffic first hits the Microgateway, making it the sole controller of the traffic bound to the microservice. With this approach running a microservice can be secured without making changes to the microservice or to the pod it's running.

Prior to 3.2.0, Microgateway can be deployed using API Controller (known as apictl - a command line tool for creating APIs) by providing the API definition through a swagger file. The steps included creating a Microgateway with the API, building a docker image and deploying it on K8. (These steps were simplified by the K8 operator which allowed deploying a Microgateway through a single command).

These steps would spawn up a Gateway with the API on K8, but in order to make the API discoverable, the same API was needed to be pushed to the Publisher portal through the apictl. While this process favored developers, helping them use a command line tool to quickly deploy a Gateway, disrupted the normal user experience of Authoring and Publishing the API.

The new feature simply fills that missing gap. With the new feature, API Product Managers, and other non-technical users, can deploy Microgateways without using a tech-focused command-line tool.

To make this work, first the K8 cluster to which Microgateway gets deployed should be configured.

As a part of the configuration you’d have to configure the K8 cluster to which the Microgateways should be deployed. Once this is done the cluster would appear on the Publisher portal, and after creating and publishing the API, a Microgateway gets spawned in the selected cluster and the same API would appear on the Store.

More information on Private Jet mode is available here.

Another major feature supported in this release is deploying APIs across a cluster without using file syncing approaches (like Rsync or Network Attached Storages). 

If you have done distributed deployments that have multiple Gateway nodes, you might have gone through the trouble of configuring Rsync or a file-share. Why this is needed is because, Gateway reads the API definitions as a set of files, so these files needs to be present in each Gateway.

These definitions get generated at the Publisher while Publishing the API. And in pre 3.2.0 deployments, Publisher would push these to a read-write Gateway node (which in pre-2.6.0 deployments was called Gateway manager) which writes the files to a file-share, letting other nodes to read from.

While these methods work, they are seldom configured right, which often causes problems while scaling across many nodes or multiple data centers. For example, if the file-sharing mechanism isn't configured in a fault-tolerant manner, then if the file-share goes unavailable, APIs get un-deployed from the Gateway.

With the latest release, the syncing mechanism has been built into the API Manager. Now once the API definition is generated, it’ll get persisted to a database and an event will be fired to Gateways notifying about the status change. Upon receiving this, each Gateway would pull the changes from a central repository and deploy locally. Pulled definitions will be kept in-memory. Nothing gets written to a file.

Another capability provided by this new feature is the support to deploy an API across a group of Gateways using Gateway Labels. A label can be assigned to a Gateway while starting up, and to an API while publishing. APIs with a particular Label will get deployed in Gateways started with that Label. For example, if you provided External as a Gateway label while starting up the Gateway, then only the APIs Labeled as External will get deployed there. This feature allows maintaining hierarchical groups and deploying APIs only to the specific groups needed. 

Refer this document for more details.

The biggest obstacle in scaling a Gateway cluster is scaling the Key Manager cluster proportionally. By making Gateways self-reliant the need of scaling Key Manager nodes has been greatly reduced which simplifies auto-scaling and brings down the node count. This also makes the Gateways much more resilient since interaction between different components while serving API traffic is now reduced.

To understand how the new change makes an improvement, we need to look a bit  into the Key Validation process. As part of the key validation, Gateway would call the Key Manager, so as new tokens are used, equal amount of traffic received by the Gateway would land on the Key Manager. So to withstand the traffic, a proportionally scaled Key Manager cluster is needed.

In the new release, reliance over Key Manager has been reduced by loading Application, API and Subscription Information on the Gateway. As the Gateways starts up, all information related to Key Validation will be fetched into the Gateways and the subsequent changes would be pulled by listening to update events. With this change, the validation calls which were sent over the network, will now be made against an in-memory store - which simply breaks the dependency over Key Manager nodes during validation, and enables scaling Gateway cluster independently. 

Improved stability is another advantage offered by this new architecture. With the dependency previously present, the Key Manager becomes a critical component and is needed when validating API calls. If the Key Manager fails, API traffic would fail making a negative impact on the business. With the reduced dependency on the KeyManager, its availability isn’t going to have much of an impact. 

API Manager 3.2.0 focuses on simplifying large scale deployments and making them more robust. By building in a mechanism to propagate APIs, 3.2.0 simplifies API deployment across clusters that would span across multiple data centers.

With the reduced reliance on key manager profile, network calls are reduced to a greater extent lowering the possibilities for Gateways to fail. Supporting Microgateway deployments through Publisher UI removes a major obstacle in adopting Microgateways and hides the complexity of spawning up Pods in a K8 cluster.

This will probably pave a path to explore K8 for hosting APIs. Last but not least, the support for third party IAM solutions, would help deploying WSO2 API Manager with an existing consumer base, making it a smooth fit for many existing ecosystems. 

You can give these a try by downloading API Manager through the official page or by contacting WSO2.