cncf / cartografos Goto Github PK

The model has received the following feedback as part of issue #48:

Add supporting links, content in sections, pictures, diagrams, or other content to break up repetition / smaller sections.

This is discussed as part of the agenda for the community meeting on 24 January and agreed that the group will consider supporting links, graphics, diagrams etc to help break up the document based on this feedback.
This issue is to specifically track diagrams/graphics to illustrate the model effectively.

Lots of cloud native environments grow organically. Lots of large organization spending time standardizing tools or “cutting the fat”

• When do you spend time refactoring?
• What's more important refactoring vs. innovating?

What are they and how to document them in cloud native

When to provide a paved road for developers i.e. all the automation and configuration needed so they have a standard tool chain i.e. Avoid clickops where a person just clicks around to get something out.

• What is needed in the paved road for tooling?
• How to take people along this journey?
• How is it automated?

Investigate getting the cloud native maturity model published on the CNCF website.
A relevant section could be the "Community" Section, near the "Cloud Native Glossary".
Part of the this project may include

• Wireframing the model
• Relevant graphic design
• Liaison with the CNCF Web Team

We think that the maturity model is a great starting point for companies but it's a little bit theoretical and we would like to contribute in order to give some real examples and guidelines. To do so we would like to create a table where we list all the best practices divided by category (the same categories that you already used in the attached excel) and for each practice describe the level of maturity. Finally as discussed in this issue (refer to the business outcome issue) the Business Outcomes in our idea should be described per level and area and not generically per level so we put different rows in the table in order to better describe the outcomes.
CNCF Cloud Native Maturity Model - Supporting Spreadsheet (1).xlsx
We are working on a proposal, if you think that this make sense we can upload a WIP we can discuss together

"Policy and guardrails are an enormous problem."

• When do you need guardrails (and what are they).
• How to enforce them.
• What is the problem with them.

"The hardest part to automation and configuration is the people"

• Need to keep everyone on board / take them along the journey
• Mandates don’t work i.e. enter shadow IT
• People always inhibit innovation
• Culture and people are the hardest part
• Don’t deliver too fast because if the “paved road” is broken, you’ll lose trust
• Take time to launch to ensure “clear path to success” before you onboard too many people
• Slowly prove out benefits of cloud native / automation

Some comments we've heard. Have we captured the people side of the model enough. We've talked about upskilling, but what about cloud native roll outs. Who should be involved and when? How do you take people along for the ride?

In website/layouts/partials/footer.html, there is a copyright text segment:

<div class="copyright py-2">
                        <small>
                                &copy; {{ now.Year}} The CNCF Authors | Documentation
                                Distributed under CC BY 4.0</small>

but in i18n/en.toml ,also has the same info as following

[footer_all_rights_reserved]
other = " | Documentation Distributed under CC-BY-4.0"

When we plan to localize website, actually the value of "footer_all_rights_reserved" is not effective.

Advised solution:
Use dynamic variable in website/layouts/partials/footer.html instead of static text.

Create markdown format copy of model supporting sheet:
https://docs.google.com/spreadsheets/d/1wn3qxV11wAoOMBFzigeCHEHrZqWHA8wG05zRWhW7RXQ/edit#gid=2147231259

This is to allow updates to be submitted by community using standard github processes.

Our website already supports multiple languages, and I would like to propose to add support for Chinese ,this will allow more Chinese developers to understand the latest cloud-native maturity model.

