The real challenges of DevOps and how to overcome them

Why DevOps is still hard#

Adopting DevOps has become essential for any company that wants both speed and control. Even so, implementing it is still full of cultural, technical and managerial obstacles.

Here are the 11 most common challenges teams run into and how to tackle each one in practice. DORA's research gives a useful frame for all of them: it groups the technical, process and cultural capabilities associated with better software delivery performance, and proposes metrics to tell whether you're actually improving.

Documentation: DORA · Capabilities catalog ↗ · DORA · Software delivery performance metrics ↗

1. Resistance to DevOps culture#

Change always meets resistance. Many teams are used to static processes, rigid hierarchies and little collaboration between development and operations. When DevOps arrives, that structure shifts: new responsibilities, unfamiliar tools and more exposure to failure.

Solution: explain clearly what is changing and why, and involve every role from the start so expectations line up. Culture can't be imposed; it's built on trust, autonomy and shared purpose. DORA uses Westrum's model to describe a generative culture, where information flows, risks are shared and failures lead to inquiry rather than blame.

Documentation: DORA · Generative organizational culture ↗

2. Too many tools, too little integration#

The number of platforms teams use grows every year: monitoring, deployment, security, communication. Each solves something, but together they can create more complexity than efficiency, and a pile of disconnected tools means lost visibility and control.

Solution: the answer isn't always more integrations, but a foundation that supports those tools in an orderly, secure way. A stable environment with sound network, permission and deployment practices lets you plug in a tool when you actually need it. The internal platform approach described by the CNCF points the same way: offer integrated, consistent capabilities instead of every team assembling its own stack.

Documentation: CNCF TAG App Delivery · Platforms white paper ↗

3. Skills gap and overloaded teams#

Demand for DevOps talent grows faster than the ability to train specialists. Many teams end up covering several roles, which increases operational load and leaves less room for innovation.

Solution: automate the repetitive work, standardize environments and make continuous learning part of the job so knowledge spreads and you depend less on specific people. Google's SRE book recommends measuring toil, the manual, repetitive work with no lasting value, and capping it so the team keeps time for engineering.

Documentation: Google SRE Book · Eliminating Toil ↗

4. Security that arrives late (and expensive)#

When security is bolted on at the end of the cycle, it's already too late. Emergency patches and critical incidents are symptoms that it wasn't considered from the start.

Solution: security starts in the infrastructure, when environments are created and access is defined. Applying DevSecOps at that layer means validating configurations, segmenting networks, controlling identities with least privilege and automating access policies. NIST's Secure Software Development Framework organizes these practices across the development lifecycle, so protection is part of the design rather than a final review.

Documentation: NIST SP 800-218 · Secure Software Development Framework ↗ · AWS IAM · Security best practices ↗

5. Scaling without losing control#

Growth without order leads to chaos: more environments, more access, more risk. Without traceability, teams lose sight of who changed what and when.

Solution: automate governance. Version configuration as code with Terraform or OpenTofu, manage access through clear policies and centralize activity logs. When every infrastructure change goes through a repository and a pull request, “who changed what” has an answer. Scaling doesn't mean losing control; it means more discipline.

Documentation: HashiCorp · What is Terraform? ↗ · OpenTofu · Documentation ↗

6. Modernizing without breaking what works#

Moving everything to the cloud can look like the answer, but doing it without a strategy can break critical services. Technical debt isn't removed by decree; it's transformed.

Solution: modernize progressively: keep what works and adapt what needs to evolve. The strangler fig pattern formalizes this: put a facade in front of the existing system and move features to the new one piece by piece until the old one can be retired. Make sure the hybrid setup interoperates before you switch anything off.

Documentation: AWS Prescriptive Guidance · Strangler fig pattern ↗

7. Teams that don't talk, pipelines that break#

Many production failures don't come from code but from misalignment between teams. When each group works on different environments or inconsistent configuration, deployments fail and time goes into hunting root causes.

Solution: standardized infrastructure, consistent environments and clear deployment processes reduce friction between development, operations and security. If staging and production come from the same infrastructure code with different variables, a whole category of surprises disappears. When everyone builds on the same base, delivery is more reliable even across different teams.

Documentation: HashiCorp · What is Terraform? ↗ · DORA · Capabilities catalog ↗

8. Fear of change: the silent enemy#

Automating or changing processes can trigger fear of losing control, relevance or stability. That fear slows adoption and blocks improvement.

Solution: build trust with early results. Small wins and transparent communication lower resistance, and change sticks when people see it makes their work simpler. Measuring delivery with DORA's metrics (deployment frequency, change lead time, change fail rate and recovery time) turns those wins into data anyone can see.

Documentation: DORA · Software delivery performance metrics ↗

9. Governance without bureaucracy#

Trying to control everything through manual processes ends in endless approvals and lost agility. Bureaucracy smothers innovation and stalls continuous delivery.

Solution: design simple, automated policies. Mandatory tags, audits and deployment rules expressed as code, for example with Open Policy Agent, keep control without a person approving every change. Good governance speeds you up instead of holding you back.

Documentation: Open Policy Agent · Documentation ↗ · AWS Whitepaper · Tagging best practices ↗

10. The hidden cost of chaos#

Cloud costs tend to grow without anyone noticing. Duplicate environments, forgotten resources and inefficient monitoring pile up month after month.

Solution: apply FinOps practices from day one: monitor usage, shut down idle resources automatically (AWS offers Instance Scheduler for this) and tie financial metrics to each deployment. Visibility is the basis of control, and it starts with knowing who owns each resource.

provider "aws" {
  region = "us-east-1"

  # These tags are applied to every resource this provider creates.
  default_tags {
    tags = {
      team        = "payments"
      environment = "staging"
      cost-center = "cc-1234"
      managed-by  = "terraform"
    }
  }
}

resource "aws_budgets_budget" "staging" {
  name         = "staging-monthly"
  budget_type  = "COST"
  limit_amount = "500"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["[email protected]"]
  }
}

Documentation: FinOps Foundation · What is FinOps? ↗ · Terraform Registry · AWS provider (default_tags) ↗ · AWS · Managing your costs with AWS Budgets ↗ · AWS Solutions · Instance Scheduler on AWS ↗ · AWS Whitepaper · Tagging best practices ↗

11. Learning as part of the job#

Without continuous learning, teams repeat the same mistakes. Improvement doesn't happen by magic; it takes reflection and documentation.

Solution: turn every project into a source of knowledge. Record good practices, incidents and lessons learned. The blameless postmortems described in Google's SRE book are the most concrete tool: they document what happened, the impact, the causes and the follow-up actions, without pointing at people. DevOps isn't implemented once; it's cultivated every day.

Documentation: Google SRE Book · Postmortem Culture ↗

Summary: challenge, symptom and first step#

DevOps isn't just tools or pipelines: it's a living practice that combines culture, discipline and continuous improvement. Each of these challenges is a point where automation has to meet human collaboration: automate without losing control, measure what matters and build a culture that learns from every deployment.