Web Runtime and Hosting Responsibility

Goal

The previous section brought traffic to the application boundary. The next decision is where the web code, API code, static content, or supporting worker should run.

This is often where teams jump to product names. That is understandable because hosting products are visible and easy to compare. But hosting is not only a location for code. It is a responsibility boundary.

The durable idea is:

Hosting is a responsibility trade-off, not just a place to run code.

The Short Version

The web runtime owns the execution of application behavior. It affects deployment, scaling, startup time, health checks, configuration, secrets, network access, observability, patching, portability, and incident response.

Common runtime shapes include:

• managed web platforms;

• managed container platforms;

• Kubernetes platforms;

• functions or serverless execution;

• virtual machines;

• static hosting for files and front-end assets.

None is automatically best. The right runtime is the one whose responsibility boundary matches the workload and the team.

The Runtime Responsibility Spectrum

Use this rough spectrum:

More provider-managed responsibility <-> More team-managed control
Managed web platform -> Managed containers/functions -> Kubernetes -> Virtual machines

The left side usually reduces infrastructure operations. The right side usually gives more control. More control can be valuable, but it creates more work: patching, scaling, networking, platform standards, upgrades, observability, and incident ownership.

The question is not "Which option is most powerful?" The question is:

Which operating boundary does this workload need?

Managed Web Platforms

A managed web platform is often a good starting point for conventional web applications and APIs. The team deploys application code or a supported container pattern to a platform that handles much of the underlying server management.

This can fit when:

• the app is a normal web app or API;

• the team wants predictable deployment and scaling controls;

• custom domains, TLS integration, health checks, and operational hooks are useful;

• the team does not need Kubernetes APIs or server-level customization;

• simplicity is more valuable than deep platform control.

Managed does not mean ownerless. The team still owns application configuration, secure access, release safety, monitoring, alert response, dependency health, and cost.

Managed Containers

Managed container platforms fit when the application is naturally packaged as container images but the team does not want to operate a Kubernetes cluster directly.

Containers can help standardize build artifacts, dependencies, and runtime behavior across environments. They can also support separate web, API, and worker components that scale independently.

Containers are useful when they solve a real packaging or operating problem. They are not required just because the application is modern. If a normal web platform fits the workload with less operational burden, that may be the stronger design.

Kubernetes

Kubernetes can be a strong platform when the organization needs Kubernetes APIs, ecosystem tools, service mesh patterns, cluster-level policy, custom controllers, scheduling behavior, or a shared platform operated by a capable platform team.

It is also a responsibility amplifier. Someone must own cluster upgrades, node capacity, ingress, network policy, workload identity, secrets integration, observability, platform security, and cost allocation. If the team only needs to run one web app or a small API, Kubernetes may be more platform than the problem requires.

Functions and Static Hosting

Functions can fit bursty, event-driven, or small request handlers when the execution model and limits match the workload. They may be useful for lightweight APIs, image processing, webhooks, scheduled tasks, or background reactions. The team still needs to think about cold starts, timeouts, retries, observability, and dependency access.

Static hosting fits when the workload is mostly files: HTML, CSS, JavaScript, images, documentation, or compiled front-end assets. Static content can often be served through object storage, static site platforms, or CDN-backed hosting while dynamic APIs run elsewhere.

This is common in web patterns: the front-end assets are static, while APIs carry the dynamic behavior.

Example: Commerce Components

A commerce system may use several runtime shapes:

One architecture can use multiple runtime models. That is not inconsistency. It is a sign that each component was matched to its responsibility.

Choosing by Team Responsibility

Runtime decisions should include team reality.

A small team may prefer a managed web platform because it reduces platform operations and lets the team focus on product behavior. A larger organization with a mature platform team may prefer Kubernetes for standardization, policy, and platform consistency. A team already using containers well may prefer managed containers for APIs and workers.

The architecture should not punish the team with responsibilities it cannot operate. A powerful runtime that nobody can patch, secure, observe, or troubleshoot is not a strong architecture choice.

Common Mistakes

• Choosing Kubernetes because it sounds more architectural.

• Assuming managed hosting removes the need for observability, deployment safety, and cost ownership.

• Choosing a runtime before understanding scaling and release needs.

• Treating portability as free when it creates operational complexity.

• Forcing every component into the same runtime model even when the components have different jobs.

• Treating static content as if it always needs a full application runtime.

If Someone Asks You

How should I choose where a web application runs?

A good answer is:

Match the runtime to the workload shape and the team's operating responsibility. Use managed web hosting when the application fits a conventional web or API model. Use managed containers when containers solve packaging, scaling, or release needs without requiring Kubernetes control. Use Kubernetes when the organization truly needs Kubernetes platform capabilities and can operate them. Use functions or static hosting when those execution models match the work.

What to Remember

Choose the runtime whose responsibilities match the workload and the team.

Questions to Check Your Understanding

1. What responsibilities change when moving from managed hosting to Kubernetes?

2. Why is runtime selection also an operations decision?

3. When might a single web solution use multiple runtime models?

4. Why can a simpler runtime be the stronger architecture choice?