Navigating the Microservice DeathStar With DeployHub

You may also like: Angular Libraries and Microservices

Microservice Deathstar Created when Configuration Management Shifts to Runtime

The microservice Deathstar shows a visual depiction of microservice configuration management. Yes, that phrase again, but what is it?

" In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software...If something goes wrong, SCM can determine what was changed and who changed it. If a configuration is working well, SCM can determine how to replicate it across many hosts."
— Wikipedia

In monolithic development practices, SCM is performed in two ways. First, code is stored in a version control repository. Much of that code is several thousand lines long, is managed using branching and merging, and also represents an entire monolithic application.

The second part of SCM is the build step — compile and link. While most people think of SCM as only version control, the build (compile and link) process performs a key part of SCM, the creation of the binaries.

This is where control over the linkage of external libraries and resources occurs. Once completed, your binary only has lower-level components such as the operating system and version of the database to be worried about. The rest is contained in the monolithic binary.

With containers and microservices, this all changes. Code will no longer be thousands of lines long and the compile and link (if it exists at all) will be very small with relatively no linking. In microservices, the configuration management is left up to the runtime environment where the linkage is resolved.

In other words, think of functions linking via APIs. Where is the configuration management? How do we track application versions and microservice versions? How do we navigate the 'Microservice Deathstar?'

While the Microservice Deathstar is a broad look at our entire universe, we need a method of tracking the different applications that are running inside a single cluster. Your cluster is a collection of Pods that are running microservices. A specific configuration of Pods makes up an application.

If one of the microservices is updated, the application will automatically get the new version. So now the application is a new version. Each time a new version of the microservice is released, your application has a new version, without you knowing about the change. Great, until there is an issue. Then you need to know.

Yes, such Microservice Deathstar diagrams are now part of the conversation and show the depth of complexity in a microservice architecture:

So, if microservices are more complicated than say a standard Service Oriented Architecture, why move to them? The reason is simple. Microservices allow developers to implement changes more safely, efficiently and quickly. No doubt about it. Microservices are the apex of agile software development.

They allow for small, independently deployable services to move freely to production and bring innovation to end users fast. To receive the benefit of microservices, our way of versioning and tracking configurations must shift from a 'version, compile/link' process to configuration management of deployed objects at runtime.

Navigating the Microservice Deathstar

Let us be clear, the microservice Deathstar is not the problem, it is how we navigate and understand the microservice Deathstar that must evolve.

While the microservice Deathstar is a broad look at our entire universe, we need a method of tracking the different applications that are running inside a single cluster. Your cluster is a collection of Pods that are running microservices. A specific configuration of Pods makes up an application.

If one of the microservices is updated, the application will automatically get the new version. So now the application is a new version. Each time a new version of the microservice is released, your application has a new version, without you knowing about the change. Great, until there is an issue. Then you need to know.

DeployHub Versions the Microservice Deathstar

DeployHub is a hosted configuration management solution that catalogs, versions and deploys microservices, tracking the logical view of application version with associated microservice versions. It is designed to be the 'single source of truth' for your microservice Deathstar configurations. DeployHub creates a map of your microservice versions and their dependent applications.

DeployHub versions and deploys database updates, environment variables, Kubernetes configurations, infrastructure components, application artifacts, and other critical parts of your software release. In other words, DeployHub treats your entire configuration as code and versions it.

By versioning these individual parts, DeployHub can reliably report a change, who made the change and the impact of the update. It was designed with microservices in mind but can also support agile teams working in legacy architectures with safe, iterative releases.

Critical Features for Kubernetes Deployments

When we created DeployHub, we knew we needed to address the new microservices architecture. We saw that it's critical for Kubernetes deployments to:

• Group 'like' Services together as a package.
• Support Domain-Driven Design (DDD) with sub-domains allowing Services to be organized based on a 'business' or 'problem' space.
• Encourage re-use and collaboration of Services.
• Perform continuous deployments of independently moving parts.
• Track a Service version to an application version, providing a single source of truth.

To provide the framework for managing Services in their Containers, DeploHub uses the concepts of Domain, Environment, Application, and Component. Some of these terms we've seen before, like Environment and Application, but Domains and Components are new and relate to how your Services are organized.

Just to make sure we are all on the same page, and Environment is a collection of endpoints where your Application is going to be deployed. Most traditional Application Release Automation solutions use these terms and concepts for doing software deployments. To support microservices, DeployHub uses the concept of Components and uses Domains to organize them.

DeployHub defines an Application as a collection of Components. Your Microservices map directly to Components. Your Application could have any combination of Component types, such as application Services and database Services. A Domain is both an object unique to DeployHub and a concept used to organize Microservices based on lines of business or 'problems'.

This is often referred to as Domain Driven Design (DDD). DeployHub Team (open source) provides you with two levels of Domains - a Global Domain and a Project Domain. DeployHub Pro supports a third level called 'Divisional Domains.

Collaborating for Success

As Developers, we know from our experience around Object-Oriented Programming that sharing and collaborating around the use of Services will become critical for their success. We know we're failing when each team begins to contain their application in private clusters and 'copy' reusable microservices into those private clusters.

DeployHub provides a collaboration framework so that your organization can leverage a single cluster with shared services. Services can then be published and shared across teams.

Conclusion

Microservices are changing the way we develop, build, and deploy software. While solving many problems, microservices are also creating new challenges around tracking and versioning the use of Services in large Kubernetes clusters. New methods of managing microservice configurations are required to track what is in the microservice Deathstar.

Further Reading

Creating a Microservices Registry