When to Use Microservices: Modules, Monoliths, and Service Boundaries

Recently a reader asked when using microservices is a good idea. The author argues that microservices are simply the most extreme resistance to monolithic architectures and that the decision should start from where to place interfaces rather than blindly following trends.

1. What is a microservice?

Microservices are defined as the opposite extreme of a monolith: instead of linking everything into a single large binary, functionality is split into many small, independently deployable services.

The spectrum between a gigantic "one‑size‑fits‑all" service and countless tiny services is continuous, and the optimal point depends on the problem at hand.

2. Boxes and arrows

In system design, modules are the boxes and interfaces are the arrows. Deciding the size of each box and when to split a box into smaller ones is one of the hardest problems in software architecture.

Over decades, various abstraction mechanisms (functions, objects, containers, VMs, unikernels, etc.) have been introduced, each with its own isolation techniques such as ABI, API, system calls, RPC, sockets, and databases.

3. Exploration of modularity

The primary goals of a module system are to isolate code, reconnect parts only through well‑defined interfaces, maintain compatibility, and allow independent upgrades, downgrades, and extensions.

Achieving strong isolation has proven difficult; many isolation mechanisms (process isolation, chroot, VM isolation, container isolation, etc.) have been broken repeatedly, leading to a cycle of new ideas, initial success, discovered flaws, patches, and eventual abandonment.

4. All virtual machines!

Creating a separate VM for every small module is painful, and no isolation technique is perfect. Attackers who can execute code can often break isolation, especially when modules share libraries, databases, network access, or system calls.

Even strong isolation tools (e.g., Chrome sandbox, gVisor) rely on the underlying platform’s security, and supply‑chain attacks remain a concern.

5. Module boundaries vs. service boundaries

Module boundaries are usually driven by Conway’s law—team organization and communication—rather than security concerns. Service boundaries, however, must consider isolation, upgradeability, compatibility, scalability, cost, and reliability requirements.

6. Where should service boundaries lie?

The article lists practical factors: start‑up time, data‑schema versioning, CI test stability, differing resource usage, request cost, and varying reliability goals. Often these reasons overlap with module‑boundary considerations, and the author advises keeping designs simple until complexity is truly required.

In summary, microservices are not a silver bullet; they are one point on a continuum of modular designs, and choosing them should be based on concrete engineering trade‑offs rather than hype.