The Core Argument: Combination Beats Either Approach Alone

DevOps and cloud computing are each powerful levers for improving software delivery. But according to a study from CA Technologies, organisations that adopt both together see dramatically better results than those that rely on only one of the two approaches.

CA surveyed more than 900 senior IT professionals worldwide to understand how high-performing organisations were achieving software delivery success. The headline finding: 81% of respondents who combined DevOps methodologies with cloud-based tools and delivery mechanisms reported an overall improvement in software delivery performance, compared with:

• 52% who reported improvement using DevOps practices alone
• 53% who reported improvement using cloud tools alone

CA labelled these high-performing, combined-approach organisations “delivery disruptors”, contrasting them with “slow movers” — organisations still relying heavily on traditional IT delivery methods.

How Delivery Disruptors Outperform Slow Movers

The study quantified performance gaps between delivery disruptors and slow movers across four key dimensions:

Beyond the headline numbers, delivery disruptors also reported benefits including:

• Greater end-to-end automation across the delivery pipeline
• Increased agility and flexibility in responding to change
• Improved time, scope and budget management
• Fewer defects in released software
• Measurably improved customer experience

Why the Combination Amplifies Results

DevOps and cloud computing address complementary problems. DevOps focuses on cultural change, collaboration between development and operations teams, and automating the software delivery lifecycle. Cloud platforms provide on-demand infrastructure, elastic scaling and a rich ecosystem of managed services that reduce operational overhead.

When the two are combined, teams can:

• Provision and tear down environments programmatically, eliminating the bottlenecks that slow release cycles in traditional on-premises setups.
• Integrate cloud-native CI/CD services with DevOps toolchains, reducing manual handoffs between build, test and deploy stages.
• Scale test environments on demand, making it practical to run comprehensive automated test suites without dedicated hardware.
• Shift cost from capital expenditure to variable operational expenditure, aligning infrastructure spend directly with delivery activity.

Ayman Sayed, then president and chief product officer at CA Technologies, summarised the business case: “Today, being built to succeed means being built to change. Working around the world with customers of all sizes, this change manifests in the move to public cloud workloads for greater flexibility, agility and cost efficiency. Now the data proves the benefits and value of the approach.”

What This Means for DevOps Teams in Practice

The study’s findings reinforce a broader industry trend: adopting DevOps practices without also modernising the underlying infrastructure platform leaves significant performance gains on the table. Equally, migrating workloads to the cloud without also investing in DevOps culture, automation and continuous delivery disciplines tends to reproduce old problems in a new environment.

Organisations looking to move from “slow mover” to “delivery disruptor” status typically need to address both dimensions in parallel:

1. Establish DevOps fundamentals — version control, CI/CD pipelines, automated testing, cross-functional team structures and a blameless incident culture.
2. Leverage cloud capabilities deliberately — use managed services, infrastructure-as-code and cloud-native deployment patterns rather than simply lifting and shifting existing workloads.
3. Measure what matters — track deployment frequency, lead time for changes, mean time to recovery and change failure rate (the DORA metrics) to validate improvement over time.

Context and Caveats

This research was published in 2017 and was commissioned by CA Technologies, a vendor with commercial interests in both DevOps tooling and cloud management products. The percentage improvements cited are self-reported by survey respondents rather than independently measured benchmarks. Nonetheless, the directional finding — that combined adoption outperforms either approach in isolation — is consistent with subsequent industry research, including the annual DORA State of DevOps reports.

Teams evaluating their own DevOps and cloud strategies should treat these figures as indicative rather than precise targets, and validate outcomes against their own baseline metrics.

The Parameter Explosion Problem in Traditional Data Centers

One of the most underappreciated challenges in DevOps is infrastructure testing — specifically, the combinatorial explosion of configuration parameters in traditional data center environments. Each application running on-premises can have thousands of valid parameter combinations across storage, processing, networking, middleware, and other infrastructure components. Determining which combinations are critical, and what the acceptable range of values is for each parameter, is an enormously difficult problem.

The practical consequence is that exhaustive infrastructure testing is rarely achieved. When the number of possible configurations is effectively limitless, teams inevitably test only a subset. A defect tied to a specific combination of parameters may never surface during testing — and only appears in production, where it causes real damage.

