Platform as a Service

For a long time, putting a service on the internet was work that started after the code was finished. You bought a machine, put it in the corner of the office (on-premise), installed an operating system, installed a web server and a database, and then hand-built the steps that moved new code onto the box. On a team of three engineers it was common for one of them to spend two solid months on nothing else.

The cloud took away the front half of that. Machines were rented by the hour instead of bought, so hardware invoices and delivery lead times disappeared. But what arrived was an empty server. Deciding what to install on top of the operating system, and how code would get there, stayed exactly where it was.

So the same scenes repeated on team after team. A new engineer needed three days to get the product running on their own laptop. Deployment was a procedure only one person knew, and during that person's vacation nothing shipped at all. More hours went into tending the machinery that released features than into building the features.

Platform as a Service (PaaS) exists because someone widened the rental. Instead of renting one server, you rent the whole environment the code runs inside, and the homework above the operating system moves to the provider.

PaaS takes over everything a running service needs except the code itself. You push code and one or two configuration files; the provider decides, in its own way, how that code actually runs. Four things move across.

1. Runtime setup — the language version, the libraries your code imports, and the web server configuration are read off the code you pushed and matched for you. This is where a new teammate's first successful run drops from three days to an afternoon.
2. Deployment — a CI/CD pipeline, which checks each change and then puts it live, comes attached by default. Shipping stops being one person's hand skill and becomes the act of merging code into the repository.
3. Scaling with traffic — when load rises the platform runs more copies of the same code, and when load falls it takes them away again. The property of being able to grow to absorb load is called scalability, and here you rent the machinery for it instead of building it.
4. Visibility — log collection and response-time charts come with the dashboard. How much you can tell about a system's insides from the outside is its observability, and PaaS turns a basic amount of it on from day one.

What you give up in exchange is fine-grained control. Which Linux distribution runs underneath, how your code gets packaged and shipped — the provider already decided. A team that needs to write its own container spec, bundling everything an app needs to run into one unit, will find this layer cramped.

The teams it fits are easy to describe. The product needs nothing unusual from its runtime, nobody is available to look after servers full time, and the open question right now is the market rather than the technology. The choice comes down to hiring one systems person at $45,000 a year or paying a couple of thousand dollars more each month in rent.

The alternatives split into renting less and renting more.

Renting less means IaaS: you take the servers and storage and build everything above them yourself. It is far more work and far cheaper for the same capacity. Load that a $900-a-month pile of servers can absorb tends to cost around $2,300 a month on a platform. Once the server bill is large enough to be noticed, that gap passes the cost of a person, and moving back down starts to pencil out.

Renting more means cutting the unit of execution smaller. Upload a single function, have it run only when a request arrives, and you have serverless, which costs far less than PaaS for anything that doesn't need to stay awake around the clock. The catch is that a function nobody has called in a while answers slowly the first time, and long-running jobs get cut off partway. So teams usually move the intermittent work — file conversion, sending notifications — rather than the whole product.

The third option is not building it. Payments, outbound email, and anything else that already exists as somebody's product can be subscribed to instead, leaving your code with nothing but an API call into their window.

"Let's put it on the platform for now, get it wired up, and drop down a layer once traffic grows."

There is no time to assemble an environment, so speed wins over price today, and the move to IaaS waits until the bill gets noticed.

"The bill is two and a half times the raw server cost, and it's still cheaper than one more person."

The comparison is being made against salaries, not against hardware.

"The platform doesn't expose that, so there's nothing we can do about it."

The request falls outside the boundary the provider drew, which leaves dropping it or moving down a layer.

Pagedeck ran its entire product on a platform through its first year. Theo was the only engineer, so there was no other option. Now, at 45 people, document storage and search have moved down to IaaS and the rest has not. When Grace asks about the line item in the monthly cost review, Theo's answer is always the same: moving down cuts the bill but requires hiring someone to tend the environment, and at this headcount that person costs more than the savings.

The most common misreading is that PaaS makes server worries go away. The marketing leads with deploying without managing servers, so it sounds that way. What actually changes is the kind of worry. Hardware and the operating system move across, but the pricing model, the number of instances spinning up, and the provider's own outages all stay yours. A team that walks in unprepared usually learns this from an invoice: traffic spikes during a launch, autoscaling responds more enthusiastically than anyone expected, and the month comes in at three times the usual figure.

The other frequent mistake is treating this as a layer only small teams use. Price drives that impression, but the deciding question is how much you need to control, not how big you are. A team with people to spare is still better off leaving the layer alone when it has no reason to reach underneath, and a team with nobody to spare still has to move down when the runtime it needs is unusual. Teams that use headcount as the trigger migrate because they grew, then find that the time spent moving, plus the operations work that arrives afterward, outweighs the money saved on rent.