Cloud Native
Cloud native describes an approach to building and operating workloads, rather than a particular hosting product. CNCF’s definition v1.1, approved in February 2024, emphasizes repeatable, programmatic operation at scale in public, private, or hybrid environments.
The definition names loose coupling together with security, resilience, manageability, sustainability, and observability. These qualities describe how components operate together, so installing a platform is only part of the work.
The technology list is explicitly secondary
CNCF lists containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs as examples that can be combined. It explicitly leaves the list open.
The examples can help achieve the qualities, but none is an automatic test of them. A system can use all of these technologies while retaining tightly coupled data access and coordinated releases. Evaluate the behavior of the system and its dependencies alongside the tools it uses.
That is why are we cloud native yet is better answered by examining coupling than by inventorying tools. Two services that share a database and must be released together are tightly coupled whatever they run on.
Five qualities, as five questions
The following questions are practical checks inspired by the five qualities, rather than an official certification test or a complete definition of each.
| Quality | The question that tests it |
|---|---|
| Secure | Is identity and authorization enforced between components, or assumed because they are inside the same network? |
| Resilient | What happens to component A when B is down or slow? If the answer is A is also down, the coupling is temporal |
| Manageable | Can teams configure, change, and operate the system predictably, with clear responsibility and repeatable procedures? |
| Sustainable | Can the team keep operating this in a year — patching, upgrading, and paying for it — without the effort growing faster than the system? |
| Observable | Can you tell what happened from the outside, for a request that crossed several components, without adding instrumentation first? |
The resilience question requires tracing dependencies. Moving a required in-process call onto a network adds a communication failure path. Whether overall availability improves depends on failure handling, redundancy, and the dependencies that remain shared; service count alone cannot decide it.
The stated benefit is conditional, which makes it a test
CNCF links these practices and automation to the ability to make frequent, predictable changes with less toil. Assessing that ability requires knowing what improvements the organization wanted.
For a team delayed by coordinated deployments, measure change lead time and failed rollouts. For a team burdened by manual operations, measure the recurring work removed. Compare similar workloads and change types. Actual release frequency also reflects demand, so an unchanged count does not by itself show that the architecture failed to improve delivery.
The definition does not prescribe a product stack, organization size, or migration sequence. Microservices are optional, which leaves room to apply these principles to a modular monolith with well-maintained boundaries. CNCF’s vendor-neutral ecosystem supports many implementations; choosing one still requires evaluating the organization’s needs.
One caveat about the term itself: the definition is versioned and has been revised, so quote the version you checked. How the definition translates into decisions about boundaries, data ownership, and what a split costs is worked through in Splitting the System Was the Easy Part.
References
- CNCF Cloud Native Definition v1.1 (approved 2024-02-26)
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.