What is DevOps?
Summary: DevOps is a set of cultural and technical practices aimed at reducing the time between writing a change and making it available, while improving reliability. This lesson gives a solid definition, lists what DevOps is not, traces its history since 2007, and clearly distinguishes it from agile, SRE and platform engineering.
1. The definition
The part of the definition that is systematically forgotten: "without degrading reliability". DevOps is not "deploying faster". It is "deploying faster and more safely". A team that deploys twenty times a day while breaking production one time out of three is not doing DevOps — it is doing accelerated chaos.
2. What DevOps is not
Point 2 deserves emphasis, because it is the most common mistake. Creating a "DevOps team" placed between development and operations produces three walls instead of one. Development hands off to the DevOps team, which hands off to operations. You have added a handoff while believing you were removing them. This topic is developed in lesson 5.
Point 6 corrects a common prejudice among people coming from regulated environments. It is sometimes imagined that DevOps consists of bypassing controls to go fast. It is the opposite: a mature DevOps team runs more checks than a traditional team — tests, security analyses, compliance controls — but they run in a few minutes instead of three weeks.
3. DevOps and agile — the distinction
The formula that settles it once and for all: agile makes the team capable of producing code every two weeks. DevOps makes the organization capable of putting it in users' hands within the day. Without the latter, the former mostly produces inventory.
4. A brief history of DevOps
Two names to remember for an interview: Patrick Debois, who organized the first DevOpsDays in 2009 and is credited with the term, and Gene Kim, author of the Phoenix Project and co-author of the research work that provided the quantified evidence.
Step H10 explains an important evolution in the job market. The DevOps ideal — every team autonomous end to end — hit a practical limit: cognitive load. Mastering Kubernetes, Terraform, observability and security on top of your own domain is unrealistic for a product team. Hence the emergence of platform teams, which build internal self-service services. It is one of the most sought-after profiles today.
5. DevOps, SRE, platform — the clear table
| Criterion | DevOps | SRE | Platform engineering |
|---|---|---|---|
| Nature | Culture and practices | Engineering discipline | Product function |
| Origin | Community, 2009 | Google, 2003 | Industry, around 2020 |
| Central question | How to deliver fast and safely? | How to guarantee reliability? | How to make teams autonomous? |
| Own tools | None in particular | SLOs, error budget, 50% rule | Internal portal, templates, self-service |
| Measure of success | Lead time and reliability | Meeting SLOs | Adoption by teams |
| Customer | The end user | The end user | The development teams |
The most useful distinction: SRE and platform engineering are two concrete answers to the question posed by DevOps. SRE brings measurement tools and a reliability method. The platform brings ready-to-use services that reduce the teams' load.
The most important point about platform engineering: its internal customer is the developers. A platform that teams work around is a failure, even if it is technically excellent. That changes everything about how to design it — it is a product, with users to win over.
6. How to recognize a genuine DevOps approach
Question 5 is the most revealing of all, and it is rarely asked. The time it takes a newcomer to deploy their first change to production measures in one shot the quality of the documentation, the degree of automation, the simplicity of the architecture and the organization's level of trust. An answer in days indicates real maturity; an answer in months indicates an accumulation of unshared knowledge.
Question 6 is excellent in an interview, for the candidate as well as the recruiter. An organization that has never tested its rollback does not have one — it has a theoretical procedure.
Remember in 30 seconds
- DevOps = reducing the time between writing a change and making it available, without degrading reliability.
- The forgotten half of the definition: "without degrading reliability". Fast and safe.
- It is not a tool, nor a team, nor (originally) a job title, nor agile, nor the absence of controls.
- Creating a "DevOps team" adds a third silo — it is the most widespread anti-pattern.
- DevOps increases the number of controls, but makes them automatic and fast.
- Agile = deciding what to build. DevOps = delivering and operating. Agile without DevOps produces inventory.
- History: Amazon 2006 (you build it, you run it) → Flickr 2009 (ten deployments per day) → Patrick Debois and the first DevOpsDays → Docker 2013 → Kubernetes and SRE → platform engineering.
- Two names: Patrick Debois (the term) and Gene Kim (Phoenix Project and the quantified evidence).
- SRE and platform are two concrete answers to the DevOps question. The customer of a platform is the developers.
- The most revealing question: how long does it take a newcomer to deploy their first change?