State of DevOps and Cloud 2026: What Industry Data Tells Us About Delivery Performance, Cloud Spend and Platform Engineering
A public-data synthesis of DevOps delivery performance, cloud spend and FinOps waste, platform engineering adoption and Kubernetes reality in 2026, drawn from DORA, Flexera, CNCF, Datadog, Puppet/Perforce, Gartner and HashiCorp research.
12 min read
61 views
Key takeaways: state of DevOps and cloud in 2026 5
What the public delivery-performance, cloud-spend and platform-engineering data shows, and how to read it against your own team.
- Delivery performance still splits into a wide band Roughly 15-20 percent of organizations sit in the DORA elite tier, deploying on demand with sub-day lead times.
- Cloud waste is a stable 27-32 percent band Flexera's repeated survey finding, closed by FinOps maturity work not by cutting workloads.
- Platform engineering is now a majority practice Gartner projects roughly 80 percent of large engineering orgs will have a dedicated platform team by 2026.
- Kubernetes is infrastructure, not a differentiator CNCF survey data puts adoption or evaluation at a large majority, roughly 85-95 percent, of cloud-native organizations.
- Build vs buy tracks organizational scale Smaller orgs get faster value from managed platforms. Larger orgs justify custom builds only when the platform team is resourced as a product.
TL;DR
- DORA and Google Cloud research groups organizations into elite, high, medium and low delivery-performance tiers. Recent cohorts put roughly 15-20 percent of organizations in the elite tier, deploying on demand with lead time for changes under a day, while a large middle band still ships on a weekly-to-monthly cadence.
- Flexera’s annual State of the Cloud survey has repeatedly found respondents estimate roughly 27-32 percent of cloud spend is wasted, and Gartner has forecast worldwide public cloud spending growing at a high-teens to low-20s percent rate year over year through the mid-2020s.
- Gartner has projected that by 2026 roughly 80 percent of large software engineering organizations will have established a platform engineering team, and the Puppet/Perforce State of DevOps research tracks a similar majority-adoption trend for internal developer platforms.
- CNCF’s annual survey has found that a large majority, roughly 85-95 percent across recent survey cycles, of surveyed cloud-native organizations are using or evaluating Kubernetes in some capacity, while Datadog’s container report finds median container lifetimes measured in hours, not days.
- DevSecOps and shift-left security scanning adoption has climbed steadily since the 2020-2022 supply-chain incidents, with SBOM generation and policy-as-code gates moving from a niche practice to a default expectation in regulated and FinTech-adjacent pipelines.
Method
This piece is a synthesis of public DevOps and cloud data, not a Pharos engagement count. The numbers reported here are drawn from named public industry surveys and forecasts, cross-checked against multiple report cycles where more than one source covers the same trend. Pharos contributes synthesis and advisory voice, anchored on the delivery patterns we see across our own platform and DevOps engagements, but no figure below is a Pharos-measured statistic.
Primary sources referenced: the DORA (DevOps Research and Assessment) program and its annual Accelerate State of DevOps report published with Google Cloud, the Flexera State of the Cloud report, the CNCF annual survey, the Datadog Container Report, the Puppet (now Perforce) State of DevOps Report, Gartner cloud spend and platform engineering forecasts and the HashiCorp State of Cloud Strategy Survey.
All ranges are reported as bands, not point estimates. Report methodologies differ in sample size, respondent seniority and region, so a figure from one cycle is not directly comparable to a different cycle of a different survey. No single number in this article should be read as a guaranteed outcome for any specific organization. DevOps and cloud maturity is a function of team structure, workload type and existing platform investment, not a flat industry constant.
Delivery Performance Benchmarks
The DORA program’s four key metrics, deployment frequency, lead time for changes, change failure rate and mean time to recovery (MTTR), remain the reference framework for delivery performance in 2026. DORA and Google Cloud’s Accelerate research groups respondents into four tiers.
| Tier | Deployment frequency | Lead time for changes | Change failure rate | MTTR |
|---|---|---|---|---|
| Elite | On-demand, multiple per day | Under 1 day | 0-15% | Under 1 hour |
| High | Weekly to monthly | 1 day to 1 week | 16-30% | Under 1 day |
| Medium | Monthly to every 6 months | 1 week to 1 month | 16-30% | 1 day to 1 week |
| Low | Fewer than once every 6 months | 1-6 months | Over 30% (varies by cycle) | 1 week to 1 month |
Recent DORA cohorts put roughly 15-20 percent of respondents in the elite tier, with a larger share, often a plurality, clustering in the medium band. The gap between elite and low performers has stayed wide across report cycles: elite organizations ship changes in under a day while low performers can take months for the same change to reach production. DORA’s research has also consistently found that elite delivery performance correlates with lower burnout and higher organizational performance, not just faster shipping, which is why the four metrics get cited as a leading indicator rather than a vanity metric. In our delivery work the pattern matches the public research closely, teams that invest in trunk-based development, small batch sizes and automated deployment pipelines move toward the elite tier within a few quarters, while teams that keep a manual release-train process stay stuck in the medium band regardless of headcount added.
Cloud Spend and FinOps
Cloud cost has become its own discipline. Flexera’s State of the Cloud survey has for several consecutive years found that respondents estimate roughly 27-32 percent of their cloud spend is wasted, most commonly on idle or oversized compute, orphaned storage and unused reserved capacity. Gartner’s public forecasts have projected worldwide public cloud spending growing at a high-teens to low-20s percent rate year over year through the mid-2020s, which means the absolute dollar value of that waste band is also growing even where the percentage holds flat.
The FinOps Foundation’s maturity model, Crawl, Walk and Run, is the most commonly cited framework for closing that gap, and public FinOps Foundation survey data has repeatedly found that most organizations still sit in the Crawl stage, with cost visibility established but real-time cross-team accountability not yet in place. Multi-cloud adds its own tax. HashiCorp’s State of Cloud Strategy Survey has found that a majority of large organizations run workloads across more than one cloud provider, and that decentralized tooling and ownership, sometimes described in that research as cloud chaos, is a recurring driver of both cost overrun and security gaps. Teams that plan a cloud migration in 2026 without budgeting for a FinOps practice alongside it tend to reproduce the same 27-32 percent waste band within the first year on the new platform, a pattern that matches what the public survey data shows and what we see when a migration is scoped as a lift-and-shift rather than an opportunity to right-size.
Platform Engineering Adoption
Platform engineering, treating the internal developer platform as a product with the application engineering teams as its customers, has moved from an emerging practice to a majority expectation. Gartner has publicly projected that by 2026 roughly 80 percent of large software engineering organizations will have established a dedicated platform engineering team, up from a small minority just a few years earlier. Puppet’s (now Perforce) State of DevOps Report has tracked a parallel trend, with a majority of surveyed organizations reporting either an established internal platform team or active plans to build one within the next year.
The stated goal in both bodies of research is the same, reduce cognitive load on application teams by giving them a self-service golden path for provisioning, deployment and observability rather than a bespoke toolchain per team. The organizations furthest along tend to report the platform as an internal product with its own roadmap, documentation and adoption metrics, not a shared-services ticket queue. In our advisory work the failure mode we see most often mirrors what the public research flags, teams stand up a platform team but treat it as central infrastructure ops rather than a product team with a defined internal customer base, and adoption stalls well short of the golden-path outcome the investment was meant to buy.
Kubernetes and Container Reality
CNCF’s annual survey has found that a large majority, roughly 85-95 percent across recent survey cycles, of surveyed cloud-native organizations are using or evaluating Kubernetes in some capacity, and a substantial majority now run it in production rather than only in staging or development. Kubernetes has effectively become the default orchestration layer for containerized workloads at any meaningful scale, which is why it shows up as infrastructure rather than a differentiator in most public research from 2024 onward.
Datadog’s Container Report adds an operational lens the adoption numbers do not capture on their own. Median container lifetimes reported in that research are measured in hours rather than days, reflecting the shift toward ephemeral, autoscaled and serverless-adjacent container patterns rather than long-lived pet containers. The same report has tracked rising adoption of managed Kubernetes offerings and serverless container platforms over self-managed clusters, particularly among smaller engineering organizations that want the orchestration benefit without the operational overhead of running control planes. The practical read for a microservices architecture in 2026 is that container orchestration itself is a solved, commoditized layer. The differentiated engineering work has moved up the stack, into service mesh, progressive delivery and the golden-path tooling platform engineering teams build on top of the cluster.
DevSecOps Shift
Security has moved earlier in the pipeline across most of the public research covered here. Since the 2020-2022 wave of high-profile software supply-chain incidents, SBOM (software bill of materials) generation, dependency scanning and policy-as-code gates have moved from a niche practice at security-mature organizations to a default expectation in regulated industries and FinTech-adjacent pipelines specifically. Puppet’s State of DevOps research has tracked a steady rise in the share of organizations that report integrating security scanning directly into CI/CD rather than as a separate pre-release gate run by a dedicated team.
The shift-left pattern shows up consistently across the DORA, CNCF and Puppet research streams. Static and dependency scanning increasingly run on every pull request rather than on a release cadence, container images are scanned before they reach a registry rather than after deployment, and policy-as-code tooling enforces baseline configuration before a resource can be provisioned rather than flagging drift after the fact. The trade-off the public research is candid about is triage load, more scanning surfaces more findings, and organizations that shift left without also investing in a triage and suppression workflow report alert fatigue as the most common failure mode, a dynamic that closely mirrors the signal-to-noise problem well documented in application security research more broadly.
Build-vs-Buy Platform Decision
Whether to build a custom internal developer platform or adopt a managed platform-as-a-service layer is one of the most consequential decisions covered across this research, and the public data does not point to a single right answer. HashiCorp’s State of Cloud Strategy research and the broader platform engineering survey data both suggest the decision correlates more with organizational scale and workload diversity than with a company’s stated technology preference.
Smaller engineering organizations and those with a narrow, relatively homogeneous workload profile tend to get faster time-to-value from a managed platform layer, PaaS offerings, managed Kubernetes and vendor-provided golden paths, since the operational burden of running the platform itself would exceed the differentiation it buys them. Larger organizations with a wide workload mix, strict compliance boundaries or genuine platform-as-competitive-advantage ambitions more often justify a custom internal developer platform, but the public research is consistent that this path only pays off when the platform team is resourced and treated as a product, not staffed as an afterthought on top of existing infrastructure duties. A hybrid pattern, a managed cloud and Kubernetes layer underneath a thin custom golden-path layer on top, is increasingly the modal outcome reported across the platform engineering survey data rather than either pure-build or pure-buy.
Decision Matrix
The right DevOps and cloud investment profile is a function of organizational scale and workload maturity, not a fixed budget line. Three archetypes cover most of what the public research and our own delivery work both point to.
- Early-stage or single-product team. Prioritize a managed cloud platform and managed Kubernetes or a serverless container layer over any custom platform build. Invest in CI/CD automation and basic DORA metric tracking before headcount for a dedicated platform team. FinOps at this stage means tagging and budget alerts, not a dedicated FinOps role.
- Growth-stage, multiple product teams. This is the stage the Gartner and Puppet platform-engineering research points to as the tipping point for a first dedicated platform team, built as an internal product with a golden path for provisioning and deployment. Formalize a FinOps Crawl-to-Walk transition with cross-team cost visibility, and move security scanning into CI/CD rather than a separate release gate.
- Enterprise or multi-cloud at scale. Platform engineering becomes a dedicated, resourced product organization, ideally supported by a FinOps team running at Walk-to-Run maturity with real-time chargeback. DevSecOps maturity should include SBOM generation and policy-as-code enforcement across every cluster and pipeline, matched to whatever compliance overlays apply in the organization’s sector.
Across all three tiers, the consistent theme in the public research is that platform and FinOps investment pays off fastest when treated as a product discipline with a real internal customer, not as a shared-services cost center measured on ticket volume.
Methodology Caveats and Limitations
Several caveats apply to every figure in this article. First, each source cited here uses a different survey population, sample size and methodology, so figures from one report are directionally comparable to figures from another but not strictly additive or directly averaged. Second, public survey respondents skew toward organizations engaged enough with DevOps and cloud practice to complete an industry survey in the first place, which likely biases the reported maturity distribution upward relative to the full population of software organizations, many of which do not participate in these surveys at all. Third, year-over-year figures from an annual report reflect that specific report cycle’s respondent pool, which changes year to year, so a shift in a reported percentage is not always evidence of an underlying trend and should be read alongside multiple cycles where available.
One more limitation worth naming: these figures largely predate the fuller integration of AI-assisted development and AI-assisted operations tooling into standard DevOps practice. Public research on how AI code generation, AI-assisted incident response and AI-driven FinOps recommendation tooling affect the DORA metrics and cloud waste figures cited above is still emerging through 2026, and early findings should be treated as directional rather than settled. The intent of this synthesis is to give an engineering leader or platform owner a defensible reference frame for DevOps and cloud maturity planning in 2026. Anchored on DORA, Flexera, CNCF, Datadog, Puppet/Perforce, Gartner and HashiCorp, the consistent picture is that delivery performance, cloud cost discipline and platform engineering adoption move together, and organizations that treat all three as one connected investment outperform those that fund them in isolation.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic, or clear filters
-
Public research from DORA, Google Cloud, CNCF and Puppet/Perforce shows delivery performance still split into a wide band. Roughly 15-20 percent of organizations sit in the elite performance tier, deploying on demand with lead times under a day, while a large middle band still ships weekly to monthly and a smaller low-performing group takes months per change. Platform engineering, FinOps and DevSecOps have all moved from emerging practices to majority-adopted disciplines across that same research.
-
Flexera’s annual State of the Cloud survey has repeatedly found that respondents estimate roughly 27-32 percent of their cloud spend is wasted, most commonly on idle or oversized compute, orphaned storage and unused reserved capacity. That is an industry-wide estimate from survey respondents, not an audited figure, and the real number for any given organization depends heavily on workload type and whether a FinOps practice is already in place.
-
CNCF’s annual survey has found that a large majority, roughly 85-95 percent across recent survey cycles, of surveyed cloud-native organizations are using or evaluating Kubernetes in some capacity, with a substantial majority running it in production. Kubernetes has effectively become the default container orchestration layer at any meaningful scale.
-
Platform engineering treats the internal developer platform as a product, with application engineering teams as its customers. It gives developers a self-service golden path for provisioning, deployment and observability instead of a bespoke toolchain per team. Gartner has projected that roughly 80 percent of large software engineering organizations will have a dedicated platform team by 2026.
-
The public research correlates this decision more with organizational scale and workload diversity than with technology preference. Smaller organizations with a narrow workload profile tend to get faster value from a managed platform layer.
Larger organizations with a wide workload mix or strict compliance needs more often justify a custom platform, but only when it is resourced and run as a product. A hybrid, managed cloud underneath a thin custom golden-path layer, is increasingly the modal outcome.
-
The DORA (DevOps Research and Assessment) program tracks four key delivery metrics: deployment frequency, lead time for changes, change failure rate and mean time to recovery. Together they group organizations into elite, high, medium and low performance tiers and are the most widely cited benchmark framework for software delivery performance.
-
Since the 2020-2022 wave of high-profile software supply-chain incidents, SBOM generation, dependency scanning and policy-as-code gates have moved from a niche practice to a default expectation in regulated and FinTech-adjacent pipelines. Public research also flags a candid trade-off, shifting security left surfaces more findings, and organizations that do not also invest in a triage workflow report alert fatigue as the most common failure mode.
DevOps and cloud glossary 5
- DORA metrics
- The four key delivery-performance metrics tracked by the DevOps Research and Assessment program - deployment frequency, lead time for changes, change failure rate and mean time to recovery. The most widely cited benchmark framework for software delivery performance.
- Platform engineering
- The discipline of building and running the internal developer platform as a product, with application engineering teams as its customers, giving developers a self-service golden path for provisioning, deployment and observability.
- FinOps
- The operating discipline that brings financial accountability to variable cloud spend, tracked through the Crawl, Walk, Run maturity model published by the FinOps Foundation.
- Internal developer platform (IDP)
- The self-service layer, tooling and golden paths a platform team builds on top of cloud and Kubernetes infrastructure so application teams can provision, deploy and observe their services without operating the underlying infrastructure themselves.
- DevSecOps
- The practice of integrating security scanning, SBOM generation and policy-as-code enforcement directly into the CI/CD pipeline rather than as a separate pre-release gate, shifting security earlier in the delivery process.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
