Microservices Ready model step 5 – API Management

2018-01-22

What would a Microservice be without means to communicate with it? How do you control who/what communicates with your Microservice and uses its resources? How do you analyze patterns and usage? This is where APIs and API Management comes into play.

The concept of APIs and API Management isn’t new, but it is currently a hot topic in the IT industry. At Redpill Linpro we even have our own ”API Ready” model to help organisations adopt the concept of APIs and the API Economy.

APIs and the ”API Ready” model focuses on how to release the power of your internal resources in a more controlled way, make it possible for internal resources to explore external data sources or to enable external resources to communicate digitally with your organisation.

With a Microservices based architecture we take this one step further. Whereas an API previously may have been used to publish an integration end-point or enabled access to legacy systems, with Microservices we will over time have loads of pieces of code that offer various functionality. To be able to manage this, we require a tool or logical function that provides us with one place to publish and manage all these APIs that are required to communicate with our Microservices.

Even though we agree that the best way to interact with a microservice is through an API, we must realize that there will be a few challenges. A few of them are listed below:

Publication/Visualisation

With a large set of various Microservices available through your newly established Microservices architecture, it can be hard for the users of the components to know where to look. By visualising your Microservices APIs through an API Manager you create an easy to use and single point of contact for those that wants to make use of your architecture.

Versioning

To be flexible and able to update the functionality of a Microservices, we may need to modify the API that we are using, in order to communicate with it. This causes a problem, since we might have several other Microservices that are communicating through the API that we want to modify. To manage this correctly, we must support (at least for a limited time) various versions of the same API. An API Manager will make it easier for you to keep track of different versions of the same API and handle deprecation of old versions of the API.

Performance

How do you keep track of traffic to and from your Microservice? How do you know which Microservices are used often and which are not? Keeping track of the API traffic/usage can help you collect data on usage that you then need to analyze. With an API Manager you can add an analytics tool that help you to analyze Microservices usage, and which ones that are popular and may need extra attention or computing power. Based on metrics you can also analyze if your Microservices architecture is performing well enough to meet overarching digital transformation requirements, or if you need to modify the set up or computing power available.

Throttling/Subscriptions

What if you want to expose an API to a certain Microservice externally? Or regulate internal usage for performance reasons or constraints from computing power, SLA, licensing or other reasons? Well, this can be done by using the API Manager to define subscriptions and throttle traffic if required. This way you can protect your Microservices from over use and potential performance issues. For external access you can even use subscriptions and get paid for access to the data that your Microservice can expose.

Analytics

We touched on this subject under the ”Performance” headline above. However, the data gathered on API usage and access from the API Manager can be used to measure performance and give you both reactive and proactive intel on your Microservices usage as well as many many other purposes. At an aggregated level, intel from your Microservices usage can be used to make important and well informed business decisions. API/Microservices usage may even be used to create new business opportunities based on knowledge regarding which information is requested and for what purpose.

Documentation

In order to let others communicate with your Microservice, you must document your API and tell the user how the interaction is supposed to go. What information does the communicating piece of software need to provide, what kind of output can be expected and how is this output delivered? API Managers provide an excellent place for this kind of information and often provide a framework for how to document your APIs, assisting external users with means of communicating with your Microservice.

An efficient API Manager is an important part of your reference architecture/platform for your Microservices initiative. Since the way to communicate with Microservices are through APIs we will end up with a lot of APIs to communicate with in a Microservices architecture. This is something that software vendors and platform companies have noticed and we are now seeing an investment in the next generation of API Managers, where they are modified to fit even better into a Microservices initiative. The upcoming version 3.0 of the WSO2 API Manager will for instance provide developers with even more flexibility and deployment options, where each Microservice can be deployed with its own small API Manager to further add to high availability and scaling options for each API. The updated API Manager will further add functionality, such as auto discovery, proxy, integration and routing, that was previously in the Microservices layer.

The further development of the API Management capabilities related to Microservices will be interesting to follow and we expect this area to be one of the talking points in the development community in the time to come.

Learn more about our Microservices Ready model here

Contact me

Written by Fredrik Svensson