In traditional enterprise data center environments, getting a realistic, safe range of parameters for a given infrastructure component often required involving vendor sales engineers. This process had to be repeated for every component in the stack — a slow, expensive, and inconsistent approach.

How Cloud Providers Reduce Configuration Complexity

One of the structural advantages of public cloud computing is the deliberate constraint on configuration choices. Cloud providers offer a curated menu of instance types, storage tiers, and network bandwidth options rather than an open-ended set of parameters. This is analogous to how car manufacturers offer a defined set of models and engine configurations — not an infinite custom-build experience.

These constraints are a feature, not a limitation. By reducing the parameter space, cloud providers can:

• Thoroughly test the configurations they do offer
• Provide predictable performance characteristics for each option
• Simplify disaster recovery through standardized failover between data center regions
• Enable global application access without requiring customers to build their own global infrastructure

For companies that cannot afford to architect and maintain a globally distributed infrastructure, this makes cloud providers particularly valuable for mission-critical applications.

Containers: A New Layer of Complexity

The widespread adoption of containers was intended to simplify application isolation and portability — and it has achieved that to a significant degree. Containers abstract away much of the underlying infrastructure and make it easier to model networking, storage, and compute consistently across environments.

However, as cloud-native applications grow in scale, the number of containers and the relationships between them introduce a new form of complexity. Container orchestration — managing how containers are deployed, networked, scaled, and recovered — is itself a configuration-rich domain. The interaction between containers, and between containers and underlying infrastructure, creates a different but equally challenging parameter space.

At the time of the original writing (2017), container management tooling was largely open source and still maturing. The ecosystem has evolved significantly since then — Kubernetes has emerged as the dominant orchestration platform and has been widely adopted and commercially supported — but the underlying challenge of configuration standardization for specific application patterns remains an active area of work.

State Tracking Across Infrastructure Components

Another significant challenge in cloud DevOps pipelines is capturing and tracking the state of all infrastructure components that interact with an application. This includes:

• Firewalls — policy changes happen frequently and a misconfigured rule can take down a service
• Load balancers — configuration tied to application routing logic must be versioned alongside application changes
• Routers and switches — network topology changes affect application reachability
• Storage infrastructure — volume configurations, snapshots, and replication settings affect data integrity and recovery

When an application deployment or change causes an incident, teams need to roll back not just the application code but the entire correlated infrastructure state. If firewall or network policies have changed between known-good states, and those changes are not centrally tracked and version-controlled, rollback becomes unreliable.

This is why infrastructure-as-code (IaC) practices — using tools such as Terraform, AWS CloudFormation, or Pulumi to declare and version infrastructure state — are a foundational DevOps discipline. They provide the audit trail and reproducibility needed to correlate application changes with infrastructure changes and roll back confidently.

Key Takeaways for DevOps Teams

• Traditional data center parameter sprawl is a testing liability. The combinatorial explosion of infrastructure configurations makes it impossible to test all meaningful combinations, leaving unknown weaknesses that surface in production.
• Cloud constraints are a deliberate quality mechanism. The limited configuration options offered by cloud providers enable more thorough testing of the configurations that are supported.
• Container orchestration complexity needs careful management. As container counts grow, the interaction between containers and underlying infrastructure creates a new parameter problem that teams must address through standardized patterns and mature orchestration tooling.
• Infrastructure state must be tracked centrally. All components — firewalls, load balancers, network devices, and storage — must be version-controlled and snapshotted so that rollbacks to a known-good state are reliable after any application or infrastructure change.
• Reliability is a security property. Reducing infrastructure complexity and improving recoverability directly improves the security posture of an application by reducing the attack surface of misconfiguration and improving incident response capability.

Conclusion

Cloud infrastructure providers address the combinatorial testing problem by offering a constrained, well-tested set of compute, storage, and network options — a significant advantage over traditional data center environments. Containers extend this model by providing application isolation and portability, but they also introduce orchestration complexity that the industry is still working to standardize and simplify.

For DevOps practitioners, the practical priorities are clear: adopt infrastructure-as-code to version all infrastructure state, choose cloud configurations from well-tested provider offerings where possible, and invest in understanding container orchestration patterns appropriate to your application type. As the container ecosystem matures, the number of viable, well-understood configuration patterns will narrow — reducing risk and improving testability in the same way cloud instance types did for compute.