How to Version Microservices
Microservice version management is becoming increasingly important as we move into cloud-native development, managing thousands of objects that make up the software supply chain. 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?”
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. Now, we 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 issues. One of the most common questions is, “How do I know what version of a service is running in any single cluster?“. The answer to this question is microservice versioning.
Versioning helps keep track of microservices as they change over time, deployed across multiple clusters, and how they impact the consuming applications. This article reviews how to version microservices, strategies and best practices, and critical features for versioning container content.
Article Contents:
- What is a Microservice?
- Defining Microservice Versioning
- How Versioning Addresses Microservice Drift
- Best Practices for Microservices Versioning
- 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 the reason 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 to see 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, which continues to be one version behind.
Most DevOps engineers will tell you when they have a new version of a microservice to release, and they will deploy it to all locations simultaneously 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 the clothing store website SRE chooses to stay a version back.
Finally, we need to think in terms of supporting Development, Test, and Production stages and understand which versions of the microservice are running in each. To do this, we use microservice versioning, which allows us the flexibility to support different versions running in different clusters.
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:
- Best Practice #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.
- Best Practice #2: Don’t change the name of your microservice, only update the image value with the image tag in your Kubernetes deployment file.
- Best Practice #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.
- Best Practice #4: Use the Git Commit SHA in the semantic versioning number. This helps connect back to the developer’s change.
- Best Practice #5: Logically track the microservice’s consuming applications as part of your versioning strategy. Using this best practice will give you a clear picture of their impact.
- Best Practice #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.
Microservice Version Management with DeployHub
DeployHub is used to simplify the complexities of cloud-native development, with built-in microservice versioning 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 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
DeployHub uses the concepts of domains, environment, application, and component to provide the framework for managing services in their containers. Some of these terms we have seen before, like environment and application. However, terms like domains and components are new concepts that relate to how your microservices are organized.
To ensure we are all on the same page, the term environment is a collection of endpoints where your application will be deployed. Most traditional Application Release Automation solutions use these terms and concepts for 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 front-end 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’. A domain 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, which is critical to versioning container content.
Closing Out: How to Version Microservices With DeployHub
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 for microservice version 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.