Cloud-Native & Infrastructure

You don’t need to be able to operate a Kubernetes cluster to manage a team that runs on one. But you do need a mental model of the pieces — enough to read an architecture diagram, follow an incident, and ask the question that matters. This page is that model: what “cloud-native” means, the projects worth recognizing, and the three tools you’ll run into on almost every modern team.

What “cloud-native” actually means

“Cloud-native” gets used as a buzzword, but it points at something specific. Cloud-native applications are:

• Containerized — packaged with their dependencies (e.g., Docker), so they run the same everywhere.
• Dynamically orchestrated — scheduled and scaled automatically (e.g., Kubernetes).
• Microservice-based — modular and loosely coupled, so pieces can change independently (one of the architecture styles worth knowing).
• Resilient, scalable, and observable — built to survive failure, grow under load, and tell you what they’re doing. That last property is what good monitoring and alerting turns into something you can act on.

The point isn’t to check every box. It’s that these properties tend to reinforce each other, and the tooling below exists to make them achievable without heroics.

CNCF: the ecosystem

The Cloud Native Computing Foundation (CNCF) is an open-source foundation under the Linux Foundation, created to support and promote cloud-native technologies. Its real value to you is as a map: when someone says “we’re adding a service mesh,” the CNCF landscape tells you what category that is and which projects are mature.

“Graduated” projects are the mature tier — widely adopted, with strong community governance and rigorous criteria for security, maintainability, and adoption. These are the names worth recognizing:

Why teams reach for CNCF projects: they’re battle-tested at scale (Google, Netflix, Uber), they follow open standards so they interoperate well — Kubernetes + Prometheus + Fluentd gives you full observability — and they’re vendor-neutral, which avoids lock-in. Graduated projects also meet a real production-readiness bar, so adopting one is rarely a bet on something unproven.

Learn more: the CNCF projects page, the Cloud Native Landscape, and the graduation criteria.

Docker: containers

Docker packages an application and everything it needs into an image that runs identically on a laptop, in CI, and in production. The core concepts:

• Docker Client — the CLI or GUI you run commands with (docker build, docker run).
• Docker Daemon — listens for client requests and manages Docker objects (images, containers, volumes, networks).
• Dockerfile — a declarative script defining how to build an image, layer by layer.
• Images — immutable, versioned templates built from Dockerfiles.
• Containers — running instances of images, with an isolated filesystem and processes.
• Registry — a place to push and pull images (Docker Hub, or self-hosted).
• Volumes & Networks — volumes give containers persistent storage; networks let them communicate securely.

Kubernetes: orchestration

If Docker runs one container, Kubernetes (K8s) runs thousands across many machines, keeps them healthy, and scales them up and down. The pieces:

• Control Plane
  • API Server — the front door for all cluster commands.
  • Scheduler — assigns Pods to Nodes based on resource needs.
  • Controller Manager — ensures the desired state (Deployments, ReplicaSets) matches reality.
• Worker Nodes
  • Kubelet — the agent on each node that watches for Pod specs.
  • Container Runtime — (e.g., containerd) launches the containers.
  • Pods — the smallest deployable unit, grouping one or more containers.
• Key Resources
  • Deployment — declaratively manages Pods and ReplicaSets for rolling updates.
  • Service — a stable network endpoint that exposes Pods.
  • Ingress — rules for routing external HTTP(S) traffic in.
  • ConfigMaps & Secrets — inject configuration and sensitive data.
  • Volumes — persistent storage attached to Pods.

The mental model that sticks: you declare the state you want, and Kubernetes works continuously to make reality match it. Most of what feels like magic is just controllers reconciling desired versus actual.

Terraform: infrastructure as code

Terraform lets you declare infrastructure — servers, databases, networks, cloud resources — in version-controlled files instead of clicking through a console. Its core concepts:

• Terraform CLI — the commands (terraform init, plan, apply) that read your configuration.
• .tf files — human-written HCL declaring resources and modules.
• Providers — plugins that let Terraform manage different platforms (AWS, Azure, Kubernetes, etc.).
• Modules — reusable, composable packages of .tf files to structure and share infrastructure.
• State — the terraform.tfstate file that tracks real-world resources and their attributes.
• Backend — where state lives (local, S3, Terraform Cloud) and how locking and remote operations are managed.
• Resource Graph — the internal dependency graph Terraform builds to order operations correctly.
• Plan & Apply — a two-step flow: plan previews changes, apply makes them live.