DevOps PeachModern software is changing on three axes at once:
| Axis | Old | Modern |
|---|---|---|
| Architecture | Monolith | SOA → Microservices |
| Infrastructure | Physical servers | VMs → Cloud, containers, serverless |
| Delivery | Waterfall | Agile → DevOps |
When the Dev team (wants fast change) and the Ops team (wants stability) work apart in silos, code is "thrown over the wall": slow releases, late bug discovery, blame games.
DevOps is a set of practices and culture where Dev and Ops share responsibility from code to production, aiming for: - shorter development cycles and more frequent deployments; - more reliable releases and fast recovery from incidents; - alignment with business goals and customer experience.
flowchart LR
subgraph Before["Silo"]
D1["Dev: change fast"] -- "throw code over the wall" --> O1["Ops: stay stable"]
end
subgraph After["DevOps"]
T["One shared team<br/>automate, measure, share responsibility"]
end
Before --> After
Short history: around 2007–2008 the Agile community discussed the Dev–Ops gap; in 2009 came Flickr's "10+ Deploys a Day" talk and the first DevOpsDays event — the word "DevOps" comes from there. Companies like Amazon and Netflix deploy thousands of times a day thanks to automation and small, independent architectures.
Traps: - Treating DevOps as a job title ("hire one DevOps engineer and we're done") or a tool ("install Jenkins and we have DevOps"). Tools only help; changing culture and process is the core. - Confusing DevOps with Agile: Agile optimizes how software is developed; DevOps extends to operations and delivery.
One visible sign of a DevOps team: small, frequent commits, each going through the pipeline.
| Command | Meaning |
|---|---|
git log --oneline -5 |
The last 5 commits, one line each |
Core practices
| Practice | What it means |
|---|---|
| Version control for everything | Code, pipelines, infrastructure, and configuration all live in Git |
| Continuous integration and delivery | Every change is built, tested, and ready to release automatically |
| Infrastructure as Code | Servers, networks, and clusters are created from reviewed files |
| Monitoring and observability | Metrics, logs, and traces show how the system behaves in production |
| Small batches | Many small changes instead of rare big releases, lowering the risk of each |
| Collaboration | Shared goals, on-call duties, and post-mortems across Dev and Ops |
The Three Ways
A popular description of DevOps thinking comes from The Phoenix Project and The DevOps Handbook:
- Flow: make work move quickly from development to production, by limiting work in progress and removing hand-offs.
- Feedback: make problems visible quickly, through tests, monitoring, and alerts, so they are fixed where they start.
- Continual learning and experimentation: build a culture where teams try improvements, learn from failures, and share knowledge.
What a DevOps engineer actually does
In job postings, "DevOps engineer" usually means someone who builds and maintains CI/CD pipelines, writes infrastructure code, runs containers and Kubernetes, sets up monitoring, and helps developers ship safely. The role exists to enable teams, not to take over all operations for them. The skills in this course (Linux, Git, scripting, cloud, containers, pipelines, monitoring) match that profile.
Related terms
- DevSecOps builds security checks into every stage rather than at the end.
- SRE (Site Reliability Engineering), from Google, is one concrete way of doing operations with engineering methods.
- GitOps uses Git as the single source of truth for deployments, with tools such as Argo CD applying changes automatically.
- Platform engineering builds self-service internal platforms so product teams can deliver without becoming infrastructure experts.