Microservices versioning best practices

user_1526119 0
Viewed 5872

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?

microservices versioning architecture
2 Answers

The author of the book is correct in that it is difficult to update the version of an API, especially if it is popular. This is because you will have to either hunt down all the users of the older version and have them upgrade or you will have to support two versions of your software in production at the same time.

But you should still version your API's, IMHO. Just never change the API version. The reason you should probably support a version in your API is because you never know when you may have to change it. So add version but you should avoid every changing it. On many cases it is easier to bring up a new API or extend an existing API in a way that does not break the current version contract.

BTW, in the future you never know when new technology or design patterns will materialize that will allow two versions of one API to easily exist on the same software instance in production in a very elegant way. If and when something like this comes out, then you may see more version changes in API's.

user_14903220
Related