Microservices without Kubernetes

What Kubernetes actually solves

Kubernetes is a container orchestration system. It handles container scheduling across nodes, horizontal scaling, health checks, rolling deployments, service discovery, and cluster networking. These are operational concerns. they answer the question of how running containers are managed across a fleet of machines.

What Kubernetes does not define: service contracts, the portability of business logic, or where a given capability should live in a distributed system. It has no opinion on whether a pricing rule should run at the edge or in a cloud region, or whether the same validation logic used server-side should be available client-side without a network call. Those questions belong to a different layer of the architecture.

Understanding this distinction matters because many teams reach for Kubernetes as the default answer to "how do we run microservices". and then discover they have solved the operational problem while leaving the architectural one untouched.

Why teams reach for Kubernetes by default

Kubernetes became the default answer to microservice deployment over a period when container tooling matured rapidly and platform consolidation made it the most documented, most job-postable, most conference-talked-about option. The ecosystem is genuinely impressive: Helm, Istio, ArgoCD, Prometheus, and dozens of adjacent tools make it possible to build sophisticated production platforms on K8s.

The problem is not that Kubernetes is wrong. It is that teams often adopt it before asking whether their workload justifies the operational complexity it introduces. A small team running a handful of services is paying a significant ops tax (cluster provisioning, node pool management, RBAC configuration, networking overlays, certificate management) for workloads that managed container platforms would serve equally well with far less overhead.

The maturity of the tooling is also a trap: because Kubernetes has a solution for everything, it can seem like the safest choice. But operational completeness is not the same as architectural fit.

Alternatives that fit better for specific workloads

Several deployment models are meaningfully better than Kubernetes for certain shapes of work.

Serverless (AWS Lambda, Cloudflare Workers, Azure Functions) is well-suited to event-driven, bursty, or infrequent workloads where idle capacity would be wasted. No cluster to manage, no nodes to patch, billing tied directly to invocations. The tradeoff is provider coupling: the invocation model, event bindings, and cold-start behavior differ meaningfully between providers.

WASM runtimes (wasmtime, WasmEdge, Cloudflare Workers) offer a different kind of portability: a compiled module that runs identically on edge hardware, in a browser, in a server process, or embedded in another application. WASM removes the container layer entirely. the runtime is the host, not the orchestrator. For workloads where portable execution across genuinely different environments matters, WASM runtimes are closer to the right abstraction than containers on K8s.

Managed container platforms (Cloud Run, Fly.io, Railway) give teams the container packaging model without cluster operations. You push a container image. the platform handles scheduling, scaling, and health. For most small-to-medium teams, this is the right point on the complexity curve. The ops overhead is a fraction of self-managed Kubernetes, and the deployment model is familiar.

The portability question Kubernetes doesn't answer

Kubernetes provides node-level portability: a container image runs consistently across any node in the cluster. That is a meaningful guarantee for operations. It is not the same as making the business logic inside the container portable across runtimes, browsers, or edge nodes.

A service that runs correctly on a K8s cluster does not automatically run in a browser, on an edge node, inside an AI agent, or in an offline mobile context. The container boundary defines the operational unit. it does not define the semantic unit or the portability boundary of the behavior inside it.

When a team discovers that the same validation logic needs to run on the server and in the client, and again at the edge, they are encountering a portability problem that Kubernetes was never designed to solve. The answer to that problem lives in how the business behavior is designed, not in which orchestrator manages its deployment.

UMA's position

UMA is not anti-Kubernetes. A UMA service can run on K8s: the orchestrator is one possible host, and it is a reasonable choice for teams that already operate Kubernetes infrastructure. The adapter layer in UMA translates between the portable service boundary and whatever host environment receives the invocation.

What UMA defines is the portable service boundary independently of the orchestrator. A UMA capability has a stable contract, explicit runtime placement logic, and a design that keeps business behavior coherent whether the host is a K8s pod, a Cloudflare Worker, a WASM module in a browser, or a function in a workflow engine. The architecture does not require K8s to be coherent. and that independence is intentional.

The argument is not about replacing Kubernetes. It is about not letting the operational model define the architectural model. Those are separate decisions, and the one that is harder to change later is the one that lives inside the service, not the one that manages its containers.

When Kubernetes is the right choice

Large teams with complex scheduling requirements, stateful workloads that need persistent volume management, multi-tenant platforms with strict isolation requirements, and organizations with existing K8s investment and operational expertise are all situations where Kubernetes earns its complexity.

If your team is already running K8s effectively, the argument here is not to rip it out. The operational platform is a sunk cost that has already been paid. and Kubernetes, once mastered, is genuinely capable infrastructure. The more useful question for those teams is whether the business logic inside their services is as portable as the containers that run them.

The judgment about fit should be made honestly, workload by workload, not from a position that Kubernetes is always right or always wrong.

Questions and answers

Can UMA services run on Kubernetes?

Yes, fully compatible. UMA defines the portable service boundary. Kubernetes can be the runtime host. A UMA-designed capability deployed as a K8s pod works exactly as it would on Cloud Run or any other container host: the adapter layer handles the translation between the service contract and the host invocation model.

What should a small team use instead of Kubernetes?

Honestly: Cloud Run or Fly.io if you want containers without cluster ops. serverless (Lambda, Cloudflare Workers) if the workload is event-driven and bursty. Railway if you want maximum simplicity. The right answer depends on the workload shape. A team that does not yet have a K8s operator on staff is almost always better served by a managed platform than by a self-managed cluster.