What is the difference between DevOps, SRE and Cloud Ops?

Quick answer: DevOps is the practice/culture of developers and operations working together across the whole software lifecycle; SRE (Site Reliability Engineering) is a more prescriptive discipline that applies software-engineering rigour (error budgets, SLOs) specifically to keeping systems reliable; Cloud Ops is the narrower, more traditional operational work of running and maintaining cloud infrastructure day to day. The three overlap heavily and the exact boundary varies a lot by company.

I was in the pilots' lounge the other day when the barkeep says "what do you do, then?" and I said "operability." He said that doesn't help him at all — what's operability? Well, this video is for him. I'm going to tell you what operability engineering is — quite straightforward really, but let's go through it one step at a time. Before I get into that, did you know you can come along to a free Q&A every Wednesday at lunchtime, where you can ask any tech questions you like, at tech-answers.club.

Is it DevOps?

DevOps is primarily about breaking down silos — communication, collaboration (continuous integration and deployment is part of that, but I prefer thinking of it as collaborative workflow), and getting code to where it needs to be deployed and working as quickly as possible — build and deploy, easy peasy, right. Its main purpose is to shrink the gap between developers and operations, and the smaller we can get that gap, the less handover, the smoother the deployments — you can start deploying stuff once every hour, or even quicker, if your coders are fast enough.

Is it SRE?

SRE — site reliability engineering — is a thing Google have championed for ages, and I guess it could be that. The main thing about SRE is having the service running to an acceptable level, which means you end up with two things: a service level objective, which is how much of the time it goes right, and error budgets, which is how many times it goes wrong. Error budgets exist because every time something goes wrong, your users think "that's rubbish," but they only have a certain amount of tolerance for that before they give up and use somebody else's product. So you develop a service level objective that's high enough to make sure your users don't leave, but low enough that your devs have got a chance to fix all the bugs.

Then there's proactive and reactive monitoring — proactive monitoring is where we're actively thinking about what can go wrong and fixing it before it does, and reactive monitoring is having those lovely dashboards so that when something does go wrong and eats into our error budget, we can identify it and do something about it.

Is it Cloud Ops?

If it's not exactly DevOps and not exactly SRE, perhaps it's Cloud Ops. Cloud Ops is all about cloud architecture and design — when I say cloud, this might be a public cloud like Azure, Google, or AWS, or it could be an internal cloud. For many years I was on-site in a data centre racking servers, and we used virtual servers to give customers who wanted servers quickly a faster response — spin up a VM, here's a template, off you go, build a server in what was probably half an hour back then; five minutes would be acceptable these days.

Cloud Ops is all about architecting the design, optimizing costs, and keeping those costs down — if you're running a server 24/7, don't pay cloud prices for it, you're wasting your money, you might as well have a data centre. It's also about security and compliance — making sure there are no holes in the system, that the people who need access have got access and those who don't, don't, and complying with whatever rules and regulations you need to, to keep the data safe.

Where operability fits

Operability engineering is all of those — it's about being maintainable as part of the design, it's about being scalable (again, cloud design, being able to deploy stuff fast), and it's about being observable — knowing when things go wrong and how often things go right.

Here's a handy way to break it down: DevOps is about reducing friction between development and operations; site reliability engineering is about system availability and performance — knowing when it's working well, when it's not, and making it work better; and Cloud Ops is about optimizing cloud resources and infrastructure so we're providing a decent service without paying lots of money, and reducing the bill where we need to.

All three care about automation — prioritizing and reducing manual intervention. Developers don't like touching servers, so give them a button to deploy the code. Continuous improvement — iterating on what we've got: as an SRE you're reducing errors, as a Cloud Ops engineer you're reducing costs, and as a DevOps engineer you're making things go faster and reducing development time. Observability — creating transparent, monitorable systems so we can see how fast builds are performing, how long a deploy takes, when errors are creeping up and eating into our error budget, and how much our bills are. Infrastructure as code — we want to treat infrastructure with the same rigour as software development: it's version controlled, we know exactly where it is, and we can deploy it quickly.

All of those things come into DevOps, SRE, and Cloud Ops. DevOps ensures a smooth development and deployment of code; SRE maintains uptime and makes sure users don't experience errors; Cloud Ops optimizes cloud spending and infrastructure — what's the minimal amount of infrastructure we need to provide that uptime.

So, over to you in the comments below — describe your understanding of operability in one tweet-sized explanation, can you do it? Operability isn't about choosing one approach, it's about understanding how these disciplines complement each other to create a robust, efficient tech system. So is it all of the above? Yes, as I said to the guy in the pilots' lounge.

I'll leave you with a joke: why is DevOps always prepared? Because there's always something in the pipeline. If you thought that was rubbish, let me know — come over to tech-answers.club, join me on the live Wednesday session, and tell me your favourite joke instead. I'll see you on the next one.