Introduction to Microservices Governance — Part II
How to align microservices governance with business goals?
This is the second part of the 4 part article series on microservices governance. We discussed the basic concepts of IT governance and how they related to the microservices architecture. You can find it here.
In this second part of the tutorial, we are going to discuss the different types of governance models and how they related to the business goals of the organization.
Governance capabilities
When it comes to governance in the microservices context, there are 2 types of governance capabilities.
Design time governance
This is where all the policies, lifecycles, standards, best practices, and dependency management capabilities are defined. The teams can have their own versions of these capabilities, but those need to be notified and defined in the governance control plane so that when business leaders need to do some sort of audit or change in business vision, everything is recorded. This also includes aspects like reusability where teams can look for existing fine-grained services before spending time on implementing duplicate services. It also improves the visibility and accountability of microservices teams to the overall business process which can help people immensely when things go wrong.
Runtime governance
These are the governance features that are used in execution time or runtime. Some examples are service discovery where a certain runtime component discovers an endpoint URL by referring to a key that is defined as a governance asset in the platform. Another example is the use of a REST API exposed by the governance platform to change the state of the lifecycle of a microservice during a CICD pipeline execution.
Business goals
At the end of the day, everything we do with microservices and governance needs to deliver results to the business. There can be different goals in different businesses, but some of the common business goals are
- Business vision
- Time to market (speed of delivery)
- Return on investment
- The total cost of ownership
When defining the policies, standards, best practices in the governance layer, and approving them for individual microservices teams, it is essential to align those with the previously described business goals in one way or another.
Let’s try to understand this interaction of microservices teams with the governance platform via a practical example where we have 4 different microservices teams at a given time within an organization delivering different types of services. These teams interact with the governance control plane to make sure things they do comply with the business standards and needs and accountable for the same.
As depicted in the above figure, there are 4 microservices teams developing services of various domains and functionalities. These teams have their own choices for
- Programming language/runtime
- Release strategy
- Delivery lifecycle
- Source code management tools
- Number of team members
- Service category
This shows that individual teams can take different approaches to execute various tasks based on their need to deliver the services with the best quality. At the same time, they will interact with the governance control plane to verify the approach and record the same for future references as well as for wider visibility within the organization.
The governance control plane exposes APIs so that these teams can interact with them programmatically with less human interaction. In addition to that, it also provides user interfaces to perform the same set of operations in case if some teams decided to go down that path. Some of the key aspects of governance that can be used in this situation are
- Lifecycle management — Each team can have its own lifecycle stages and transitions with respective roles. At the same time, these details will be captured and governed through the governance control plane. This interaction can be manual or through the APIs exposed by the governance layer.
- Service repository and reusability — While teams developing new microservices with a domain-based design where microservices serve a specific functional capability, there can be certain overlaps in actual implementations. It is good to go through the existing set of microservices before allocating resources to replicate the same functionality. This is where the service repository aspect of the governance layer helps with reusability and improves the overall efficiency of the system.
- Standards/ Policies — While each team can decide on the technologies, release models, lifecycles, there should be a common mechanism to define various aspects of the development process through standards and policies. If it is about API design, then it is good to have a common agreement on which specification is accepted at the organization level since that is a technology-agnostic decision to make. If there are certain certifications (HIPPA, FEDRAMP) that need to be achieved at the organizational level, they need to be honored by all different teams.
- Best practices — This is something similar to lifecycles where teams can have their own best practices based on their technology choices. But it is the responsibility of the teams to publish these best practices at the governance level to make sure those best practices aligned with business goals.
- Dependency Analysis — When things starting to boom on the business side, more and more microservices can be added to the ecosystem and understanding the relationship between microservices and related assets becomes really useful. That is where the dependency analysis can help with visualizing the complex dependencies between various asset types including microservices teams, service URLs, roles, and many others.
- Monitoring / Auditing — Microservices teams cherish the idea of autonomy and it helps them to innovate and come up with new ideas that can transform the business at times. At the same time, there can be many cases that things do not work out. It is the nature of trying out new things. All of these things are acceptable results. At the same time, there should be a mechanism to do a retrospective of the failed projects and learn from those mistakes. That is where the auditing and monitoring aspect of the governance platform can help organizations.
The above-mentioned capabilities of the governance control plane allow the business to align its vision with the work that is done by microservices teams without restricting their freedom and innovation. The above diagram depicts a model called “trust but verify” where you build a distributed governance structure based on trust with the central verification layer.
Let’s dig a little deeper and define 2 lifecycles that are used by one of the 4 microservices teams mentioned above. The first lifecycle is a generic lifecycle to initiate an idea and prove that as a valuable and doable idea. The result of that is spinning off a microservices team. The next lifecycle defines the service release process of a given microservices team.
On the left-hand side of the above figure, you see a lifecycle that is used to convert an idea into a concept and then spin off a microservices team to develop that as a service and deliver it to the consumers. This lifecycle can come from one of the microservices teams. But it is a reusable lifecycle that can be followed by many teams regardless of the technologies they used.
On the right-hand side, you see a typical software lifecycle that involved design, implementation, test phases, and finally deploy and publish as a managed API via a developer portal that is accessible to the external consumers. The Microservices team can implement a CICD pipeline to go over the lifecycle automatically. It can integrate with the governance platform via APIs to update the lifecycle changes on the governance layer. That will make sure that every release is tracked and passing the required governance requirements before going into the production environment.
This lifecycle can be different in another team. With the central control plane, architects can always compare these lifecycles with each other and make suggestions to improve based on the learnings from each team.
That is all for the second part of the article. We will discuss how we put all these concepts to a reference architecture in the 3rd part of this article series.
