Cloud

Running a service required machines, and machines had to be bought. Buying them was not a short procedure. Pick the specification, get a quote, file a purchase request, wait for approval, and when the hardware arrives, rack it, connect power and network, and install an operating system. Three weeks if everything went well. Six weeks more often.

The trouble was that those six weeks had to pass before anyone knew the demand. The order had to be placed against a guess about future usage, and the guess was wrong far more often than it was right. Order too little and the service fell over on a busy day. Order too much and machines sat in the server room drawing electricity. Reversing either direction took another six weeks.

What Theo ran into shows the shape of that delay. He wanted one server for a few days to measure how a new feature behaved under load. His purchase request came back with the note that it wasn't in the quarter's budget. He ended up running the test at night against a production server, and the people who logged in during those early hours got slow pages. A structure that requires buying an asset to meet a three-day need produces exactly that choice.

Cloud is the name for changing that structure. Machines get rented instead of bought, rented through a screen in minutes rather than through a contract, and deleted when the work is done so the charges stop. Once the decision to buy is separated from the decision to use, everything else follows.

What the cloud removes is waiting and irreversibility. It shows up in three places.

1. Procurement time — choose a specification on a screen, press create, and there's a usable machine two minutes later. The six weeks above turn into minutes. Theo's load test becomes something he starts in the afternoon and deletes in the evening.
2. Demand forecasting — there's nothing to guess. Add capacity when traffic arrives and remove it when traffic leaves. Wire up autoscaling, which hands that add-and-remove decision to a rule, and the fleet drops to two machines overnight and climbs to eight at lunchtime.
3. Upfront capital — a large one-time payment becomes a smaller monthly one. Five servers at $6,000 each means $30,000 before anything runs; renting the same specification costs around $1,500 in the first month.

Reversibility changes people more than it changes technology. When failure gets cheap, attempts go up. A $30,000 decision gets three meetings. A decision that ends with pressing delete just gets tried, and undone if it doesn't work.

What you can put on the rented ground widens along with it. There's the virtual machine (VM), which splits one physical server so it behaves like several, the container, which bundles just what a program needs so it runs the same way anywhere, and serverless, where nothing is managed directly and code runs one function at a time. All three are billed the same way.

The cloud isn't the only option. There are roughly three ways to get machines.

1. Owning them — buy the hardware and keep it in your own server room or data center. Shipping a product to run on a customer's own servers, or on-premise delivery, is this same form. If a workload will run at a steady level for three years or more, total cost comes in below renting. In exchange, somebody has to drive to the building at 3 a.m. when something breaks.
2. Colocation — own the hardware but rent the space, power, and connectivity. The burden of running a facility goes away while the choice of hardware stays. It's the middle path common in regulated settings like finance, where physical control is required.
3. Hybrid — mix the two. Databases holding personal information stay on owned equipment while the front end, where traffic swings, sits in the cloud. This takes the most work, since it means maintaining a link between two locations and two sets of operating practices.

Three questions decide it. How steady is the load, does regulation dictate where the data physically sits, and is there someone available overnight. Steady load plus available staff favors owning. Swinging load or thin staffing favors renting. Pagedeck, forty-five people just after a Series A, sits firmly in the second case.

"I'll spin the load-test instance up in the cloud and delete it as soon as I'm done."

The resource is needed for a few days, so it gets rented rather than bought as an asset.

"Cloud spend is up 40 percent from last month. Let's find the cause first."

Billing follows usage, so something unused is probably still running somewhere.

"That customer needs their data held domestically, so I put them in the Seoul region."

Storage location is a choice, and it was set to match a regulatory requirement.

The conversation comes up most often at Pagedeck during the monthly cost review. Theo opens the previous month's bill line by line and Grace points at whatever grew. The cause is usually one of three: a machine created for an experiment and never deleted, a specification sized larger than anything needed it to be, or storage that looked deleted but wasn't. When machines were bought, this kind of waste got caught once at the purchase step. When they're rented, nothing catches it and it leaves quietly every month.

So Theo made tags mandatory at creation time: purpose, owner, and deletion date. Writing infrastructure down in a file and running it rather than clicking it together on a screen — infrastructure as code (IaC) — attaches those tags automatically.

The most common misreading is that the cloud is always cheaper. No servers to buy makes it look that way, and for the first several months it usually is. But the bill scales with time and volume, so at some size the two lines cross. A service with steady load passes a point where three-year total cost runs above owning the hardware. Staying cheap means somebody has to keep turning off what isn't in use, and the team that assigns that to nobody gets a surprise a year later.

The other misreading is that management disappears. Nobody touches hardware, so operations look like they've gone. What's gone is swapping drives and badging into a server room. What arrives is access control, backups, and cost management. Where the data physically lives is now a value someone has to choose, too. Putting servers in a US region makes the setup a cross-border transfer of personal information, which carries its own disclosure and consent obligations. Leaving the region dropdown on its default quietly creates a legal duty.