Don't build your (micro)services, chisel them out

David Heinemeier Hansson on microservices + follow-up are a great read.

Real mastery is knowing when to extract a component into a service. So much of the discourse on this topic paints a black-and-white outcome—"microservices good, no microservices bad"—and completely misses the point. It's not the tool but how and when you use it.?

DHH calls out Shopify as a monolith, but that's a generalization that's not quite right. Shopify is a large and well-partitioned system (modules, namespaces, and yes... services) that is constantly evolving.

For example, there was a time when buyer storefronts were rendered by the same Rails stack that powered the merchant admin. As Shopify scaled, we separated those responsibilities and rewrote the storefront stack several times. Today, it runs on geo-distributed clusters, backed by a custom Liquid renderer and server runtime, ..., querying a tuned projection of storefront data. Carts are a related subsystem that we've rewritten several times that runs on its own set of optimizing infrastructure. These are two services (of many at Shopify) done right: chiseled-out services based on a deep understanding of product+performance requirements of the domain.

DHH nails it in his follow-up...

Leave isolated performance hotspots for last.?When microservices are done right, they often target a narrow, isolated, and usually performance-critical segment of the system, which can benefit from a rewrite in a clunkier but faster programming language...?

Learn to partition large systems with modules rather than networks.?So much of the motivation for microservices has been driven by the fallacy that if you can't figure out how to properly architect a large system using programming tools like modules and namespaces...

Simplicity demands that you do not start by inviting the beast of complexity – distributed systems – to the first dance...

Spot on advice and mirrors many of the points we made in?Principles of a modern Commerce OS.?