What is DevOps, and what is an SRE?

What is DevOps, and what is an SRE?

DevOps is a way of working where the people who build software also run it in production. An SRE, or site reliability engineer, is the person responsible for keeping a live system available and fast, and the role uses engineering rather than manual work to do it.

Both titles live on the operations side of an engineering team. Shipping a feature covered the path code takes to reach customers. Why software is never done covered what happens when the live system breaks. The roles in this lesson own those two territories full time: the pipeline that moves code out, and the machines and services that keep running after it lands. They are among the most confusingly titled roles in software, because the same word can name a philosophy at one company and a team of forty people at another. The sections below take the words one at a time, then give the one sorting rule that separates them cleanly.

Is DevOps a role, a team, or a way of working?

It has been all three, and the word started as the third one. DevOps is a blend of "development" and "operations". For most of software history those were separate departments: developers wrote code and handed it over, and an operations team ran the servers it lived on. The handoff caused constant friction, because the people who wrote the code never felt the pain of running it, and the people running it had no power to fix it. Around 2009 the DevOps movement proposed collapsing the wall: the team that builds a service should also operate it. In that original sense, DevOps is a culture, and every modern engineering team practices some version of it.

Then the industry did what it always does with a popular idea and turned it into a job title. A DevOps engineer, at most companies, is the person who owns the CI/CD pipeline and the cloud setup. They write the automation that tests and deploys everyone else's code, manage the company's AWS or Google Cloud accounts, and keep the path from laptop to customer paved. The work is real engineering: the tools of the trade are code, and the systems they build are load-bearing for the whole team.

What is an SRE?

A site reliability engineer keeps a live service available and fast. The title comes from Google, which coined it in 2003 and published a book about the practice in 2016, and the founding idea is stated in one sentence: treat operations as a software problem. Where a traditional operations person might restart a failing server by hand, an SRE writes a program that detects the failure and restarts it automatically, then moves on to the next thing worth automating.

The day-to-day revolves around the live system. SREs carry the on-call rotation for the services they own, lead the response when an incident hits, and run the postmortem afterward. Between incidents they hunt down the causes of slowness, plan for scaling before traffic arrives, and build the automation that makes the next failure smaller. The role is common at companies whose product is a large always-on system, which is why SRE openings cluster at scaled tech companies and at any business where an hour of downtime costs real money.

For seniority, the environment is the tell. An SRE's skill grows with the size and stakes of the systems they have carried. Someone who held the pager for a service with millions of users has operated under conditions that can be found in only a few hundred companies on earth.

What is platform engineering?

A platform engineer builds internal tools for the company's own engineers. The name is newer than DevOps or SRE, and the job grows out of a pattern every scaling company hits: once there are many teams shipping many services, each team keeps re-solving the same problems. How do we deploy? Where do the logs go? How do we get a database? Platform engineering answers those questions once, centrally, by building an internal platform that every product team uses.

The output is a paved road. A product engineer at a company with a good platform team can create a new service, deploy it, and see it running in production in an afternoon, because the platform team already built the machinery underneath. Many companies that once had a "DevOps team" have renamed it a platform team, and the rename carries a real shift in mindset: the team treats the company's engineers as customers and builds products for them, with roadmaps and support and all.

Who is each role's customer?

This is the sorting rule, and it separates the three titles more reliably than any list of tools. A DevOps engineer's customer is the delivery process itself: their job is done well when code moves from a developer's laptop to production quickly and safely. An SRE's customer is the live service and the users on it: their job is done well when the system stays up and fast. A platform engineer's customer is the company's own engineers: their job is done well when a product team can ship without thinking about infrastructure.

All three roles overlap heavily in skills. They all work in the cloud, write automation, and sit closer to the machines than to the product. What changes is the direction the work faces, and that is what a hiring manager means when they use one title instead of another. A req that talks about deployment speed and pipeline reliability is describing DevOps work whatever the title says. A req that talks about availability targets and incident response is describing SRE work. A req that talks about developer experience and internal tooling is describing platform work. When the title and the body of the req disagree, the body is the truth.

What are uptime and an SLA?

Uptime is the percentage of time a service is working correctly. It is the core number the reliability roles are measured on, and it is written in nines: 99.9% uptime allows about eight and a half hours of downtime per year, and 99.99% allows about fifty-two minutes. Each added nine costs far more than the last, because reaching it means the system must survive failures automatically, with no waiting for a human. A system built to keep working through the failure of its own parts is called highly available, and high availability is a genuine specialty: it involves running spare copies of everything, often across cloud regions, so that no single failure takes the service down.

An SLA, or service level agreement, turns uptime into a contract. It is a formal promise to customers that the service will hit a stated target, usually with refunds or penalties if it misses. Once an SLA exists, reliability stops being a preference and becomes an obligation with a dollar figure attached, which is exactly when companies start hiring SREs. A developer who has owned an SLA target has operated with real consequences on the line, and the vocabulary of this lesson, nines, availability, incident response, will be native to them.

What are monitoring and logging?

Monitoring is the system that watches software in production and raises an alert when something looks wrong. It collects a stream of measurements, error rates, response times, traffic, and compares them against thresholds. When a threshold trips, the monitoring system pages whoever is on call. Monitoring is how a team finds out about a problem before customers do, and building good monitoring, alerts that fire on real problems and stay quiet otherwise, is a skill the reliability roles take seriously.

Logging is the record. As software runs, it writes down what happened: each request served, each error hit, each decision made, with a timestamp. Nobody reads logs in real time. They exist so that after something goes wrong, an engineer can reconstruct the event, and they are the primary evidence in the postmortem that follows an incident. The two work as a pair: monitoring tells the team that something is wrong right now, and logging tells them what actually happened once they go looking.

Together they are how engineers see production, and fluency with them marks a developer who has run software live rather than only built it. Owning a service in production means being the person the monitoring pages, and that experience shows up in how a developer talks about their work: in incidents survived, in postmortems written, and in the specific numbers they can quote about systems they kept alive.