WSO2 API Microgateway: A Developer-Oriented Gateway for Microservices
- Rajith Roshan
- Associate Technical Lead - WSO2
WSO2 API Microgateway is a cloud-native, decentralized, highly scalable, immutable API gateway designed for microservice architecture (MSA). It provides security, authorization, routing, service discovery, and many more API management-related functionality while collecting information for rate limiting and analytics as well.
In this article, we will briefly look at how gateways evolved to become microgateways with the current trends in the market, and how WSO2 API Microgateway fits perfectly into delivering those market trends and requirements.
Why We Need a Gateway
When developing a service or microservice, what major challenges would one face? In a production deployment, implementing functionality would be the least of your worries. The bigger challenges come when securing the services, limiting access to the services, visualizing service metrics, and exposing the services in a client agnostic manner. These are a common set of problems faced in every deployment when services are about to be deployed in production.
The old fashioned way would be to independently incorporate these capabilities into each and every service, but in the long run, this can be difficult to maintain as services might adopt different approaches towards each problem. This led to the most commonly adopted pattern where an abstraction layer was added on top of the service layer. This layer builds in common functionality like security, rate limiting, logging, transformations, caching, and analytics.
This abstract layer became a gateway for services as a proxy with quality of service (QoS) on top of it. The basic functionality of this API gateway is to act as a proxy with an abstraction layer and expose services to clients in a unified manner irrespective of their underlying implementations and protocols.
Why We Need a Microgateway
As the number of services within a deployment increased, handling service-to-service communication and scaling the gateway to cater to all services became difficult. Once services became interdependent and tightly coupled, deploying a certain part of the deployment when an upgrade is done to a single service was hard. This spaghetti architecture required redeployment of the complete system even when a slight change had been made to a certain service.
These problems led to new ideas that minimized the coupling between services and broke them down into smaller parts that did a specific business logic only. This does not mean that having a maximum number of services without interdependency would solve the issue. The idea is to identify a minimum set of services required with minimal coupling with each other in order to provide the desired capabilities. Hence the concept of MSA was developed and has now become a heavily adopted pattern by many organizations.
Having a large number of lightly coupled services makes the maintenance of the gateway layer more problematic. Because each microservice may have different scaling factors based on its business purpose, scaling the gateway to match all services will always end up either under- or over-utilizing resources. Gateway layers aren’t typically lightweight and require a substantial amount of resources, hence scaling them to match the most frequently used lightweight microservice would not be the ideal solution.
That’s why a dedicated gateway for a set of services or a cluster of the same services was needed. In order to cater to this idea of a per-service gateway, a lightweight, scalable, distributed gateway layer was required. The microgateway came into the picture to solve this issue faced by modern architecture patterns.
Modes of Deploying the Microgateway in MSA
In an MSA, microgateways can be deployed with microservices in the following manner:
- Private Jet / Per Service Gateway
Certain microservices may need to be scaled independently from other services. This might be due to the heavy usage of that service compared to others. So the gateway should also scale up to a certain ratio with the microservice. In this kind of scenario, it’s better to have a dedicated gateway for that particular microservice.
- Microgateway as a Sidecar
In containerized deployments, there might be use cases to deploy the gateway with the service in the same node or pod. This is a good example for the sidecar pattern where functionality like security, logging, and monitoring is tightly integrated so that the shared resources can be used efficiently.
- Shared Gateway
Services that don’t have a large load may not require a private jet or sidecar gateway. These kinds of services can share a single gateway cluster. For example, two or more microservices can be exposed via a single gateway cluster.
Key Attributes of WSO2 API Microgateway
- Cloud-native - WSO2 API Microgateway is designed as lightweight containers with a small memory footprint and fast bootup time. It works in a completely stateless manner which makes it less troublesome when deploying in the cloud. It can be deployed in any system irrespective of the factors underlying the operating system. It has a smooth DevOps cycle that enables agile development. The inbuilt support for generating deployment artifacts enables the deployment process to be automated. Another key advantage is it was developed using the Ballerina language, which is specifically designed as a cloud-native integration language.
- Developer centric - WSO2 API Microgateway is designed by the API developers during the development cycle. The OpenAPI definition written by API developers, which explains the interfaces of the microservices, acts as the single source of the truth to manage microgateway projects. Microgateway projects can be developed collaboratively in parallel with microservices. Any addition or change to the microservices would be reflected in OpenAPI definition and incorporated in the microgateway project automatically.
- Decentralized - WSO2 API Microgateway can be deployed in a decentralized manner closer to the microservices. It can be deployed as dedicated gateways for particular microservices that need higher throughput requirements.
- Highly scalable - WSO2 API Microgateway was designed to run independently. It does not have tight coupling with any other runtime components like key managers, traffic managers and analytics servers as it is designed to work in a completely locked down environment without needing external connections. This allows the microgateway to horizontally scale without having to scale other components.
- Immutability - Immutability is a key factor in containerized deployments. The images or artifacts should be immutable and the changes to APIs or microservices requires artifacts/images to be built again and deployed.
WSO2 API Microgateway Design
WSO2 API Microgateway is designed to use code over config. Therefore it’s more developer-oriented. This microgateway gives the API developer the flexibility to design their own microgateway based on the interface definitions of their APIs.
The above diagram explains the microgateway components like toolkit and runtime and how each component is used in the development and operational phases. The microgateways are designed by API developers using the OpenAPI Specification. This enables developers to collaboratively design their APIs from microservices and directly incorporate microgateways with those APIs during the development cycle. The following sections explain two basic components of the microgateway that enables developers and operational teams to completely design, test and deploy microgateways.
- Command-line interface (CLI) to manage microgateway projects
- Initialize microgateway projects with OpenAPI definitions
- Builds the projects to create
- Runtime artifacts (APIs packed in) for runtime containers and distributions
- Immutable containers with built-in APIs
- Kubernetes (K8s) artifacts used to deploy in K8s clusters
- Import APIs from WSO2 API Manager
- Serves the requests applying
- Rate limiting
- Analytics and more
- Available as archived distributions as well as Docker images
- Can be build burning APIs into container images to spawn immutable containers
- Runs on top of artifacts generated by the toolkit
Microgateway Development Cycle
The following steps demonstrate how a development team can work on a specific project to develop a set of microservices to cater to a certain business use cases and how they can parallelly develop the microgateway to expose their service as well.
- Developer starts creating the microservice
- Defines the OpenAPI definition for the microservice
- Initiates the microgateway project from the OpenAPI definition
- Builds the microgateway project
- Locally tests the service exposed via the microgateway
- Commits the project to the source version system (e.g. Git)
- Developers collectively develop other microservices
- Checks out the microgateway project
- Modifies the OpenAPI definitions to add the newly added microservices
- Builds the microgateway project with multiple services now
- Locally tests the specific microservice via the gateway
- Individually each developer commits changes to the project
Microgateway Operations Cycle
In an agile development environment after a few cycles of development, once the project comes to a stable state, the next step would be to deploy the project in the development environment so everyone can test and develop. The following will be the steps to follow once the request comes to the operations team to deploy the microgateway project:
- Operations team checks out the project
- Creates the deployment configuration for the project
- Builds the project with the deployment configuration using the toolkit
- Deploys the microgateways using the build artifacts (in Docker/K8s)
The deployment configuration is a human-readable representation to help the DevOps team to deploy the microgateway in Docker or Kubernetes.
Microgateway CI/CD Process
Once the initial environment is deployed there should be a process to continuously deploy in subsequent environments. Created artifacts should be usable across multiple subsequent environments until it goes into production.
- Completes the deployment and testing of the dev environment
- Creates the deployment configuration file for the test environment
- The configuration is changed to use the same runtime artifact s(executables/containers) from the dev environment
- Provides environment-specific data as environment variables
- Builds the project with deployment configuration for testing
- Deploys the microgateways using the build artifacts (In Docker/K8s)
- Continues the process until deployed in production
So we can see that the same runtime artifacts used in the dev environment can be used across multiple environments overriding the environment-specific values using environmental variables.
This way it is guaranteed that the artifacts tested in dev and test environment will behave in the same manner when deployed in production as well.
The key attributes of a microgateway have given it a competitive advantage over legacy gateways when it comes to modern-day deployments. Its low resource consumption, stateless nature, fast bootup times, high scalability, and immutability has made microgateways a preferred option in MSA. Microgateways are no longer just a tool for developers for testing, while legacy gateways conquer the actual deployments. Microgateways are now replacing the legacy gateways with their ability to adapt in any deployment architectures.