Nanoservices and AI: Why the Anti-Pattern Becomes the Architecture

Why nanoservices stop being an anti-pattern

While AI agents can now write high-quality applications autonomously without anyone ever seeing the code, organizations remain accountable for their output. In order to govern this, verification has to be possible from the outside. This is a new structural constraint for software architecture: accountability without visibility. The structure this points to is one that has been warned about as an anti-pattern for many years: nanoservices.

The larger the scope behind a contract, the more behaviors may escape verification. A microservice is already small. But it can still bundle multiple operations, contain internal interactions, implicit state transitions, and edge cases that no contract can fully capture. In this state, contract-based verification is structurally incomplete because the contract describes a surface and the surface conceals behaviors that determine outcomes. Below it, the contract can exhaustively describe the behavior. The nanoservice — one input, one output, one behavior — is the unit at which accountability without visibility becomes achievable.

What is a nanoservice

Arnon Rotem-Gal-Oz coined the nanoservice as an anti-pattern in his book SOA Patterns (Manning, 2012). His definition bundles two things:

A granularity level: a service that owns a single operation. Rotem-Gal-Oz illustrates this with a calculator service that exposes individual arithmetic operations as service endpoints. Each operation is trivially simple.

And an economic judgment:

A nanoservice is a service whose overhead (communications, maintenance, etc.) outweighs its utility.

In the SOA era, these two were inseparable. At single-operation granularity, the overhead always outweighed the utility. The granularity and the verdict came as a package, and “nanoservice” became the label for both. But the definition is worth examining precisely, because the granularity is a structural property and the economic judgment is a product of the era’s constraints. They are not the same thing.

Four consequences grounded the economic judgment:

Poor performance. Every service call incurs serialization on the caller side, handoff to the OS network stack, protocol translation, wire travel, deserialization on the receiving side, and the same chain in reverse. Add security (encryption, firewalls), routing, and retries. With many fine-grained services, these costs compound into what Rotem-Gal-Oz calls a “significant performance nightmare.” The root cause is violating two of the fallacies of distributed computing: assuming bandwidth is infinite and transport cost is zero.

Fragmented logic. Breaking what should be a cohesive service into minuscule steps scatters business logic across service boundaries. Completing a meaningful business operation requires hauling across several services, which increases the chance of tight coupling between them (the Knot anti-pattern).

Development overhead. Each service carries a fixed development cost regardless of how much business logic it contains: WSDL or contract definitions, registry entries, configuration scaffolding, policy compliance code. At single-operation granularity, the cruft dominates the codebase.

Management overhead. Each service must be tracked in a registry, monitored, configured, governed. The per-service management burden multiplies with every additional service, and at fine enough granularity the overhead of managing the services exceeds the value they deliver.

Rotem-Gal-Oz is careful to note that the definition cuts on the ratio, not on the granularity. A fraud detection service with a single operation is not a nanoservice if the innards involve rule engines, blacklist matching, and complex decisioning; the utility justifies the overhead. Conversely, a service with a comprehensive contract can still be a nanoservice if it becomes a central bottleneck whose cost outweighs its contribution.

This verdict was correct. In the SOA era, all four costs were too high for single-operation services. The granularity was technically possible but economically irrational. What matters for the argument that follows is that the label “nanoservice” fused a granularity level to an economic condition. If the economic condition changes, the granularity remains but the label, by Rotem-Gal-Oz’s own definition, no longer applies.

Why the economics of nanoservices have inverted

Rotem-Gal-Oz’s four objections grounded the anti-pattern for the SOA era. They need to be re-examined against what has actually changed, and when.

Network overhead

The SOA era’s network pain was specific and measurable. SOAP used verbose XML serialization with WSDL contract definitions and envelope wrappers. Communication was typically WAN-centric, crossing network boundaries between organizations or data centers. HTTP/1.1 meant one request per connection, with head-of-line blocking and no multiplexing.

Each of these constraints has shifted over the past fifteen years:

REST replaced XML with JSON, reducing payload size and eliminating the WSDL overhead that made even simple calls expensive. gRPC went further with compact binary serialization over multiplexed connections, with the advantage most pronounced for the small, frequent calls that characterize fine-grained architectures.

More fundamentally, modern cloud deployments moved service-to-service communication from WAN to intra-region, and often intra-VNet or intra-cluster. Per-call latency drops from the tens or hundreds of milliseconds Rotem-Gal-Oz’s analysis assumed to single-digit milliseconds. Service meshes and platform networking absorbed mTLS, routing, retries, and circuit breaking into the infrastructure layer.

This is the trajectory that made microservices viable by roughly 2016. It was not AI-driven. It was infrastructure-driven, and it has been underway for over a decade. The fallacies of distributed computing still apply; a request traversing multiple nanoservices in sequence adds real latency. But the per-call cost has dropped far enough that it is no longer the blocking factor for finer granularity within a cluster.

Operational overhead

Rotem-Gal-Oz’s management overhead assumed a roughly constant marginal cost per additional service: new server provisioning, new monitoring configuration, new deployment pipeline, new registry entry. In the SOA era, deploying ten services meant ten times the operational burden.

That linear relationship broke with platform engineering:

Containerization and Kubernetes made the marginal cost of the Nth service drop sharply after the initial platform investment. Deploy a hundred containers or deploy ten: same pipeline templates, same cluster, same operational surface. Infrastructure as Code made provisioning repeatable and version-controlled rather than manual. OpenTelemetry established one instrumentation standard, one collection pipeline, one dashboard layer; adding a service no longer requires adding monitoring.

