3 ms·
I don’t see how this is a problem. I see that the combinatorial explosion exists, but that isn’t an actual problem. The entire point of microservices is indepen
by ewindal 7y ago
I don’t see how this is a problem. I see that the combinatorial explosion exists, but that isn’t an actual problem. The entire point of microservices is independent deploys, meaning you literally only have two permutations per deploy, new and old. If you think deploying 10 services at once is feasible, you don’t understand the appral of microservices, and should never have opted for them in the first place.
- taleodor 7y agoDeploying one at a time may be fine if you always test that each one is working in backward compatible manner. However you still have same search space and same problem as before. Imagine a - you have 10 microservices, 1 update per each. Each supposed to be backward-compatible. You start rolling out. One by one. 5 go fine, 6th breaks. You end up in a weird state where 5 out of 10 are updated. You hope it's fine due to backward compatibility but you never really tested this config exactly. (Which is why I might prefer either converging to deploying all 10 or rolling back fully - if that was a known good state - and having canary cluster rather than canary microservice in many cases). b - same as above but now you try to catch this behaviour on test / staging. You still have same hard problem at hands. Key here is you clearly can't try every possible variation of what may break, so need to make conscious decisions about what to do in the case of failure.