Chapter 3: What Is Universal Microservices Architecture (UMA)?

What separates UMA from conventional microservices

A conventional microservice is defined by its network boundary: it receives a request, processes it, and returns a response. The host environment (the runtime, the framework, the infrastructure) is assumed. UMA rejects that assumption. A Universal Microservice is defined by its behavioral contract: what it guarantees, what it needs, and how it behaves, stated in a form that is independent of any specific host. The network boundary is still there, but it's a runtime concern, not the defining property of the service. This shift has consequences for how contracts are written, how governance works, and how portability is proved rather than assumed.

Three durable separations

UMA is built on three separations that stay stable as execution surfaces change.

The portable service owns the business rule. It has no hidden runtime dependencies. no direct filesystem access, no environment-specific SDK calls, no assumptions about where it runs. The same binary can be loaded by a browser runtime, a cloud function host, or an AI-assisted workflow without modification. This is the unit that carries behavioral guarantees across environments.

The active descriptor makes the contract machine-readable. It declares the service's inputs, outputs, constraints, and placement preferences in a structured form the runtime can validate and act on. The descriptor is what enables the runtime to make placement decisions without human configuration at each new deployment surface. A service without a descriptor can still run. but the runtime has no basis for governance, and the contract exists only as implicit knowledge.

The runtime layer handles everything that varies by environment: transport, validation, adapter binding, trust enforcement, and approval traces. The runtime is what makes a portable service usable in a specific host without requiring the service to know anything about that host. Keeping runtime concerns out of the portable core is what makes portability a verifiable property rather than a deployment promise.

Why definitions matter more than names

Most teams that adopt "microservices" end up with services that are independently deployable but not portable. Most teams that claim "portable services" mean services that run on multiple cloud providers with a thin configuration layer on top. Neither of those is UMA's definition, and the distinction matters because loosely defined properties can't be governed. If "portable" means "runs on AWS and GCP," then a service that caches the AWS region in a module-level variable is portable by that definition. If it means something falsifiable (the service meets three structural separations or it doesn't) then that variable is a violation, and you can detect it in CI before it becomes a production incident.

UMA's definition is precise because it has to be falsifiable. Either a service separates its behavior from its runtime, carries a machine-readable descriptor, and defers execution concerns to a governed layer (or it doesn't. There is no partial credit. A service that meets two of the three separations is a better service than one that meets none, but it isn't a Universal Microservice, and the runtime cannot make the same guarantees about it. This precision isn't pedantry) it's what makes governance possible. You can't automate enforcement of a property you can't define sharply enough to test.

The chapter spends time on why existing definitions don't hold. "Microservices" as a term has accumulated so many contradictory usages that it no longer specifies a falsifiable architectural property. Teams use it to mean small, independently deployable, single-responsibility, domain-aligned. all of which are directionally useful but none of which is testable in the binary sense UMA requires. UMA's three separations are testable. That's what makes the name worth having its own definition rather than borrowing an existing one.

What the three separations enable

Each separation in UMA is there to unlock a specific capability that conventional microservices can't offer. Separating behavior from runtime enables portability without rewrite. A service that carries no assumptions about its host can be loaded by a new runtime (browser, edge, AI agent) and the business logic runs identically. This is not true of a service that uses a framework-specific lifecycle, accesses environment variables directly, or makes outbound calls without going through the declared interface. Those services can be ported, but porting requires rewriting the coupling points, and rewriting coupling points at the moment of deployment to a new surface is exactly the pattern that produces diverging implementations.

Separating the contract from the implementation enables governance without instrumentation. When the active descriptor is a computable artifact that travels with the service, the runtime can validate inputs, enforce constraints, and record evidence without any out-of-band configuration. A governance team doesn't need to instrument each service individually. They configure the runtime once. Every service that carries a descriptor gets governance automatically. This is the separation that makes compliance tractable at scale. not because the rules change, but because the runtime can enforce them without human configuration at each deployment.

Separating placement from business logic enables runtime diversity without duplication. When the service doesn't decide where it runs (when that decision belongs to the runtime, guided by descriptor constraints) the same artifact can be placed differently for different contexts. An evaluator that costs too much to run in the browser can be placed at the edge. the same descriptor, the same binary, a different placement decision. The service doesn't need a browser-specific variant. The runtime variant handles the difference. This is the separation that makes execution surface proliferation a runtime concern rather than a codebase proliferation problem.

How it connects

Chapter 2 shows what breaks when logic is environment-coupled. Chapter 4 traces the architectural lineage. how thinking evolved from SOA through microservices to the metadata-driven model UMA introduces.