With enterprises adopting the API-first approach as part of their digital journey, APIs have taken center stage of every organizational initiative and have become an integral part of their growth strategies. API gateways are a key ingredient in any API program, and have matured in recent years, be it in terms of features or their role in enterprise deployment architecture.

Today’s enterprise applications are spread across multiple customer data centers – on-premise and on multiple cloud environments. Applications are owned and governed by different business units. So, the traditional approach for deploying API Gateways (which was to have a centralized monolithic gateway to front-end enterprise applications) is now becoming obsolete for such architecture and business necessities.

To handle such use cases, a lightweight gateway which is also called as a Microgateway is the best choice instead of a centralized (monolith) gateway in each DC/cloud. Microgateway is a message processor, which works along with the centralized API Gateway. Microgateway is easy to install; an instance can be made up and you can get it up and running within minutes. It has a light footprint and enables decentralized deployments architecture, provides enterprise-grade security, and scalability on a need basis. During runtime, APIs are pulled from the centralized gateway and are executed on Microgateway, while data for management purposes is pushed to the centralized gateway.

One of the key scenarios where the value of Microgateway can be realized is to securely manage APIs in a distributed environment where enterprise is spread across multiple data centers or cloud environments. The recommended approach here is to follow Hub and Spoke Cluster pattern. In this pattern, microgateway clusters are deployed in various datacenters to front-end the business applications. These clusters are always in sync with the centralized gateway, which may be hosted in the same or different datacenters or in the API vendor’s cloud.

Another scenario is to keep API traffic within the enterprise-approved boundaries by eliminating the need for APIs to route through a central gateway, while at the same time ensuring federated governance for backend apps. We have two ways to address this problem. First and the most popular way is to use the Private Jet pattern, where each individual application will have a dedicated microgateway deployed on a separate machine to front-end the API traffic. This pattern is used when maximum security and horizontal scaling per application are the top priorities. The second way is the Side car Proxy pattern where a Microgateway is deployed alongside a parent application on the same machine. This is specifically useful when we need fine-grained control over machine resources and would like to limit for a particular resource.

Microgateways are powerful and have a crucial role to play in any API program with regards to managing security and governance while saving that extra license cost. Do you think enterprises are ready for this paradigm shift?