CodeCrush

## glossary

What is DevOps?

DevOps is a culture and a set of practices that integrate the development and operations teams, aiming to shorten the cycle between writing code and delivering it to production safely. It emerged around 2009 as a reaction to a concrete organizational problem.

The problem was a conflict of incentives. Development was measured on shipping changes; operations, on keeping things stable. Since every change threatens stability, the two teams worked against each other’s goals — and the software sat idle between them.

What DevOps is not

Worth spelling out, because the term has been heavily distorted:

  • It is not a job title. "Hiring a DevOps" to be the sole person responsible for deploys recreates the silo the practice exists to eliminate.
  • It is not a separate team. Creating "the DevOps team" between dev and ops adds a third wall.
  • It is not a set of tools. Docker and Kubernetes help, but installing tools without changing responsibilities does not change outcomes.
  • It is not just automation. Automating a bad process delivers the bad result faster.

The practices that hold it up

In practice, DevOps rests on CI/CD to automate the delivery line, infrastructure as code to version environments the way you version software, observability to understand behavior in production, and shared responsibility — whoever writes the code takes part in keeping it running.

Infrastructure as code: the environment becomes a versioned file
resource "aws_s3_bucket" "assets" {
  bucket = "codecrush-assets-prod"

  tags = {
    Environment = "production"
    Project     = "codecrush"
  }
}

resource "aws_s3_bucket_versioning" "assets" {
  bucket = aws_s3_bucket.assets.id
  versioning_configuration {
    status = "Enabled"
  }
}

The DORA metrics

The DORA research established four indicators that measure delivery performance objectively, avoiding subjective debates about maturity:

  • Deployment frequency — how regularly code reaches production.
  • Lead time for changes — how much time passes between the commit and it running.
  • Change failure rate — what percentage of deploys causes incidents.
  • Time to restore — how long it takes for the service to come back after a failure.

The counterintuitive finding of the research is that speed and stability are not opposites: teams that ship more often also fail less and recover faster, because small changes are easier to verify and revert. To track how the system behaves after the deploy, it is worth reading about observability in distributed systems.

## faq

Frequently asked questions

Are DevOps and SRE the same thing?

They are close approaches with distinct origins. DevOps is a culture that defines broad goals of collaboration and flow. SRE (Site Reliability Engineering), created at Google, is a specific implementation with concrete practices such as error budgets, SLOs and a cap on manual toil.

Do I need to know how to code to work in DevOps?

Yes. Infrastructure as code, pipeline automation and internal tooling demand real programming — usually Python, Go or shell script. The profile that only operates a cloud provider’s graphical interface has less and less room.

Where should I start learning DevOps?

With the fundamentals: Linux and the command line, networking, Git and a simple CI pipeline. Then containers, one cloud provider and infrastructure as code. Jumping straight to Kubernetes without that base usually ends in memorizing commands without understanding what happens.

## read next

Related articles