DevOps Fundamentals

DevOps started as a cultural movement: developers and operations sharing responsibility for production. The term has been diluted — every tool calls itself "DevOps" — but the underlying ideas are real and have transformed how software ships.

This page covers what DevOps actually changed and the practices that matter.

The original problem

Traditional split:

Result: misaligned incentives. Developers move fast; ops slow them down. Production failures fall in the gap. Each side blames the other.

What DevOps proposed

Shared responsibility. Developers care about production; ops cares about delivery. Tools that bridge the gap. Cultural shift away from blame.

The CAMS framing (Damon Edwards, John Willis, 2010):

The cultural part matters more than the tools, but tools are what's visible.

Practices that emerged

Continuous integration / continuous delivery

Every change goes through automated build, test, deploy. See CiCdPipelines.

Infrastructure as code

Servers, networks, load balancers — all defined in code. Reproducible; version-controlled. See TerraformFundamentals.

Monitoring and observability

Production state visible to developers. Metrics, logs, traces all accessible. See CloudMonitoring.

On-call rotations

Developers handle production issues alongside ops. Sometimes called "you build it, you run it." See OnCallPractices.

Postmortems

Incidents get analyzed; lessons captured. Blameless culture: focus on system causes, not individual blame.

Trunk-based development

Short-lived branches; frequent integration. Avoids the "release in 6 months" pattern. See TrunkBasedDevelopment.

SRE: Google's variant

Site Reliability Engineering (SRE) is Google's specific implementation. Treats operations as an engineering problem.

Key concepts:

SRE is a flavor of DevOps. Many companies adopt SRE titles without the underlying practices.

What "DevOps" doesn't mean

The term has been diluted. Some misuses:

"DevOps engineer" as a job title

Often means "ops person who can also write some scripts." Not bad work, but doesn't capture the cultural change.

"DevOps tools"

Tools (Kubernetes, Terraform, GitLab CI) are useful but aren't the practice. Buying tools doesn't make you DevOps.

"DevOps team"

A team named DevOps that handles deployments doesn't bridge the dev/ops gap; it just relocates it.

The cultural change is what matters. The tools support it.

What DevOps actually changed

For most modern software organizations:

  1. Deploy frequency: from monthly/quarterly to multiple per day
  2. Lead time: from weeks/months to hours
  3. Change failure rate: through better testing
  4. MTTR: faster recovery via better tooling and observability

The DORA metrics (DevOps Research and Assessment) measure these. Elite teams deploy multiple times per day; low performers, less than monthly.

What DevOps didn't fix

A reasonable adoption path

For traditional organizations adopting DevOps practices:

  1. Start with CI/CD: automated build and test on every change
  2. Add IaC: infrastructure version-controlled
  3. Improve monitoring: developers can see production
  4. Cultural shift: shared responsibility; blameless postmortems
  5. On-call rotation: when the team is ready

Each step is meaningful on its own. Don't try to adopt everything simultaneously.

Common failure patterns

Further Reading