Applies toOCI Compute (VM and bare metal shapes, instance pools), OKE (managed and virtual nodes), OCI Container Instances, OCI Functions
Decision path
Needs hardware-level access, no hypervisor, very large memory/cores, licensing tied to physical cores?
└─ yes → Bare metal
Vendor software / OS-level control / Windows apps?
└─ yes → VMs (instance pools + autoscaling for stateless fleets)
Event-driven, short-running code (Events, API Gateway, Connector Hub)?
└─ yes → Functions
A few containers, no orchestration platform wanted (jobs, small services, sidecar-free apps)?
└─ yes → Container Instances
Many containerised services, Kubernetes APIs, platform team?
└─ yes → OKE (virtual nodes to avoid node management where features allow)
Comparison
| VM | Bare metal | OKE | Container Instances | Functions | |
|---|---|---|---|---|---|
| You manage | OS, patching, scaling | Everything above hardware | Workloads, node pools (not with virtual nodes), upgrades | Containers | Code |
| Scaling | Instance pools + autoscaling | Manual / pools | Autoscaler, HPA | Per instance (no autoscaling built in) | Automatic per invocation |
| Long-running | Yes | Yes | Yes | Yes | Limited by timeout |
| Good for | General workloads, COTS | Databases on BM, HPC, licensing | Microservices platforms | Simple container workloads, batch | Glue code, webhooks, events |
| Typical trap | Patching debt | Over-sizing | Operating Kubernetes is a job | Missing orchestration features | Cold starts on user-facing APIs |
Placement and resilience
- Spread VMs and node pools across fault domains (and availability domains in multi-AD regions).
- Instance pools with a load balancer for stateless tiers (see the HA web tier post).
- For OKE, spread nodes across fault domains/ADs and use topology spread constraints.
Shapes
- Flexible shapes (E-series AMD, A-series Ampere, Intel X-series) sized by OCPU and memory independently.
- GPU shapes for AI/ML (check capacity per region early).
- Dense I/O shapes for local NVMe needs (data is local, so plan replication).
Questions for the design review
- Who patches the OS/runtime, and how is compliance shown (OS Management Hub)?
- How does it scale, and what's the downstream bottleneck?
- What happens when a fault domain or AD fails?
- How is it deployed and rolled back (Resource Manager/Terraform, DevOps service, CI)?
- Can the owning team run it at 3 AM?
Tip
Container Instances are often overlooked: for one or two containers that just need to run (an internal tool, a scheduled job), they avoid both VM patching and a Kubernetes platform.
Checklist
- Workload shape and operating team identified
- Decision path recorded
- Fault domain/AD placement designed
- Shape family chosen
- Patching, scaling and deployment ownership written down