What is a Microservice Deathstar?
When configuration management shifts to runtime, the microservice deathstar shows a visual depiction of that process. Yes, that phrase again, but what is it exactly?
“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 to 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 linkage of external libraries and resources occur. 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. So 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.
Amazon and Netflix Deathstars
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 allows 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 a configuration management of deployed objects at runtime.
Navigating the Microservice Deathstar
Let us be clear, the microservice deathstar itself is not the problem, it’s how we navigate and understand it 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 Microservice Map
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 independent 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, an 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.
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.
Get Started with DeployHub
To begin tracking your microservice deathstar, sign up with DeployHub Team. This option is based on the open source Ortelius Project. It is provided for free and hosted for high performing development teams who want to manage Services in the new modern architecture.
- DeployHub Team Sign-up: The hosted team version can be used to deploy to unlimited endpoints by unlimited users.
- This Jenkins Demo Video shows how DeployHub interacts with the Jenkins pipeline (including the blue ocean visualization).
- Get Involved in the OS Project. Help us create the best, open source microservice configuration platform available at ortelius.io.
We empower development teams with the ability to catalog, configure, version and deploy microservices and reusable components in both a legacy and modern architecture. If you want to migrate to microservices, ask us. We can help.
About the Author
Tracy Ragan is CEO of DeployHub and serves on the Continuous Delivery Foundation Board. Tracy was a consultant to Wall Street firms on build and release management for 7 years prior to co-founding OpenMake Software in 1995. She was a founding member of the Eclipse organization and served on the board for 5 years. She is a recognized Thought Leader and has been published in multiple industry publications as well as presenting to audiences at industry conferences.
- Versioning your Deployment Configuration for a Single Source of Truth
- Domain Driven Design using Microservices
- Migrating to Microservices – Step 1: Define your Domains – Whitepaper
- Microservices and Components
- DeployHub’s Version Engine
- Drive your Deployment Process using the Jenkins Continuous Deployment Plug-in
- Track Component to Endpoint with a Feedback Loop
- Interact with the Jenkins Pipeling – This Demo shows how (including the blue ocean visualization).
- Get Involved in the OS Project – Help us create the best, open source continuous deployment platform available.
- DeployHub Team Sign-up – Our free and hosted Team version deploys to unlimited endpoints by unlimited users.