Introduction to Microservices Governance — Part IV
How microservices governance relates to API Management?
This is the final part of the microservices governance tutorial series. You can find the first 3 parts of the tutorial in the below links.
In this final part of the tutorial, we discuss how microservices governance and API Management coexist in an enterprise platform.
Microservices governance and API Management
One of the biggest confusions in the industry around microservices governance is that API Management platforms can cover up the governance aspect of microservices through their API publishing tools and developer portals. This is not true. API Management tools provide some level of governance to the APIs(API Proxies) that are developed on top of the microservices. If a certain backend microservices team decides to utilize the API management platform to expose their microservices to other components, at that point, the APIM platform will start interacting with the microservices with a new lifecycle, standard, and policy that is related to the API fraction of the service. But it is not capable of handling the governance capabilities that are required prior to the API development. This is the time where people tend to cover up the governance aspect via the API platform by creating a lifecycle that expands beyond the API lifecycle with stages like “Design”, “Review”, “Implement” for backend microservice without any connection or relation to the actual progress of the microservices development. By doing this, users will lose the ability to properly govern the microservices development process, rather it will only be able to handle the governance of API Proxy development.
The other arguable fact about microservices development is that every microservice should be exposed via an API management platform. These arguments help vendors to push the idea of using the API Management platform to govern your microservices since all the microservices are published through the same. Even in a situation like that where all the microservices are exposed via an API platform, those platforms are not capable of handling the governance aspect of the microservices development (except the API proxy part). The best solution for this sort of scenario is to build a bridge between the microservices governance platform and the API management platform where API management becomes an extension of the microservices governance.
As depicted in the above figure, microservices governance captures the lifecycle transitions of the development process that are independent of the API development. In a waterfall type of development model where one microservices team responsible for both microservice implementation and the API development, this sort of integration can help to bridge the 2 components.
In most cases, these 2 tasks of microservices development and API development can execute in parallel without waiting on each other (within a single microservices team or in 2 different microservices teams) when there is a defined API interface. This is called the “API first” development approach where architects will define the API as an output of the initial lifecycle of idea generation (depicted in a previous figure) and then spin off 2 microservices teams to work on the development of backend implementation and the API creation and related activities.
Lifecycle management is only one of the features that can differentiate the functionality of the microservices governance framework and API management platform. In addition to that, API management platforms always create an API proxy out of the microservice and add another component to the runtime architecture which is not desirable for every microservice. There can be microservices that just need to publish their metadata to other users without introducing any additional runtime layer on top of the existing service since those required QoS services are already available within the microservice itself. This can be a common case where microservices teams use technologies like service meshes where it provides additional control of the QoS functionality within it. In such cases, using an API management platform to govern the microservice will not be required unless otherwise, that platform has a mechanism to register these microservices without generating a proxy API. In such a case, a microservice governance framework can provide the required functionality of reusability and service discovery via the same without needing an API management platform.
In addition to the above-mentioned points, features like dependency analysis to identify the relationship of a given service with the rest of the ecosystem is not something available in API management platforms since it only cares about a particular API and its related endpoint/s.
As depicted in the above figure, even though similar functionalities like service registry (reusability), service discovery, lifecycle management, user management, and best practices are available within APIM platforms, their scope is well outside the microservices development process. The Microservices governance platform needs to compliment the API management platform to implement end-to-end governance on a microservices architecture.
In summary, we can identify that there is a clear void in the space of microservice governance that people often overlook when adopting microservices architecture and due to that, maintaining such an architecture has become a major challenge to an extent where some of the early promoters of microservices architecture is leaving it behind as a mistake. But in reality, it has a lot of advantages that deliver value to the business and the consumers if we govern the process properly.
Future improvements
The term “governance” is an ever-evolving concept in every context (political, business, IT) that is applicable. In the context of IT governance, we identified that design-time governance and runtime governance are the 2 branches of governance that help organizations to achieve their business objectives through the use of technology and people. One key aspect missing in the governance tools is the “observability” where the results of the delivered services are captured and analyzed with modern tools like Artificial Intelligence and Machine Learning to expedite the processes of service delivery by predicting the future requirements rather than waiting for ideas to be stemmed from people all the time. These analytics tools can be used to measure the effectiveness of the processes and derive better models (lifecycles, team sizes, release cycles) to work on and hence improve the overall efficiency of the system.
That ends the 4 part article series on microservices governance.
References:
https://www.wipro.com/blogs/dr-gopala-krishna-behara/microservices-governance/
https://www.leanix.net/en/blog/microservices-governance
https://dzone.com/articles/efficient-enterprise-microservice-governance
https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/
https://medium.com/ibm-garage/microservices-technical-governance-f5aed10189d1
