You missed my point. I did not say reusability is the only factor that dictates the use of microservices. If we wrote everything as one big service, we'd lose

You missed my point. I did not say reusability is the only factor that dictates the use of microservices. If we wrote everything as one big service, we'd lose the dozen-or-so benefits of microservices. Hypothetically, if we rewrote what we have today as one big monolith: * We couldn't selectively open-source parts of it. * It'd really all have to be a single language, as opposed to the three we use right now. * ...and if we decided to change the language (like we're in the process of doing with a transition from Ruby to Go + Node.js), we'd have to rewrite all of it. * Deployment would be potentially more brittle since you're deploying a single codebase. Our apps are designed to gracefully tolerate partial unavailability. * We'd have to be careful to control individual services' resource footprint. We have some services which are super light and have very few dependencies — they don't carry a monolith on their back. * We'd have to jam in product-specific stuff for N different products into a single codebase. Some of our microservices aren't reusable; they're completely product-specific. Squishing lots of unrelated concerns into a single codebase is not feasible. * Developers would be trying to tightly couple services and violate separation of concerns faster than you can spell "technical debt". ...and so forth. Maybe I didn't articulate it well enough, but my original point was that microservices are great for all sorts of reasons, but also a too-often missed point is the benefits of reusability if you just design thing right. Put differently, microservices are a lot less powerful if you don't design them for reusability (and, as a prerequisite, multi-tenancy)