How to keep multiple microservices updates in sync?

[Vasu]

Hello everyone,

I work at a company (enterprise software) who does microservices. We have a about 30 or so microservices as of now and it seems like we cannot update 1 service independently without other services breaking.

For e.g. if we want to implement a feature, we usually need to update 2 or sometimes 3 services simultaneously for that feature to work. Hence, as different teams are delivering their part of the feature on different timelines we have some difficulties in synchronizing the deployment of different services such that our system is stable.

I was just curious and wanted to know if others have seen such problem and how they might have solved it?

P.S we are trying to solve the problem using feature flags. All the code for some feature which spans across services would have to be under a feature flag. Hence only after all services has finished developing their part of the feature, we can enable the feature flag.

[Chris Richardson]

Vasu,

This is an important issue.

In those situations where changes span multiple services then using feature flags to enable a feature make sense.

However, an essential characteristic of the microservice architecture is that the services are loosely coupled.

If you are regularly needing to change multiple services in lockstep that's an indication that your services are tightly coupled.

I'd explore ways to redraw your service boundaries so minimize the frequency of lockstep changes.

Sometimes this is as easy as reducing granularity by using the Service per team pattern: https://microservices.io/patterns/decomposition/service-per-team.html

Another common refactoring is eliminating Data Services and "co-locating" data and business logic.

Here is a recent presentation that I gave on this topic: https://chrisrichardson.net/post/microservices/2020/12/14/designing-loosely-coupled-services.html

I'd be happy to talk more. And, I'm available for consulting :-)

Chris

--
You received this message because you are subscribed to the Google Groups "microservices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microservice...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/594cbc10-c68f-4d13-84c1-5fc87b9e304an%40googlegroups.com.

--

Learn microservices - http://learn.microservices.io

Microservices application platform http://eventuate.io

Consulting and training http://chrisrichardson.net

[Dimit Chadha]

Yes, I totally agree with Chris. Microservices should behave like a lonely island , habitat of isolated breeds. - LOL. 

Any changes in one microservices should not impact others. For intercommunication among microservices , either use messaging systems like Kafka or if in java use Rest template , no other means strictly. 

To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/CAA9exRuAWg_h0gBpq1R5J1CUUGcuqbfB0qsBcVXyyUsriMdh-w%40mail.gmail.com.

--

With Best Regards
Er. Dimit Chadha

Dimit....@gmail.com

+91- 9818550874

[Ant Kutschera]

We use feature toggles and backward compatible APIs so that we can roll out bigger features across multiple services. This allows us to develop, deploy and test them independently. To "release" the feature we just need to do one final acceptance test for which the toggle is live, and then make it live for everyone, when the test is successful.