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.