End User executives gathered at the KubeCon + CloudNativeCon CTO Summit in Detroit of October 2022 to discuss strategies for adopting and accelerating the use of cloud native technology. The second CTO Summit, which built off the successful first iteration at KubeCon + CloudNativeCon Europe 2022, featured a diverse cast of 21 participants to encourage more discussion around how the cloud native community can expand the application of maturity-driven thinking.
Knowledge-sharing programs like the CTO Summit provide a forum for discussion strategies, wins, and opportunities, all of which help technology leadership better build bridges between the technology and business units within their organization.
Relaying the value of cloud native technology is paramount from the very beginning of an organization's adoption journey, which starts with the provisioning layer of the Cloud Native Landscape. Provisioning tools are used to automatically configure, create, and manage cloud native infrastructure, providing the foundation on which all their applications are built.
As organizations adopt cloud native technologies into their applications and infrastructure, they often seek frameworks to gauge the maturity of cloud native architectures to inform their strategies for adopting new tools, paradigms, and patterns. The availability of community support and resources is a crucial factor in these decision-making processes.
Cloud native maturity is defined as the level-by-level progression of an organization as it moves from initial adoption to full integration of cloud native technology in its applications and infrastructure. With goals, minimum standards, and KPIs for each level, cloud native maturity is more than a technical assessment. Organizational culture has a dramatic impact on how software is built and deployed, while business goals and customer demands drive technology decisions. Organizational maturity quantifies where technology, culture, and business intersect. The larger an organization is, the more likely its teams operate at varying levels of cloud native maturity.
How can an organization better apply this model to its respective cloud native journey, and how can it continue to refine the stages and markers of success based on real-world usage?
Summit participants were selected based on the following criteria:
- Ownership of technical decision-making, budget, and platform/application KPIs
- Awareness of the cloud native landscape, but with a diversity of practical experience, to best explore the practical applications of the Cloud Native Maturity Model
- Experience in implementing cloud native provisioning tools from a managerial perspective
Industries represented at the Summit included financial services, aerospace, automotive, e-commerce, media services, retail, lifestyle, manufacturing, and more. Participants are leading information technologists in their organizations, with the responsibility to scope new opportunities and lead multiple teams toward a common goal.
Most importantly, all the Summit participants are part of CNCF's end user community. These are organizations that use cloud native technologies internally and don't sell any cloud native services externally. The End User community excludes vendors, consultancies, training partners, and telecommunications companies.
In this report, we'll cover the main takeaways from this year's CTO Summit and showcase opportunities where members of this community can continue to learn from one another.
This report is made possible because the cloud native community has always prioritized learning and sharing. Every day, countless individual contributors volunteer their time and knowledge to teach others despite the projects they contribute to, their organizations, their personal and professional education, or the challenges they face in their daily lives. Under the Cloud Native Computing Foundation (CNCF), the community diligently maintains these traditions to make cloud native computing a sustainable solution for more real-world problems.
Choosing the right cloud native tools to solve a specific provisioning problem, and establishing procedures and policy to match, can't happen in a vacuum. Those choices need to account for where the organization is in its cloud native journey, which can vary between units, teams, or even applications. Technology leaders are asking—a request repeated often at the CTO Summit—for a methodical approach to identify the cloud native maturity of each component within their organization, which helps them not only identify the right technical solutions, but also address people, process, and policy.
Under the Cartografos Working Group, the CNCF worked with internal collaborators and industry representatives from Fairwinds, Stackegy, and Accenture to develop the Cloud Native Maturity Model (see Appendix B for details). The Model formalizes states, goals, and key performance indicators (KPIs) in five dimensions and five levels of maturity, which dramatically simplifies how technology leaders identify their maturity levels, identify goals, and design more targeted strategies for adopting cloud native technology to run scalable applications and solve real business challenges.
The Model maps to several organizational archetypes:
- Businesses starting down the path of digital transformation
- Organizations wanting to adopt projects of the CNCF landscape with a trusted framework
- Open source and CNCF projects and practitioners wishing to use or contribute to the Model
- Executive leadership looking to understand the benefits of cloud native, scope of effort, and level of investment
- Technologists wishing to implement cloud native technology but need to understand the journey better ahead from a technology and business perspective
Continuing to discuss and promote the Cloud Native Maturity Model, and further investigate ways to integrate standards and KPIs into the culture of end user organizations is paramount to how end user organizations formalize and optimize their cloud native strategies.
Participants agreed that culture remains a difficult roadblock for successfully adopting cloud native technology, particularly at the provisioning layer, which is always the first step in adoption and migration. Multiple participants noted that as newer members of their organization, they face additional friction in rolling out cloud native technologies.
Participants stated that they would prefer to create a straightforward experience for their development teams and a standardized toolkit that solves configuration, security, and compliance concerns for them. But they must tread carefully and find a delicate balance between providing repeatable patterns and not creating an unsustainable workload at consolidating development, operations, DevOps, and security.
Part of this resistance is, as many Summit participants pointed out, an unfamiliarity with translating the value of cloud native technology to their peers in business units. This was true regardless of their background, experience, or industry vertical. But rather than this being a challenge for Summit participants and other end user leadership to solve on their own, it's a signal that the Cloud Native Maturity Model is shaping up to be a viable framework for creating a common language between technology and business units.
We are enormously grateful to the Summit participants for their spirit of transparency and for sharing knowledge that teams can leverage for adopting cloud native tools and projects to solve real-world business problems.
CTO Summit participants presented many challenges and solutions to help their peers on each cloud native journey. They aligned on specific calls to action based on internal success stories:
Drive informed organizational strategies by understanding an organization's place in the Cloud Native Maturity Model
Many end user organizations have codified methods of tracking their cloud native migration and adoption, a dynamic first step. But when people create a system in a vacuum, they miss out on essential lessons from the cloud native community based on real world results.
Maturity levels can vary application by application, team by team, database by database, cloud provider by cloud provider. Being at a single level of maturity across an organization is quite rare and not a typical scenario.
The people behind the Cloud Native Maturity Model have worked with many end user organizations to define the states and KPIs for each combination of Level and dimension. Instead of implementing a cloud native strategy from scratch, organizations can immediately benefit from standards and goals validated by other end user experiences.
Make informed decisions by utilizing the Cloud Native Landscape
Technology leaders struggle over whether to dictate a set of approved cloud native tools or let teams self-organize around technology that works best for a particular use case. Tool choice remains a difficult balance between flexibility and efficiency and typically is only possible after a latent period, without innovation, where teams standardize, refactor, and “cut the fat” to make way for cloud native technology.
Many participants agreed on taking a collaborative approach of standard tools over custom frameworks. For example, in a major CVE, an organization can fix deployments based on standard tooling with a single bot for creating PRs with an approved fix versus engineers spending time diagnosing, testing, and deploying a patch for their custom toolkit. When platform engineering teams can design and standardize a rich and effective environment, developers suddenly realize the utility of having a standard toolkit and proven workflows.
Ideally, the standard tooling approach integrates many valuable tools into as simple an output as possible to prevent building an unsustainable ecosystem inside an organization. Developing that solution is a multi-year challenge, and all these decisions get far more complex when an organization expands across regions. Leaders should continue referencing the Cloud Native Landscape for insights on new technologies that can simplify tool choice for everyone.
Organizations need to be wary of packaging too much complexity into their toolkits, or else they will overwhelm developers by having to also work as operators, platform engineers, security experts, and more.
through organizational culture
Aligned to cloud
Cloud native adoption is as much a people and process equation as a technology one. An organization can shift left security and implement every technological solution, from multi-tenant models and policy checks. However, it still requires cultural collaboration to keep teams aware of troubling trends and best practices.
Changing an established software development culture takes far more work than convincing the CIO/CTO to dictate how things should work and get teams in line. This is even more true for those traditionally underrepresented in technology spaces. An entire organization, including business units, must buy into the positive impacts of a technological shift on responsibility and collaboration.
According to CTO Summit participants, every cloud native maturity journey will face a degree of “status quo” mindset, which resists not technological change itself, but rather shifts that affect day-to-day operations. Even the most well-intentioned practices and cultures, like DevSecOps, are often received as an attack on the way they've successfully worked for years or decades. A frontend developer, for example, who is now responsible for the frontend, the backend, the entire product lifecycle, configuration and deployment of the infrastructure, while ensuring the entire surface area of the application is secure through its entire lifecycle, might be fairly skeptical of cloud native adoption.
Cloud native technology performs best with empowered cross-functional teams, like DevOps or platform engineering, which operate as a friendly and knowledgeable middle ground between development, operations, and security experts eager to implement. Cross-functional teams can support specialists with guideposts and best practices that help them experiment and deploy with confidence and reliability in mind.
At each level of an organization's [cloud native] maturity, they should communicate the value of this whole movement.
communicate business value
into cloud native
For many business leaders, the migration and continuing adoption of cloud native technology are not as clear-cut as migrating workloads as-is from on-premises to hybrid/public clouds. They are unlikely to sign off on major technological shifts, which inevitably create process and cultural change, without understanding the tangible benefits to them.
Organizations must develop meaningful processes for sharing information and results between technology and business units, which might mean seeking out new talent with technical expertise and passion for sharing information. The highest-performing organizations actively coach their team members through recruiting or internal up-skilling to help create more certainty in their roles, leading to fewer bets and creating a more educated organization.
Participants strongly agreed in wanting more open discussions over what their peers in the end user community are using to solve their technological challenges.
information-sharing councils for quick
on cloud native strategy
According to Summit participants, culture and people are the most challenging part of an organization to move and mature. This is exacerbated by movements in the ever-changing technology landscape, like DevOps or shift-left, which create deep ripples in how people collaborate on the job.
Participants strongly agreed that talented employees are the solution if they're given ample opportunity to share their knowledge and learn from one another.
One proven solution is councils, which consist of a single senior member or leader from each time across the organization. By getting these folks in the same room, they can discuss and disseminate opportunities for improving security and compliance, lessening the individual burden to learn the modern best practices or make collective decisions on what success looks like. It's a top-down approach that prioritizes peer-to-peer education, prioritizing people and improving culture.
Transition from free
tool choice to a paved
road strategy unlocks
The era of free tool choice, whether through ClickOps or giving developers console access to deploy infrastructure on their whim, inevitably needs to end as an organization matures its cloud native posture. CTOs will fight a losing battle against security and compliance issues or struggle with maintaining a competitive velocity. They can stand up quickly and optimize freely if they don't have an agreed-upon package.
The CTO Summits participants offered many options for exploring and defining a paved road of cloud native tools that works for an organization's unique needs, culture, and business/governance environment:
- Create as many POCs as possible, using them as opportunities to review open source code and/or their vendors.
- Evaluate vendors by analyzing their company size, funding, their place on Gartner's Magic Quadrant, and analyst reviews.
- Freely dogfood new tools and clusters for internal use cases to deeply test new projects without interrupting the customer experience.
- Slowly prove out cloud native tools and workflows, recognizing an organization might only use the technology for 3-4 years as the Cloud Native Landscape adopts new ideas.
Engage in opportunities
to contribute to the
convergence of tool and
As much as the Summit's participants advocated for a paved road and wished they could simply implement a stack of “best practices” tools and configurations, defining that goes against the CNCF's mission of neutrality. CNCF leverages groups like the Technical Oversight Committee (TOC) not to pick favorites but to accept feedback from the end user community to define the visions, standardizations, and best practices to be applied across the landscape.
The cloud native landscape should thrive where it's most proven by driving business value, and it hasn't yet converged on a single paved road.
A valuable opportunity for any end user organization is the ability to influence the direction of the cloud native community by sharing their experiences and insights on how these tools have effectively addressed real-world business challenges and delivered value to customers. By sharing their knowledge and expertise, end users have the power to shape the development of future cloud native solutions.
During this Summit's breakout rooms, participants focused on the intersection between the Cloud Native Maturity Model and the provisioning layer of the cloud native landscape.
The Cloud Native Maturity Model has five dimensions and five levels, and the provisioning layer is broken up into four subcategories. If participants in the breakout sessions tried to focus on each of these combinations, they'd have to wrestle with 100 points of conversation. Instead, participants focused on the four subcategories of the provisioning layers in terms of people, process, policy, and technology.
Provisioning is the first layer in the cloud native landscape, encompassing tools used to create and harden the foundation on which cloud native applications are built and deployed. This extends into tools for applying security and governance policy, managing keys and secrets, and how an organization delivers containers, the fundamental cloud native building block, to its clusters.
Automation & Configuration
These tools speed up the creation and configuration of compute resources, allowing developers to iterate and deploy far more rapidly than on infrastructure of the past. With declarative configuration and infrastructure-as-code (IaC), one can reproduce any cloud native infrastructure or application with a single click.
Registries store and categorize repositories of containers, allowing users to pull, build, and run containers from a centralized, standardized, and secured source. These tools are more than a web API that returns an image, scanning the underlying code for CVEs or policy violations that would put an organization at unnecessary risk.
Security & Compliance
This subcategory of tools provides assurance and confidence that despite how quickly cloud native applications are iterated on and deployed, it always happens in a secure and policy-driven way. Use cases include automatically detecting vulnerabilities, flagging misconfigurations, and hardening containers or the Kubernetes control plane.
To meet many of those security and compliance requirements, along with the on-demand nature of cloud native infrastructure, organizations need to securely store sensitive data, like encryption keys, in a way that's programmatic and automated. These tools maintain proper access by introducing authentication and authorization, understanding whether a request is valid, and having permission to take action.
The following two sections contain the condensed takeaways and advice from the two breakout sessions.
The points below represent advice, opinions, and proposed best practices from more than a dozen end user organizations from many verticals. They should not be considered as recommendations from the CNCF, endorsements of any particular strategy, or a checklist required to reach any level in cloud native maturity.
Breakout session 1Automation & Configuration + Container Registry
Levels 1 and 2 of the Cloud Native Maturity Model
Agree on internal definitions for automation and configuration (and configuration automation).
For some, that means all their platform and applications run on Kubernetes, all their configuration is in ConfigMaps or built into the containers themselves, and their CI/CD pipeline deploys everything. The details are less important than ensuring technology and business teams are on the same page.
Spend more time validating tool choices when bare metal is involved.
Organizations responsible for the foundation beneath the cloud native foundation must spend additional time validating their toolkits and running proof of concept infrastructure.
Be aware of where containers come from.
Containers from popular public registries can include vulnerabilities, low-quality code, or unknown third-party libraries.
Balance between risk and efficiency through automation.
Setting up a complete auto-scaling solution, from the tooling one uses to close negotiations with their public cloud provider, is often not the cheapest. But it will likely come at a lower overall cost, factoring in time and additional development effort for an organization.
Determine the level of container scanning security that's ‘good enough.'
All organizations should scan all their containers, whether self-hosted or on a public registry, for known CVEs during development and deployment as a baseline.
Levels 3 AND 4
The maturation process will feel like a crawl for a long time.
Transitioning to a cloud native foundation, including every process from code commit to shipping a product to production, requires considerable planning and oversight.
Recognize that automation has a litany of complicated subplots.
Aside from standing up a Kubernetes cluster, automation and configuration tools are also responsible for resiliency, resource optimization, developer productivity, horizontal/vertical scaling, resourcing with cloud providers, load balancing, and more.
Start hosting containers internally.
An organization can scan and generate reports based entirely on its organization's security, governance, and risk profiles, disallow public registries, and guarantee its cluster never runs a container without explicit approval.
GitOps enables powerful ‘cloud native, but not in the cloud' experiences.
With a single repository for stamping out many instances of a valuable stack, one can enable localized, experimental, or air-gapped teams to launch infrastructure based on cloud native technology without being run in the cloud.
The ratio between cloud native tooling vs. internal “glue” code is a good maturity signal.
Many organizations balance processes built ten years ago with brand-new cloud native infrastructure and applications. But, if an organization has dispensed with many of the custom Bash scripts and internal Go libraries for automation and configuration, it's on the right track.
Resist the urge to give developers direct web console access to cloud providers.
When teams want to spin up cloud native resources for experimentation, there can be misunderstandings around access to cloud-specific roles, access, services, and APIs. Teams want a self-service experience, provided by a platform team that offers expertise of a specific cloud or compute platform.
When an organizations establish provisioning, each incremental category becomes easier to adopt.
As organizations tie-up the latent period to standardize their provisioning tools and move into innovation, they'll unlock new technological and cultural complexity levels.
Create different experiences for platform teams and developers.
Those building platforms on top of infrastructure require lower-level automation and configuration. By separating infrastructure configuration from application configuration, an organization can provide a cloud native experience for both teams that work at their level.
Prepare automation for the unexpected (and expected).
For example, organizations running e-commerce sites must create advanced plans on a provisioning level to override or bypass established configurations to deal with holiday rushes or unexpected events.
The container registry becomes a CDN-like service with ‘Tier 0' uptime requirements.
To keep clusters pulling containers happily, one must prevent a self-inflicted DDoS with a multi-region, multi-cloud resilient service.
Continuously educate teams.
Run internal classes to teach development teams best practices on auto-scaling (vertical and horizontal), the differences between node and pod auto-scaling, resource planning, and more.
Prioritize making lives easier over chasing diminishing efficiency returns.
At this point in an organization's journey, additional cost optimization might inadvertently increase its risk. Instead, focus on improving developer experience and productivity.
Breakout session 2Security & Compliance + Key Management
Levels 1 and 2
Know that security and compliance are two distinct (but converging) conversations.
Security is about locking down and protecting applications and infrastructure. Compliance is about defining a policy and doing what that policy demands.
Feel comfortable experimenting with new security tools.
Unlike the tool(s) an organization uses to configure or automate clusters, it can more quickly adopt a tool that scans containers for CVEs or runs a policy engine to check Kubernetes manifests for misconfigurations.
Plan ahead for the expense of security maturity.
Development teams must implement secret, key, certificate management, network protection, penetration testing, and regulations requiring years of audit logs to do security right. Proper planning accounts for both operational and capital expenditures.
Know that making a million mistakes along the way is normal.
Recognize that every organization can and will get things wrong on its journey toward standardized platforms that abstract security away to simplify workflows for application development teams.
Create standards for key management.
An organization should know how long processes take for operations like key rotation in case of a breach and other governance requirements.
Levels 3 AND 4
Continuously build a culture of shifting security left into early applications.
Consider running security architecture reviews (SAR) to assess the security of new applications across infrastructure, application, people, and processes.
Empower security teams with administrative roles.
When teams receive data about a potential vulnerability, they can meet with the relevant team to discuss the implications and design a fix. If the service isn't patched within an agreed-upon timeline, the security team has the right to shut the service down.
Good governance requires strong alignment on tool alignment.
To create a solution that meets an organization's cloud native maturity, it will need a “paved road” toolkit that includes data security, data access, and customer access.
Going multi-region uncovers new security and compliance issues.
For example, how do teams move workloads in a way compliant with all the regions they collect, store, and send user data to? How do they design and enforce these policies?
Create security councils for disseminating best practices.
Organizations should regularly get its development team leads into the same room as security leadership to organically educate and spread awareness of dangerous trends or new opportunities.
Investigate how to monitor compliance levels and determine success criteria.
Some organizations might aim for a specific percentage of compliance, such as 70%, while others might rely on compliance engines that regularly generate reports on misconfigured policies for manual review. DevOps teams often use key performance indicators (KPIs) such as mean time to recovery (MTTR) to measure resiliency, but determining the success of compliance efforts can be less straightforward. It is important for organizations to consider their specific compliance needs and goals carefully and to establish clear metrics and processes for monitoring and evaluating compliance levels.
Maturing the definition
Cloud Native maturity
Throughout the Summit, participants noted how refreshing it was to speak candidly with other end users about real-world usage of cloud native provisioning tools. In this setting, they could compare and contrast their definitions of maturity against other organizations and what's already codified in the Cloud Native Maturity Model.
The content of their discussions is a valuable signal, for the CNCF and the Cartografos Working Group, as they work on refining the KPIs and goals for each level and each dimension of the Model.
Cloud native maturity model
Cloud native maturity isn't an all-in, perfectly-linear journey. Every end user organization, progresses at a different speed. Participants welcomed the honest discussions and recognized that cloud native maturity is core competency. Organizations are not competing by trying to leave one another behind, but mountaineers tethered to one another towards a common goal.
Participants generally agreed on the following practical takeaways:
- Encourage more discussion from end user contributors to the CNCF around how to set KPIs for cloud native maturity and build cultures eager to meet those challenges.
- Investigate novel ways to communicate the business value of cloud native, both within end user organizations and through the CNCF.
- Continue the CTO Summit at the next KubeCon + CloudNativeCon gathering in 2023 with a focus on different layers of the Cloud Native Landscape, such as Runtime, Orchestration & Management, App Definition & Development, Observability & Analysis, or Platform.
Given the mission of enabling collective learning for every organization, whether contributing to the landscape or building new end user experiences with the tools represented, the CNCF continues to explore better ways to disseminate information about the Cloud Native Maturity Model.
Appendix A: Summit Process and Discussion Framework
The Summit began with introductory remarks from Taylor Dolezal, Head of Ecosystem at CNCF. Dolezal got participants on the same page regarding the areas and levels of the Cloud Native Maturity Model and then detailed the provisioning layer of the cloud native landscape, which includes significant subcategories: Automation & Configuration, Container Registry, Security & Compliance, and Key Management.
The Summit operated under Chatham House Rule. This verbal agreement between participants in a meeting or discussion states that they are free to use any information they gather from their conversation but not attribute any comments to a particular person or organization.
This rule applied during the introduction and breakout sessions. Participants spoke freely about their journeys as leading technologists into cloud native, even if they expressed views at odds with their organizations or executive leadership peers. This also allowed participants to candidly discuss the effectiveness and promise of cloud native projects, based on real-world applications without concern for how the community might receive their comments.
Participants split into two breakout sessions based on role and business vertical. Each breakout session had a facilitator responsible for generating discussion and moving conversations between four subcategories, as indicated by the Summit's schedule. CNCF recorded each breakout session, with additional notes taken by contributors to the CTO Summit, to discover and collate critical findings in this report.
There was no formal discussion framework for the breakout sessions. Unlike the previous CTO Summit, participants had more unstructured time to create more open discussions, letting them expound on specific topics or track down unexpected but fruitful conversations. Participants still had the Summit's core discussion points, the Cloud Native Maturity Model and the four subcategories of provisioning tools, to guide their discussions with the help of the facilitator.
Appendix B: What is the cloud native maturity model?
Organizations begin on their cloud native maturity journey as soon as they've driven consensus on the business outcomes they would like to achieve. Technological transformation via the cloud native landscape is a productive journey but not always straightforward. A shared organizational goal helps guide technology leadership through the inevitable difficult decisions ahead.
Achieving the right business outcome happens at the intersection of technology and culture. The Cloud Native Maturity Model helps organizations align on a single set of goals, KPIs, success stories, and opportunities that incorporate both.
In addition, the Model is flexible enough to be applied to multiple units within a single organization or even from application to application to identify small-scale and organization-wide states, which drive more confident and precise strategies for continued improvement.
There are five dimensions of the Cloud Native Maturity Model, which ask essential questions about the nature and structure of an organization:
How does an organization work, and what skills does it require to move from adoption to immersion in cloud native technology?
How does an organization leverage technology to codify workflows and security in code and CI/CD?
What policies are required to meet security and compliance standards, and how are teams using tools like CI/CD to shift left security?
How does cloud native technology support and augment the organization's people and processes for better observability, security, and more?
How does cloud native drive genuine business value for the organization, and how does it communicate that value to leadership?
And within each dimension, an organization can progress through five maturity levels:
Level 1: Build
Teams have baseline cloud native implementations and successful proof of concepts (POCs). Initial findings are found and shared on how cloud native will help improve applications and services.
Level 2: Operate
Cloud native is an established solution, and workflows are moving to production. The ability to evaluate the benefits of the migrations. Most organizations reach this level of maturity and plateau.
Level 3: Scale
Cloud native teams build their confidence, security, efficiency, and competence while implementing processes for scale. Organizations have started to notice that services are more scalable.
Level 4: Improve
The organization focuses on improving security, policy, and governance across environments, and time gets spent on business problems instead of cloud native maintenance.
Level 5: Optimize
Teams continue to revisit earlier decisions and optimize workloads, in a continuous cycle of improvement, based on advanced and performance metrics created by observability tools.
Appendix C: Glossary
API: Application Programming Interface
CNCF: Cloud Native Computing Foundation
CTO: Chief Technology Officer
CVE: Common Vulnerabilities and Exposures system
MTTR: Mean Time To Recovery
SAR: Security Architecture Review
Detroit Photo Highlights
A big thank-you to the CNCF for designing and hosting the second CTO Summit this year at KubeCon + CloudNativeCon in Detroit.
We're all indebted to the CTO Summit committee, whose members are responsible for deciding the content discussed and creating bridges with other end user organizations still ramping up their participation in CNCF and CTO Summit activities:
- Amr Abdelhalem (Fidelity Investments)
- Arun Gupta (Intel)
- Henrik Blixt (Intuit)
- Ricardo Torres (Boeing)
- Pratik Wadher (Intuit)
- Priyanka Sharma (Cloud Native Computing Foundation)
- Hilary Carter (Linux Foundation Research)
The breakout sessions were home to vibrant and valuable conversations thanks to our three facilitators: Henrik Blixt (Intuit), Ricardo Torres (Boeing), and Jeff Sica (CNCF). We're indebted to their conversational natures and deep knowledge of the cloud native landscape, which established a spirit of transparency that got participants talking openly about their challenges and opportunities. A special thanks to our note-takers, Danielle Cook (Fairwinds), John Forman (Accenture), and Simon Forster (Stackegy). Their hard work helped create this report and, more importantly, helped the CNCF and Cartografos Working Group internalize many vital lessons.
The Cartografos Working Group has spearheaded the Cloud Native Maturity Model and worked enormously hard to codify its dimensions, levels, and guidelines. The entire cloud native ecosystem is grateful for these efforts.
Thanks to Uptycs for generously sponsoring the Summit, including the reception and dinner that followed this event on October 26, 2022.
We've gone long enough without thanking Taylor Dolezal, the Head of Ecosystem at CNCF, for being a bright waypoint for the end user community. Without him, we wouldn't have such an inviting culture of openness and willingness to learn from one another. We're also enormously indebted to the 21 participants of this autumn's CTO Summit, who contributed invaluable insight not only for this report but also for the continuous improvement of the CNCF's End User Community and Cloud Native Maturity Model.
Your comments and feedback at firstname.lastname@example.org
The Cloud Native Computing Foundation (CNCF) hosts critical components of the global technology infrastructure. It brings together the world's top developers, end users, and vendors and run the largest open source developer conferences. CNCF is the open source, vendor-neutral hub of cloud native computing, hosting projects like Kubernetes and Prometheus to make cloud native universal and sustainable. The CNCF is part of the Linux Foundation.
Thanks to our CTO Summit Sponsor
Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.
To reference this work, please cite as follows: “CTO Summit Report NA 2022: Exploring the Foundations of Cloud Native Maturity,” foreword by Amr Abdelhalem, Arun Gupta, Ricardo Torres, Pratik Wadher, and Hendrik Blixt, The Cloud Native Computing Foundation.
This report is provided “as is.” The Linux Foundation and its authors, contributors, and sponsors expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, noninfringement, fitness for a particular purpose, or title, related to this report. In no event will the Linux Foundation and its authors, contributors, and sponsors be liable to any other party for lost profits or any form of indirect, special, incidental, or consequential damages of any character from any causes of action of any kind with respect to this report, whether based on breach of contract, tort (including negligence), or otherwise, and whether they have been advised of the possibility of such damage. Sponsorship of the creation of this report does not constitute an endorsement of its findings by any of its sponsors.