Cloud-native, the operational foundation of enterprises in 2026
The debate over cloud-native adoption is over. According to the Cloud Native Computing Foundation (CNCF) 2025 annual survey, published in January 2026, 98% of surveyed organisations have adopted cloud-native techniques and 59% report that most of their new development is now cloud-native. The share of companies running most or all of their production applications in containers rose from 41% in 2023 to 56% in 2025: the container is no longer an architectural choice, it is the default unit of deployment.
This shift changes the nature of the conversation. The question is no longer whether to adopt containers and orchestration, but how to industrialise an infrastructure that has become the operational foundation of the business: distributed architectures, daily deployments and on-demand elasticity are no longer differentiators, but baseline expectations, from customers as well as from development teams who refuse to go back.
For technology leaders, the stakes therefore move to three fronts: the internal platform that puts this infrastructure within reach of every team, the security of the software supply chain that produces it, and the economic and environmental control of an elasticity that gets very expensive when left unmanaged. This is where the value of cloud-native is now decided.
The geography of deployment has also grown more complex: most large organisations now combine public cloud, private infrastructure and edge or sovereign environments. Cloud-native is precisely what makes this hybridisation manageable: the same container images, the same Kubernetes APIs and the same deployment pipelines work everywhere, which avoids multiplying operating models per provider and preserves the reversibility of hosting choices.
Kubernetes, the operating system of the cloud and of AI workloads
Kubernetes has definitively won the orchestration battle: 82% of container users run it in production, up from 66% in 2023. The project, whose version 1.36 has been available since spring 2026, keeps a steady cadence of three releases per year and a backward-compatibility discipline that makes it a predictable foundation, at hyperscalers as well as in private datacenters and sovereign environments.
AI inference joins the cluster
A striking finding of the CNCF survey: 66% of organisations hosting generative AI models use Kubernetes to manage some or all of their inference workloads. GPU sharing across teams, training job queues, autoscaling of inference servers based on traffic: the orchestrator born for microservices is establishing itself as the de facto operating system of AI in production, and the project roadmap, accelerator scheduling, dynamic resource management, tracks precisely this demand.
Stateful workloads are now routine
Patterns once considered risky have become the norm: 79% of organisations run stateful containers in production, 64% use serverless and 39% a service mesh. Databases, message queues and caches run inside the cluster, backed by mature operators that automate backups, failovers and version upgrades. The cluster no longer hosts only the frontend and the APIs: it carries the whole system.
This centrality imposes an upgrade discipline: with three releases per year and a support window of about fourteen months per version, clusters that fall behind accumulate a dangerous debt. High-performing organisations automate their version upgrades, conformance tests, progressive node rollover, instead of turning them into exceptional projects.
Platform engineering: cloud-native on self-service
The richness of the cloud-native ecosystem carries a cognitive cost that not every product team can absorb. Platform engineering answers it: a dedicated team builds an internal developer platform (IDP) that exposes golden paths, paved roads to create a service, deploy it and operate it without directly handling Kubernetes, Helm or network policies. The complexity does not disappear: it is absorbed once, by a team equipped for it.
Developer experience managed as a product
The platform is managed as a product, with its users, the developers, its roadmap and its adoption metrics. A Backstage-style portal, template catalogues, ephemeral environments provisioned on every pull request: the time from idea to production is counted in hours, and every service is born compliant with the organisation's security, observability and naming standards, with no extra effort from the teams.
AI agents built into the platform
The defining evolution of 2026 is the integration of AI agents into these platforms: generating manifests and pipelines, diagnosing failed deployments, assisting the remediation of first-level alerts. The IDP becomes the interface through which AI acts on the infrastructure, with the platform's guardrails, quotas and traceability, rather than through direct cluster access that is impossible to audit.
Securing the software supply chain: a shared responsibility
The attack surface of a cloud-native infrastructure is no longer limited to the network perimeter: it spans the whole software chain, from source code to image registries and open source dependencies. Supply chain attacks have imposed new standard practices: SBOMs generated on every build, artifact signing with Sigstore, verifiable provenance under the SLSA framework. You no longer deploy an image whose origin you cannot prove.
Policy as code, the automated guardrail
Security policies are written and versioned as code. Engines such as Kyverno or OPA Gatekeeper reject unsigned images, privileged containers or non-compliant configurations at admission time, while the service mesh encrypts internal traffic in a zero trust logic. Security becomes a verifiable property of the system rather than a manual review at the end of the cycle.
The condition remains cultural: security must be a responsibility shared across development, operations and security teams, tooled by the platform rather than delegated to a silo of specialists stepping in after the fact. That is the whole point of DevSecOps applied to cloud-native: the controls live in the pipeline, not in a committee.
That leaves secrets and runtime: external secret managers rather than plaintext environment variables, automatic credential rotation, ephemeral workload identities and runtime intrusion detection with tools such as Falco. Defence in depth thus covers the three stages of the system: build, deployment and runtime.
GitOps and immutable infrastructure: declarative operations
GitOps has established itself as the reference operating model: the desired state of infrastructure and applications is described in Git, and controllers such as Argo CD or Flux continuously reconcile the actual state of the cluster with that declaration. Every change is traced, reviewed and reversible, the production audit reads like a Git history, and rollback is a simple revert.
Infrastructure as code after Terraform
On the provisioning side, infrastructure as code is now split between Terraform and its community fork OpenTofu, hosted by the Linux Foundation, along with general-purpose language approaches such as Pulumi. Combined with the principle of immutable infrastructure, you replace an environment, you never modify it in place, this approach eliminates configuration drift and makes every environment reproducible identically, from the developer workstation to production.
This declarative model is also what makes infrastructure governable at scale: since the entire desired state lives in repositories, security policies, reviews and automation agents operate on the same versioned substrate, whatever the number of clusters or clouds involved.
Progressive delivery completes the picture: canary releases, blue-green and feature flags, orchestrated by tools such as Argo Rollouts, expose each new version to a fraction of the traffic before rolling it out fully. Combined with observability unified by OpenTelemetry, correlated metrics, traces and logs, these techniques turn going to production from a moment of risk into a measurable, reversible non-event.
FinOps and GreenOps: steering the costs of elasticity
Elasticity has a downside: costs that drift as fast as clusters grow, especially now that inference GPUs have joined the bill. FinOps answers it by crossing financial data with engineering data: cost visibility per team and per service, rightsizing of requested resources, commitments on reserved instances and spot instances for workloads tolerant to interruptions.
Continuous optimisation driven by AI
What is new is the automation of this discipline: AI-driven optimisation tools recommend, or even continuously apply, resource adjustments and workload rescheduling. The same telemetry feeds GreenOps: measuring the carbon footprint of workloads and moving deferrable jobs to the time slots when electricity is least carbon-intensive is becoming a first-class operating criterion, on a par with cost or latency.
Mature organisations treat these signals as economic SLOs: a cost per transaction or per inference request, tracked in the same dashboards as availability, with alerts when the trajectory deviates from the budget. This convergence between finance, engineering and sustainability conditions the acceptability of cloud-native for executive management, for whom unmanaged elasticity has too often translated into unpredictable bills.
Building a cloud-native roadmap with Adservio
A successful cloud-native infrastructure cannot be decreed: it is built in stages, starting from the use cases that justify the investment, time-to-market, resilience, AI workloads, rather than from the technology for its own sake. The classic mistake is to stack up ecosystem tools with no platform and no operating model to hold them together over time.
At Adservio, we support companies along this entire trajectory: maturity assessment, internal platform design, GitOps industrialisation, software supply chain security and FinOps implementation. With one constant principle: transferring control to internal teams, so that cloud-native becomes a lasting capability of the organisation rather than a dependency on outside experts.
The right indicator of success is not the number of clusters deployed, but the speed and serenity with which a product team delivers value: deployment frequency, lead time to production, change failure rate and time to restore. It is against these software delivery performance metrics that a cloud-native trajectory should be steered and, when needed, corrected.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
