cncf-landscape

CNCF Landscape technology selection

Use this skill to turn a capability or architecture problem into a defensible shortlist of cloud-native technologies. The Landscape is a discovery and evidence source, not a recommendation engine.

When to load

Load this skill when someone:

• asks what projects or tools exist for a capability that is not in the current stack;
• wants to compare CNCF projects by maturity, category, repository signals, license, or ecosystem evidence;
• asks for a shortlist for an architecture decision, proof of concept, technology radar entry, or build-versus-buy discussion;
• needs to discover a CNCF project before reading its documentation or source repository.

When not to use

• For operating or configuring a named technology, load its operational skill or use its authoritative documentation.
• For the general adoption/hold governance process, load technology-radar and use this skill only for candidate discovery and evidence.
• For broad platform architecture, data architecture, or API design without a Landscape discovery question, use the matching methodology skill.
• For procurement, contract, export-control, or licensing advice, treat this skill's license fields as discovery evidence and obtain qualified review.

Decision workflow

1. Frame the decision before searching. Capture the capability, workload, interfaces, runtime and topology, scale and SLOs, data sensitivity, deployment model, team ownership, operational skills, budget, timeline, license constraints, and acceptable maturity risk. Separate hard constraints from preferences. If the user has not supplied these, ask for the smallest missing set rather than pretending that a category name is a requirement.
2. Discover candidates from the live API. Start with the bundled query tool:

   python3 scripts/landscape_query.py --help
   python3 scripts/landscape_query.py \
     --category "Observability and Analysis" \
     --subcategory Observability \
     --search tracing \
     --maturity graduated \
     --has-license --has-release \
     --sort stars --limit 10
   

   Load references/api.md when selecting an endpoint, interpreting a field, or diagnosing a response. Use the projects source for technology candidates. Use members or end-users only for ecosystem context; membership is not a product-quality signal.
3. Apply hard filters first. Filter by capability and category, then by explicit maturity, license, repository evidence, deployment constraints, or other user-supplied requirements. Do not turn stars, contributor counts, or CNCF maturity into implicit hard requirements unless the user asks for them.
4. Inspect the shortlist. Use the id returned by projects/all.json to fetch each project's per-record endpoint. Record the API endpoint and retrieval time. Read the project's own documentation, supported deployment paths, release history, source repository, license, and security/advisory material before making implementation claims.
5. Compare fit, not fame. Use references/decision-framework.md and references/output-template.md. Distinguish:
   • Observed: fields returned by the Landscape or statements verified in project documentation;
   • Inferred: a reasoned implication, such as likely ecosystem reach from repository activity;
   • Unknown: a requirement the available evidence does not establish. Never rank a project solely by stars, CNCF maturity, membership, or a generated score.
6. Make the recommendation conditional. Name a best fit only against the stated constraints. Include credible alternatives, excluded candidates and the reason for exclusion, material trade-offs, reversibility and migration concerns, and the next experiment that could disprove the recommendation.
7. Close with a validation plan. Define a bounded proof of concept or documentation/source review that exercises the user's real interfaces, workload, security boundary, operability, upgrade path, and failure modes. A Landscape record can identify what to investigate; it cannot prove production readiness.