How cloud-native companies work differently—and better

By Noel Bravo

When I’m invited to talk about the future of enterprise technology, I often start by sharing my recent experience with an auto insurance adjuster.

My car had been damaged, and the claims adjuster came to inspect it with little more than his phone in hand. Using the phone, he did everything from documenting and assessing the damage to generating a payment invoice — a series of steps that not long ago would have been impossible to do in a matter of minutes, let alone on location.

As a customer, I appreciated the swift experience. As a cloud evangelist, I celebrated the platforms, culture and workflow that must have enabled it.

Even as a lion's share of attention has shifted to AI, many companies still wrestle with a basic challenge: making cloud investments pay off in terms of tangible business outcomes. Only one-third of respondents to Kyndryl’s Cloud Innovation Survey strongly agree they’ve achieved success with their cloud investments.

I believe one key reason is they regard cloud only as a technology solution. They lifted and shifted workloads from on premises to a private or public cloud and were stymied by complexity. I anticipate any sort of competitive advantage such a company may have gained simply by migrating workloads to the cloud will disappear in the year ahead. As we are seeing in real time, you just can’t lift and shift your way to competitiveness.

There’s an urgency to address tech debt and other smoldering issues about how technology, workflows and teams are set up to deliver for their stakeholders; to get foundations in place lest obsolescence. I think cloud-native is at the heart of that discussion. While lift-and-shift is about moving, cloud-native is about modernizing to build muscle for ongoing transformation.

The organizations experiencing greater success with their cloud investments are more likely to have embraced a cloud-native operating model—and this is much more than a technology conversation. From test cases to new product rollouts, cloud-native companies move faster, scale smarter and have the flexibility required to continuously adapt to the pace of change that AI has accelerated.

What cloud-native really means

The term “cloud-native” already is widely referenced in IT circles, but it has not yet gained traction more broadly. Only 12% of respondents to Kyndryl’s Cloud Innovation Survey  used cloud-native to describe their organization’s current approach to cloud infrastructure. The number is expected to grow to 19% within two years. Still, I suggest that’s remarkably low.

One reason may be because the term is often misunderstood. Cloud-native isn’t shorthand for a company that started with zero physical infrastructure, and it’s more than just containers or software that automates managing application containers, such as Kubernetes.

Cloud-native is a fabric of platforms, operating models and organizational psychology.

Cloud-native organizations move from traditional horizontal technology layers to modular, composable structures. This enables them to reduce tech debt, speed up time to market, and encourage innovation.

• Speed to market: Instead of quarterly release trains, ticket-driven handoffs and waiting days for environments, cloud-native companies build with modular decoupled architectures, which enables them to react quickly to shifting market conditions and opportunities.
• Limited tech debt: Because teams adopt product lifecycle ownership, automated testing and standard “paved roads” for modernization, technical debt doesn’t accumulate. Rigid legacy architectures are sunset.
• Fostering innovation:  Rather than organizing teams by function and project—such as separate units for application development, operations, and security—cloud-native organizations structure teams for end-to-end ownership and empower them to experiment.

Cloud-native also does not mean everything gets moved to the cloud. But it does mean bringing forward a cloud-native mindset and design principles no matter where the infrastructure is. For example: a payments platform may keep certain low‑latency services on‑premises for regulatory or proximity reasons, but it still uses the same cloud‑native design principles—containerized services, Infrastructure as Code (IaC), GitOps, automated testing, Service Level Objectives (SLOs) and autoscaling—across both on‑prem and public cloud so teams ship and operate in one consistent way.