Microservice Versioning

Question

What is the best practice to adapt for versioning in a Microservice Based Architecture, in terms of supporting multiple versioned deployment of the same service during runtime a

Answer 1

you can mix and match of different stretagies

For Major changes you can use Routing based versioning

For other you can use Adapter Based Versioning

Answer 2

What is the best practice to adapt for versioning in a Microservice Based Architecture

One strategy that I use in my microservice project is to version through routing.

We use JSON RPC 2.0 so it's a little different from REST but it can be applied.

We only use major versioning and try to live with the old and the new version at the same time to let the time to consumer to be updated.

Things to take care of

• Avoid having more than two versions of a service in production (really hard to manage if you have some model updates).

• Find a way to tell the consumer that the version there are using is deprecated.

I know that some microservice architecture lives without versioning but it means that you have a strong coupling between consumer and producer so I may not recommand this approach.

To answer the second question

how the consumers would be able to use different versions?

It sounds not possible because a consumer should only use one version at a time.

If you want it to know that the version is available to use it at runtime you can walk through feature flipping coupled with a service discovery.

Your consumer will ask regularly to a service discovery if the route x exists. If true then use the feature, otherwise continue with the current version. It could works but it is kinda tricky to manage.

Answer 3

I think it is safe to say that as of now it is not a solved problem. In a Microservice Architecture, each service should be loosely coupled. If when you change a producer, you have to hunt down consumers to change them too, then it indicates that you have a design flaw. The routing based versioning presented in the link seems to have much more than a "few drawbacks".

Should you version the entire service or just the api?

If you version the entire service, you will invariably open quite a can of worms. Imagine that you implemented the first version (v1) of a service A. Imagine now that after a while, a new version (v2) had to be implemented because of the business. What happens if a bug is discovered on the v2 of this service? The team should check that the same bug doesnt exist on v1 too. If it does, v1 should be corrected and redeployed too. Even if it is just copy and paste, both versions need to be retested and redeployed. And what if there was refactoring between versions and the way to fix v1 is diferent from the way to fix v2? And what if instead of 2 versions, there are 5 or 10? Someone funnier than me should make a "That scalated quickly" meme for this.

Just by scratching the surface of how much headache this option could give, we basically can already decide by versioning just the api. But basically if you version your service on the code level:

1. The team just has to support one version of the service (bugs are just corrected once)
2. Less cognitive drain on the team for not having to understand tons of different and potentially very distinct versions of the service
3. Less resource consumption
4. Garantee that everything is consistent between versions (if not a garantee, at least it is much more probable)

How the client communicate what version of the api they will consume?

For this answer, I will refer only to REST apis because its what i know enough to talk about. There are basically 4 ways of versioning the api (that i can think of):

1. Versioning the URI: "http://host/serviceA/v3/whatever"
2. Version in the Accept Header
3. Version in Custom Header
4. Version as parameter

This tutorial will explain each one of these with their drawbacks better than me, but basically anyone of these should do just fine =)

How (the f*****g hell) do I sustain inumerous service versions in the same code? (are you crazy???)

Your service per se is just one. What you should do is apply Adapter Design pattern, so as to exist different versions of ins and outs interacting with the business layer of your service. This way you just have some versions of some objects, with it being transparent to the core of the service. It is the same conclusion of the article mentioned in the question, and it even has a neat example to showcase it.

Answer 4

There is no best practice. It's going to depend on how versioning should work in your specific case.

Shawn Wildermuth discussed about api versioning in a pluralsight video. Not sure about your microservice implementation details, but if you are using rest api, you may try the versioning the actual payload

You could also do this with an Accept header. Accept allows for you to annotate the Accept header with a version type against the API you want to look at. And you can also do this with content type as well. The application/vnd for vendor specifies the version of the returning data, so that when the application then sends it, it knows what version of the payload it is. And this is an important technique in versioning, because you have to version both the API, the actual URI calls, as well as the shape of the data that's coming back.

If you find a mechanism that works well in your environment and with your customers and users, go ahead and use that.