CNCF Landscape

The CNCF Landscape is a categorized map of cloud native projects and products. It helps you explore a large ecosystem by problem area.

The landscape is not a required-tool checklist. It is also not proof that two entries work together. Use it to find candidates, then verify each candidate against your requirements and its official documentation.

Why the landscape exists

Cloud native systems involve many concerns. Teams package applications, schedule workloads, connect services, store data, observe behavior, enforce policy, and automate delivery. Each concern has many possible tools.

The landscape gives those tools a shared structure. Its categories and subcategories provide starting points for research. Its entry details can link you to project websites, repositories, and other metadata.

CNCF describes the landscape as a map of cloud native technologies. CNCF projects form one well-traveled route through that map, but the landscape also contains products and projects outside CNCF.

Read the map in layers

Start with four layers:

1. Problem area: What capability do you need, such as observability, storage, networking, or application delivery?
2. Category and subcategory: Where does the landscape group that capability?
3. Entry: Which project or product might address the problem?
4. Evidence: What do official documentation, governance, releases, security practices, and your own tests show?

This order prevents logo-first selection. A familiar name is not a requirement, and a category match is not a design decision.

CNCF status and landscape inclusion are different

An entry can appear in the landscape without being a CNCF project. Landscape inclusion means that an entry fits the landscape's scope and listing rules. It does not assign CNCF project status.

CNCF project lifecycle stages are separate. The current lifecycle defines Sandbox, Incubation, Graduation, and Archived stages. These stages describe CNCF governance and maturity evaluation. They do not tell you whether a project fits your workload, team, budget, or risk tolerance.

Read a maturity badge as one evidence signal. Then investigate the project itself.

A practical research method

1. Write the requirement first

State the outcome, constraints, and operating environment before opening the landscape.

For example: "Collect traces from services written in three languages, export them to an existing backend, and avoid proprietary instrumentation APIs."

That statement is more useful than "choose an observability tool." It gives you criteria for rejecting poor matches.

2. Find the capability area

Use the landscape's categories, subcategories, search, and filters to narrow the field. Treat classification as a navigation aid. The landscape generally places a project in one primary category, even when it spans several concerns.

3. Separate projects from products

Identify what each entry represents. An open source project, a hosted service, and a commercial product can solve related problems while creating different ownership and operating models.

Check licensing, deployment options, support, upgrade responsibility, data handling, and exit costs. Do not infer these properties from a logo or category.

4. Check project evidence

For a CNCF project, inspect its lifecycle stage and official project material. For any candidate, review current documentation, releases, governance, maintainers, security reporting, compatibility, and adoption evidence relevant to your environment.

Project activity numbers can help form questions. They do not answer whether the project is healthy or suitable on their own.

5. Test a short list

Compare a small number of candidates against the same scenario. Record installation effort, failure behavior, resource use, integration work, operational burden, and removal cost.

The result should be a decision record tied to evidence. The result should not be a screenshot of the landscape.

Common uses

• Build vocabulary for an unfamiliar cloud native capability.
• Discover projects and products in a known problem area.
• Identify adjacent capabilities around a platform design.
• Find official entry points for deeper research.
• Explain an ecosystem to teammates without presenting one prescribed stack.
• Create a long list before applying technical and organizational criteria.

Important limits

The landscape changes as entries and metadata change. Treat counts, positions, and activity fields as a current snapshot.

Classification compresses reality. A project may span several concerns while appearing in one primary box.

Metadata can come from external systems such as GitHub or Crunchbase. The landscape repository directs corrections to the corresponding source when that source owns the data.

Most of all, the landscape does not perform architecture analysis for you. It cannot know your service-level goals, regulatory duties, staff skills, existing contracts, or migration constraints.

Where this skill leads

After this course, practice turning a real requirement into a short list. Then study the official documentation for each candidate and run a controlled evaluation.

As your judgement grows, add lifecycle cost, governance, security, interoperability, and replacement strategy to every comparison. That is how the landscape becomes a useful research tool instead of a wall of logos.