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, SBOMs, CVEs, licenses, swagger details, consuming applications, and deployment metadata. 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 about 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.
