CTO SUMMIT

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.

Amplify maturity through organizational culture
Aligned to cloud native values

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.

Incorporate and communicate business value
into cloud native adoption

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.

Create information-sharing councils for quick
alignment 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 architecture choice

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.

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.

Level 5

• 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?

Level 5

• 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.