3 ms·
Great article, but I'd like to dispute one point: > A new version of the subscriptions service may store data in the subscriptions database in a different shap
by adambyrtek 9y ago
Great article, but I'd like to dispute one point:
> A new version of the subscriptions service may store data in the subscriptions database in a different shape. If you are running both services in parallel, you are running the system with two schemas at once.
Microservices should manage their own separate data stores and communicate with others through a well-defined API. Only then services can evolve independently, and each team is free to change the internals (including schema migrations) without coordinating with everybody else.
Multiple services sharing the same database is the perfect example of the "monolith in disguise" anti-pattern mentioned in the article, with all of the costs of microservices but few benefits.
- paulddraper 9y agoThey might be talking about a slow rollout.
- adambyrtek 9y agoIf that was the case then it wouldn't be anything specific to microservices.
- dwmkerr 9y agoHi Adam, Thanks for the point! In this case I meant more the situation that the same service (single service, single DB) might be running with more than one version concurrently (during a rolling deployment, or a canary deployment etc) which can lead to issues. The other case is that if services depend on an old contract there could be times where teams might run multiple versions of a service to allow different APIs to be used, rather than a single version of the service which exposes all current compatible APIs. Although to be honest, this is an issue with any service.