Some buzzwords have a rather straightforward meaning, whereas others seem to be discussed for years, over and over again. Guess what I’m thinking of … correct, Microservices. As we tap into similar waters with the Microgateway in this post, getting behind the buzz is an exciting journey — let me guide you through it.
(Note: This is a neutral & vendor-agnostic article)
The API Management Market
API Management solutions have evolved in the past years, growing from a pure gateway and security focus to a platform incorporating an API’s full lifecycle — from API creation over publishing to consumption & developer enrolment. New players, especially from the open-source space, joined the market with a compelling low-cost offering for certain API Management areas. As an example, there now is the Tyk API Gateway or Gravitee.io API Platform waiting in the wings of the established APIM solutions from Apigee/Google Cloud, Axway, CA Technologies, MuleSoft, Tibco, WSO2 and others. The fact that there are 30+ solutions for API Documentation is yet another proof of the market’s diversity.
Gartner did evaluate this competing market in its Magic Quadrant stressing out the importance of Full Lifecycle API Management. However, this was October 2016 and we haven’t seen any recent API Management reports since — neither from Gartner nor KuppingerCole, Forrester or Ovum. Nevertheless, you can trace down APIM trends for the upcoming year with a bit of research across IT magazines, blog posts and latest APIM product releases. Some major trends I’ve found were (1) the emerging integration of an API Management platform into the DevOps toolchain , (2) its growing capabilities for secure mobile app development and (3) the expansion into microservices architectures and IPaaS platforms.
Narowing down the focus to the last point, a significant component for managing a microservices architecture from the perspective of API Management is the so-called Microgateway, recognised by Gartner’s Hype Cycle, marked “At the Peak” in 2017 and introduced into multiple API Management offerings the same year.
At first glance, you might think it’s a gateway tailored for microservices with similar capabilities across the board. However, looking at the different Microgateway solutions, you’ll notice that their purpose and the vendors’ value propositions differ significantly from each other. The following chapter lists and compares the available Microgateway offerings and clarifies its purpose within the vendor-specific APIM portfolio.
To shed light on the Microgateway and spot what’s behind this buzzword, we must have a look at the individual solutions as each of them is positioned and pitched differently.
Available Microgateways (as of March ’18, A-Z)
Here’s the list of currently available Microgateway offerings:
- Apigee / Google Cloud Microgateway
- CA Microgateway
- IBM API Connect Microgateway (Strongloop)
- Tibco — Project Mashling
- WSO2 API Microgateway
Pitch & Positioning
Let’s have a look how each vendor pitches its Microgateway, the top three use cases and how it fits into the corresponding API Management portfolio.
Apigee / Google Cloud Microgateway
“[…] Its main job is to process requests and responses to and from backend services securely while asynchronously pushing valuable API execution data to Apigee Edge where it is consumed by the Edge Analytics system. […]”
“Reducing latency of API traffic for services that run in close proximity to eliminate the need to always route APIs through a central gateway”
“Keeping API traffic within the enterprise-approved boundaries […]”
“Ability to process messages if internet connection is temporarily lost.”
The value proposition and use cases above reveal that the Microgateway is tailored to the proposed Hybrid Cloud API Management approach where APIM components can run on both the Cloud as well as on premises. This is an attractive enhancement to the APIM platform, for both existing customers and enterprises looking to invest inAPIM. With the Microgateway,
- organisations favouring on-premise APIM are offered a more seamless path towards hybrid and Cloud deployments as they can still monitor, inspect and secure services running on-premise whilst moving the management and publishing functions to the Cloud
- organisations favouring a Cloud or hybrid APIM offering can optimise their infrastructure with local enforcement points nearby back-end services to reduce network latency
The Microgateway optimises the APIM deployment, increases flexibility and is in line with today’s demand towards moving to the Cloud. It allows an organisation to leverage a SaaS solution and reduce the in-house infrastructure of an API Management footprint to the bare minimum.
“CA Microgateway is a lightweight, containerized API gateway that is designed to scale within highly decentralized environments, including microservices architectures. CA Microgateway is easily deployable and configurable by developers at design time using provided templates and integrates with DevOps toolchains for scripted production deployments.”
“[Enforcing] common patterns for microservices including service discovery, circuit breakers, routing and last mile security […]”
“Enabling microservices developers to easily proxy and secure their APIs with simple, extensible policy templates to support new or custom use cases.”
“Lightweight containerized Docker gateway ideal for deployment at remote locations as part of a secured API management solution, as well as for capturing machine data for integration into modern applications.”
From a portfolio perspective, the CA Microgateway extends CA’s Full Lifecycle API Management with security and optimisation capabilities for a microservices infrastructure. It technologically stems from CA’s Enterprise API Gateway and allows policy configuration from the same drag & drop graphical interface, the Policy Manager.
Compared to the enterprise API Gateway, it has a reduced footprint, offers faster startup times and comes with newly introduced Quickstart templates which are pre-built policies to be published via a simple JSON Web API interface. It also allows for auto-scaling of x Microgateway instances which is enabled by integrating with either Consul or PostgreSQL as the API repository. Some Quickstart templates to be enforced out of the box are: CodeInjectionProtection, CORS, EncodeDecodeJWT, RequireOAuth2Token, RouteOrchestrator (to route to multiple backends) and more. Adding to the above REST API and its available templates, there are also new capabilities within the Microgateway engine such as enforcing the Circuit Breaker Pattern to improve resiliency.
With the above characteristics, the Microgateway allows for more flexible handling and integration into a fully automated CI/CD lifecycle — widening its usage into development teams as opposed to the Enterprise API Gateway’s focus on infrastructure and centralisation.
In addition to the capabilities above, the Microgateway comes with great extensibility as it allows an organisation to add templates enforcing custom logic and create custom Docker base images with the added configurations. In a diverse microservices environment, this comes handy as a Microgateway with tested and approved templates can be shared with the engineering teams making use of the templates via the simplified REST API.
IBM API Connect Microgateway (Strongloop)
“The Microgateway is a developer-focused, extensible gateway framework written in Node.js to enforce access to Microservices & APIs. The Microgateway was developed with the goal of making something simple and community-based that could be easily extended to anyone’s needs.”
“Proxying microservices with the ability to embed cross-API capabilities such as security enforcement, access control, rate limiting or content modification into the microgateway.”
“Independent usage of the open-source microgateway as opposed to being packaged exclusively for use with IBM API Connect previously.”
Since May 2017, any developer can take advantage of the open-sourced IBM/StrongLoop Microgateway primarily focussing on two areas, policy management and API definitions.
POLICY MANAGEMENT — Besides pre-built policies such as API key validation or rate limiting, users can create their own custom policies within the API Designer toolkit, the graphical interface the for Microgateway. The fact that it can be used to create API Connect Gateway policies could imply that the Microgateway’s underlying logic and technology is similar (or originated from it / rephrase it). The GUI allows a user to create a policy which is composed of a visual flow, conditions, error handling and more.
Even though the Microgateway is limited to REST and SOAP services where it is unfolding its full potential, it perfectly fits into the IBM API Connect platform as a whole. It is added value for enterprises which have decided to build their APIM platform on IBM API Connect as the Microgateway helps them to hand over gateway capabilities (policies) to a wider team of IT professionals.
Tibco — Project Mashling
“An ultra-lightweight microgateway built on the Go language that allows developers to move beyond the […] request/response message patterns supported with REST APIs and build a new class of APIs that can interact in very flexible ways with evented microservices on the backend.”
“Being ultra-lightweight and deployable as a stand-alone microgateway, it supports edge computing and IoT scenarios and can complement enterprise API management as a federated gateway.”
“Build event-driven microservices and complement service meshes with event-driven patterns.”
“Create and publish reusable recipes that encapsulate common microgateway patterns by making use of popular IDEs with plug-ins.”
As having no dependencies on the TIBCO APIM solution, it is an open-source solution which is more focused on microservices infrastructure rather than management. It purely focuses on improving a microservices architecture by allowing a visual mappings approach of triggers and inter-communication between microservices. Those are called recipes and can be found on and shared with the open-source community. You can already find a handful of recipes which are then easily enforced on the microgateway instance. One simple recipe example is a Content-Based HTTP Router which allows to route requests based on the incoming content.
Under the hood, a recipe is represented as a JSON file declaring the behaviour and logic in a proprietary tree data structure. The main tooling consists of a Visual Studio Code extension and a Mashling CLI (Command-Line Interface) which shows the solution’s strong developer focus.
The Mashling Microgateway is able to integrate with TIBCO/Mashery’s API Management solution with a pre-built recipe allowing you to publish an API configuration into the APIM platform. Altogether, the solution is a suitable complement to the vendor’s enterprise API Management solution and highly relevant for enterprises moving towards a scalable microservices infrastructure.
WSO2 API Microgateway
“As the API Gateway usually connects with other API management components on a continuous basis, the WSO2 API Microgateway is able to completely isolate API runtime from API management traffic to considerably reduce the average response time to serve an API call.”
“As microservices architectures add up a significant amount of network calls, a self-sufficient and lightweight API Gateway operating in a network-isolated environment is required to reduce overall latency.”
“As microservices architectures add up a significant amount of network calls, a lightweight API Gateway is required to reduce the overall network latency.”
“To prevent an API Gateway sending multiple network calls as part of its enforcement policies, the API Microgateway offers offline capabilities such as API Key authentication and JWT handling in a network-isolated environment.”
As we’ve already seen with previous Microgateway solutions, a primary driver for WSO2 to introduce the Microgateway was to allow complete decoupling and isolation from other components within an APIM deployment such as analytics, statistics and publishing. Additionally, microservices patterns and evolving infrastructure characteristics have been taken into consideration. In his article, Lakmal Warusawithana from WSO2 describes the three most relevant API Gateway deployment patterns which give an interesting background of how the Microgateway can be utilised within a microservices architecture — and also how WSO2 positions its solution:
- Centralised API Gateway — This is the well-known and most common way of deploying API Gateways nowadays, namely by horizontally scaling API Gateway instances which sit either between internal services or are used as a mediator for the communication with external entities.
- Private Jet API Gateway — In this scenario, each individual microservice (swarm or cluster) is fronted by one dedicated API Gateway for potential load balancing or failover capabilities.
- Sidecar API Gateway — With this pattern, one dedicated API Gateway is tightly coupled with one microservice which is a setup often seen in service-mesh architectures where required microservice capabilities such as service discovery or reliable delivery are offloaded to the concerning gateway (you can read more about service mesh here).
Looking at the three scenarios, the Microgateway is most suitable for the second and third pattern where characteristics such as lightweight deployment, small footprint, fast startup and low-latency processing are of importance. Summarised, WSO2's Microgateway has been introduced to offer a tailored solution for microservices environments, thus expanding their APIM capabilities into a microservices infrastructure.
Each particular Microgateway solution offers its very own set of capabilities which are always aligned to the vendor’s complete API Management portfolio. Some solutions are rather focused on API Management optimisation (e.g. reducing calls to APIM analytics tools) whereas others endeavour to provide capabilities for microservices and related infrastructure and development patterns. I was consciously not aiming for a technical comparison as it could not have demonstrated the essential differences you are now aware of.
If you would like to know more about the Microgateways’ technology, below is a list of all GitHub repositories.