Microservices
In the trade-off between high cohesion and low coupling, microservices are on the high cohesion side of the spectrum. Microservices have a small scope, aka microscope, hence rely on lots of interaction over the network to create a cohesive macroservice. Sometimes, to optimize, a family of microservices gets deployed on the same host. This practice is known as a cellular architecture, in which case the network interactions get cut short, but still, there’s a lot of interaction going on.
From a security point of view, network interaction is the vehicle to control. What happens inside a piece of software is a matter of the owner and the user, but when pieces of software exchange information, there’s a joint responsibility. As we all know, there are significant risks involved in network interactions. So, it’s no wonder guarding those interactions is important.
The API Gateway has become one of the most valuable and trusted tools to guard those interactions. With API Management, you can develop smart policies, knowing the developer and the user context, and enforce your authorization policies, rates and quota. But tunneling all your network traffic over a single gateway might be not the smartest choice. True, the WSO2 API Gateway can easily scale up to thousands of invocations per second, but still.
This is where the microgateway comes in. Conceptually, it’s a satellite for the main gateway with a limited responsibility to control access to a specific domain. A domain can be any collection of one or more microservices. Actually, it intercepts all incoming messages, and enforces access control policies on them, just like the regular gateway. But where the regular gateway is optimized for manageability, the microgateway is optimized for processing speed. Your API definitions and policies get compiled into a specialized runtime. Consequently, whenever you want to change anything, you’ll have to rebuild your microgateway.
Since the WSO2 API Microgateway is optimized for speed, it’s designed to operate autonomously. After all, interactions with other components over the network will add latency. In other words, a microgateway is not only a policy enforcement point, and it can be its own policy decision point too.
Sometimes, you actually want your microgateway to work in isolation, and you’re prepared to accept certain limitations. An autonomous microgateway is aware of local traffic, but generally unaware of traffic flowing through other gateways or even other gateway instances. That’s the price you pay for autonomy, so you’ll simply have to design your traffic policies with that in mind. Additionally, when using self-contained JWT access tokens, you can do token validation and user authorization without direct interaction with your identity provider. You can even get a message when a token gets revoked. That’s pretty solid. On the other hand, when you do want to enforce overarching throttling policies, or you do need support for other types of access tokens, you can still set up your microgateway to use an outside API Traffic Manager or API Key Manager as your policy decision points.
Go Connext
Connext by Yenlo is well-suited to help manage your microservice architecture. It has the WSO2 API Management platform, where you can define your APIs and manage your policies. You can also use the API Manager to publish your micro-APIs to the store. It’s often useful to have a single developer portal where you can find all your APIs, given the appropriate authorization, of course. Connext also has the API Gateway to enforce your policies at the perimeter. This is where you can apply your quota and collect your usage data for monetization. Connext also has an identity provider, the WSO2 Identity Server, which implements the authentication endpoint on the perimeter gateway. This allows you to manage your user identities, their accounts, and (strongly, if needed) authenticate your users. You can even manage your user’s consent. WSO2 Identity Server will happily generate self-contained Access and ID-tokens, which can be used for authorization on the API Gateway and the API Microgateway. You can also forward them to your microservices to implement additional logic.
Typically, you would not want to expose your internal resource model to the outside world. That would couple your outside applications too tightly to your current microservices design. It would expose the kind of system intricacies you’d better keep private. And you want to be able to change your internal representation without affecting your external representation. It makes total sense to define different APIs for your global gateway and your microgateways. A single product-API alongside one or more micro-APIs.
With the WSO2 Microgateway Toolkit, it is easy to build your own WSO2 Microgateway Runtime. All you need is an Open API Specification of your API, and a YAML file to specify any additional policies. That’s it. If you build your runtime as a Docker container, and why not, you can simply run it on your Connext platform. You can use it instantly for your cross-domain API requests. All you’ve got left to do now is tie your two tiers of APIs together – an API on the global gateway with one or more on your microgateways. So you need to do some integration.
Integration doesn’t have to be painful, though. Not if you’re fortunate enough to use Connext. Sometimes, you can simply forward a macro-API method invocation to a micro-API – don’t forget to forward the tokens also. But often, there will be some logic in between those requests. It might be transformation, it might be enrichment, it might be filtering, it might be orchestration. That’s why we’ve included a full-blown WSO2 Enterprise Integrator in Connext. You have all the power you need to solve any integration problem with the least amount of hassle.
Think of the possibilities this opens. It’s huge. If you want, you can use Connext to wrap your legacy systems in a layer of microservices. Or to interconnect all your SaaS-systems. And you can certainly think of much, much more useful stuff to do.
So, there you have it. Isn’t that micro thing mega cool?
