Memory hook: Design for change and failure; choose a tool by its job; contribute through an open process.
Must remember
- Cloud native describes ways to build and operate applications that adapt to dynamic environments through automation, resilience and manageable change. It is not limited to one public cloud: cloud native systems can run on premises, at the edge or across cloud providers.
- Microservices split an application into independently deployable services around clear responsibilities. They can improve independent scaling and ownership but add distributed communication, data-consistency and operational complexity. A monolith can still use containers and modern delivery practices.
- Loose coupling limits how much components must know about each other. APIs, events and queues can reduce direct dependencies, but contracts, retries and failure handling remain necessary. Repeated retries need backoff and safe/idempotent behaviour to avoid amplifying failures.
- Immutable infrastructure favours replacing a versioned component over manually patching it in place. Declarative configuration records intended state. Automation and reconciliation make repeatable changes possible; neither prevents a bad specification from being applied consistently.
- Resilience plans for partial failure using replicas, health checks, distribution, timeouts, recovery and tested dependencies. Elasticity adjusts capacity with demand. Scalability is the ability to handle growth; it does not require that every scaling decision be automatic.
- Serverless moves more provisioning and scaling responsibility to a platform and often uses event-triggered execution. Servers still exist; users retain responsibility for code, permissions, data and service limits. Knative is an ecosystem example for serverless workloads on Kubernetes.
| Need | Recognisable ecosystem examples |
|---|---|
| Container orchestration | Kubernetes |
| Node container runtime | containerd or CRI-O |
| Metrics and alerting | Prometheus |
| Telemetry instrumentation and transport | OpenTelemetry |
| Log collection and forwarding | Fluentd or Fluent Bit |
| Service traffic proxy or mesh | Envoy; Linkerd or Istio for mesh capabilities |
| Desired-state application delivery | Argo CD or Flux |
| Image registry | Harbor |
| Cluster state key-value store | etcd |
| Policy decisions | Open Policy Agent |
- CNCF is a vendor-neutral home for open source cloud native projects within the Linux Foundation. Its landscape groups projects by purpose; inclusion is not a statement that every project solves every problem or has identical maturity.
- CNCF maturity levels include Sandbox, Incubating and Graduated. Graduation reflects evidence of project maturity, governance and adoption under CNCF criteria; it does not certify that a particular deployment is secure or guaranteed to fit your requirements. Archived status is different from active graduation.
- Open source communities collaborate through public repositories, issues, pull requests, design proposals, reviews and meetings. SIGs, working groups, maintainers and contributors organise work. Read a project's contribution guide, governance and code of conduct before submitting changes.
- Useful contributions include documentation, translations, reproducible bug reports, testing, accessibility, triage and code. Follow the project's licence and contribution requirements, such as DCO sign-off or a CLA when requested. Open source does not mean “no licence conditions.”
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Select among many projects for one platform capability | Identify the category, integration needs, maturity and operational trade-offs |
| Reduce unrecorded manual production changes | Versioned configuration, reviewed delivery and reconciliation |
| Begin contributing without being an experienced programmer | Documentation fixes, testing, issue triage or reproducible reports |
| Decouple request handling from background work | Appropriate events or queues with explicit failure handling |
| Assess a project's decision-making and contribution process | Its governance, maintainer rules and contribution documentation |
Traps
- Running an unchanged application in a public cloud does not automatically give it resilient cloud native behaviour.
- Microservices, Kubernetes and a service mesh are architectural choices, not compulsory ingredients for every application.
- A Graduated project can still be misconfigured, compromised or unsuitable for a particular requirement.
- Open source permits use under its licence; it does not eliminate ownership, attribution or redistribution obligations.
Active recall
1. Can an on-premises Kubernetes platform follow cloud native principles?
Yes. Cloud native concerns architecture and operations such as automation, resilience, loose coupling and manageable change. It is not restricted to a public cloud location.
2. A team edits each production container by hand after every release. Which principles would improve repeatability?
Build versioned replacement artifacts, record configuration declaratively and deliver changes through a reviewed automated process. This reduces drift and makes recovery to a known version more feasible.
3. Does CNCF graduation guarantee that a project is secure in any installation?
No. It signals project maturity against CNCF criteria. Deployment security, supported versions, configuration and ongoing maintenance remain the operator's responsibility.
4. A newcomer cannot yet modify the project's source code. Name three valuable contributions.
Examples include fixing documentation, reproducing and describing a bug, testing a release, improving a translation or triaging issues. Follow the project's contribution and conduct guidelines.
5. A workload needs a container registry, not a scheduler. Which ecosystem category and example fit?
Image distribution and registry storage, with Harbor as an example. Kubernetes schedules and manages workloads; a registry stores and distributes their image artifacts.