Infrastructure¶
Container runtimes, container orchestration, public cloud platforms, and cloud infrastructure — from lightweight container engines to full-stack enterprise landing zones.
Topics¶
| Platform | Description |
|---|---|
| Docker | Industry-standard container engine for building, shipping, and running OCI-compliant containers — the foundation of modern containerization. |
| Kubernetes | Industry-standard container orchestration — desired-state reconciliation, scheduling, networking, storage, and self-healing at scale. CNCF Graduated. |
| OpenNebula | Lightweight, sovereign cloud platform for VMs, containers, and bare metal — simpler than OpenStack, with edge and hybrid cloud support. |
| OpenStack | Modular open-source cloud operating system for building large-scale private and public IaaS — managed by OpenInfra Foundation. |
| Alibaba Cloud | Alibaba's cloud platform (Aliyun) — dominant in China, with distinctive networking (CEN), database (PolarDB), and multi-account (Resource Directory) services. |
| AWS | Amazon Web Services — architecture patterns from single-VPC through enterprise landing zones with Control Tower, Transit Gateway, and multi-region DR. |
| GCP | Google Cloud Platform — architecture patterns from single-project through enterprise landing zones with Shared VPC, VPC Service Controls, and Cloud Spanner. |
| Tencent Cloud | Tencent's cloud platform — strong in China with distinctive networking (CCN), database (TDSQL), and security (Anti-DDoS Advanced, Cloud Firewall) services. |
| Multi-Cloud Governance | Cross-cutting architecture and governance patterns for enterprises running across 2+ clouds — networking, identity, DNS, observability, FinOps, security, IaC, and GitOps. |
Comparisons¶
| Comparison | Scope |
|---|---|
| Infrastructure Platforms Comparison | Kubernetes vs OpenNebula vs OpenStack — architecture, operational complexity, and use-case fit |
Landscape¶
The infrastructure landscape is converging around containers as the primary compute primitive while simultaneously expanding to accommodate VMs, bare metal, and serverless workloads within unified control planes. Kubernetes has become the de facto orchestration standard, but the operational complexity of self-managed clusters has driven adoption of managed services (EKS, GKE, AKS) and lightweight distributions (k3s, Talos) for edge and resource-constrained environments.
Sovereign cloud mandates — particularly in the EU, China, and Southeast Asia — are driving demand for OpenStack and OpenNebula deployments that keep data and compute within national borders, often operated by regional telcos or government agencies. Edge computing is the next frontier, with initiatives like CNCF's KubeEdge and AWS Outposts pushing orchestration closer to end users.
Container-VM Convergence
The container-VM convergence is visible in projects like Kata Containers, Firecracker, and KubeVirt, which provide VM-level isolation with container-like ergonomics. KubeVirt allows running traditional VM workloads alongside containers within the same Kubernetes cluster, enabling gradual migration from VM-centric infrastructure without forklift upgrades.
Multi-cloud strategies force enterprises to abstract away provider-specific primitives using tools like Crossplane, Cluster API, or internal platform layers. The Cluster API project deserves particular attention — it provides a declarative Kubernetes API for provisioning and managing Kubernetes clusters themselves, with provider implementations for AWS, GCP, Azure, vSphere, OpenStack, and bare metal.
Key Concepts¶
Container Orchestration¶
The automated management of container lifecycle, scheduling, networking, storage, and self-healing across a cluster of nodes. Kubernetes implements this through a declarative desired-state model: users submit manifests, and control loops (controllers) continuously reconcile actual state to match.
Key scheduling decisions include:
- Resource requests/limits: Guarantee minimum CPU/memory (requests) and cap maximum consumption (limits)
- Affinity/anti-affinity: Co-locate or spread pods based on node labels or existing pod placement
- Topology spread constraints: Distribute pods evenly across zones, regions, or custom topology domains
- Priority preemption: Higher-priority pods evict lower-priority pods when resources are scarce
Infrastructure Abstraction¶
The practice of decoupling application teams from underlying infrastructure details through APIs, CLIs, and internal developer platforms. Crossplane extends Kubernetes with Composite Resource Definitions (XRDs) that expose simplified infrastructure APIs; Cluster API provides a declarative Kubernetes API for provisioning and managing Kubernetes clusters themselves. The goal is a self-service model where developers request capabilities (a database, a cluster, a network) without knowing the cloud provider specifics.
Landing Zones¶
Landing Zone Components
A pre-configured, multi-account cloud environment that implements an organization's governance, networking, identity, and security baseline. AWS Landing Zone uses Control Tower with Account Factory; GCP uses a resource hierarchy of Org > Folder > Project with Shared VPC; Azure uses Management Groups with Landing Zone Accelerators. Each provides guardrails (SCPs, Organization Policies, Azure Policies) that enforce compliance before resources are provisioned.
Network Fabric¶
The interconnection layer that provides reachability between workloads across nodes, availability zones, regions, and clouds. In Kubernetes, the network fabric is implemented by CNI plugins (Cilium, Calico, Flannel) providing pod-to-pod connectivity. At the cloud level, transit gateways (AWS TGW, GCP NCC, Alibaba CEN) hub-and-spoke topologies connect VPCs, while SD-WAN or dedicated interconnects bridge on-premises and cloud networks. Overlay networks (VXLAN, Geneve, WireGuard) encapsulate traffic for cross-network portability.
Control Plane vs Data Plane¶
A fundamental architectural pattern in distributed systems separating the decision-making components (control plane) from the traffic-handling components (data plane). In Kubernetes, the control plane is the API server, scheduler, controller manager, and etcd; the data plane is the kubelets, kube-proxy, and container runtime on worker nodes. This separation enables independent scaling, security isolation, and failure domains — a pattern replicated in service meshes (Istio istiod vs Envoy sidecars), load balancers (NGINX controller vs upstream proxies), and cloud networking (SDN controller vs forwarding elements).
Open Questions¶
- As Kubernetes dominates container orchestration, what role will OpenStack play in five years — will it retreat to telco/NFV niches, or will projects like Ironic (bare metal) and Magnum (managed K8s) keep it relevant as a Kubernetes substrate?
- How do organizations effectively implement multi-cloud without creating a lowest-common-denominator abstraction that sacrifices the unique capabilities of each provider?
- With WebAssembly (Wasm) runtimes like SpinKube emerging as a lighter-weight alternative to containers, will Kubernetes evolve to schedule Wasm workloads natively alongside containers, or will a separate orchestration layer emerge?