DevOps is a way of working that brings development and operations teams together to ship software faster and more safely, without pitting them against each other. This page is for any DevOps beginner: a developer, system administrator or manager who is discovering the term and wants to understand where it comes from before applying its practices.
You will find the historical origin of the movement (2009), the concrete problem it solves (the wall between Dev and Ops), a definition stripped of common misunderstandings, and a timeline of the ecosystem (Agile, SRE, GitOps, Platform Engineering) up to the latest DORA reports.
What you will learn
- Place the origin of DevOps in 2009 and its precursors (Agile, SRE)
- Distinguish DevOps from a tool, a job title or a team
- Explain the historical wall between Dev and Ops and its toxic cycle
- Recognise the structuring frameworks: the Three Ways and CALMS
- Place DevOps in its current ecosystem (GitOps, Platform Engineering, AI)
What is DevOps?
DevOps is a way of working that brings development (Dev) and operations (Ops) teams together around a shared goal: shipping software faster and more safely. The word is the contraction of Development and Operations, two historically separate professions that DevOps seeks to reconcile.
It is neither a tool you buy, nor a job title you hire for, nor an isolated team. It is a combination of practices, cultural principles and automation: automated tests, continuous integration, infrastructure as code, shared observability. All these practices aim at the same result: shortening the lead time between an idea and its release to production, without sacrificing stability.
To understand why this culture took hold, you have to go back to the problem it solves: decades of siloing between those who build the software and those who run it.
The historical problem
The context: IT before 2000
In the 1980s and 1990s, enterprise IT worked on a model radically different from today's. Servers cost hundreds of thousands of dollars. An IBM AS/400 server represented the equivalent of several years of an engineer's salary. Each machine was therefore precious, irreplaceable, and treated as such.
Development cycles were measured in years, not weeks. A typical project followed the V-model: 6 months of specifications, 12 months of development, 6 months of testing, then a "big bang" release to production. Deployments were rare and risky events, often scheduled at weekends, with whole teams on standby "just in case".
The diagram shows why this model was slow: each test phase validates a design phase that took place months earlier, so a specification defect was only discovered at acceptance testing.
In this context, the separation of responsibilities made sense:
- Developers built applications, often without ever seeing a production server
- Operations maintained the infrastructure, protecting these expensive machines from risky changes
- Each team had its own goals, its own metrics, its own priorities
The wall between Dev and Ops
This separation, logical at first, turned into organisational silos. Two distinct cultures emerged with contradictory goals, a phenomenon described in detail in the DevOps anti-patterns lesson.
The Dev team (development):
- Goal: ship new features as fast as possible
- Success metric: number of features shipped
- Perception of Ops: "They block everything, they are slow, they always say no"
- Behaviour: throw changes "over the wall" and move on to the next project
The Ops team (operations):
- Goal: maintain stability, avoid incidents
- Success metric: uptime, availability
- Perception of Dev: "They ship buggy code and we are the ones handling the problems at 3 a.m."
- Behaviour: minimise changes, slow down deployments, multiply checks
The toxic cycle
This conflict of goals created a predictable vicious circle:
- Dev ships a new release after months of development
- Ops discovers problems when deploying to production
- The deployment fails or causes incidents
- Ops tightens the controls and slows down the next deployments
- Dev piles up more changes between releases (since deploying is hard)
- Releases become riskier (more changes = more risk)
- Back to step 1, with even more tension
This cycle fed itself. The harder deployments were, the longer teams waited to deploy, which made each deployment even more risky.
The measurable consequences
Studies from the time, then the DORA reports later on, quantified these dysfunctions with metrics still used today to diagnose an organisation (full details on the DORA metrics page, in French):
| Metric | "Traditional" organisations | Impact |
|---|---|---|
| Deployment frequency | Once a month to once a year | Slow feedback, accumulated risk |
| Lead time | 2 to 6 months | Unable to respond to the market |
| Change failure rate | 30-60 % | Frequent incidents, stress |
| Time to restore (MTTR) | Days to weeks | Prolonged unavailability |
The human cost
Beyond the metrics, this model had a considerable human cost:
- Night-time deployments: Ops teams regularly worked nights and weekends
- Blame culture: after each incident, the question was "who made this mistake?"
- Chronic stress: fear of deploying, waiting for the incident
- High turnover: good engineers left for less toxic environments
- Burnout: the build-up of technical debt and pressure
The emergence of DevOps
The official birth: 2009
The term "DevOps" was born in October 2009 at the first DevOpsDays in Ghent, Belgium, organised by Patrick Debois. But the idea had been brewing for several years in different communities.
The precursors:
- 2008: Andrew Clay Shafer and Patrick Debois meet at the Agile conference and discuss "Agile Infrastructure"
- 2009: John Allspaw and Paul Hammond present "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" at the Velocity Conference, a revelation for the industry
- 2009: Patrick Debois organises the first DevOpsDays, and the #devops hashtag is born on Twitter
A pragmatic definition
Put more simply: DevOps means breaking down the wall between Dev and Ops so that both teams work together towards a shared goal: delivering value to users, quickly and reliably.
What DevOps is NOT
Before going further, let's clear up some common misunderstandings. Creating a team called "DevOps" next to the existing Dev and Ops teams is in fact one of the most frequent anti-patterns recorded on this site.
| What DevOps is not | What DevOps really is |
|---|---|
| A position or a job title | A culture and practices |
| A tool or a product to buy | A philosophy of organisation |
| A separate "DevOps" team | A shared responsibility |
| Just CI/CD automation | A deep cultural change |
| Reserved for big tech companies | Applicable to any organisation |
The DevOps ecosystem: the timeline
DevOps did not develop in isolation. It is part of a wider ecosystem of movements, tools and practices that transformed the IT industry, and that keeps evolving with the arrival of artificial intelligence in the development cycle.
Key moments
Here are the major events that shaped DevOps, from the Agile Manifesto (2001) to the recent DORA reports (2024-2025). This timeline shows how ideas and tools combined to transform the IT industry.
| Date | Event | Impact |
|---|---|---|
| February 2001 | Publication of the Agile Manifesto | Lays the foundations of fast iteration and collaboration |
| 2003 | Ben Treynor Sloss creates SRE at Google | First formalisation of reliability engineering |
| October 2009 | First DevOpsDays in Ghent | Official birth of the DevOps movement |
| August 2010 | Publication of "Continuous Delivery" (Humble & Farley) | Formalises continuous delivery practices |
| 2012 | Neil MacDonald (Gartner) publishes "DevOpsSec" | Puts forward the idea of building security into the DevOps cycle |
| January 2013 | Publication of "The Phoenix Project" | Popularises DevOps beyond technical circles |
| March 2013 | Launch of Docker | Revolutionises application packaging and portability |
| 2014 | Puppet's State of DevOps report, run with Nicole Forsgren | First statistical measurements of performance, which would give rise to DORA |
| June 2014 | Google open-sources Kubernetes | Standardises container orchestration |
| 2017 | Alexis Richardson (Weaveworks) introduces "GitOps" | A new declarative approach to deployments |
| 2018 | Evan Bottcher (ThoughtWorks) defines the internal platform on martinfowler.com | Emergence of internal platforms |
| 2024-2025 | DORA reports include generative AI | AI becomes an amplifier: it speeds up good practices but also worsens existing dysfunctions |
The last point deserves a word of explanation: the most recent DORA reports (2024, then the 2025 edition "State of AI-assisted Software Development") show that generative AI is neither a silver bullet nor a danger in itself. In teams with solid technical foundations (automated tests, continuous integration, a good internal platform), AI genuinely speeds up delivery. In teams already accumulating technical debt and chaotic processes, it amplifies instability: more failed changes, more code rework, more time lost fixing. It is the most recent demonstration of a principle central to DevOps since 2009: culture and foundations matter more than the tool.
The tools that shaped the movement
DevOps was built around tools that made the new practices possible. Knowing this list helps understand why some names keep coming back in job offers and training: they are not passing fads, but building blocks that became de facto standards.
Infrastructure as Code:
- Terraform (2014): declarative multi-cloud infrastructure
- Ansible (2012): automation and configuration
- Puppet (2005) / Chef (2009): pioneers of configuration management
Containerisation and orchestration:
- Docker (2013): containers for everyone
- Kubernetes (2014): container orchestration at scale
CI/CD:
- Jenkins (2011, a fork of Hudson): the veteran of continuous integration
- GitLab CI (2012): CI/CD built into the code manager
- GitHub Actions (2019): native automation in GitHub
Observability:
- Prometheus (2012): metrics and alerting
- Grafana (2014): visualisation and dashboards
- ELK Stack: log centralisation
The structuring frameworks
DevOps is organised around two complementary frameworks that guide its day-to-day implementation. The lesson Three Ways and CALMS details them; here is the essentials to place the vocabulary.
The Three Ways
Formalised by Gene Kim in "The Phoenix Project", the Three Ways describe the fundamental principles of DevOps:
- Flow: speed up the flow of work from Dev to Ops to the customer
- Feedback: create fast, constant feedback loops
- Continual Learning: encourage experimentation and learning
The CALMS model
An acronym that captures the cultural pillars of DevOps:
- Culture: collaboration and shared responsibility
- Automation: automate everything that can be automated
- Lean: eliminate waste, optimise the flow
- Measurement: measure to improve
- Sharing: share knowledge and responsibilities
These two lenses come back throughout the DevSecOps course. They also serve as a basis to place SRE (Site Reliability Engineering), the approach born at Google that applies some of these principles with a different vocabulary: the Introduction to SRE lesson details what they share and how they differ.
Key points
-
DevOps was born from a real problem: decades of silos between Dev and Ops created slow delivery cycles that were risky and stressful.
-
2009 marks the official birth with the first DevOpsDays in Ghent, but the ideas had been brewing for years.
-
DevOps is a culture, not a tool: it is about breaking down silos and sharing responsibility for the product in production.
-
A rich ecosystem has developed: Agile, SRE, containers, Kubernetes, GitOps, Platform Engineering complement each other.
-
Two frameworks structure the philosophy: the Three Ways (Flow, Feedback, Learning) and CALMS (Culture, Automation, Lean, Measurement, Sharing).
-
The ecosystem keeps evolving: the most recent DORA reports show that artificial intelligence amplifies existing practices, good and bad alike, rather than replacing them.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Three Ways and CALMS: the foundations of DevOps
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most frequent doubts about DevOps: its definition, its origin, how it differs from a job title and how it relates to Agile and SRE.