Sooner or later, someone in a platform team puts the CNCF landscape on a screen. Usually it is in a strategy session, and usually the reaction is the same: a long silence, a nervous laugh, and a question along the lines of "which of these do we need?"
It is a fair question asked of the wrong artefact. The landscape is a catalogue of what exists in cloud-native technology, sorted into categories. It was never designed to tell a Johannesburg retailer, a Durban logistics firm or a Pretoria department what to run. Read as a shopping list, it produces logo walls: architecture slides covered in project marks, each one implying a decision nobody actually made.
CloudNala's view is that the landscape is a map of options, not a recommendation, and its most useful signal is not which box a logo sits in but whether the entry is a CNCF-hosted project and, if so, at what maturity level. Read that way, and read only after you have named the job you need done, it becomes one of the best free tools a platform team has.
This series is a practical guide to that kind of reading. This first part explains how the landscape is organised and what a maturity level means. Later parts look at what graduation does and does not promise, how to score candidate projects, how managed services in South African cloud regions change the decision, the minimum platform around Kubernetes, and what is ready for AI workloads.
One note before we start. CloudNala's guidance in this series is independent. It is informed by public CNCF material, including the landscape, the project pages and the contributor documentation, but it is not endorsed by or affiliated with the CNCF. Where we state a project's maturity level, we checked it on 28 October 2026. Levels change, and the last part of the series covers how to watch for that.
Baobab Retail Group is fictional, and its systems and figures are illustrative. Baobab is a Johannesburg omnichannel grocery retailer with roughly 300 stores, an e-commerce app and a 15-person platform team running containers on one hyperscaler. Its new head of platform inherited an architecture slide with 41 cloud-native logos on it. Fourteen were in production. Nine had been trialled and abandoned. The rest were aspirations. Nobody could say which was which from the slide.
What is actually on the landscape
The CNCF landscape groups entries into categories and subcategories. On 28 October 2026 the landscape's own data file listed top-level categories that included Provisioning, Runtime, Orchestration and Management, App Definition and Development, Observability and Analysis, Platform, Serverless, Wasm and CNCF Members, along with a growing set of AI-related categories such as Inference, Training, AI Agent and AI Native Infra. Each category breaks into subcategories: Observability and Analysis, for instance, holds Observability, Chaos Engineering, Continuous Optimization and Feature Flagging.
The trap is that these categories sort by kind of technology, not by kind of entry. The same subcategory can hold four very different things.
CNCF-hosted projects. These are open-source projects the foundation hosts, and each one carries a maturity level: Sandbox, Incubating, Graduated or Archived. On 28 October 2026 the CNCF's projects page listed 39 Graduated and 38 Incubating projects, and the landscape data marked more than 150 entries as Sandbox and 28 as Archived.
Other open-source projects. The landscape's contribution guidelines say cloud-native projects with at least 300 GitHub stars that fit an existing category are generally included. That is a threshold for being listed, not an assessment. A project in this group has no CNCF level, because the CNCF does not host it.
Commercial products. Closed-source products appear too, provided they link to a clear product description. The same guidelines say commercial versions of open-source software are generally not included, with one stated exception: every Certified Kubernetes implementation is shown.
Programmes and membership. The Platform category lists Certified Kubernetes distributions, hosted services and installers, which have passed a conformance programme. Separate categories list CNCF members, certified service providers and training partners. These entries tell you about conformance or membership, not about project health.
The landscape website can filter entries by CNCF maturity level. Most logo walls lose that distinction the moment someone copies the logos onto a slide.
What a maturity level describes
The From Experiment to Trusted Platform series already covers the CNCF lifecycle in detail, so here is only the part that matters for reading the landscape.
A maturity level describes the project: its governance, its maintainers, its adoption and its processes. In short, Sandbox is early and experimental, Incubating is growing in adoption and stability, Graduated has passed the foundation's due diligence (Part 2 looks at exactly what that checks), and Archived is no longer active in the foundation.
That is genuinely useful information. A Graduated project is much less likely to disappear next year because its only maintainer changed jobs. An Archived project is a signal to plan an exit.
What a maturity level does not describe is your situation. It says nothing about:
- whether the project fits the job you need done;
- whether your team has, or can hire, the skills to run it;
- which versions are supported and for how long;
- whether anyone will answer the phone when it breaks at two in the morning;
- what it costs you to run, or to leave.
A Graduated project with no local skills, no managed option in your cloud region and a heavy configuration burden can be a worse choice for a 15-person team than an Incubating project your engineers already know. Part 2 looks at this gap closely, and Part 3 turns it into a scorecard.
The logo wall problem
Baobab's 41-logo slide is typical, and each of its failures is worth naming.
It mixed levels without saying so. Graduated projects sat beside Sandbox projects and commercial products in identical boxes. Two of the logos were projects that had since been archived.
It showed tools, not jobs. The slide had three logos in the observability area and none for secrets management. Nobody had decided Baobab did not need secrets management. The slide simply did not ask the question.
It implied ownership that did not exist. Several logos belonged to trials run by one engineer. Placing them on the official architecture made them look adopted.
It could not be checked. Without versions, owners or status, there was no way to tell whether the slide was true.
The capability architecture article in The Agentic Enterprise series makes the same argument for AI tooling: replace the logo map with a map of jobs, owners and status. The cloud-native version is identical in spirit. The landscape is where you look for candidates after you have named the job, never the place you start.
A capability-first way to read it
Here is the method Baobab now uses. It has five steps, and the landscape does not appear until step four.
1. Name the job. Write the capability in plain language, without product names. "Deploy changes to every cluster from a reviewed source of truth" is a job. "Argo CD" is not.
2. Find who does it today. Every job is already being done somehow, even if badly. Baobab's deployments were done by a mix of pipeline scripts and two engineers with cluster-admin access. Writing that down is uncomfortable and essential.
3. State the gap in one line. "Changes reach production without review, and nobody can tell what is running where" is a gap. If you cannot state it in a line, you are not ready to choose a tool.
4. Open one category. Now go to the landscape, open the category that matches the job and filter to CNCF projects first. For Baobab's deployment gap that meant the Continuous Integration and Delivery subcategory, where Argo and Flux were both listed as Graduated on 28 October 2026.
5. Shortlist two or three. Pick a small number of candidates to score properly. Include the option of a managed service or of doing nothing new, because both are legitimate answers.
The output of the first three steps is a capability statement with an owner. The output of the last two is a shortlist. Neither is a logo.
| Step | Question | Baobab's answer for deployments |
|---|---|---|
| Name the job | What must be done, in plain language? | Deploy reviewed changes to every cluster |
| Who does it today | How is it done now, and by whom? | Pipeline scripts and two admins |
| State the gap | What goes wrong because of how it is done? | No review, no record of what runs where |
| Open one category | Where on the landscape does this job live? | Continuous Integration and Delivery |
| Shortlist | Which two or three candidates are worth scoring? | Argo CD, Flux, the cloud provider's GitOps add-on |
Reading signals beyond the level
Once you have a shortlist, the landscape still has more to give. Each entry links to its repository, and the CNCF project pages show when a project was accepted and announcements record when it moved levels. Use those to ask three questions.
Which way is it moving? A project that moved from Incubating to Graduated this year is on a different trajectory from one that has sat in Sandbox for five years. Kyverno, for example, was announced as Graduated in March 2026 after joining as a Sandbox project in 2020. Kubeflow was announced as Graduated in August 2026.
Is it the project, or a part of one? Several important tools are subprojects. Argo CD is part of the Argo project, and OPA Gatekeeper sits in the Open Policy Agent ecosystem. The level belongs to the parent project, so check how the subproject you care about is governed.
Is it a CNCF project at all? Some of the most widely used tools in a category may be hosted elsewhere. Part 6 shows that this is especially true for AI workloads, where Ray and vLLM are hosted by the PyTorch Foundation rather than the CNCF. A missing CNCF level is not a warning sign. It simply means you have to find the governance evidence somewhere else.
Where the landscape genuinely helps
None of this is an argument against the landscape. Used capability first, it is valuable in four specific ways.
It reveals options you did not know about, especially in fast-moving areas. It shows consolidation: when an area once had a dozen projects and now has two Graduated ones, the market has made a decision you can learn from. It flags endings, because archived projects remain visible in the data. And it gives a shared vocabulary for categories, which makes architecture conversations faster.
What it cannot do is choose for you. That needs your jobs, your gaps, your team's skills and your constraints, none of which are on the map.
What Baobab did with its 41 logos
The head of platform rebuilt the slide in an afternoon. The new version listed 12 capabilities, not 41 logos. Each capability showed the tool in use, its CNCF level if it had one, the version, the owner and a status: production, trial or retiring.
Fourteen logos became nine production tools, because some of the "production" entries turned out to be duplicates doing the same job. Three capabilities had no tool at all, including secrets management. Two archived projects were given retirement owners. The nine abandoned trials disappeared from the official architecture and moved to a short list of past experiments with one-line conclusions.
The slide was less impressive. It was also the first architecture view at Baobab that the operations team said they could actually use.
Start this week
- Take your current architecture slide and mark every logo as CNCF Graduated, Incubating, Sandbox, Archived, other open source, or commercial. Check the levels on the CNCF's project pages rather than from memory.
- Rewrite the slide as capabilities with owners and status. Use the capability architecture method if you need a template.
- Pick one gap and run the five steps above for it. Do not open the landscape until you have a one-line gap statement.
Next: Part 2, Graduated is a governance signal, not a support contract. All parts are on the series page.
How CloudNala can help
CloudNala runs cloud-native platform reviews. We map your current platform as capabilities rather than logos, check the status and maturity of each component against public sources, identify gaps and duplicated tools, and recommend a shortlist and sequence for the changes that matter most. Our guidance is independent, and we will tell you when the right answer is a managed service or no new tool at all.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Cloud Native Platform Review or write to us at consult@cloudnala.co.za