What Even Are Microservices?

A July 2026 post on var0.xyz, written after the author's previous piece got dragged into the usual Hacker News argument about microservices. The observation it starts from is that everyone recognizes a microservice on sight and almost nobody can say what makes something one.

The definition nobody has

How small is micro? One responsibility, or two? A thousand lines, or ten thousand? Deployments per day? The author's position is that none of these produce a convincing answer, because they are all attempts to measure the boundary in the wrong unit. Years of trying to define microservices by technical characteristics have produced characteristics that stay vague. That is the tell: the line is being drawn somewhere other than in the code.

Every technical reason survives inside a monolith

The reasons people give for leaving a monolith are slow deployments, slow test suites, painful builds. Those are real, and every one of them can be improved without splitting the system apart. So the migration is not actually being caused by them.

What is being caused by them is the timing. The thing that forces the move is that dozens or hundreds of engineers need to work independently: teams want ownership, and they want to release on their own schedule without coordinating with everyone else first. Microservices draw boundaries that mirror the organization's boundaries. That mirroring is the product; the technical shape is the side effect.

What the autonomy costs

You trade centralization for it. Inside a monolith, "which dependencies are we shipping" and "is this code still used anywhere" are questions static analysis can usually answer. Spread the same code over thirty services and both become research projects with no reliable method.

Then come the substitutions, which the post lists without drama: communication between functions becomes communication over the network, a method call becomes an HTTP request, a compiler error becomes a runtime failure. Latency, retries, partial failures, serialization, consistency — the full catalog of distributed-systems problems moves inside your application. None of it is surprising, and that is the point. It is the price of the flexibility, not a defect in the execution.

The same inheritance shows up outside architecture. log-distributed-llms makes the argument that fanning work out across parallel LLM agents is a distributed consensus problem with the impossibility results attached, not a coordination detail that better models will smooth over. Splitting a system across teams buys the identical bill. Concrete instances of it accumulate quickly: jwt-for-sessions notes that service-to-service verification without a shared session store is the one case where JWT genuinely earns its complexity, and that case only exists because somebody split the system.

The cost that never appears in the diagram

Overhead is usually discussed as APIs talking to each other. The other half is that the teams now have to talk too.

Changing an API stops being a refactor and becomes a negotiation. Consumers need advance notice. Versioning becomes mandatory. Old versions stay alive until everyone has migrated. A database change that used to be a commit becomes a coordinated effort across groups of people. As the post puts it: "The software isn't the only thing that's distributed anymore. The decision making is as well."

Choosing for the stated reason

None of this is an argument against microservices, and the post says so directly — many companies could not operate any other way. The test it proposes is about which problem you actually have. If the problem is organizational scaling, this may be exactly the right answer. If the problem is purely technical, check whether the solution being reached for is larger than the problem it is aimed at.

This is a useful counterweight to how architectural patterns get sold. porto-sap advertises a monolith-to-microservices migration path where a Container is self-contained enough that splitting it out is mostly a build and deploy change. Read against var0's argument, that promise addresses the half that was never the hard part. Extracting a clean Container does nothing about needing a team to own the result, and the negotiation costs arrive regardless of how tidy the boundary looked on day one.

metapatterns, Denys Poltorak's compendium that sorts hundreds of architecture patterns into fewer than 20 metapatterns, files this architecture under Services and Layered Services.

The author also published a video version of the same argument at https://youtu.be/aacClo78H-8.