What is cloud computing and how does it fit into the DevOps era?

Quick answer: cloud computing — renting compute, storage, and services on demand instead of owning hardware — is what made DevOps practical at scale: infrastructure as code, auto-scaling, and managed services only work because the underlying infrastructure is API-driven rather than a physical box in a server room, which is why DevOps as a discipline grew up alongside the major cloud providers.

Welcome back to the channel — today I'm talking about embracing the cloud: what it is, how it can help you, mistakes to avoid, and specifically how DevOps sprung out of the cloud (or did the cloud create DevOps — who knows). I'll also touch on infrastructure provisioning, since defining infrastructure is a big part of the cloud, and serverless computing, since there's no point having the cloud unless you can use serverless — we don't want to look after servers, right — and managed services.

What is cloud computing?

Cloud computing is using someone else's hardware — essentially everything that's not on-prem is public cloud computing (there's also "private cloud," but we're not talking about that today).

The rise of the cloud

Before AI, before Kubernetes, Amazon Web Services was created in about 2001 — yes, that's a long time ago. They started with S3, a way of storing data securely with lots of nines of durability, so it doesn't go walkabout (keeping the data safe is very important). Shortly after, they developed EC2, Elastic Compute Cloud, where you can request a virtual machine on demand — again, back in 2001, before AI, before Kubernetes, before serverless was even a thing.

Why does "elastic" matter? The whole point of elasticity is being able to pay for exactly what you need. If your application runs fine on one server, only pay for one server — but if it suddenly spikes on a Friday afternoon because all your customers want their stuff done before the weekend, and you need four servers, traditionally, running on-prem, you'd have to have those four servers running all the time. The advantage of cloud elasticity is you can borrow somebody else's servers for when you need them — spin up four servers for the Friday afternoon rush, then by 6pm, when everyone's down the pub, spin them back down to one, and everything's happy for the weekend. We've serviced those customers without paying for four servers all week.

For that to work, servers need to be able to spin up as quickly as possible — there's no point having a server if it takes ages to build. In the days of CD-ROMs, and before that floppy disks, building a server could take days. With cloud and online networking, we can get that down to five minutes, sometimes less. Public cloud providers also want a self-service portal, so you can request servers yourself — after all, they can't start billing you until they've delivered the service — and tools like Terraform let us do this even faster than clicking through a console.

The downside is that on-demand computing costs money (I've got another video on why AWS servers cost so much — link in the description) — the short answer is, while that server exists, somebody's got to pay for it.

Pets versus cattle

This led to the next big idea in cloud computing: pets versus cattle (I believe a Microsoft person coined the term). In the old days, a server took ages to arrive from the supplier, you spent days building it, and then you nursed it — redundant power supplies, redundant CPUs, redundant everything, because it's the only one you've got and you don't want it to die. It's your pet. The cloud flips that on its head — if you can have a server up and running on demand within five minutes, and switch it off as soon as demand disappears, then it's like cattle: you raise it, it's useful for a while, then you retire it. A bit brutal, but if you can automatically build your servers, you don't need to treat them like pets.

Provisioning and configuration

Where do these servers come from? Ultimately, the cloud API — whether Linode, AWS, or Azure, they all have APIs where you can request a server with a given amount of CPU and memory, and bolt on a couple of disks. Cloud APIs can be a little clunky and change constantly — just look at how often the Terraform AWS provider gets updated.

To help us, there's configuration management. Once the cloud API spins up the server, we need to configure it — step one, get the server (like ordering hardware), step two, configure it: load the OS, load all the software, configure the settings, user accounts, and so on. Configuration management tools like Puppet, Chef, or these days most commonly Ansible, handle this — you load your configuration, the server spins up, asks "what's my configuration," and an Ansible playbook configures it in a couple of minutes, ready to work for you. Bundling the API calls together in Terraform modules, plus Puppet, Chef, or Ansible for configuration, is what we mean by configuration as code.

Other cloud tools and services

Besides the big cloud services — Azure, Google Cloud, AWS — there are other ways of accessing the cloud, like Microsoft 365 or Google Workspace (email, Word, spreadsheets), which also run on somebody else's computer, so they qualify as cloud too — the software developer builds the software and sells it to you monthly along with the servers needed to run it, they make more money, you get more convenience, win-win.

Then there's serverless and managed services — S3, as I mentioned, definitely uses servers, but you don't look after them. Same with the Google AI Platform, Amazon RDS/Aurora (a database service where you don't manage the backend), GitHub Actions, or Cloudflare for WAF and CDN needs — all of these use servers, none of which you touch directly, because you don't need to look after them, but they're serverless and they're cloud services.

Migrating to the cloud

The scariest phrase you can say to any engineer is "lift and shift" — don't do that. If you're just going to lift a server and shift it into the cloud unchanged, you might as well keep running it on your own hardware — you won't save money, because you'll pay for the hardware, the data centre, and the software still needs looking after. You're wasting your money, and the server you've already got may well be more resilient — cloud providers don't always tell you their commodity servers are cheap precisely because they're expected to fail, with no built-in failsafe. S3 works so well because it's thousands of servers working together with replicated data — if one dies, no impact on the service. If you've got one server running a service and it dies, that's a direct impact on you.

If you're migrating a cluster, there might be some gains, but the real gain isn't in lifting and shifting — it's in re-architecting your software so it can automatically scale, following demand as it ebbs and flows through the day, rather than paying for the peak number of servers you need all the time. That, plus using managed services so you don't have to look after servers at all, are the two big reasons cloud computing can save you time and money — and saving time means not paying engineers so much for undifferentiated work.

In summary

We've covered the cloud services themselves — AWS, Azure, Oracle, OVH, DigitalOcean, Linode, and plenty more — and whichever you choose, you don't have to lock yourself in if you're using infrastructure as code; tools like Terraform let you blend providers, though I wouldn't recommend it for a single service, stick with one platform there. Being multi-cloud in the broader sense (Microsoft 365 for productivity, AWS for servers and databases) is fine, but spreading engineers thin across every cloud provider's quirks costs more without much benefit. With infrastructure as code, Terraform links into the cloud APIs to provision servers, then configuration management gives them a personality and gets them working for you in as little as five minutes.

Other tools worth mentioning: managed services, online office and collaboration tools, managed infrastructure like databases, and of course, containers. If you're migrating and adopting the cloud, please don't lift and shift — it'll cost you more in the long run. Use the cloud-native features, and look at something like the Twelve-Factor App methodology, which lays out the factors that make an application flexible and cloud-ready.

Any questions, put them in the comments below, I'd love to answer them — until next time, have fun, and may all your deployments be smooth.