Backwards compatibility in Microservices

As stated in the previous posts, a side effect of designing a system using microservices is that you end up having tens and hundreds of services that you need to keep operational. When you deploy a new version of a service that contains a bug fix in particular service, or when you want to improve another by adding a feature to it, the ‘system’ as a whole would still require to be functional. But how do you ensure that?

The problem is that if there is a fault at one of the services, other services communicating with it may fail and this would end up having a domino-effect bringing down the whole system. Furthermore, what if due to that bug-fix or enhancement, you need to update the service interfaces of that microservice. This would be a breaking change so any other service relying on it won’t be able to communicate with it anymore and would have to update.

Is it possible to spend time and resources to run the new release (of the whole system) in pre-production environment? To simulate things running in production, now you’d have to have two sets of production environment, which would have running and maintenance costs.

Kargar & Hanifizade (2018) advise that “the microservices must have backward compatibility, so that each version of microservices must also support the previous version inputs” and this can be enforced with the use of regression and integration testing.

References
Kargar, M. J., & Hanifizade, A. (2018, 25-26 April 2018). Automation of regression test in microservice architecture. 2018 4th International Conference on Web Research (ICWR)

Leave a Reply

Your email address will not be published. Required fields are marked *