Infrastructure as a Service

Launching a service used to start with buying machines. You picked the specs, collected quotes, pushed the purchase through approval, and when the boxes arrived you rented rack space, bolted them in, and installed an operating system. Six weeks from order to first request was normal.

The harder part came before those six weeks even started: you had to guess a year of usage in advance. Buy too little and the service falls over on the day traffic spikes. Buy generously and you have tens of thousands of dollars sitting in machines that run at 10 percent most of the time. Planning meetings ended the same way every time. Marketing would say next month's campaign should triple traffic, and engineering would answer that anything ordered today arrives after the campaign ends. The money had to be committed up front, with no evidence and no way to take it back.

Infrastructure as a Service (IaaS) turns that purchase into a rental. The provider builds the data center, then slices the servers and storage inside it into pieces it hands out by the hour. You pick a size on a screen, press create, and two minutes later you have a machine; delete it and the billing stops at that moment. A six-week decision became a two-minute one, and that is the whole idea.

IaaS removes the decision to buy capacity ahead of time. Three things follow from removing it.

1. Procurement time disappears. When six weeks becomes two minutes, the way people work changes. Spin up a server to try a feature, decide against it, delete it the same day, and the bill is a few dollars. Cheap failures mean more attempts, and a test that would once have waited for the next purchase cycle happens on a Tuesday afternoon.
2. A lump sum becomes a monthly one. Ten servers cost around $45,000 at once and get written down over three years; renting the same ten costs roughly $1,100 a month. For a company a year past its funding round, that difference matters.
3. Capacity no longer has to be predicted, because you add machines when you need them. Adding machines to absorb load is called horizontal scaling, and handing that judgment to a rule is autoscaling. Set it to run two machines overnight and eight at lunchtime and the money spent on idle capacity drops with it.

Rented remote computing in general goes by cloud, and IaaS is the lowest layer sold that way. The provider owns the building, the power, the physical servers, and the software that slices them up. One slice is a virtual machine (VM) — a share of a physical server that behaves like a separate computer of its own.

Everything above that slice belongs to the renter. You install the operating system, apply security patches, install the software, and bring it back when it dies. What you rent is the machine, not the work of running it.

There are three ways to not use IaaS: drop below it and own the hardware, move above it and delegate more, or leave the machine unit behind entirely.

Below it sits on-premise, where you buy the machines and run them in your own space. Past a certain scale renting costs more than owning, so if usage is predictable and the footprint will hold steady for three years or more, owning gets cheaper. It's also the only option left when a contract says the data cannot leave a specific network, or when the systems that need it sit on a network with no route to the public internet at all.

Above it sits PaaS, where you push code and the provider handles server configuration, deployment, and scaling. Nobody has to think about operating systems or patches, which is how a team of three engineers runs a product without a systems administrator. The trade is that you can't touch settings outside the shape they give you, and the unit price runs two to three times higher.

The third direction is serverless, where instead of renting a machine you upload a piece of code that wakes up only when a request arrives. With no requests the bill is close to zero. The cost is a cold start: the first request into a sleeping environment is noticeably slower than the rest.

Companies rarely pick just one. The main product usually runs on IaaS, an internal tool thrown together last quarter sits on PaaS, and the nightly billing job runs serverless.

"We should drop down to IaaS and manage this ourselves. We're paying $9,000 a month and half of it is capacity we don't touch."

A proposal to give up the convenience of a higher layer in exchange for a lower bill.

"We're not an IaaS provider. Installing on the customer's own servers is a separate contract."

Drawing a line: what we sell is finished software, not infrastructure.

"That's outside what the IaaS provider covers. Anything above the operating system is on us."

The outage came from our configuration, not from the rented hardware.

Pagedeck runs on servers rented from an IaaS provider. Theo picks the sizes and the count, and set a rule that adds machines during the busy part of the day. Every quarter Grace opens the cost breakdown and asks why a line item grew, and Theo points to which machines are sitting idle. Nothing about that conversation would have been possible with hardware bought three years earlier.

The word also comes up when an enterprise customer asks for an installation on their own servers. That request puts our product on their infrastructure, which is a different layer and a different contract from the IaaS we rent. When Sofia misses that distinction, a promise gets made in a sales meeting that nobody can keep.

The most common mistake is assuming renting is always cheaper. The lump sum is gone, so it looks that way, but the hourly rate usually costs more than buying the same specs and keeping them three years. The gap widens with scale, and past some point owning wins. Believing it's cheap and never checking is how forgotten machines and abandoned storage quietly drain a few thousand dollars a month.

The more expensive mistake is assuming there's nothing left to manage. The provider's responsibility ends at the physical machine; the operating system and everything above it belongs to the renter. A server breached because a patch was never applied is not the provider's fault. That boundary is written into the contract, and teams that start without reading it find out where their half began only after an incident.