Source: devops.com. Original announcement made at OSCON (Open Source and Software Development Conference), July 2019.
WSO2 API Microgateway 3.0: What Changed
At OSCON, WSO2 announced version 3.0 of its open source WSO2 API Microgateway, a lightweight, developer-focused API gateway designed for microservices architectures. The release introduced several capabilities aimed at reducing the operational burden of managing large numbers of APIs across distributed systems.
Key Features Introduced in Version 3.0
- Multi-microservice API exposure: Multiple microservices can now be exposed through a single API endpoint, simplifying the interface surface for consumers.
- Automatic microservice discovery: The gateway can detect microservices automatically, reducing manual configuration overhead.
- Legacy API transformation: Incoming legacy API request formats can be translated into more modern formats, easing migration paths.
- OpenAPI Specification (OAS) support: Previously known as Swagger, OAS support was added to improve developer collaboration on API design and documentation.
- Decoupled toolkit and runtime: The WSO2 API Microgateway toolkit was separated from its runtime, enabling greater scalability and allowing smoother, less disruptive upgrades.
Performance and Core Capabilities
The WSO2 API Microgateway is engineered for fast startup — designed to boot in under one second — making it well-suited for dynamic, container-based environments where services are frequently started and stopped. Beyond routing, it provides a broad set of built-in capabilities out of the box:
- Authentication and authorization
- Rate limiting and throttling
- Service composition
- Service discovery
- Request and response transformation
- Analytics and observability
It is designed to integrate with the WSO2 API Manager, an open source API management platform that can be deployed on-premises or in the cloud, giving teams centralized visibility and control over their API estate.
Kubernetes and Container Orchestration Support
Recognizing that the majority of microservices are now deployed in containers, WSO2 built native Kubernetes support directly into the gateway. This allows teams to generate Kubernetes artifacts from the gateway configuration and apply them directly to Kubernetes clusters — tightly integrating API management into container orchestration workflows rather than treating it as an afterthought.
WSO2 also provides a visual flow diagram interface that lets organizations map and manage the relationships between APIs and services, offering a graphical overview of an otherwise complex dependency graph.
The Ballerina Connection: Integrating Development and Operations
A recurring theme in WSO2’s messaging around the Microgateway is the convergence of application development and integration work into a single team — a goal closely aligned with DevOps principles. To support this, WSO2 has actively promoted Ballerina, a general-purpose, open source programming language designed specifically for writing distributed integrations.
According to Ken Oestreich, vice president of product marketing at WSO2, Ballerina enables developers to build and embed their own micro-enterprise service bus (ESB) logic directly within a distributed application — without needing a separate, centrally managed integration layer. These integration components can then be version-controlled, tested, and deployed as part of standard CI/CD pipelines.
The Broader API Management Challenge in Microservices Environments
The WSO2 announcement addresses a problem that has grown significantly as container adoption has accelerated: API sprawl. In traditional monolithic architectures, managing a relatively small set of APIs was tractable. In a microservices environment, each discrete service exposes its own API, and the number of APIs in a large organization can reach into the thousands.
This creates several operational risks:
- Dependency fragility: APIs are often tightly interdependent. Changes to one API can degrade the performance of downstream consumers, even if no individual service crashes outright.
- Ownership ambiguity: Developers typically create APIs, but once those APIs are deployed to production, ownership often shifts to operations or platform teams — creating gaps in accountability.
- Operational visibility: Without centralized tooling, it becomes difficult to track which APIs exist, who is consuming them, and what the impact of a change or deprecation will be.
Integrating API Management into DevOps Workflows
The underlying challenge is cultural as much as technical: API management needs to become a natural, first-class part of the DevOps lifecycle rather than a separate concern handled by a siloed team. This means treating API definitions as code, versioning them alongside service code, and including API contract testing in CI/CD pipelines.
The WSO2 API Microgateway 3.0 release reflects an attempt to make this integration more practical — by decoupling the toolkit from the runtime, supporting OAS for design-time collaboration, and providing Kubernetes-native deployment artifacts that fit naturally into GitOps and pipeline-driven workflows.
For teams managing large numbers of microservices, a gateway that can boot in under a second, auto-discover services, and integrate directly with Kubernetes represents a meaningful improvement over heavier, centralized API gateway patterns inherited from SOA-era architectures.
This article is based on reporting from devops.com covering WSO2’s announcement at OSCON in July 2019. For the latest WSO2 API Microgateway documentation and release notes, refer to the WSO2 API Management product page.