Is there a paved road toward cloud native resiliency?

What does maturity mean in the software world? Especially in the cloud-native world, where progress is extraordinarily fast, new frameworks and projects are emerging all the time, and developers, engineers, and leaders are constantly being asked to learn the next new thing?

This topic was taken up by the CTO Summit, embedded inside KubeCon + CloudNativeCon North America 2022, just a stone’s throw from the Detroit River. This close-knit group of technology leaders comes from some of the largest cloud-native end users, with special thanks to event sponsor Uptypcs, which helps with container log inspection and other security features.

The CTO Summit focused on the intersection between provisioning and the cloud-native maturity model; Leaders candidly discussed the challenges, cultural shifts, and technology solutions they saw on their journey to improve the maturity and resilience of cloud-native infrastructure.

The goal of the CTO Summit was to learn from each other and uncover new insights to share with the entire cloud-native community — which has been the soul of the entire KubeCon conference, Priyanka Sharma, CEO of Enterprise Cloud Native Computing stated in her opening remarks.

“We’re starting this CTO Summit where end users, like Fidelity, Intuit, and many others can get together and have a private conversation, in a safe space, about how they’re addressing these challenges in their organizations,” she said. “We all have each other to learn from.”

Live Chat with Cloud Native Computing Foundation

What is a cloud-native maturity model?

A project of the Cartografos Working Group, with contributing members from Fairwinds, Stackegy and Accenture, the Cloud Native Maturity Model provides a framework for organizations working with cloud-native software from inception to full adoption of CNCF Landscape.

Also Read :  How to add bullets in Apple Pages

The model includes various criteria for people, policy, technology, and business outcomes, with concrete goals that must be met before an organization—or even a small team—considers itself mature enough to move to the next stage. The countries are:

  • Build: A core implementation has been implemented on cloud-native.
  • Operation: A cloud-native enterprise is built, and you’re moving into production.
  • Scale: The production environment is running, and you are defining processes for scale.
  • Improve: You improve security, policy, and governance across the environment.
  • Optimization: Decisions in previous stages are reviewed and improved based on application and infrastructure monitoring.

The goal of the model is to simplify the scope of cloud-native improvements and standardize the KPIs that KPI technical teams should strive to achieve in their path. When it works, it works fine.

Progress is being made, but still, challenges

“We’ve begun to measure [cloud-native maturity] Using speed of development, which we define as what gets shipped to our customers. We measure every version. Where we were making this journey and transferring all our capabilities [to cloud native]We noticed a 6-fold increase in development speed.

However, CTO summit participants said other challenges remain.

One participant observed that different applications, even within the same infrastructure or the same cluster, could operate at different maturity levels, and the growth was not linear.

Another participant detailed the various cultural barriers that affected each stage of maturity and how their team unlocked completely unexpected levels of technical complexity once they reached the final optimization stage.

In subsequent breakout sessions and panel discussions, the end-user participants also took advantage of the “Chatham House Rule” to openly discuss their challenges and solutions in their unique cloud-native maturity journeys.

Also Read :  Protesting workers beaten at Chinese iPhone factory

Tool choice: a top-down “paved road”, or a free-for-all?

Each participant has already faced (or will soon face) an important decision: Will they decide which cloud-native tools they build their teams with, or will they let developers and engineers develop with whatever works best for them?

In the break rooms, participants hung on to the often negative response to the “Paved Roads” toolkits, which they carefully crafted with long-term development, security, and governance in mind. Those who have recently stepped into their role or organization have faced opposition and allegations of dictatorship in the field of technology.

But the Log4j vulnerability, which affected nearly every software company at the end of 2021, was the common ground to frame this discussion. A participant with a large cloud-native infrastructure, dozens of applications, and several governance headwinds allowed teams to build with a paved deck or craft kit. When Log4j hit, their infrastructure teams, using approved tools, patched and restarted their clusters in 30 minutes. On the other hand, the application teams needed 10 days to fix and improve the security situation in the middle of the holiday season.

It’s a powerful illustration of the importance of labels and waypoints on any organization’s journey toward cloud-native maturity.

Container Logs: A ‘minor’ issue with many concerns

When a subroom moved on to talking about container logs, one participant quipped that “there’s not much” to talk about.

Everyone agreed that carelessly pulling containers from public registries like Docker Hub or Artifact Hub carries a lot of vulnerability risk. But this participant’s tech solution — a self-hosted Artifactory instance that runs security/policy scans every time their team adds a new container, whether developed in-house or obtained from a public registry such as Docker Hub or Artifact Hub — wasn’t quite received as a problem. Solved.

Also Read :  ‘I hurt my baby;’ capital murder jurors hear Mobile man tell police officer

A tech leader with plenty of cloud-native maturity across its infrastructure has warned others about the technical complexity of self-hosting a private container registry service. This organization considers its registration a zero-class service that is mission-critical, which means that a lot of thought and effort goes into the maturity stages. It’s surprisingly easy to DDoS logging your container, and your cluster can’t schedule pods if the service goes down.

Which creates entirely new problems that cannot be easily solved on their own.

These concerns are driving companies to push powerful container logging security features such as threat detection for the Kubernetes control plane, scanning container images in the logs for vulnerabilities, malware, secret keys, and more.


The spirited talks at this year’s CTO Summit went way beyond paved roads and records, providing important reminders that each organization’s cloud-native maturity is moving at its own pace, as a whole and its many constituent parts of people, applications, and cultures, with many important lessons to learn and codify among the community.

As the cloud-native landscape continues to grow with more tools, projects, and solutions to all of these challenges, CTO Summit attendees valued community above almost all else—the willingness to share, learn from each other, and mature together. They did it not as competitors, but as peers, in an industry-wide journey in the vast sea of ​​the original cloud.


Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles

Back to top button