Skip to main content
Microservice Version Management

Microservice Version Management

How to Version Microservices

Microservice version management is becoming increasingly important as we move into cloud-native development where we are managing thousands of objects that make up the software supply chain. Just ask yourself “what does the future look like when I’m managing and tracking 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 to track and version microservices. 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 the monolithic build 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. One of the most common questions that we hear is “How do I know what version of a service is running in any single cluster?“. The answer to this question is microservice versioning – keeping track of microservices as they change over time, deployed across multiple clusters, and how they impact the consuming applications.

In this article, we review how to track and manage microservices versioning, strategies and best practices, and critical features for versioning container content.

Article Contents:

  1. What is a Microservice?
  2. Defining Microservice Versioning
  3. How Versioning Addresses Microservice Drift
  4. Best Practices for Microservices Versioning
  5. Microservice Version Management with DeployHub

What is a Microservice?

Before we get to microservice version management, let’s start from the top. What is a microservice and how do we decompose a monolithic application into Services?

Defining a Service

Here’s 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 services with minimal collaboration with other teams.   

With microservices, we let go of the concept of monolithic software applications and linear pipelines. We instead have a non-linear configuration of different microservices 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 microservices versioning is important.

What is Versioning in Microservices?

In microservices, ‘versioning’ means tracking not just the changes in your container, but all of the attributes of the service including key-value pairs, CVE, licenses, swagger details, consuming applications, and deployment scripts. The ability to track and manage versions of microservices is critical and the only way of seeing the changes between two versions of the same microservice. 

Microservices 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. They continue to be 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, canary or rolling 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 website SRE choose to stay a version back.

Finally, we need to think in terms of supporting Development, Test, and Production stages and be able to understand which versions of the microservice are running in each. To do this, we use microservice versioning which allows us the flexibility needed to support different versions running in different clusters.

Best Practices for Microservices Versioning

How do we version microservices to improve upon their use and success in building microservice applications? Important to remember in versioning microservices is that they are deployed independently and frequently. Second, a microservice is more than just a container image. It has many attributes that need to be versioned and tracked. The following best practices should be considered when defining a microservices versioning strategy:

  1. The attributes of your microservice go beyond the contents of your container. Versioning the CVE, licensing, Swagger details, Key-Value pairs, deployment logic, and endpoint configurations are all part of your microservice’s configuration and should also be versioned and tracked.
  2. Don’t change the name of your microservice, only update the image value with the image tag in your Kubernetes deployment file.
  3. Logically track a version number for every release. Use semantic versioning. Calendar versioning can get confusing if a service is changed multiple times in a single day.
  4. Use the Git Commit SHA in the semantic versioning number. This helps connect back to the developer’s change.
  5. Logically track the microservice’s consuming applications as part of your versioning strategy. This will give you a clear picture of their impact.
  6. Include a snapshot of your service to service API endpoint relationships.

Versioning microservices goes well beyond registering them to an image repository. The more data you can include in your versioning strategy the better.

Best Practices for Microservices Versioning

How do we version microservices to improve upon their use and success in building microservice applications? Important to remember in versioning microservices is that they are deployed independently and frequently. Second, a microservice is more than just a container image. It has many attributes that need to be versioned and tracked. The following best practices should be considered when defining a microservices versioning strategy:

  1. The attributes of your microservice go beyond the contents of your container. Versioning the CVE, licensing, Swagger details, Key-Value pairs, deployment logic, and endpoint configurations are all part of your microservice’s configuration and should also be versioned and tracked.
  2. Don’t change the name of your microservice, only update the image value with the image tag in your Kubernetes deployment file.
  3. Logically track a version number for every release. Use semantic versioning. Calendar versioning can get confusing if a service is changed multiple times in a single day.
  4. Use the Git Commit SHA in the semantic versioning number. This helps connect back to the developer’s change.
  5. Logically track the microservice’s consuming applications as part of your versioning strategy. This will give you a clear picture of their impact.
  6. Include a snapshot of your service to service API endpoint relationships.

Versioning microservices goes well beyond registering them to an image repository. The more data you can include in your versioning strategy the better.

Microservice Versioning Whitepaper

Microservices at scale offer new challenges in managing your software supply chain. DeployHub is solving the challenge through microservice versioning.

Download

Microservice Version Management with DeployHub

DeployHub is used to simplify the complexities of cloud-native development, with built-in microservice versioning that is designed to create a unified view of all your services. Here are some features of using DeployHub for microservice versioning.

  • Unified microservice catalog
  • Features for Versioning Container Content
  • Microservice Organization

A Unified Microservice Catalog

A hosted unified microservice catalog tool simplifies the use of microservices by versioning and tracking them creating a clear picture of the supply chain across all clusters. It was developed to be a central dashboard to show usage, dependencies, deployment configurations, and inventory.

DeployHub’s microservice version management 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 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 saw the following versioning features critical to cloud-native development:

  • Support Domain-Driven Design (DDD) with sub-domains to easily organize microservices
  • Track microservice ownership and details
  • 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.

Microservice Organization

To support microservices organization, DeployHub uses Components and Domains to manage your overall supply chain.

  • 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.

Closing Out: Microservice Versioning

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 our overall software supply chain.

New methods and best practice strategies of microservice versioning management are 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.

Next Post
Close Menu