Microservices Governance

Introduction

In the Microservices world, developers have the freedom and capability to experiment with new languages, patterns, frameworks, data stores, and other innovative aspects of IT development. This can result in the operations team feeling a level of discomfort when confronted with new experiments done by the developers.

Various views exist in regard to Microservices architecture having no governance or thin governance compared to service-oriented architecture (SOA).

What is a microservices governance?

Microservices Governance is a methodology or approach that establishes policies, standards, and best practices for the adoption of Microservices to enable an enterprise agile IT environment.

Governance with monoliths is centralized. Decisions are made top-down, rigid control is maintained to ensure standards are in place across the organization and within the application stack. Over time, this model degenerates, creating a stagnant technological and architectural system, thus minimizing innovation.

Microservices promote a polyglot model regarding technology stacks for supported languages, tools, and data stores.  The main concept of these Microservices is the reusability of assets and tools which can be decentralized. The core theme of decentralization governance is the concept of building and running it.

This decentralized model is best suited for Microservices governances. The benefits of decentralized governance give Microservices teams the freedom to develop software components using different stacks. 

The microservices governance framework

Based on experience and adoption of Microservices, the Microservices governance framework emphasizes the following:

Business

• Strategic alignment of IT with Business: Derive the IT mission to align with the vision of the business.
• Reusability of services and quick-time-to-production.

Technical Components

• Microservices Reference Architecture: An architecture guideline for service design and integration with enterprise usage systems, etc.
• Identifying, specifying, creating, and then deploying Microservices through DevOps methodology.
• Enterprise-wide service policies, common infrastructural services.
• Developing fine-grained services by composition and orchestration.
• Service monitoring and management: Management and monitoring of access policies, Quality of Service (QoS) metrics, and KPIs to gauge throughput and performance.

Organizational

• Establish a dedicated Microservices enterprise to govern effective management
• Enterprise structure which delegates who will authorize critical decisions in regard to the Microservices adoption and usage
• Establish standards on how decisions will be made, implemented, and monitored

Elements of microservices governance

Microservices Governance plays a critical role in the success of Microservices initiatives.

The failure to implement proper governance mechanisms can result in an unmanageable and unstable architecture; however, with the correct governances in place, you can avoid the distributed mess of services while gaining the business's support.

A Benefit of Microservices Governance is the fact that it results in a significantly higher return on enterprise investments. However, for return on investments, it is crucial to establish policies along with clear communication channels where accountability and effectiveness can be measured.

A strong Microservices Governance foundation contains three elements: people, process, and technology. For a successful functioning Microservices governance, these three elements must align.

The following diagram demonstrates these elements:

Guiding principles for microservices governance

It is crucial for every enterprise to define guiding principles for Microservices governance. Once these principles are defined, they then need to be followed. Therefore, defining these principles takes place prior to establishing the foundation.

Below are a handful of fundamental guiding principles for a successful Microservices governance.

Independent Services: Microservices are independent of all other services. Independence of services enables rapid service development & deployment. Requires both design & runtime independence of services.

Single Responsibility: Focuses on one. Requires business function, decomposition into granular.

Self-Containment: Microservices are self-contained, independently deployable units. In order for a Microservice to be independent, it needs to include all necessary building blocks for its operation contained within.

Policies & Best practice guidelines: Compliance with Microservices Domain Reference Architectures, Governance Processes, and Roadmap.

People for microservices governance

The Microservices architecture team is focused primarily on managing and monitoring the enterprise activities, which includes designing the enterprise application based on Microservices technology. The team provides the right function to end-users and the appropriate operational support for the new architecture.

Microservices Organizational Model

In enterprise-level Microservices adoption, the team structure and skills play a major role rather than the underlying technology. Flat organization structures, flexible teams, and cross-functional abilities are crucial to the success of Microservices adoption.

Forming a capable, skilled team requires realigning staff around functionality rather than architecture.

Establishing a DevOps practice before transitioning to Microservices is the best approach which helps in determining communication strategies in advance.

Skill & Competency 

Microservices teams consist of various members with different skill sets. The team consists of system analysts, UX/UI designers, backend and frontend developers, etc., who are responsible for their Microservices project from end to end – development, deployment, operations, monitoring, and management.

The size of the team is determined by the size of the enterprise along with the project being developed. Experience shows the ideal size is 8-10 people per team.

In Microservices architecture, the growth of the business will scale the Microservices team. Every team will have a collaborative platform to complete objectives for the project. This ensures deadlines are met, leading to a more efficient and effective product launch.

