This looks very similar to Paul Hammant&#x27;s &quot;cookie cutter scaling&quot; pattern (<a href="http:&#x2F;&#x2F;paulhammant.com&#x2F;2011&#x2F;11&#x2F;29&#x2F;cookie-cutter-scaling&#x2F;" rel="nofollow">http:&#x2F;&#x2F;paulhammant.com&#x2F;2011&#x2F;11&#x2F;29&#x2F;cookie-cutter-scaling&#x2F;</a>), which I find equally baffling.  Perhaps I&#x27;ve just never encountered the conditions which are favorable to it, but what I like about microservices is how they decouple every services&#x27; rate of change, and going back to lock-step deploys throws that all away.<p>&gt; In addition, with a monolith, the work of monitoring, alerting, configuration, and a local development is paid once. But with a microservice design, that cost must be paid for every service.<p>The second sentence is only true if _every service_ actually rolls its own monitoring, alerting, etc.  I cannot imagine a situation like that in practice.  The standardization of those things (and more, such as build and deployment pipelines) is necessary to enable microservices in the first place.  It&#x27;s true that plenty of organizations committed to their microservice framework will also run some things outside of it, but I&#x27;ve never seen the ratio of things in the framework  closer to 0 than 1.