Nanoservices

Large programs today rarely consist of a single piece. Instead, they are broken down into smaller parts that run separately and send each other messages over the network. Nanoservices are the extreme case of this decomposition: each part is so small that it often fulfills only a single function, such as checking a postal code or converting a date. The term originates from software development and is deliberately meant as an exaggeration. Experts mostly use it as a warning: things have been sliced too finely here. A nanoservice is thus not progress compared to a somewhat larger building block, but a sign that a good idea was taken too far.

When decomposition becomes more expensive than its benefit

Breaking software down into independent parts has real advantages. A team can change its part without disturbing all the others. If one part fails, the rest often keeps running. And heavily used parts can be scaled up individually instead of making the whole program bigger. This is precisely why such architectures have become standard in recent years.

But every independent part also incurs fixed costs. It needs its own startup environment, monitoring, logging, version management, and an external interface. This effort is justified for a large building block. For a building block with twenty lines of code, it is absurd. You end up managing more surrounding infrastructure than actual program code.

On top of that comes a point that is easily underestimated: every call over the network takes longer than a call within the same program. A direct function call takes fractions of a millionth of a second. A network call quickly reaches several milliseconds. If a single user request queries thirty nanoservices in sequence, this adds up to noticeable wait time.

What makes the cut too fine

What matters is not the number of lines, but the question of whether a building block makes sense on its own. A good building block owns its own data and can fully handle a business task on its own, such as managing a shop’s orders. A nanoservice, by contrast, cannot do anything alone. It needs information from other parts for almost every call.

This creates the main problem: changes do not stay local. Anyone who adds a field suddenly has to adjust six building blocks at once and redeploy them in the right order. The parts are technically separate, but functionally tightly interlinked. Experts call this a distributed monolith: you get all the disadvantages of a large program plus the disadvantages of a network on top.

A comparison makes this tangible. Dividing a kitchen into work areas makes sense: appetizers, main courses, dessert. Each area has its own ingredients and delivers a finished result. If, instead, you assigned one person just to salting, one just to stirring, and one just to tasting, someone would constantly have to call out, wait, and hand things over. That is exactly how nanoservices behave.

Where the accusation shows up in practice

You most often encounter the term in discussions among developers, for instance in blog posts or talks about failed restructurings. A typical story is that of a company that broke its application down into hundreds of parts and then merged some of them back together. Such rollbacks are openly documented and are a recurring topic at tech conferences.

Cloud offerings play a special role here, where you upload only individual small functions and pay per call. There, tiny building blocks are technically intended, because the provider takes care of the management. Even so, the same rule applies: anyone who spreads functionally related things across too many functions runs into the same problems with coordination and latency.

For you as a reader of tech news, the key distinction is the useful takeaway. Medium-sized building blocks are considered established best practice. Nanoservices are not a distinct architectural style that someone deliberately pursues, but rather a diagnosis. If an article states that a system has disintegrated into nanoservices, it means: it was cut too small and has thereby become harder to operate.