Container platform decisions

Introduction

Use containers as the default packaging stance. They give the product a flexible route from POC to Pilot to Production without forcing the final hosting decision too early.

The important early habit is not choosing the perfect platform. It is building an image, deploying it repeatably and avoiding hand-configured servers. If the workload is packaged cleanly, the company can move from a lightweight runtime to a more controlled runtime as assurance, scale and operational needs grow.

The platform decision should mature with the stage. POC should be cheap and disposable. Pilot needs more assurance. Production needs a platform that can support the operating model, resilience, security and cost expectations.

Detailed decision considerations

• Whether the workload is packaged as a repeatable container image.
• Whether the current stage needs cheap experimentation, external-user assurance or production

resilience.

• Which platform is deliberately temporary and which platform is intended to carry forward.
• What complexity would trigger a move from a lightweight container runtime to Container Apps or AKS.
• What needs to be true before AKS is introduced.
• Whether the team has enough operational knowledge to run the chosen platform safely.
• What the rollback or migration plan is if the chosen platform becomes too complex.

POC

For a POC, do not overthink the platform. Use something lightweight, cheap and throwaway.

Azure Container Instances or an equivalent simple container runtime can be ideal for very low workloads because it keeps cost and platform ceremony down. The POC is there to learn, not to prove that the final hosting model has been solved.

The POC should still teach the right habits:

• Build a container image.
• Deploy it repeatably.
• Keep secrets out of source control.
• Record the temporary platform choice.
• Make it clear that the environment is disposable.

Pilot

Moving to Pilot changes the assurance requirement. External users may be involved, data may become more sensitive and the platform needs to be more deliberate.

Container Apps can be a strong Pilot choice because it gives more operational structure without forcing the team to run Kubernetes too early. It can support a more controlled deployment route, managed scaling, environment separation and background workloads while keeping platform management lighter than AKS.

This is also the point to consider Kubernetes seriously, not fearfully. If the product shape is still simple, Container Apps may be the better answer. If the workload is already growing into multiple services, workers, scheduled jobs, migrations and environment-specific configuration, AKS may soon become the cleaner operating model.

Production

By Production, the platform should match the operating promises being made to customers. The decision should consider resilience, private networking, deployment control, observability, upgrade lifecycle, incident response, cost and team capability.

Container Apps can remain appropriate if it keeps the product simpler and meets the assurance need. AKS can be appropriate where a consistent deployment model, stronger workload orchestration or more complex operating requirements make Kubernetes easier to reason about than a spread of separate managed container services.

The decision is not ideological. Record the trade-off and revisit it when complexity, risk or cost changes.

Container shape

Where possible, use a single application container that supports multiple actions through a single entrypoint based on commands.

Examples:

• Run the API.
• Run a worker.
• Run a scheduled job.
• Run a migration.
• Run a maintenance task.

The SPA front end is the exception. Keep it separate and serve it from nginx or static hosting.

Keeping Kubernetes simple

Kubernetes should not be treated as automatically too complex. A small, targeted AKS setup with a small number of workloads can be easier to reason about than a scattered set of container apps once background jobs, scheduled jobs, migrations and environment-specific configuration grow.

The point is not to introduce service meshes or unnecessary platform tooling early. Keep the deployment shape boring. Helm charts can be simple when the workload is simple, and a consistent deployment model can reduce operational confusion.

The decision should still be based on what works. If Container Apps keeps the product simpler, use it. If AKS gives a cleaner operating model, record why the added platform responsibility is worth it.

Runtime hardening habits

Start as you mean to go on. Containers should not rely on writing application state into the image filesystem. Where possible, run containers as read-only and make writable locations explicit.

Fixing this early prevents bad habits from becoming hidden assumptions in workers, scheduled jobs, migrations or support tasks.

How this evolves as the company grows

• At POC, favour lightweight, cheap and disposable hosting that proves the idea without pretending to be Production.

• At Pilot, move towards a platform that can be recreated and operated with more confidence, such as Container Apps or a clearly justified alternative.

• Before Production, reassess whether operational complexity has grown enough to justify Kubernetes or stronger platform engineering.

• At scale, platform choice should be reviewed against deployment friction, resilience, support load, cost and team capability.

What an agent should look for

• Is the platform appropriate for the stage?

• Can it be deployed and recreated repeatably?

• What triggers a move to stronger platform capability?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.