Microservices Strategy & Roadmap

DevOps Strategy: Reducing the development to deployment cycle time is crucial. Rather than deploying one application, the team will deploy multiple services.

Agile Environment: Services are developed by teams in increments; short phases allow the team to release frequently. This strategically positions the businesses progress. CI/CD should be followed to increase the level of resilience.

Data Strategy: A robust Master Data Management strategy is required to support the distribution of the data. Consumption of Core data of an enterprise, done by multiple Microservices which are stored in their local databases.

Technology for microservices governance

Reference Architecture

Microservices is not a product, framework, or platform. It is a strategy for building large enterprise distributed systems—microservices architecture benefits enterprises in multiple ways. Advantages of Microservices include independent scalability of diverse application components to faster, easier software development and maintenance.

The sizing of the Microservices is critical for the design of quality services. Microservices reduce vendor lock-in and eliminate long-term technology commitment. Overall, helping decision-makers choose the tools needed to meet IT and business goals.

Microservices Reference Architecture

• Provides ready-to-use blueprints for building Microservices-based systems, speeding – and improving – development.
• Create a platform for testing new features, whether developed internally or externally.
• Help understand partner systems and components to enterprises to gain a holistic perspective on the Microservices ecosystem.

Registry

As the enterprise grows, tracking the number of Microservices can be a challenge due to their continuous deployment. To solve this challenge, the usage of dynamic registries will help by tracking the deployed services. These registries provide consumers with lookup addresses to monitor services easily.

Tools

When building a highly scalable architecture using Microservices, tools are required to manage additional services and application components, which include: 

• Service discovery tools, e.g., Kubernetes.
• Packaging standards for containerizing applications, g., Docker, and orchestration tools for replicating containers at scale, e.g., Kubernetes. OpenShift by Red Hat includes both of these proven open-source technologies.
• CI environment creation tools, Jenkins or Shippable for Docker and Kubernetes.
• Dependency resolution tools, e.g., Nexus.
• Failover and resiliency tools, including libraries such as Hystrix and Ribbon.
• Service monitoring, alert, and event tools, e.g., ELK (ElasticSearch, LogStash, and Kibana) stack.

Cloud & API

API is used to establish the interaction between the Microservices, which helps the application to work properly. In addition, the version control mechanism establishes the services interface between new and old services.

Infrastructure Management

Infrastructure management monitors storage, CPU consumption, memory consumption, and hardware network characteristics for deployed services. Infrastructure resources are monitored by Nagois, which raises alerts whenever service levels are breached. If a service is deployed on an IAAS or PAAS platform, then the respective cloud or platform management tools are used. 

Service Monitoring

Service monitoring happens when the application service deploys for uptime and monitors the health. Services can report their health by Pull mechanism via JMX or exposing an HTTP URL where the agents can collect the statistics, using Spring Actuator Push mechanism.

Process for microservices governance

Federated Teams & DevOps

In Microservices environments, developers continuously add and remove functionalities. These changes can consist of a change to the code or replacing core elements of the application. While these changes take place, Microservices constantly evolve. An application is broken down into multiple interdependent services. Large, siloed teams are broken into small, multifunctional teams.

This coincides with the progression from development, testing, and IT that are transforming into smaller DevOps teams. It is efficient to have the team who built the Microservice own its implementation and maintenance. This benefits the current functioning and future evolution of the service.

Design Time Independence

Defining and controlling the service creations, design, and implementation of service policies.

Runtime Independence

SLAs, throttling, monitoring, common security requirements, and service discovery are not covered at each Microservice level. API Gateway helps to realize Runtime governance at a dedicated component level.

Data Management

Unlike SOA, Microservices do not share data. Each Microservice has a separate physical data store and polyglot persistence which allows a variety of database engines to run under each Microservice.

However, maintaining multiple copies of an enterprise database can increase licensing costs and complexity. 

Generic extract, transform, and load (ETL) or data virtualization tools can help with data normalization, event sourcing is a well-known design pattern that helps align data stores to adjust to retroactive changes.

Conclusion

In summary, Microservices adopt decentralized governance, these standards enable the team to efficiently build and deploy the code that has been created according to individual governance plans. The goal of decentralized governance is to free dev teams, allowing them to allocate time to solving development problems effectively within a timely manner.

It is important to develop a DevOps mindset within the enterprise. This mindset empowers developers to control how their governed components are built and operated.