Infrastructure
Container Platforms
Choose how containerized workloads run by required orchestration control, cloud integration, platform ownership, and operational capacity.
Recommendation
Use the least orchestration the application actually needs.
Four container operating models
The choice ranges from a managed application service to organization-owned Kubernetes control.
Cloud and API boundary
Decide whether provider-native orchestration or Kubernetes compatibility is an actual organizational requirement.2
Operations
Assign capacity, upgrades, networking, storage, security, observability, incident, and recovery ownership.2
Portability and cost
Model the full deployment graph; a portable image does not make identity, network, state, scaling, or operations portable.5
Container routes
Begin with the lowest-operations route and move toward Kubernetes only when a named requirement demands it.
The workload is an application service in a container
Evaluate Google Cloud Run.
It avoids cluster management while retaining a container deployment contract and managed scaling.
Verify: Kubernetes APIs, daemons, direct nodes, or unsupported service behavior require another route.12
AWS integration is the operating center
Evaluate Amazon ECS.
Tasks and services integrate with AWS identity, networking, discovery, and capacity without adopting Kubernetes.
Verify: Kubernetes portability or an inability to own AWS-specific resource configuration should move the route.12
Kubernetes is required but management should be delegated
Evaluate Google Kubernetes Engine.
GKE provides Kubernetes with Standard and Autopilot ownership choices.
Verify: If Kubernetes is not independently justified, a managed application container is the simpler route.123
Kubernetes is an organization-level platform standard
Evaluate Kubernetes.
Its API and ecosystem can support cross-team platform control and extensibility.
Verify: The team must be prepared to own or govern clusters, nodes, networking, storage, policy, upgrades, and workloads.124
Boundary: Docker remains supporting image and runtime technology, not a peer managed platform. Hosting covers simpler deployment, while Infrastructure as Code covers resource-change workflows.
Where responsibility moves
Every step toward a general orchestrator expands both control and the platform-engineering surface.
- Control plane
- Application services hide orchestration; ECS exposes AWS tasks and services; Kubernetes exposes a general cluster API.14
- Capacity
- Managed instances, Fargate or EC2 capacity, Autopilot, Standard clusters, and self-managed nodes shift ownership.12
- Operations
- Upgrades, network policy, storage, security, observability, and recovery grow with orchestration control.24
- Portability
- Images may move more easily than service identity, networks, state, policies, scaling, and incident procedures.2
Official resources
Use the primary documentation to verify runtime behavior, operating limits, service boundaries, and current commercial terms.
Sources
Official documentation supporting the routes and decision boundaries on this page.
- 1Cloud Run container runtime contract
Google Cloud · Accessed Official
- 2Amazon ECS developer guide
Amazon Web Services · Accessed Official
- 3Choose a GKE mode
Google Cloud · Accessed Official
- 4Kubernetes overview
Kubernetes · Accessed Official
- 5Docker Build overview
Docker · Accessed Official