How to keep track of multiple versions of assemblies?

Question

We're deploying microservices to azure service fabric.

How do we keep track of multiple versions of our services?

How we will allow multiple versions of the services in production:

1. consumer is issued a token
2. that token would be sent to the microservice in the header
3. gateway will receive the request and redirect to the version of the microservice that corresponds to the token in the headers

Another words, multiple consumers will be able to hit an endpoint:…./api/accounts(12343), but will be routed to a different version of the microservice depending on their header token.

Do we create separate TFS branches for every version of the microservice? Do we simply create a nuget package repository?

How do we keep track of multiple versions of our services?

Why would we want to keep track of multiple versions?

1. Perhaps we may want to revert to an older version.
   2. Maybe we would need to implement a fix for a client in their specific version.
   3. Maybe we would need a different version of a service because we discovered that there's tight coupling with a different service.

Answer 1

I think trying to keep track of different versions of microservices will end up being frustratingly difficult to do and prone to error.

I would suggest that you modify your approach and deal with your specific concerns in different ways. Possibly expose all of your microservices through a web api, and version the controllers.

In my microservice implementations I do not allow microservices to talk to each other. Instead, I use service bus queues and topics to accomplish cross service communication. In this way you don't have the maintenance and planning overhead of making sure your system doesn't get too coupled, and actually by doing what you're doing you are creating a monolith in my opinion. A microservice should be fully encapsulated and function with the inputs it is given. An email notification service should not be calling out to a user service to get additional user data to craft a custom email. It should either be given that on demand from whatever invoked the notification, or it should be storing that metadata via a subscription to a service bus queue/topic. You will find that you are storing duplicate data throughout your system, but that is okay to achieve the decoupled pattern.

I think some things you can do to alleviate your issues is create unit tests for every public function in your microservice, and leverage a test environment to test before deploying to production. If you do find a problem in production you simply either roll the service back or fix it.

Here's the types of tests I write for all my methods:

Example function: AddOrUpdateUser

Test: Add works
Test: Update works
Test: function fails if required fields were null
Test: function fails if username is shorter than X
etc..

Doing this takes time, but in my experience I have had very very little bugs in production and the ones I had were minor.

Really, testing like this should be done in every app, but doing it in a monolith is just significantly harder. Using microservices you can obtain super high function reliability easily.