Cloud Native Fundamentals
Cloud native fundamentals covers the principles and technologies — containers, orchestration, microservices, CI/CD, and observability — that enable organizations to build and run scalable applications on modern cloud infrastructure with speed and resilience.
itCloud native tools and technologies | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Cloud Native Fundamentals
Cloud native is a way of arranging software so that change is treated as a normal operating condition, rather than an excuse to open a terminal and develop a new relationship with dread. It is not public cloud with extra stickers. It is architecture, automation, and operating practice aimed at making a workload change predictably while remaining secure, resilient, manageable, sustainable, and observable.
The central character is desired state. You describe the condition you want: three replicas, this version, these connections. A controller observes actual state, compares it with the declaration, and acts on the difference. Then it does it again, because systems have a regrettable habit of continuing to exist after the deployment meeting ends. This repeated correction is reconciliation.
The arrangement has three layers. The workload contains application behavior, configuration needs, and data responsibilities. The platform deploys, connects, secures, scales, and observes the workload. Infrastructure supplies compute, network, and storage. Each boundary needs a contract, because a tidy diagram cannot restart a database or explain a timeout.
Containers make an application package repeatable. An image carries a filesystem and runtime configuration, a registry distributes it, and a runtime creates a container process. An orchestrator manages many such processes across machines. Kubernetes is one example: its API accepts objects that describe what should exist, and its controllers work to make the cluster match. Containers are useful, but they do not appoint themselves fleet managers. Sensible containers have limits.
The surprise is that automatic recovery is not the same as correct recovery. A platform can replace a failed replica or remove an unhealthy endpoint from traffic. It cannot decide whether repeating a payment is safe, whether data is durable, or whether an application health check means anything. You still need accurate readiness, timeouts, recovery objectives, and tested degraded behavior. Automation repeats mistakes with impressive consistency.
Cloud native is a toolbox, not a scavenger hunt. Microservices, service meshes, GitOps, immutable infrastructure, and serverless platforms all solve particular problems while adding their own network paths, identities, policies, telemetry, and failures. Start with repeatable builds, declared configuration, useful telemetry, and clear ownership. Add machinery when the workload can name the problem it solves.
Read the intro for the full map of layers and tradeoffs. Use the slides for the relationships at a glance, the cheatsheet for components and diagnostic questions, and the practice reference to watch a Deployment restore its declared replicas in a disposable cluster. The Field Notes cover the costs that wait politely outside an architecture diagram.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://github.com/cncf/toc/blob/main/DEFINITION.md
Supports
- Cloud native definition across public, private, and hybrid environments
- Loose coupling and secure, resilient, manageable, sustainable, observable operation
- Typical technologies and the role of automation in frequent, predictable change
- https://glossary.cncf.io/
Supports
- Vendor-neutral vocabulary and navigation among cloud native concepts
- https://glossary.cncf.io/container/
Supports
- Containers as isolated processes running from packaged images
- Relationship between container processes and an operating system
- https://glossary.cncf.io/microservices-architecture/
Supports
- Microservices as independently deployable services around application capabilities
- Operational and network complexity introduced by distributed services
- https://glossary.cncf.io/service-mesh/
Supports
- Service-to-service traffic management
- Consistent reliability, observability, and security functions across services
- https://glossary.cncf.io/immutable-infrastructure/
Supports
- Replacement of infrastructure instead of in-place modification
- Version-controlled automation used to recreate infrastructure
- https://opencontainers.org/about/overview/
Supports
- OCI image, distribution, and runtime specifications
- Path from a packaged image to an unpacked runtime bundle and running container
- OCI governance for open container standards
- https://kubernetes.io/docs/concepts/overview/components/
Supports
- Kubernetes control plane and node component responsibilities
- API server, scheduler, controller manager, kubelet, and container runtime roles
- https://kubernetes.io/docs/concepts/overview/working-with-objects/
Supports
- Kubernetes objects as records of intent
- Specification as desired state and status as current observed state
- Control plane management of actual state toward desired state
- https://kubernetes.io/docs/concepts/architecture/controller/
Supports
- Control loops that observe cluster state and move it toward desired state
- Controllers tracking resources through the Kubernetes API
- https://kubernetes.io/docs/concepts/workloads/controllers/
Supports
- Declarative workload APIs and control-plane management of Pods
- Deployments for interchangeable stateless workload replicas
- https://kubernetes.io/docs/concepts/architecture/self-healing/
Supports
- Container restart, replica replacement, rescheduling, volume reattachment, and endpoint removal
- Limits of self-healing for storage failures and application errors
- https://opengitops.dev/
Supports
- Declarative desired state
- Versioned and immutable state storage
- Automatic pull and continuous reconciliation
- https://opentelemetry.io/docs/concepts/observability-primer/
Supports
- Observability through emitted telemetry
- Definitions and roles of metrics, logs, spans, and distributed traces
- Reliability and service level indicators from a user's perspective
- https://github.com/cncf/landscape
Supports
- Landscape as a categorized map of cloud native projects and products
- Multiple possible routes for deploying cloud native applications
- https://docs.docker.com/engine/release-notes/prior-releases/
Supports
- Docker Engine 1.0 production support on 2014-06-09
- https://www.docker.com/blog/10-years-since-kubernetes-launched-at-dockercon/
Supports
- Kubernetes open source announcement on 2014-06-10
- https://www.docker.com/blog/open-container-project-foundation/
Supports
- Formation of the Open Container Project in 2015
- Common container format and runtime specifications
- https://kubernetes.io/blog/2022/08/23/podsecuritypolicy-the-historical-context/
Supports
- Kubernetes 1.0 release on 2015-07-10
- https://www.cncf.io/announcements/2015/06/21/new-cloud-native-computing-foundation-to-drive-alignment-among-container-technologies/
Supports
- CNCF launch and Kubernetes contribution in July 2015
- https://www.cncf.io/projects/kubernetes/
Supports
- Kubernetes CNCF incubation in 2016 and graduation in 2018
- https://www.cncf.io/announcements/2018/03/06/cloud-native-computing-foundation-announces-kubernetes-first-graduated-project/
Supports
- Kubernetes as the first CNCF graduated project
- https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
Supports
- OpenTracing and OpenCensus merger into OpenTelemetry in 2019
- OpenTelemetry CNCF sandbox status
- https://www.cncf.io/blog/2021/08/26/opentelemetry-becomes-a-cncf-incubating-project/
Supports
- OpenTelemetry incubation in 2021
- OpenTelemetry governance and telemetry components
- https://stripe.com/blog/operating-kubernetes
Supports
- Production Kubernetes integration and operating effort
- Service-level objectives for scheduled workload outcomes
- Pod eviction behavior during loss of node contact
