DevOps Culture in the Cloud: Adapting Your Team for Scalable Cloud Infrastructure

Cloud migration has been a dominant theme in enterprise tech for years. But only 42% of companies reported fully achieving their cloud outcomes across cost, speed, resilience, and business enablement, according to research by Accenture.ⁱ Much of the disappointment stems from a common misstep: migrating servers but keeping a physical hardware, data-center mindset.

Real cloud adoption goes beyond changing where servers live. It also means changing how teams work, how they think about available system resources, and how they make runtime decisions. You can think of it like moving to a new country. Getting your belongings across the border just takes logistics. But you don’t experience the real difference until you learn the language, adopt local practices, and start thinking like your new country is home.

You’ve moved the servers, not the culture

The initial steps of lifting your existing setup and shifting it to a different environment do give you a win. You can easily provision virtual machines in the cloud, tweak RAM or CPU resources, and then deal with resource crunches by adjusting as needed.

But if you’ve come from a data center world, many old habits persist. For example, when servers are physical assets in your data center, you tend to maintain and repair them like long-lived resources because these “bare-metal” builds are expensive.

This lift-and-shift thinking keeps configurations running on live machines rather than in version control. Teams continue tuning processes for hardware and cost constraints that have changed. This mindset perpetuates the fragility of the environment you left behind and limits your success. Life doesn’t really change until you stop behaving as if you still live “back home,” which starts with learning the new language.

Learning the language

In cloud-native operations, that language is Infrastructure as Code (IaC). With IaC, instead of managing conversations, tickets, and manual changes on running machines, you describe environments as code. This code captures what the infrastructure should look like, the services that should be running, and what should be available to them in text that both developers and infrastructure teams can read, review, and version.

From there, you can adjust configurations in text and adopt GitOps-style workflows (i.e., you merge your description of the environment into a repository, similar to code changes). You don’t have to log into a box and inspect it. Because it’s declared in a file, you can search through the text to find what you need. You can also quickly recreate an environment somewhere else and reproduce an issue without another set of machines.

This way of working highlights the cultural change I am talking about. Developers are accustomed to using a Git repository to see when something changed, review the line of code, and reason backward from that. Instead of submitting tickets to find out what changed in the environment, any developer can see what changed when the bugs started happening and understand how an infrastructure change might interact with their code.

Thriving in a new culture

Once your infrastructure is declared in code and driven through Git, your new language starts to shift day-to-day habits and practices. The ability to spin up environments to do a job and remove them when you’re done makes experimentation routine, rather than exceptional. Small experiments become cheap, and large experiments can start small, with fewer people involved and without provisioning for the future until they succeed.

Development teams can take the initiative to produce new proofs of concept, try them out, and see what works. They can see actual resource consumption, bills, and tradeoffs. They can also feel comfortable using resources and then shutting them down, because failing something and destroying a server might be the fastest resolution.

That kind of visibility creates a new level of discipline. Just over half of engineering leaders say the disconnect between FinOps and development teams is leading to wasted spend on cloud infrastructure costs.ⁱⁱ

For example, the right answer to an experiment might be to improve an algorithm, but the cheapest, fastest answer could also be to slap a little more memory onto the machine and run it with a bigger headspace. If it fails, development teams may shut down resources completely. They get used to making that decision consciously, with a clear view of both the bill and the behavior.

This is where development and infrastructure teams start to converge, working with the same constraints, making runtime decisions together, and sharing accountability for how code performs in production. Each infrastructure person can hold a larger task in their head, define the change in the abstract, roll it out in pieces across the environment, watch how it behaves, and roll back if it doesn’t look right. They can also trace incidents, monitor the affected services more effectively, handle edge cases thoroughly, and design solutions that are more robust rather than patching on patch after patch.

Full assimilation

Full assimilation comes when development and infrastructure teams have shared accountability. Cloud infrastructure is uniquely suited to this convergence. For many developers, that convergence starts out as uncomfortable. Instead of magical infrastructure environments that satisfy whatever code should do, it takes work to care about the fact that an AWS Lambda executes in a certain number of minutes, or it just dies.

Getting developers to make choices early on is critical if you want them to own those tradeoffs instead of pushing them onto infrastructure people. When they see the real cost and real impacts of the way their code runs, they don’t just ask, “Why didn’t it work?” and wait for an infrastructure person to fix it. They design with those constraints in mind and treat capacity, runtime, and spend as part of the work.

This convergence changes the work of infrastructure teams, as well. They spend less time in developer code and less time in conflict with development teams, because they can manage change together. They can identify what’s coming down the road, preview a change to the infrastructure in a lower environment, and let developers run their code there so they’re ready when it moves to a higher environment.

When infrastructure is expressed as code, all of this plays out in familiar tooling. Version control, pull requests, and code review apply to infrastructure definitions as much as application code. Anyone can look at the Git repository, see when it changed, see the line of text, and start to reason backward from there. Accountability and ownership are handled through strict permissions for managing approvals. Set that up front, and it’s clear who can get changes done.

A 12–18-month roadmap for “living in the cloud”