The situation
What needs investigation
A team has containerized an application and needs to choose how it runs in production. The decision is not simply which platform has more features; it is which runtime the team can deploy, monitor, secure, scale, and upgrade with confidence.
Signals we look for
Workload
- runtime and CPU profile
- stateful dependencies
- batch or service behaviour
Operations
- cluster ownership
- patching responsibility
- deployment tooling
Networking
- service discovery
- ingress requirements
- private connectivity
Cost
- idle baseline
- compute flexibility
- operational overhead
How we investigate
Each step is validated against the workload before the next change.
- 01
Profile workloads
Classify services, jobs, state, traffic, and scaling behaviour.
- 02
Compare runtimes
Evaluate ECS, Fargate, ECS on EC2, and EKS against the actual requirements.
- 03
Review ownership
Define who operates nodes, upgrades, networking, and add-ons.
- 04
Test deployment
Validate image delivery, health checks, scaling, and rollback.
- 05
Model cost
Compare baseline and peak capacity with required operational work.
- 06
Choose deliberately
Document the decision and conditions that would trigger a later change.
Architecture / decision path
Example engineering decision
Illustrative runtime selection — not customer data
Servicesfour stateless APIs
Trafficpredictable business-hour peaks
Platform ownershipapplication team only
Engineering interpretation
A managed container runtime may be a better fit than operating a Kubernetes cluster when the workload does not require Kubernetes APIs and no team owns cluster lifecycle work.
Possible next investigation
- Compare ECS Fargate operating model with EKS requirements.
- Validate private networking and ingress.
- Model peak task count and startup time.
- Document monitoring and patching responsibility.
Trade-offs we consider
Control
Lower-level runtime control normally increases operational responsibility.
Cost
Cheaper compute can require node management and capacity planning.
Portability
A portable image does not make surrounding platform controls portable.
Team fit
The selected runtime must match the team that will own it.
What the engagement can produce
Typical outputs for this type of work
Scope depends on the environment and the problem being investigated.
- workload classification
- runtime comparison
- network and scaling design
- cost and ownership assumptions
- deployment validation plan
- platform decision record