Microservices versioning best practices

Question

I read the Susan Fowler's book "production ready microservices" and in two places (until now) I found

• (page 26) "Avoid Versioning Microservices and Endpoints",
• "versioning microservices can easily become an organizational nightmare" (page 27),
• In microservice ecosystems, the versioning of microservices is discouraged(page 58)

Anyway, I used all types of versioning for all kind of different projects: git tag, deb package versioning, python packages versioning, http api versions and I never had very big problems to manage the project's versions. Beside of this I knew exactly to what version to roll out in case of some failures or bugs from customers.

Anybody have any clue why in this book the microservice versioning is so blamed and what advises would you have regarding the topic?

Answer 1

Are you sure that she was not talking about incorporating the version into the name of the service or into the name of the endpoint? Service called OrderProcessing_2_4_1 with a versioned endpoint of get_order_2_4_1 is a very bad idea. OrderProcessing_2_4 with a versioned endpoint of get_order_2_4 is a little less evil but still problematic.

if your calls to microservices have to address endpoints that have a version number in the name, you will have a maintenance (and production) nightmare every time you change a service. Every other service and client will have to be checked to change any reference to your updated service.

That is different from having versions for your API, code pr services. Those are required if you are going to actually get many of the benefits of microservices.

Your orchestration function has to be able to find the right version of the service that matches the client's version requirements (Version 2.6.2 of client "Enter New Order" app requires service "OrderProcessing" that is at least version 2.4.0 in order to support the NATO product classification).

You may have multiple versions of a service in production at the same time (2.4.0 being deprecated but still servicing some clients, 2.4.1 being introduced, version 3.0.0 in beta for customers who are testing the newest UI and features prior to GA).

This is particularly true if you run 24/7 and have to dynamically update services. The orchestration function is the place where services and endpoints are matched up and when you introduce a new version of a service, you update the orchestration database to describe the versions of other services that are required. (My new Version 2.4.1 of OrderProcessing requires the a version 2.2.0 or later of the ProductManager because that was when the NATO Product Classification was added to the product data).