| [ Web Proxy ] |
| Viewing: https://dora.dev/devops-capabilities/technical/cloud-infrastructure | [Back] [Original] |
Flexible infrastructure allows teams to rapidly and reliably adapt to changing business needs without being bottlenecked by hardware procurement or manual provisioning. DORA research shows that utilizing flexible infrastructure, which is typically achieved through cloud computing, is a key driver of continuous delivery, software delivery performance, and overall organizational success.
When teams can provision and manage their own environments dynamically, they reduce lead times and recover from failures faster.
Infrastructure flexibility is a proven driver of top-line business outcomes. DORA findings indicate that leveraging flexible cloud infrastructure directly increases overall organizational performance.
Flexible infrastructures lead to 30% higher organizational performance. (Accelerate State of DevOps 2023)
As AI accelerates the pace of code creation, flexible infrastructure has become a critical safety net. While AI tools significantly increase individual productivity and flow, the resulting surge in code volume can severely strain deployment pipelines, negatively impacting software delivery stability and throughput. Flexible, elastic infrastructure allows teams to spin up automated, on-demand test environments to absorb this increased volume and catch AI-generated regressions before they reach production.
Many organizations seek flexible technical infrastructure, often in the form of cloud computing. But there’s more to it than buying your infrastructure from a cloud provider. The US National Institute of Standards and Technologies (NIST) defines five essential characteristics of cloud computing (whether public, private, or hybrid):
The 2019 State of DevOps Report found that only 29% of people who claim to have adopted cloud technologies agreed or strongly agreed that they met all five of the characteristics defined above. In both 2018 and 2019, DORA’s research found that elite performers were more than 23 times more likely to have met all five essential cloud characteristics than low performers. This may explain why teams and executives who claim to have adopted cloud computing technologies also express frustration at not reaping the expected results.
When organizations continue to use traditional data center practices and processes to manage their infrastructure, they can’t achieve the expected benefits, which, according to DORA’s research, include:
Respondents who met all essential cloud characteristics are 2.6 times more likely to be able to accurately estimate the cost to operate software.
For example, many organizations with cloud infrastructure do not allow developers to self-service their environments on demand: they require them to raise tickets or send emails and wait days for environments to be provisioned or for configuration changes to be made. In this case, although the organization may pay for a cloud service, they don’t have a cloud by NIST’s definition.
When moving to the cloud, organizations must invest in re-designing the processes and practices that they implemented when they were using traditional data centers. They must adopt cloud-native patterns and practices to achieve the agility, stability, availability, and cost transparency of cloud computing. If the underlying technology is in the cloud but the outcomes for practitioners remain unchanged days or weeks to obtain test environments, provision new infrastructure, or get configuration changes made then organizations will not reap the results they want.
Adopting cloud-native processes and practices to implement NIST’s five characteristics involves substantial change by several functions, including business stakeholders, developers, operations teams, information security, procurement, and finance. The changes require close collaboration between these functions in order to identify and resolve conflicting aims.
For example, many developers expect complete control over production infrastructure when using cloud platforms. Information security professionals oppose this practice, and with good reason without disciplined change management, cloud infrastructure can turn into a fragile work of art that is hard to manage, vulnerable to external threats, and does not meet regulatory requirements.
However, developers can be empowered to provision the resources they require while meeting these requirements. Many organizations have adopted the infrastructure as code (IaC) paradigm. Infrastructure configuration is checked into version control, and developers can provision environments, make configuration changes, and execute deployments through an automated mechanism. The mechanism takes the code from version control and performs operations through the cloud’s API on demand without human intervention. Using version control and automation, all actions and their output are logged to provide complete traceability and auditability of every change to each environment.
Infrastructure as code allows you to manage changes effectively and to apply information security controls. For example, you can implement segregation of duties by requiring all changes to the configuration specified in version control to be approved by a designated group. However, moving to infrastructure as code requires significant engineering effort and process change, including changing policies for implementing information security controls. To make this transition actionable, start small. Pilot these automated processes with a single, low-risk application or an enthusiastic early-adopter team. This allows you to test new guardrails, prove the value of self-service, and build cross-functional trust before rolling out global policy changes.
Consider another example. While cloud providers typically only bill for infrastructure while it is in use (meeting NIST’s fifth characteristic, measured service), this change from fixed-cost infrastructure to variable cost can have significant implications for both procurement and finance. As described in Accelerate State of DevOps 2019: “Some in finance may say that the cloud has not led to cost savings in the short-run, yet we know that it provides greater information transparency. How can this be? While the cloud provides transparent information about costs to the system owners, users do not pay for these costs unless there is a chargeback model or similar mechanism. This can lead to wildly variable costs that go unchecked, making cloud costs unpredictable. In these scenarios, teams that pay for infrastructure may prefer data centers because they are predictable, even though their visibility disincentivizes system users to build more efficient systems. We suggest organizations better align incentives so that system owners have both visibility to build more efficient systems, and the incentives to do so, by using chargeback or similar mechanisms.”
Align incentives so that system owners have both visibility to build more efficient systems, and the incentives to do so.
In addition to considering how infrastructure is managed at both the configuration and finance level, applications must often be re-architected to reap the benefits of increased stability, reliability, and agility that cloud can provide. Re-architecting systems to a cloud-native paradigm is discussed in Google Cloud’s white paper, Re-architecting to cloud-native: an evolutionary approach to increasing developer productivity at scale.
The most crucial consideration is whether your cloud deployment has actually helped your organization achieve more rapid, reliable releases, and higher levels of availability, velocity, and reliability.
Flexible infrastructure is the underlying engine that powers successful platform engineering.
By abstracting flexible cloud resources into an Internal Developer Platform (IDP), platform teams can provide developers with “paved roads.” The goal is to design multi-tenant environments that prioritize self-service and autonomy, ensuring the platform removes infrastructure bottlenecks so developers can focus on writing application code.
…prioritize self-service and autonomy… so developers can focus on writing application code.
Organizations may be better off staying in the data center if they are not willing to radically transform their application or service. (Accelerate State of DevOps 2024)
Building gates instead of guardrails: While utilizing an IDP can improve productivity, it can decrease change stability and throughput if it restricts developer independence. If an IDP mandates rigid, one-size-fits-all infrastructure requirements or requires manual ticket approvals to access cloud resources, it negates the benefits of flexible infrastructure.
Incentivizing the wrong metrics: Executives often incentivize pure migration volume or speed (for example, move 80% of apps to the cloud by Q3). This drives teams to bypass modernization and architectural updates, leading to a sprawling cloud footprint that cannot scale elastically or be provisioned on demand.
Organizations must overcome several obstacles on this journey, including:
Overcoming these obstacles requires a substantial change program. It is essential to prioritize the human element allocating dedicated budget and time for continuous learning alongside sustained investment and collaboration between people at every level of the organization.
To decide what to measure, start by considering what benefits you hope to gain from implementing cloud infrastructure. Crucially, before making any changes, establish a baseline for your current traditional processes. Capture existing metrics, such as your manual provisioning lead times or current operational costs, so you have a definitive point of comparison to prove the return on investment (ROI) to leadership later. Then start measuring the extent to which those benefits are being realized.
For example, if your goal is to improve cost visibility, you might track how well you’re doing at ensuring the cost of infrastructure is correctly billed to the relevant business line, team, product, or environment.
Avoid measuring success based on the percentage of workloads hosted on cloud servers.
You can also directly measure against the NIST characteristics such as:
Read more about cloud and flexible infrastructure in the following publications:
| Web Proxy Viewer | New URL | Original Page |