WSO2 Updates Microgateway to Boot Faster, Serve Multiple Microservices
The distributed nature of microservices means a centralized gateway can be a choke point. As WSO2’s Vice President of Marketing Ken Oestreich explained it:
“A lot of services are not in your data center anymore. In fact, they’re not even with your primary cloud provider anymore. They’re all over the place. So this notion of a central gateway on a server somewhere [creates] a scale problem because you’re reaching into all these different clouds now. … So why not make your gateway distributed as well?
A microgateway sits out in front of one or a handful of microservices. The microgateways act as proxies to the main gateway, and you might not even have a main gateway anymore. They’re lighter weight, they start up more quickly. It’s all is propelling the market space to go more distributed, more microservice, more multicloud, he said.
At OSCON this week, the integration-focused company revealed version 3.0 of its open-source API micro gateway, which boots up in less than a second and features built-in capabilities including authentication, authorization, rate limiting, service composition, discovery, transformation, and analytics.
The new features include:
- Developer-first runtime generation using the OpenAPI Specification, so APIs can be developed in collaboration and then tested independently.
- Run-time service discovery support to automatically find services whose IP addresses changed as they are redeployed.
- Support for composing multiple microservices and then exposing the combination via a single API.
- Support for transforming API requests and responses from legacy formats to modern ones, so they can be exposed to modern consumer apps.
- Separation of the WSO2 API Microgateway toolkit from the runtime for better scalability and smoother upgrades.
As Oestreich described it, the microgateway boots faster and now can handle multiple microservices.
The company unveiled pared-down and microservices-tuned containerized versions of its API gateway, enterprise service bus (ESB), identity server and stream processor last July.
It touted the microservice gateway as a component that can “serve as a dedicated proxy for a microservice, a sidecar for a microservice running on the same host, or an API hub that proxies one or more microservices.”
While Axway vice president of engineering David McKenna, in this API Friends post, described a microgateway as a service mesh, WSO2 maintains that service meshes in their native form have an “API management gap.” It addresses this with its API Management product, which it recently announced as a bridge with the popular service mesh Istio. While Istio provides data plane and control plane capabilities, WSO2 API Manager provides management plane features, it says.
It’s all part of a strategy to make microservices deployment easier, combining it with DevOps, continuous integration/continuous delivery, and making integration more compatible with all sorts of containers, according to Oestreich.
As part of that, version 1.0 of its programming language called Ballerina will be released in a couple of weeks, he said. It developed Ballerina to make it easier for developers to connect their applications with other services, eliminating, or at least minimizing, the need for middleware such as ESBs.
Ballerina contains network-distributed concepts in the language itself, Oestereich said.
“The language is network-aware. It understands transactions. It understands network delays. It understands how to integrate services and what happens when there’s an error. So the amount of code you’d have to write to integrate a service is very low. If you’re writing network-distributed applications, this is a very efficient language, far better than any general-purpose language out there,” he said.
WSO2 is a sponsor of The New Stack.
Feature image via Pixabay.
