Modern applications rarely need one universal deployment model. A web frontend, webhook handler, scheduled pipeline, inference service, and long-running worker behave differently. Containers, serverless functions, and edge runtimes are tools for placing those workloads where their operational characteristics fit.

Containers: a portable unit of execution#

Docker packages an application with its runtime and system dependencies, making development, CI, and production more consistent. Containers suit APIs, workers, scheduled jobs, and services with predictable resource needs. They allow control over process behaviour, networking, files, and dependencies without coupling the application completely to one platform.

A container is not an operating model by itself. It still needs image scanning, a registry, configuration, secrets, health checks, logs, metrics, rollouts, and capacity management. A managed container platform is often the right first destination because it provides these capabilities without requiring a team to operate a cluster.

Kubernetes: useful when coordination is the problem#

Kubernetes becomes valuable when an organisation has many containerised workloads and repeatedly needs scheduling, service discovery, policy, autoscaling, controlled rollouts, and shared platform automation. It can create a consistent operational surface across teams and environments.

For a small product with a few services, Kubernetes may move complexity rather than remove it. Cluster upgrades, ingress, networking, identity, observability, policy, and cost allocation require ownership. Use it when platform standardisation and workload coordination justify a platform team—not as a prerequisite for calling an application cloud native.

Serverless: pay for events, accept constraints#

Serverless functions fit bursty APIs, webhooks, scheduled automation, event processing, and glue code. They reduce idle cost and infrastructure management, while automatic scaling handles uneven demand.

The constraints must match the job: startup latency, execution duration, memory, ephemeral filesystems, concurrency behaviour, and provider limits. Database connections are a frequent failure point because rapid scaling can create more concurrent connections than PostgreSQL can accept. Use pooling, bound concurrency, and make event handlers idempotent so retries are safe.

Edge: move computation only when locality helps#

Edge runtimes can reduce latency for routing, authentication checks, personalisation, redirects, lightweight API composition, and cached content. Frameworks such as Hono make web-standard edge code approachable.

Compute location is only useful when data is nearby or the work can avoid central state. An edge function that calls a single-region database on every request may add complexity without reducing latency. Runtime APIs are also more constrained than a conventional Node or container environment, so verify library support and execution limits.

Place a workload from evidence#

Describe each workload by request duration, traffic shape, state, CPU and memory needs, data location, startup sensitivity, networking, and compliance. Add team capability and incident response: the theoretically ideal platform is wrong if nobody can diagnose it.

Start with the simplest managed environment that meets reliability and cost requirements. Measure cold starts, tail latency, saturation, error rate, and spend per useful transaction. Move only the workloads whose evidence supports a different model.

Containers provide control and portability, serverless provides event-driven elasticity, edge provides geographic proximity, and Kubernetes coordinates substantial container estates. Strong architecture does not choose one camp—it gives each workload an appropriate home and keeps the boundaries observable.