Skip to main content
How DeployHub Tracks Microservice Versioning?

How DeployHub Tracks Microservice Versioning?

Microservice Versioning for Indispensable Clarity

Microservice versioning is becoming increasingly important as we move into cloud-native development.  Just ask yourself “what does the future look like when I’m managing hundreds of microservices that make up a single version of my software solution?  Let’s just say, you’re going to need more than an Excel spreadsheet.

Microservices are game-changers in terms of how we develop and deliver software. In the past, we have relied on a monolithic approach, with everything moving at the same time because all the artifacts were statically linked in the build process. We relied on version management to track the changes to our binary. We now need to transfer this important information into a microservices architecture, by migrating monolith to microservices.

With microservices, we have independently deployed functions. While solving many problems, this approach also creates its own set of issues.  The primary problem is how to visualize what those individual microservices create over time in terms of the whole base application and subsequent application versions. This is the purpose of microservice versioning.

In this article, we review how to track and manage microservice versioning, and critical features for versioning container content.

What is a Microservice?

Let’s start from the top. What is a microservice and how do we decompose a monolithic application into Services?  I like how Chris Richardson of CloudFoundry fame defines a Service:

  • A service should implement a small set of strongly related functions;
  • Services that change together should be packaged together;
  • The Service can be changed without affecting clients;
  • And, each team that owns one or more services must be autonomous. A team must be able to develop and deploy their services with minimal collaboration with other teams.   

With microservices, we let go of the concept of a monolithic software applications and linear pipelines.  We instead have a non-linear configuration of different points of services that represents the ‘logical’ microservice application. For managing these microservice applications we need to understand what is in this ‘microservices soup’ in terms of ownership, usage, and microservice configurations. We need to see the whole picture, or what we can call the ‘monolithic equivalent.’  This is why microservice versioning is important.

Microservice Versioning Addresses Microservice Drift

As you begin implementing microservice applications, you will quickly learn about microservice ‘drift.’  Drift is created when you have different versions of a single microservice running in multiple clusters and Namespaces. In the below example, all three websites, the candy store, clothing store, and toy store use a set of common microservices including the Shipping service. Notice that ‘drift’ has occurred at the clothing store and they are one version behind.

microservice versioning for drift

 

Most DevOps engineers will tell you when they have a new version of a microservice to release, they will deploy it to all locations at the same time in order to avoid drift.  This is not ideal as it stands in the way of Blue/Green and canary deployments where updates are pushed out in a more methodical way to avoid potential errors. What is needed is a way to track the microservice version along with where it is running to support these deployment models. In addition, in some organizations, not all teams may want to take a new version of a common microservice – at least not a first. There may be a good reason why the clothing store choose to stay a version back.  And finally, we need to think in terms of supporting Development, Test, and Production stages and be able to understand which version of the microservice are running in each. To do this we begin microservice versioning, which allows us the flexibility needed to support different versions running in different clusters.

A Unified Microservice Catalog

DeployHub is a hosted unified microservice catalog tool that simplifies the use of microservices by versioning and tracking them across the lifecycle and all clusters. It was developed to be a central dashboard to show usage, dependencies, deployment configurations, and inventory. DeployHub’s microservice versioning shows what microservice is in a container, who is using it, where it is running, and the microservices relationship to other services. Most interesting is DeployHub’s ability to track a microservice version’s ‘blast radius’ even before you deploy. The blast radius shows who will be impacted if a new version is released.

DeployHub can also versions database updates, environment variables, Kubernetes configurations, infrastructure components, application artifacts, and other critical parts of your software release.

Critical Features for Versioning Container Content

When we created DeployHub, we knew we needed to address the new microservices architecture which included microservice version management.  What we also saw as critical for cloud-native development was the ability to:

  •         Support Domain Driven Design (DDD) with sub-domains to easily organize microservices;
  •         Services are organized based on a ‘business’ or ‘problem’ space;
  •         Encourage re-use and collaboration of microservices;
  •         Support external deployment engines for inventory tracking;
  •         Track a microservice version to a microservice application providing a logical view of all versions.

To provide the framework for managing services in their containers, DeployHub uses the concepts of Domains, Environment, Application, and Component. Some of these terms we’ve seen before, like Environment and Application, but Domains and Components are new concepts that relate to how your microservices 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 organization, DeployHub uses Components and Domains. 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 a frontend microservice and a collection of common microservices.  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) and is a critical feature of microservice versioning, and versioning container content.

DeployHub Team (based on Ortelius open source) is a microservice dashboard that provides you with two levels of Domains – a Global Domain and a Project Domain. DeployHub Pro supports a third level called the ‘Divisional’ Domain.  Components are organized under the Domain structure. This organization is critical to versioning container content.

In 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 microservice versioning management is needed to simplify the complexities of cloud-native development. DeployHub is one such solution. Its microservice catalog with built-in microservice versioning is designed to create a unified view of all your services, who uses them, who owns them and where they are running.

Key Features

Meet the Co-Founders

Get Started

Ortelius Open Source Project

Next Post
Close Menu