&gt;It makes me wonder if the &quot;microservice&quot; part of it was necessary. What if they had produced &quot;microlibraries&quot; rather than &quot;microservices?&quot;<p>So the OP did discuss considering micro-libraries (perhaps via Rails engines), but they decided not to.<p>&gt; We discussed using Rails engines and various other tools to implement this... At the deployment side, we would need to make sure that a feature can be deployed in isolation. Pushing a change to module to production should not require a new deployment of unrelated modules, and if such deployment went bad and production was broken the only feature impacted should be the one that suffered the change...<p>It goes on a bit. I think the reasons against this approach for them aren&#x27;t entirely clear in the discussion, it would be good to hear more.<p>Although as a Rails dev myself, this one rings true:<p>&gt; The code had suffered a lot during the past few years, tech debt everywhere. Besides the mess we made ourselves, we still had to update it from Rails 2.x to 3, and this is a big migration effort in itself<p>The ability to migrate from Rails 2 to 3 one service at a time is actually a pretty huge benefit, since that migration was monstrous. This is probably generalizable.<p>One other thing their ultimate microservice approach got them was the ability to write different services in different languages, and thus gradually transition to clojure&#x2F;scala. I don&#x27;t know if that was part of the original analysis; or if everyone would consider this a benefit. :) But it worked out for them.<p>Lately the reason microservices are a _pain_ is pretty clear to me; it is good to get an essay like the OP grounded in very specific experience on how microservices worked out very well for them. It does seem to make sense by the end. As the OP also says at the beginning, this is as much for organizational reasons as technical reasons. I suspect you need a fairly large team, where the microservices can be divided up amongst different developers, as in OP, before the benefits can start to outweigh the costs.