Introduction to Microservices Governance — Part III
A reference architecture for microservices governance and API Management
This is the third part of the microservices governance tutorial series and you can find the first two parts of this in the below links.
In this part of the tutorial we discuss a reference architecture for microservices and how that architecture can be realized with a reference implementation.
Microservices governance reference architecture
Now that we have covered the details of the microservices governance and how it works at a non-technical level, let’s try to bring these ideas into a solution architecture that depicts the various components and their interactions in a technical context.
Let’s take an example of a modern brownfield enterprise that is being transformed into a microservices architecture.
The above figure depicts a detailed view of the previously discussed architecture where people, technology, and governance process interacts with each other to deliver results to the business.
Technology components
The end result of a microservices team is the microservice that is up and running in a production environment. What you see in the above figure at the top half is a production environment that has various types of microservices deployed with multiple replicas. This diagram does not depict other components like security token services, service meshes, message brokers, etc. for the sake of simplicity. It also depicts the legacy services that are an unavoidable part of an enterprise architecture.
The bottom half of the technology components section depicts various underlying technology components that are utilized by the microservices during the runtime as well as during the development and testing phases. These components can be different from microservice to microservice. But using different variations of all those components for different microservices can be overkill. As an example, if the organization decided to use a certain IaaS provider for infrastructure, then it is advisable to use that instead of going for a different provider if there is no real reason. Similarly, the polyglot concept needs to be utilized with care. With the governance in place, utilization of technology components can also be managed in a “trust but verify” model.
People
This diagram details the people aspect as well. It depicts different roles that people play within a microservices-based development process. These are the people who interact with the governance platform from time to time to deliver services that align with business goals. From the initial design phase to the final retirement phase, various team members play one or more roles from the mentioned list to provide the best experience to the users. These roles will have different permissions according to the requirements of microservices teams and overall business needs.
Governance platform
We have already discussed the capabilities of the governance platform in previous sections. In this section, We’re discussing the advantages of these capabilities in the microservices context.
Repository/Catalogue
In a typical enterprise deployment with an N-tier architecture, there are different types of services from backend services, middleware services, APIs to frontend services. Usually, API platforms have developer portals that expose the API details to the consumers. But other types of services are not stored in this portal. It is the responsibility of the governance platform to keep all the different types of services and make sure that each service is reusable. Additional functionalities like search, browse, discovery, categorization, dependency analysis will increase the value of the platform.
Service discovery
Runtime service discovery is one of the important aspects within a microservices-based self-contained, service-oriented, n-tier architecture model where different functionalities are executed at different services. When the services are deployed through different environments, the actual URL of these services can be changed. In such a situation, having a common reference as a “key” in the implementation and mapping that to a “value” via the service discovery function can reduce the management complexity of the services when going through environments.
Lifecycle management
This is another key functionality used by services other than APIs. In most cases, API platforms only manage the lifecycle of API proxies which is an overlay on top of the actual microservice. These core microservices also have their own lifecycles and need to be governed according to the business standards and best practices. That functionality is provided by the governance platform as we discussed earlier in this writing. Different teams can have their own lifecycle stages and attach those lifecycles to the respective microservices via this platform.
User/Group management
One of the key aspects of any governance process is the management of users and their permissions. This is the functionality that manages the people aspect of the governance story where different roles can be assigned with different permissions to do certain operations. One example is the management of lifecycle states. Developers will do the development and need to get approval from testers to move it to the production environment.
Interaction over API
Some teams may prefer programmatic access to governance functionalities so that they can build automated pipelines to deliver services. One of the key capabilities of the governance platform is to expose almost all the required capabilities via a defined API so that teams can interact with the platform via that. This needs to be protected with a mechanism like OAuth2 or basic authentication based on the ability of the clients.
Standards/Policies/Best practices
Giving too much freedom to microservices teams can lead to a complex overall architecture with so many different technologies, standards, and practices. That is one of the key reasons why microservice architecture needs a governance layer to “trust but verify” the microservice teams’ work. These policies need not be pushed from top to bottom always. These can come from the individual teams but need to be verified and reviewed by the architects and business leaders to verify that they are in line with the business standards and goals.
Microservices governance reference implementation with WSO2
The reference architecture we discussed before needs to be something that is practical. In other words, it needs to be possible to implement with existing software tools. That is the intention of the final section of this writing to discuss the possible solution architecture with the WSO2 open source software stack. This architecture includes many other existing tools and technologies in addition to WSO2 to make it a complete reference implementation.
As depicted in the above figure, microservices pertaining to different domains can be implemented with a variety of technologies. A few examples are
- Frontend applications — Javascript, React, Angular
- API gateways — WSO2 API Manager, Microgateway
- Integration services — WSO2 Enterprise Integrator, Micro Integrator
- Backend business services — Spring boot, Golang, .Net
- API Developer portal — WSO2 API Manager developer portal
In addition to this, there can be legacy services that need to integrate with the overall ecosystem since those systems cannot be replaced with microservices.
- Legacy services — SOAP, XML, SAP, FIX, JMS
All these services utilize various underlying tools and technologies to deliver value to the end-users. Those technologies are
- Infrastructure — AWS, Azure, VMs, or Physical hardware
- Container runtime — Docker, rkt
- Language runtimes — JDK, .Net framework, Node
- Continuous Integration tools — Jenkins, TravisCI, CircleCI
- Source code management tools — GitHub, GitLab
- Test automation tools — Selenium, Newman, SOAPUI
- Design/Implementation tools — IDE, VSCode
When it comes to the governance of the overall ecosystem, there are 2 types we have identified at the beginning of this writing. Those are design-time governance and runtime governance. Let’s dig a little deeper into these concepts with this reference implementation.
Design time governance
This is the part of governance that involves lifecycle management, policies, standards, best practices as well as reusability. Different microservices teams can have their own lifecycle definitions and different user roles to manage the lifecycle state transfer. That allows teams to work autonomously. At the same time, the WSO2 digital asset governance solution allows these teams to create custom lifecycles and attach them to the services that they implement. As part of that, there can be roles that verify the overall governance across multiple teams by making sure that everyone follows the industry best practices that are accepted by the business. As an example, If the industry best practice is to use Open API Specification for API definitions, every microservices team needs to adhere to that standard since it is technology-neutral. At the same time, teams should have the autonomy to select the programming language and the libraries used in their development.
Another key aspect of design-time governance is the reusable aspect. Given that microservices teams are stemmed from ideas, there can be situations where certain services that are required to retrieve data for this new microservices implementation is already available via a service developed by another team. Instead of reimplementing the same service, that team can make use of the existing service. This is the functionality of the repository aspect of the WSO2 governance solution where users can browse, search existing services and reuse the same wherever possible. That reduces the overall time to market and duplicates effort that could waste considerable time from the team.
When it comes to managing the lifecycle of the services, sometimes it is necessary to deprecate older services to make the way to the new services. At a time like that, it is essential to understand the impact of a given service before deprecating it. In a large enterprise with 1000s of services, finding this relationship can be extremely difficult if you don’t have a governance tool that supports this capability. Fortunately, the WSO2 governance solution allows the users to analyze the impact of a given service (or asset) on other similar objects.
When it comes to API development, WSO2 API Manager comes with the API Publisher and Developer portal that serves the functionality of lifecycle management and repository aspects for APIs (API Proxies). This is mainly designed to be exposed to internal as well as external developers who are planning to utilize the APIs in their respective delivery channels (mobile, web apps). WSO2 Digital Asset Governance solution can be integrated with WSO2 API Manager to implement a seamless experience for API development where API designing can be done at the governance platform and push that to the API Management layer for managing the rest of the lifecycle.
Runtime governance
This is the component of governance that is often being overlooked. But it is an essential part of building a modern automated, dynamic enterprise platform. Runtime governance deals with the runtime interaction of services with the governance platform via an API to find out certain assets in the platform. As an example, in a typical integration developed in WSO2 EI, the endpoint name can be given as a fixed value like “hospital”. But the actual URL of this value can be different based on the environment (DEV, UAT, PROD), and that runtime mapping of the endpoint name to the URL can be achieved through the governance platform where it can store the value against the URL and resolve that during the runtime. This functionality is often called “service discovery” where the runtime discovers the actual URL of the service by calling the governance platform.
In addition to that, the governance platform exposes a set of REST APIs to perform most of the design-time governance functionalities via these APIs in a programmatic manner. If the microservices team has a fully automated development, deployment, testing lifecycle, then the governance platform should support that lifecycle implementation without hindering the same. These APIs allow such teams to integrate their automated deployments with the lifecycle management aspects of the governance platform so that both parties are accountable. It is good to have at least one step in the lifecycle where manual inspection happens before a particular service is deployed into the production to make sure that we align with the “trust but verify” strategy.
Another aspect of the runtime governance is the ability to send real-time notifications (emails) to the respective parties when there are changes happening on services. As an example, if a service is transitioning from implementation to publish state, the users of similar services (or users of the previous versions of the same service) can be notified via the platform automatically so that users can reap the benefits of this new service in no time. The same can be applied for certain activities like deleting an asset so that there are additional security measures taken for harmful actions by responsible people.
Security of the governance platform
One of the key aspects of governance is the security of assets (services) that are maintained by the platform. Users can be residing in an enterprise user store like LDAP, AD, or in a database that is connected to the governance platform. According to the requirements of microservices teams and overall company needs, roles are defined with a given set of permissions. These permissions define the activities that the respective users can perform on the governance platform. As an example, a user with the developer role will not be able to change the lifecycle of a service from implementation to publish state. But a user with a product manager can do that after verifying the necessary details. Similarly, if there is a requirement to logically isolate the assets across different business units, multiple tenants can be created and maintained in their own repository without any interference from other teams.
That is all for the third part of the microservices governance tutorial. We will discuss how microservices governance relates to API Management in the final article here.
