The most common cloud-native selection meeting goes like this. Two engineers each favour a different tool. Both tools are well known, both are CNCF projects at the same level, and both have enthusiastic users. After an hour, the decision goes to whoever argued longest or whoever will be doing the work.
That is not a terrible way to choose, but it is an unrepeatable one. Six months later nobody can say why the choice was made, and when the champion leaves, nobody can say whether it still holds.
CloudNala recommends a short, weighted scorecard that treats maturity level as one input among several, and that weights the criteria to your organisation before anyone scores a candidate. The weights are where the real decision lives. Agreeing them first, while nobody is yet attached to a tool, is what makes the outcome defensible.
Baobab Retail Group is fictional, and its systems and figures are illustrative. Baobab's 15-person platform team needed two decisions in the same quarter: a GitOps controller to replace its pipeline scripts (the gap identified in Part 1) and an admission policy engine to stop misconfigured workloads reaching production.
Eight criteria
The scorecard has eight criteria in three groups. Each is scored from one to five against a short, written description of what each score means, then multiplied by its weight.
Project health
- Maturity level. The CNCF level, if the project has one, and its direction of travel. A project that recently moved up is different from one that has sat still for years. If the project is not CNCF-hosted, look for equivalent governance evidence elsewhere.
- Maintainer diversity. How many organisations employ the people who can merge and release? The CNCF requires at least two for graduation. More is better, and so is a governance model that stops any one company dominating.
- Release cadence and support policy. How often does it release, how many versions are supported and for how long? A predictable cadence with a published support window is worth more than a fast one.
- Security response. Is there a published process for reporting vulnerabilities, a record of handled advisories, and evidence of independent review? Open source does not mean low risk or high risk covers how to check these signals, so we do not repeat it here.
Fit for your organisation
- Integration with what you run. Does it work cleanly with your cloud, identity provider, CI system, observability stack and existing manifests? Integration debt is paid every week.
- Local skills availability. Can you hire or train people who know it, in your city and your salary band? In Johannesburg, Cape Town or Durban, the answer can differ sharply between two tools with similar global popularity.
- Managed-service availability. Is there a managed add-on from your cloud provider, or a vendor offering support, in a region you can use? Part 4 looks at this for South African regions.
Exit
- Exit cost. How hard would it be to replace? Tools that consume standard formats and keep state in places you control are cheaper to leave.
The interactive version below shows the same scorecard as a tree, with Baobab's weights for each group and criterion.
Set the weights before you score
Baobab's weights reflect a small team on one hyperscaler that cannot afford to run tools nobody understands. The group weights were agreed in a 45-minute session with the head of platform, two senior engineers and the security lead, before any candidate was discussed:
- Project health: 50 points. Maturity level 10, maintainer diversity 10, releases and support 15, security response 15.
- Fit for Baobab: 40 points. Integration 15, local skills 15, managed option 10.
- Exit: 10 points.
Two things about these weights are deliberate. Maturity level is worth only 10 of 100, because it is already partly captured by the other health criteria and because two shortlisted candidates often share a level anyway. And local skills is weighted as heavily as security response, because for a 15-person team in Johannesburg, a tool nobody can operate at two in the morning is itself a security risk.
A bank with a large platform team and strict regulatory obligations might weight security response at 25 and local skills at 5. A start-up might weight managed availability at 25. Neither is wrong. The scorecard is useful precisely because it makes those differences explicit.
Write the scoring guide
A five-point scale is only useful if each point means something. For each criterion, Baobab wrote one line for scores 1, 3 and 5. Two examples:
| Criterion | Score 1 | Score 3 | Score 5 |
|---|---|---|---|
| Local skills | Nobody on the team has used it; no local hiring pool | One engineer has production experience; some local candidates | Most of the team has used it; easy to hire for |
| Exit cost | State and configuration in a proprietary format; months to replace | Mostly standard formats, some custom resources to migrate | Standard formats throughout; weeks to replace |
The scoring guide prevents the most common distortion, which is that the favoured candidate gets fours and fives because its champion fills in the sheet.
Decision one: a GitOps controller
The shortlist was Argo CD and Flux. Both are CNCF Graduated projects, as checked on 28 October 2026 (Argo CD is part of the Argo project). Both are widely used, both reconcile clusters to the state declared in Git, and both would have closed Baobab's gap.
Baobab scored the health criteria level, giving each project the same marks. That was a conscious choice: the team did not have evidence that would separate two Graduated projects on health, and inventing a difference would have been false precision. The decision therefore came down to fit.
| Criterion (weight) | Argo CD | Flux |
|---|---|---|
| Project health (50) | 42 | 42 |
| Integration (15) | 12 | 12 |
| Local skills (15) | 15 | 9 |
| Managed option (10) | 6 | 8 |
| Exit cost (10) | 8 | 8 |
| Total (100) | 83 | 79 |
Argo CD won on local skills: four of Baobab's engineers had used it before, and its web interface mattered to product teams who wanted to see deployment status without learning a command-line tool. Flux scored higher on managed availability, because Baobab's cloud provider offered a managed add-on built on it.
Decision two: a policy engine
The shortlist was Kyverno and OPA Gatekeeper. Kyverno was announced as a CNCF Graduated project in March 2026. Gatekeeper sits within the Open Policy Agent ecosystem, and OPA is Graduated. Again, health was scored level, at 42 each.
The difference was skills. Kyverno policies are written as Kubernetes-style YAML, which Baobab's engineers already read and write every day. Gatekeeper policies are written in Rego, OPA's policy language, which nobody on the team knew. Kyverno scored 4 on local skills against Gatekeeper's 2, and finished at 78 against 72.
Notice what happened in both decisions. The maturity level, which dominates so many selection conversations, separated nothing. The margin came entirely from Baobab-specific factors. A team fluent in Rego, or one whose provider offered a managed Gatekeeper add-on, could reasonably score the same pair the other way round. That is not a weakness of the method. It is the point.
Record the decision, not just the score
A score is not a decision record. Baobab files a one-page record with each selection: the capability and gap, the shortlist, the weights, the scores with one line of justification each, the decision, the runner-up, and the conditions under which the decision should be revisited.
The revisit conditions matter most. For the GitOps choice, Baobab wrote three: the controller falls outside its supported versions for more than a quarter, the project's maturity level changes, or the team's skills shift enough that the local skills scores would reverse. Part 6 returns to how to watch for those signals.
Common ways scorecards go wrong
Scoring before weighting. If the weights are set after the scores, they will be bent to justify the favourite.
Too many criteria. Twenty criteria with small weights produce totals that all land within a few points of each other and mean nothing. Eight is plenty.
Treating the total as the decision. A four-point margin on a 100-point scale is a weak signal. When totals are close, the decision record should say which criterion actually decided it.
Forgetting the null option. Every shortlist should include "use the managed service" or "change nothing yet". Sometimes the honest score says the gap is not worth a new tool.
Next: Part 4, Managed or self-hosted: cloud native in South African regions. All parts are on the series page.
How CloudNala can help
CloudNala facilitates technology selection for platform teams. We help you agree weights before the debate starts, write scoring guides, gather evidence on candidate projects from public sources, and produce decision records with explicit revisit conditions. Our guidance is independent of any project or vendor, so our role is to make your decision defensible, not to steer it.
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