What is Cloud Native?
The phrase "we moved to the cloud" often means "we are running the same application on someone else's servers." That is cloud hosting. Cloud native is something fundamentally different - it means designing software specifically to take advantage of how cloud infrastructure works: elastic scaling, geographic distribution, automated failure recovery, and on-demand provisioning.
Cloud native is not a single technology. It is an architectural philosophy with a collection of practices and tools that, together, make applications resilient, scalable, and manageable at any scale.
The CNCF Definition
The Cloud Native Computing Foundation (CNCF) defines cloud native as techniques that "empower organisations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds." The CNCF specifically calls out containers, service meshes, microservices, immutable infrastructure, and declarative APIs as the key patterns.
The CNCF also maintains the Cloud Native Interactive Landscape - a map of over 1,000 open-source and commercial tools across the ecosystem. Kubernetes, Prometheus, Argo, Envoy, and Helm are all CNCF-graduated projects, meaning they have reached production maturity under governance.
The Four Pillars
Containerisation: Applications are packaged as container images rather than deployed to configured VMs. A container image is immutable - once built, it does not change. This means the same exact artifact runs in CI, staging, and production, eliminating environment drift. See containerization for a deeper look.
Microservices: Rather than a monolithic application, functionality is split into independent services that communicate over well-defined APIs. Each service is owned by a small team, deployed independently, and scaled independently. See microservices for the architectural tradeoffs.
CI/CD and automation: Every change goes through an automated pipeline - build, test, scan, deploy. No manual server configuration, no SSH-and-patch deployments. Infrastructure is defined as code and applied automatically.
Orchestration: Kubernetes (or a managed equivalent like EKS or GKE) runs containers at scale. It handles scheduling, service discovery, health checks, autoscaling, and self-healing - restarting failed pods, replacing unhealthy nodes, and spreading workloads across availability zones automatically.
The 12-Factor App
The 12-Factor App methodology, originally described by Heroku engineers, defines twelve practices that make applications genuinely portable and cloud-native. The most impactful principles are:
- Store config in the environment: No hardcoded credentials or endpoints. All environment-specific configuration comes from environment variables, making the same image deployable to any environment.
- Treat backing services as attached resources: Databases, caches, and message queues are attached via a URL in config. Swapping from a local Postgres to a managed RDS instance requires only a config change.
- Stateless processes: Application instances hold no local state between requests. Session data lives in a shared store like Redis. This enables horizontal scaling - add more pods without worrying about session affinity.
- Disposability: Processes start fast and shut down gracefully. This enables autoscaling and zero-downtime deploys.
- Dev/prod parity: Development, staging, and production environments are as similar as possible. Docker Compose closes most of this gap by running the same images locally.
# docker-compose.yml -- local environment matching production containers
version: "3.9"
services:
api:
image: myregistry/api:${IMAGE_TAG:-latest}
environment:
DATABASE_URL: ${DATABASE_URL}
REDIS_URL: ${REDIS_URL}
APP_ENV: development
ports:
- "3000:3000"
depends_on:
- postgres
- redis
postgres:
image: postgres:16-alpine
environment:
POSTGRES_DB: appdb
POSTGRES_USER: app
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- pgdata:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
pgdata:
Config comes from environment variables (12-factor compliant), backing services are swappable, and the same container image used locally is the one that ends up in production.
Cloud Native vs Traditional Architecture
A traditional three-tier application might have a web server, application server, and database - all running on dedicated VMs, configured manually, and deployed by copying files to a server. Scaling means provisioning a new VM, configuring it, and adding it to a load balancer manually.
A cloud-native version of the same application runs in containers orchestrated by Kubernetes. Scaling is a kubectl scale command or an automatic HorizontalPodAutoscaler policy. Deployment is a Git commit that triggers a CI/CD pipeline. Infrastructure is defined in Terraform and applied idempotently. Failures are detected and recovered from automatically.
The operational difference at scale is significant: a cloud-native team of five engineers can manage infrastructure that would require a dedicated team of twenty in a traditional model.