It would be difficult to say whether containers or microservices are the hottest topic in IT and application design. That alone makes the governance implications of both concepts critical to IT management, architects, developers and operations specialists.
The good news is that many governance practices can be applied to both concepts. The bad news is that there's a lot of fuzziness in the definition of both container and microservices, particularly in usage, and this can muddy the planning of a governance model. To get it right, define your usage of the two concepts precisely; align your design, development and deployment practices to match your definitions; and make sure you use orchestration tools to enforce your decisions.
Precise definitions are key to understanding a complex issue, and precision is especially essential to application governance. Governance, containers and microservices all have definitional problems, and you'll have to come to terms with your own use of the terminology before you launch your planning.
Governance, in broad terms, is the process of insuring that IT applications, resources and deployments match business goals. This mission is so broad that most companies don't use the term that way, focusing instead on specific security and compliance targets for "governance." It's this lighter-weight term that we'll use as the definition here.
IT governance, in this sense, defines information and application security requirements. In traditional IT, these requirements are often met in a static way by using special platforms and partitioning networks, providing access controls for applications and information based on fixed resource addresses. All these mechanisms can break down when the application-to-resource relationships change dynamically and, more so, when functional elements are shared across applications whose governance requirements are different. In container and microservices governance, the goal is to restore governance without compromising the benefits of the cloud, virtualization and service-based application design. Doing that starts by deciding how your company approaches application design in a container and microservices world.
If you've come to understand virtualization and the cloud from the virtual-machine starting point, you may see containers as being a lightweight form of a virtual machine. If you come at containers from a software design perspective, you may see them as deployable units of functionality -- essentially, the component plus its runtime. If you have an SOA background, microservices may be a modern take on SOA principles. If you come from the web side, they're intended to displace SOA completely. In a sense, SOA is a platform-centric vision of governance and the web presumes an application-centric vision.
From a technical perspective, the key question with governance of containers and microservices is where "governance" as a set of tools or features actually resides. Some believe that it is always an attribute of the platform on which applications are run; governance is an environmental requirement. Others see governance as being derived from the application's goals, policies and security demands.
Combine this divergence with the definitional issue already noted and you can see how governance of container and microservices can be complicated. Your best path to fixing that is to set a definition for yourself and then stick to it across all your applications. Otherwise, your practices will be inconsistent -- meaning ineffective. Consider your options to be either application-centricity or platform-centricity.
Is it application- or platform-centric governance?
Platform-centric governance relies on partitioning for protection first and API management second. Protected information and applications are partitioned at the network level to avoid cross-access by unauthorized personnel or applications, and shared application elements like microservices are accessed through API management tools that enforce access policies across all applications and users.
Many users find partition-driven governance the easiest approach, because it's closest to the way governance is applied traditionally to virtual private networks and private data centers. Containers and microservices are both deployed on governance-ready networks and hosts, and SOA-like principles control application assets. As long as the governance facilities of the platforms are effective, then everything works.
Microservices pose the greatest risk to this model, because shared componentization (while supported via SOA) isn't a common application feature. That's why it's probably smart to adopt API managers to control microservice access even given the potential impact they have on performance. Platform-driven microservice governance should focus on API management, and it might be smart to then think of component management and application composition overall in microservice terms, using containers as only slots into which you deploy things.
An application-centric view of governance, in contrast, cannot presume a single framework for governance. In fact, the presumption is that governance requirements will vary significantly among the applications, so there's little to be gained enforcing a common approach. Where governance needs do exist, it's the responsibility of the application deployment tools (DevOps or orchestration) to enforce it.
The benefit of this governance is that it works with whatever the specific relationship between container and microservices happens to be. You can still bind microservices directly into each application where they're used, rather than requiring they all be shared, but you can also support shared microservices by treating them as separate applications.
DevOps: How does it fit?
The role of orchestration of DevOps in governance of either microservices or containers is critical because these tools form the bridge between governance policies and deployment practices that are responsible to insure those policies are met. Manual deployment and redeployment will always create a risk of an accidental violation, and it can be very difficult to spot these.
DevOps tools used to support governance need to be able to support modular definitions that can be reused easily, especially when an application-centric model of governance supports per-application microservices. Otherwise, inconsistencies in deployment will threaten not only governance, but application stability overall.
Governance is critical to all IT applications and it's something that should be built in, rather than glued on. You have to start your governance deliberations knowing where that building-in process is focused for your particular application, and you have to be prepared to rethink your whole model if changes in how you build and deploy applications emerge as your business changes.
Hadoop system with containers and microservices
Should you combine containers and microservices?