One of the most underrated benefits of serverless—especially AWS Lambda—is not cost, scale, or managed infrastructure.

It’s architectural clarity.

When you design systems using functions as your core building block, something subtle but profound happens: the system becomes easier to reason about, harder to get wrong, and more stable as it grows.

I want to argue that serverless systems deserve their own architectural name—and that name is:

Nanoservices

A serverless function is a concrete object.

It has:

A clearly defined trigger (HTTP, SQS, EventBridge, S3, cron, etc.)

A well-defined input shape

A single responsibility

A clear output or side effect

Strong isolation boundaries

You can point to a function and say:

“This runs when X happens and does Y.”

There is very little ambiguity.

This is not accidental—it’s the result of the serverless execution model. And it turns out to be incredibly powerful from a system design perspective.

Now compare this to microservices.

What is a microservice?

Depending on who you ask:

A REST API

A container

A domain boundary

A deployment unit

A team boundary

A database + API

A “small service” (whatever that means)

Microservices are a concept, not a concrete primitive.

And because they’re vague, there are many ways to get them wrong:

Services that are too large

Services that are too chatty

Services coupled through databases

Services coupled through synchronous APIs

“Distributed monoliths” in disguise

Entire books, talks, and consulting practices exist just to explain how not to mess up microservices.

That alone should tell us something.

Microservices tend to work until they don’t.

As systems scale, teams often discover they need to:

Split services

Merge services

Introduce async messaging

Add caches

Redesign APIs

Repartition ownership

Rework data boundaries

In other words: scaling forces architectural evolution.

This is not a failure—it’s a natural consequence of choosing a flexible but poorly defined unit of composition.

But it is expensive. And risky.

In serverless systems, the unit of composition is already minimal: the function.

Functions are:

Completely isolated

Stateless by default

Independently deployed

Independently scaled

Independently owned

When a serverless system grows, you don’t usually:

Split functions

Merge functions

Redesign function boundaries

You just… add more functions.

Adding a new function almost never impacts existing ones. There is no shared runtime, no shared memory, no implicit coupling.

This is an extremely strong architectural property.

This is why I think serverless systems deserve their own name.

Not microservices. Not “FaaS-based microservices.”

Nanoservices.

A nanoservice is:

A single-purpose function

Triggered by a specific event

With explicit inputs and outputs

Fully isolated

Designed to be composed, not extended

Where microservices aim for “small,” nanoservices are intentionally tiny.

And unlike microservices, nanoservices are:

Enforced by the platform

Cheap to create

Cheap to delete

Hard to over-design

Nanoservice-based systems scale through composition, not coordination.

You compose behavior using:

Event buses

Queues

Streams

State machines

Workflow engines

Instead of asking:

“How do these services talk to each other?”

You ask:

“What events exist in the system, and who reacts to them?”

This naturally leads to:

Lower coupling

Better fault isolation

Easier experimentation

Safer evolution over time

Most discussions about serverless focus on:

Cold starts

Pricing

Vendor lock-in

Performance

These are valid concerns—but they miss the bigger picture.

Serverless isn’t just an execution model. It’s an architectural constraint that turns out to be incredibly well chosen.

By forcing us to build with nanoservices, it removes entire classes of architectural mistakes that microservices make easy.

Microservices tried to make architecture disciplined.

Serverless makes architecture inevitable.

By reducing the building block to its smallest useful unit, nanoservices give us systems that:

Scale without redesign

Grow without rewrites

And remain understandable long after the original authors are gone

That alone makes serverless worth taking seriously—not just as a platform, but as an architectural philosophy.

No posts