The pattern is the same as with network overhead. The marginal cost curve flattened, and that flattening is what made microservices operationally sustainable. It was not sudden, and it was not triggered by AI. It was a decade-long maturation of platform capabilities.

At nanoservice scale — hundreds or thousands of services — operational overhead is not zero. Service discovery, configuration management, and observability at that density remain demanding. Rotem-Gal-Oz revisited the granularity question in 2025 with AI in mind. He concedes that AI struggles with large solutions and that breaking systems into services makes them more tractable for agents. But he stops at the nanoservice threshold: “cross that threshold into nano-services, and you’re just creating overhead for no good reason.” The anti-pattern verdict, in his view, still holds.

Development overhead

Network and operational costs dropped over fifteen years. That trajectory enabled microservices. It did not enable nanoservices. The reason is development overhead.

Each service carries a fixed development cost that is independent of how much business logic it contains: project scaffolding, dependency injection configuration, health checks, logging setup, deployment scripts, conversion layers between internal models and contracts. At microservice granularity, a handful to a few dozen services, this boilerplate is a manageable fraction of the codebase. At nanoservice granularity, hundreds of single-operation services, the boilerplate dominates.

This cost scales linearly with the number of services. Unlike network overhead (addressable through better protocols) and operational overhead (addressable through platform investment), development overhead could not be amortized. Every additional service required someone to write the same scaffolding again.

This is the cost that AI collapses. Repetitive, pattern-following, structurally identical across services: project setup, configuration, infrastructure code, conversion layers. This is precisely the kind of work that AI generates reliably. The per-service development cost that made nanoservices economically irrational for humans approaches zero for autonomous AI agents.

Design overhead remains

Rotem-Gal-Oz’s second objection, fragmented logic, was never about cost. It was about cognitive complexity. Business logic scattered across many fine-grained services is hard to reason about. Where do the boundaries fall? How does data flow? How do failures propagate? How do you ensure consistency across services that each own a fragment of a business process?

AI does not solve this. Where to decompose, what each contract should specify, how services compose into a coherent whole: this is design work that requires domain understanding, architectural judgment, and deliberate human decisions. At nanoservice granularity, this work gets harder, not easier, because there are more boundaries to define and more interactions to manage.

Design overhead is the cost that persists after network, operational, and development overhead have dropped. It is also the cost that determines whether nanoservices deliver on their promise or collapse into the Knot anti-pattern that Rotem-Gal-Oz warned about.

Nanoservices as AI-native architecture

This is where the argument lands inside emergence theory. Prigogine’s bifurcation framework states that a system reorganizes into a new order when two conditions hold at once: the pressure on the existing structure exceeds what it can absorb, and the cost of the new order falls below a critical threshold. Both are now true for software architecture. The pressure is accountability without visibility, which has no answer at microservice granularity. The cost reduction is development overhead collapsing through AI, on top of the network and operational reductions that platform engineering had already delivered. The granularity does not drift smaller; the system bifurcates.

By Rotem-Gal-Oz’s own definition, a service whose overhead outweighs its utility is a nanoservice. The granularity is the same as before. What flipped is the ratio. Network and operational overhead came down through infrastructure. Development overhead came down through AI. And a category of utility that did not exist in 2012 — exhaustive contract-based verification of code no one will read — was added to the other side of the equation. The anti-pattern was never a property of the granularity. It was a property of the economics, and the economics have changed.

This is also where the argument parts ways with Rotem-Gal-Oz’s own 2025 position. He sees AI as a force for smaller services and acknowledges it changes the economics of boilerplate, but his analysis assumes humans remain in the construction loop, writing and reviewing and reasoning about the code. Under that assumption, fragmented logic still outweighs the utility of finer granularity, and the anti-pattern holds. The constraint identified here only bites when the human steps out of the loop entirely. When the agent builds autonomously and no one reads the code, contract-based verification is not optional. It is the only mechanism left, and it is large enough to tip the ratio.

What this argument does not settle

Two things are worth acknowledging directly. First, no contract literally captures every behavior of a service. Side effects, internal state, error modes, and performance characteristics still escape a signature; smaller granularity reduces the surface but does not eliminate it. Second, if humans no longer read code, someone still has to read the contract. The verification burden does not vanish; it concentrates in specifications, tests, and templates. Both problems belong to the implementation layer rather than to the economic case made here, and both are addressed in the follow-up article: Software Architecture for AI Agents: Designing for Permanent Absence. The argument here establishes that the granularity is now economically rational. The follow-up works through the architecture that makes that granularity actually verifiable.

What this means for DRY, YAGNI, and other human-era verdicts

Anti-patterns are not eternal. They are verdicts pronounced under specific economic and human constraints, and they survive only as long as those constraints do. The verdict on the nanoservice was a verdict on overhead, not on granularity. Three of the four overheads — network, operational, development — that grounded it have now collapsed. The granularity that the SOA generation could see but could not afford is the granularity the autonomous AI agents can.

The label detaches and the structure stays. What follows from that is more interesting than the nanoservice itself. Every architectural verdict from the human-author era was issued under the same set of assumptions: that someone would write the code, that someone would read it, that scaffolding had to be paid for in human hours. Those assumptions are not permanent. The verdicts that depended on them — on DRY, on large classes, on YAGNI, on code comments — deserve the same re-examination this one has just received. Some may turn out to have been verdicts on economics that no longer apply.

Related

• Software Architecture for AI Agents: Designing for Permanent Absence
• The Impact of AI on Software Architecture through the Lens of Emergence Theory

Opus 4.7 was used to support formulation. The ideas, framework, and editorial decisions are my own.

Frequently Asked Questions