Governance is a dirty word for most developers, but it's a necessary evil for large enterprise applications, regardless...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
of how they are built and deployed. Using microservices and cloud service containers doesn't change this.
The chief reason that governance is so reviled is that it adds process overhead and complexity that developers perceive it to be of little value in their focus on one piece of a larger project. Indeed, as the application gets more sophisticated, with more and more interdependent subsystems, the governance overhead can be stifling as each module adds dependencies that affect many others. Centralizing governance for such large, interconnected projects can significantly slow the introduction of new features and frustrate individual developers who don't see the bigger picture.
What if there was a way to employ a decentralized governance model in which a limited amount of overhead was applied to individual code modules? Among its other benefits, microservices architecture offers this possibility. Breaking down large, monolithic applications into bite-sized pieces not only improves product agility and responsiveness to changing requirements, but it can significantly reduce the burden of complying with enterprise standards and policies.
A microservices approach in which applications are designed around tightly framed functional elements with standard interfaces and a modular, often container-based deployment model allows for decentralized governance in which many requirements can be limited in scope to the component and its interfaces. Processes and controls not relevant to a particular microservice are of no concern or burden to the developers of that component.
Distributed governance is analogous to the efficiency and adaptability of regulated capitalism with millions of independent actors working within a rule-based system toward individual goals versus a centrally planned authoritarian economy. In both cases, decisions can be pushed to the lowest possible level, and every change need not be approved by central planning. Decentralized governance enables experimentation and the rapid introduction of new features and bug fixes using a continuous integration and delivery (CI/CD) process. However, focused, streamlined governance doesn't imply zero governance. Enterprise applications are no place for chaos and tribal warfare, so we'll examine some categories, techniques and tools for microservices governance.
Elements of microservices governance
A core tenet of enterprise architecture is standardization and reuse; however, in traditional designs, these are typically applied to software code via centralized repositories, language choices, interface and coding standards, and code boilerplate or templates. These elements are still useful in a microservices architecture, but by encapsulating functions into executable components with defined functions and interfaces, the elements also enable moving standardization to higher levels of abstraction by facilitating the reuse of microservices in different applications. However, service reuse requires that developers have a consistent way to register and find services, standards for service composition and APIs, a place to centralize service configuration and manage deployments, and a consistent method for logging and collecting performance, usage and error metrics.
Another form of microservices governance is applied to running workloads in which IT operators must define and manage resource usage and limits, workload scheduling and placement on physical systems and network connectivity and security policy. When using microservices that can automatically scale to meet capacity demands and where an enterprise may have scores of different components, policy enforcement itself must be applied automatically. Indeed, an important part of operations governance also entails having a central registry describing the composition and location of all running microservices.
Each category of microservices governance has different constituencies, requirements and automation tools.
1. Services, templates and component reuse are elements that are managed by a microservices registry. Registries provide three essential functions: a central repository for microservice container descriptions, images and functional service descriptions. Registries are searchable, allowing applications and other microservices to discover available components and working with service orchestrators or cluster managers (like Kubernetes) to deploy new microservice instances. Most container suites (like Docker, CoreOS Quay or Apcera) and cloud container services (including Amazon Web Services, or AWS, and Azure) include a registry with interfaces that allow it to be integrated into a CI/CD development pipeline.
2. Interfaces for both application programmers, i.e., APIs, and infrastructure communications, i.e., network parameters (addressing, virtual LAN, ports), and security. Developers are most interested in APIs where a conventional governance method employs an API gateway that aggregates interfaces for multiple applications and can expose, manage and control APIs designed for different clients such as mobile devices, browsers or internet of things endpoints. The major cloud services including AWS, Azure and Google Cloud offer API gateway services, as do most on-premises software products.
While an important aspect of microservices governance, network interface details and the management of policy are not something developers typically are concerned with since these are ideally transparent to the underlying service. Security is a possible exception, which is why microservice governance must include well-communicated standards for communication protocols with developers understanding that services can only communicate via published APIs over standardized protocols (like HTTPS).
3. Deployment governance is highly dependent on the platform; however, most microservices use application containers where the container platform will have an orchestration system to manage workload placement. Container orchestrators -- often called cluster managers since they can simultaneously deploy across a cluster of systems -- typically include a policy engine that controls resource usage and container placement based on application-specific rules with different policies for development, test and production workloads.
Microservices using container infrastructure enable a distributed, hierarchical governance model that provides a balance between central policy with local implementation and enforcement that significantly improves agility without sacrificing control. By partitioning responsibility both vertically between developers and IT operations teams and horizontally across different applications and component functions, microservices provide finer control over policy without burdening developers with layers of process overhead and red tape.
In the future, microservices may embed governance features that would allow other services to validate the functions, data and protocols provided before incorporating them into an application. An open source project called Republic (available on GitHub) is such a service designed to validate other services as legitimate "citizens" that comply with the protocols and behaviors required for a particular application.
What does microservices governance require?
How microservices architecture impacts IT
How containers add pep to old apps
Quiz yourself on the impact of microservices