The Cloud Reflex, Part 1: What is the Cloud, Actually?
Most companies we talk to can’t remember “choosing” the cloud.
They “chose” the cloud the same way you “choose” to open a bank account: because that’s what serious companies do. Then one day they woke up with a frightening bill and a stack built on services that don’t exist anywhere else.
If this sounds familiar, you might be operating under what we have started calling the Cloud Reflex: the unquestioned assumption that anything serious must live in AWS, GCP, or Azure.
In a series of blogposts, we’re going to examine this reflex. But first, let’s make sure we understand what the cloud is.
Servers and clouds, demystified
A server sounds more intimidating than it is. When I started programming, I never quite understood what people meant by the word. Something abstract, somewhere out there, reserved for grizzled sysadmins.
Turns out, it’s just a computer. Same components as your laptop: a processor to run code, memory to hold data, a disk to store things, a network connection. The difference is it lives in a datacenter instead of on your desk. You could technically host a website on your laptop, but every time you close it, your site goes down. That’s why companies like Hetzner and DigitalOcean exist: they run warehouses full of these machines and rent them out. Pay a monthly fee, get a whole computer, running 24/7, yours to use however you want.
If a server is just a computer that’s on all the time, what’s the cloud? The cloud is also servers. AWS, Google Cloud, Azure — underneath, it’s still racks of computers in datacenters. Same hardware.
The difference is what you’re renting. Instead of getting a whole computer, you get slices, packaged as services. S3 for file storage. Lambda for running code. RDS for databases. Each one metered separately: per gigabyte stored, per request made, per millisecond of compute time. You never see the machine. You interact through dashboards and APIs. This is where the term “serverless” comes from, by the way. Not that there are no servers, you just never touch them.
What the difference looks like in practice
This distinction, whole machine versus sliced services, might sound abstract. But it shapes everything: how you build, what you pay, and how easily you can leave.
Let’s make this more tangible. We run partijplein.nl and zonopjebakkes.nl on a single server. These are web applications with a Python backend and a simple frontend. The server costs us about €15 per month. We log in, deploy our code, and it handles thousands of simultaneous users just fine.
In a cloud environment, apps like partijplein.nl and zonopjebakkes.nl would be assembled from multiple managed services: one for handling requests, another for the backend logic, a third for a database, plus monitoring, permissions, and so on. Each billed separately, each with its own dashboard and documentation. Instead of one machine running your code, you’re orchestrating a constellation of services.
“Okay,” you might be thinking, “a simple web app is one thing. But what about real infrastructure? What about serious amounts of data?”
Fair question. At STL, we also train deep learning weather models. That means downloading terabytes of meteorological data, preprocessing it, and serving it to remote GPU clusters for training. The kind of workload that sounds like it demands a cloud-native architecture. Nope. It runs on a single server: 80 cores, 18TB storage, 256GB of RAM.
Any developer can log in and see exactly what’s running. No certifications required, no service maze to navigate. The cloud alternative? We’ll get into the economics in Part 2, but let’s just say there’s a reason we didn’t go that route.
So why does everyone use the cloud?
All of this begs the question: if it’s all doable yourself, why does the cloud exist? Of course, there are clear advantages, and situations in which those sliced services make a lot of sense.
The cloud’s core promise is: you focus on your product, we handle the infrastructure. You don’t manage servers, you don’t think about hardware. Their teams handle that. You pay for the convenience.
The flagship example is elastic scaling. If your app needs to go from 100 users to 100,000, the infrastructure stretches to match. You don’t provision capacity upfront, it grows with demand. If you’re building something that might go viral overnight, that elasticity could save your launch.
And the cloud offers more: a whole ecosystem designed to keep big organizations from tripping over themselves. Permissions that work across services, visibility into who did what, infrastructure that fifty engineers can share without fighting over it. These platforms have spent years building tooling that large enterprises genuinely need.
But here’s the question you should be asking: is that actually your situation?
Most companies aren’t running at that scale. They’re not onboarding engineers every week or fielding traffic that doubles overnight. They’re running steady, predictable things. A web app serving customers. A data pipeline processing the same sources each day. Batch jobs that run every night. They don’t need to 100x one day to the next. They need something reliable that doesn’t drain their budget.
Yet they’re paying for infrastructure designed for problems they don’t have.
The reflex
That’s the Cloud Reflex.
Not a reasoned decision, but an unexamined default. Many companies never sat down and evaluated the alternatives, because the cloud was the only option they’d ever been shown.
The thing is, it’s not a neutral choice. When you build on the cloud, you’re building in a particular way: one where complexity doesn’t disappear but shifts, where the services you depend on don’t exist anywhere else, and where the costs are higher, and harder to escape, than they might first appear.
These trade-offs are worth understanding, even if you end up staying where you are. We’re not here to tell you the cloud is wrong. That’s not what this series is about. The goal of this series is to make sure you’re actually choosing.