I realize that a PR(#60 ) for Chinese support was previously submitted by someone else, but our maturity model has been updated to v3, so we need to resubmit it based on the new v3 version.

TODO list

See PR #64 for detailed .

When we begin our Cloud Native journey we do a lot of Click Ops... Clicking on different options, installing whatever looks good. We seem to break automation during this process we have no real process to follow. Eventually as we mature these clicks turn into defining "Everything as Code''..

• Should we add a section in the maturity model to include this concept?

The model has received the following feedback as part of issue #48:

Add supporting links, content in sections, pictures, diagrams, or other content to break up repetition / smaller sections.

This is discussed as part of the agenda for the community meeting on 24 January and agreed that the group will consider supporting links, graphics, diagrams etc to help break up the document based on this feedback.

This issue is to specifically track supporting links for the model. The group considered relevant sources the initial suggestion to make use of CNCF usecases documented here

The model has received the following feedback as part of issue #48:

• On Level 4, Helm is discussed as guidance vs. recommendation, "You’ll be expecting most of your software to be packaged with Helm with the feedback loop being closed as quickly as possible to reduce configuration drift."

  • TODO: Re-word to be a recommendation vs. direct guidance to use helm (i.e. Kustomize and other tools could do the job). I think this is well done in the earlier sections, "you may be starting to write Helm Charts..." sounds a lot better than "you're using Helm by now."

• Kustomize is discussed at lower levels of maturity and then isn't mentioned again when some folks are leveraging it at scale.

  • TODO: I think generalizing the customization tooling in early stages or group all customization tooling together and mention the group throughout (maybe a glossary term?). Alternately, replace all tooling-by-name with a generic "automated configuration and deployment tooling" blurb.

  • This isn't a Kustomize vs. Helm problem, it's a perception of the right tool for the right job potentially being ignored. There's other generators too that are popular.

• It makes sense to have the certificates from a sales point of view, but those could potentially be summarized at the beginning or end vs. sprinkled along the model.

The group agreed in the community meeting of 24 January 2023 that the the model be reworded/rephrased in line with these recommendations.

OPA is difficult and requires high maturity.
Deployment/support team(s) need to learn Rego

• Add Rego learning resources to the documentation

Update readme.md with Cartografos logo.

The group decided on 31 May 2022 that the cloud native definition from the CNCF needs to be added into the prologue of the maturity model.

Refactor before innovate - at a point during maturity do we discuss refactoring?

• should we add to the mode?
• Need to build trust and by in

I'm adding this using the feedback function from the level pages (looks great!)
However, I didn't see an option on the overview (main page). That could be intentional, but there is a lot of really great content there, so I wanted to upvote having a feedback link on that page as well.

This currently reads as:

• Level 4: Apply your policy against production in case you haven’t already. You’ll continue to tune your policies in production.

A suggestion from @Pinolo was as follows during review of issue 11:

I wonder if we could be more prescriptive about when to apply policy in production: Level 3 or L4?

We could expand a little bit this point by mentioning what we've already said in "Policy". Something like: "You'll continue to tune your policies in production, based on business needs, and you will start expanding your policy tooling."

We know that the business outcome section is the newest and we would like to improve it with some specific examples. Also it's not very clear to us if you think about Business Outcome as a new category of the maturity model (like people, technology, process and policy) or if it's a transversal topic that affects all the areas and it is different for each level of maturity. If it is the first case we would like to suggest moving the business outcome to a more transversal topic in order to give the reader a specific outcome for each area and for each level.

Create markdown versions of initial Google documents for:

• Prologue
• People
• Process
• Policy
• Technology

Markdown files to be stored on cncf/cartografos repo for community review.

Also compose update to readme.md linking to the five documents.

Update Zoom details - these currently point to Bevy, and need to move to Zoom due to difficulty of participants being able to join Zoom

I've recently got the page feedback buttons to work on the CNCF Glossary site (see at the bottom of the page). They feed events into our cncf.io Google Analytics 4 property which we can later create reports on to see which pages get good feedback, which do not.

Would we like this feature activating for the Maturity Model site? If not, please just close this issue.

It is about culture
People are the barriers of Cloud Native maturity.

• Add section in documentation to expand this concept

The Cloud Native Maturity Model requires further security and compliance updates.
Some points are as follow:
Security Scanning
Should this be emphasised through the software supply chain such as a build time as well as runtime?
What about fuzzing? Should this be a practice undertaken? The CNCF is fuzzing graduated projects.

Security Divisions within Organisations
What role do these play and for example how often should product or infrastructure teams engage with them?
What is the scope of their "powers"? Should they have the ability to direct that business critical systems be shut down or should their role be more advisory?

Access to CSP portals and tooling for developers
Should developers have direct access to cloud service provider portals and tooling or should this be arbitrated by internal tooling?
Should more senior developers have different access compared to junior developers?

Measuring Compliance
We can measure MTTR and other metrics relating to resilience but how do we measure GDPR? Is this something organisations should aspire to?

As a result of significant updates to the technology document, Level 2 of Infrastructure within the technology document is now just one sentence.

• Level 2: Because production is your goal, you’ve built Kubernetes clusters for production. Your aim is to move away from ‘pets’ to ‘livestock’ so you invest in declarative solutions for your Infrastructure as a Service with Infrastructure as Code (IaC) tooling such as Terraform, Pulumi etc.

This is now:

• Level 2: Because production is your goal, you’ve built Kubernetes clusters for production.

This requires further detail.

FinOps is becoming more important for teams to develop responsibility.

• What do you need to do first - optimize (and when);
• Second: look at saving money (when?)
• How to change the culture to adopt financial responsibility

Where does this fit into the model.

Hey all! @caniszczyk shared the model with the ex-CNCF-Ambassadors slack channel and I shared with with a few peers at Google. The following is the combined feedback:

• "A lot less meat there that I would have expected" (There was some disagreement here)
  • TODO: Add supporting links, content in sections, pictures, diagrams, or other content to break up repetition / smaller sections.
• On Level 4, Helm is discussed as guidance vs. recommendation, "You’ll be expecting most of your software to be packaged with Helm with the feedback loop being closed as quickly as possible to reduce configuration drift."
  • TODO: Re-word to be a recommendation vs. direct guidance to use helm (i.e. Kustomize and other tools could do the job). I think this is well done in the earlier sections, "you may be starting to write Helm Charts..." sounds a lot better than "you're using Helm by now."
• Kustomize is discussed at lower levels of maturity and then isn't mentioned again when some folks are leveraging it at scale.
  • TODO: I think generalizing the customization tooling in early stages or group all customization tooling together and mention the group throughout (maybe a glossary term?). Alternately, replace all tooling-by-name with a generic "automated configuration and deployment tooling" blurb.
  • This isn't a Kustomize vs. Helm problem, it's a perception of the right tool for the right job potentially being ignored. There's other generators too that are popular.
• It makes sense to have the certificates from a sales point of view, but those could potentially be summarized at the beginning or end vs. sprinkled along the model.

TL;DR: Most of the feedback is around softening the tooling recommendations, otherwise it was well received.

Update Technology on basis of working group sessions on 8th March 2022 and 22nd March 2022

Given that the cloud native landscape is changing rapidly and that a target audience for the cloud native maturity model includes individuals, the model needs review to in order to be able to assist individuals who may wish to further build out their own skills.
Topics this may include could be:

• Technical areas to focus on
• Further describing the role of process and policy. For those who have not worked in large organisations, this may be specifically relevant
  This could either be written as an enhancement to the 'People' key area, or could alternatively include sections relevant to individuals within each key area.

The model's discussion of provisioning requires further updates.
Bare Metal Deployments

The CNCF has multiple projects focussed on bare metal deployment.

• Tinkerbell
• Metall3-io

Is there value in incorporating a discussion of provisioning technology include bare metal within the maturity model?

Air Gapped Environments
Airgapped environments pose a specific challenge for deployment with no internet access at all.

Container Registries
As dependencies on these grow, they become more critical. How does the model describe increasing dependency on supporting infrastructure?

Infrastructure APIs
Is there room to further discuss infrastructure APIs such as Crossplane and how they fit in with GitOps.

Multicloud
Should organisations consider multicloud strategy? Closer integraton with one cloud service provider may allow for better and closer technical integration. Also, are their commercial or policy considerations an organisation should take into account with pursuing a relationship with a CSP?

This currently reads as:
Level 5: Here we further optimize the automation used in responses to issues by working to prevent mistakes from entering production in the first place.
This requires further updates as it is not comprehensive enough.

We identified in today's Community meeting, that we need to include information in the Technology document around the operator pattern.

Evaluate whether to include recommendation to contribute OSS projects to CNCF. The model recommends that users contribute to the opensource community, but there is no discussio about contributing software to the community.

Tool choice and efficiency is a challenge - tech debt is created as many same tools in the environment landscape

• Large amount of education is needed
• Tools need to fit use case
• Tech Debt will stunt cloud maturity growth

-- Add section to documentation

Some things we've heard:

• Manage risk with budget
• Track app lifecycle, deploy, secret management, key management
• Developer shouldn't need to know all about security
• It’s hard to prioritize security and explain it to business management

Questions to answer:

• Do we have enough in the MM on automating security so devs don't need to know what to do. How do we do it?