The Three Cloud Layers Stopped Fitting

The definitions are worth having exactly, because they are better than their reputation. NIST Special Publication 800-145, seven pages, September 2011. Infrastructure as a service is where "the consumer is able to deploy and run arbitrary software, which can include operating systems". Platform as a service is where you deploy "consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider", with no control over the operating system underneath. Software as a service is where you use the provider's application and configure it, and that is all.

Read those again and notice what NIST is actually doing. Not one of the three definitions describes a technology. Every one of them is a sentence about which party manages which layer, with the boundary moving up as you go. The taxonomy was never a taxonomy of products. It was a taxonomy of responsibility, and the product names were shorthand for where the line fell.

That worked because in 2011 the shorthand held. You rented a virtual machine and you patched it, or you pushed code to a platform and the provider patched the runtime under it, or you logged into an application somebody else ran entirely. Three purchases, three buyers, and the label told you the line.

The label does not tell you the line any more. It has not for years, and the reason is not that vendors got sloppy with words. It is that the most valuable products to build turned out to sit exactly where the boundary is negotiable, and a name that means "the boundary is somewhere in the middle" carries no information at all.

A managed database is in none of the three. You do not control the operating system, so by the NIST text it is not infrastructure. You do not deploy an application onto it using provider-supported languages and tools, so it is not a platform either. It is not a finished application you log into. It is a component with an endpoint, and it lands in a hole in a definition that was written six years after the first managed relational database went on sale. Everybody calls it PaaS anyway, which is the taxonomy being used as a shrug.

A function runtime is a machine you rent by the invocation. A serverless function fits the platform definition on paper and behaves like nothing else in the category. The unit you buy is not a month of a place to run code, it is a few hundred milliseconds of one. Capacity planning becomes a concurrency limit, cost becomes a function of traffic shape rather than of fleet size, and the failure modes are about cold starts and per-account limits. Filing that next to a hosted web application because both are "platform" tells a reader nothing they can use.

Container services span the line on purpose. A managed Kubernetes cluster hands the provider the control plane and leaves you the nodes, the images, the operating system on those nodes, the network policy and every upgrade decision. Half of it is infrastructure by the NIST definition and half of it is not, in one product, sold under one name, with one bill. There is no third position in the taxonomy for a product that is deliberately half of two.

The word "platform" means two opposite things. From one vendor it is a thin convenience layer over machines you could have rented directly, and leaving costs you a week. From another it is an opinionated framework with its own deployment model, its own configuration language and its own idea of what an application is, and leaving costs you a rewrite. Those are not two points on a scale. They are different purchases, and the category name is identical.

The blurring is a business decision, not an accident. Renting machines is a commodity with a visible unit price that competitors can undercut. Selling a finished application is a crowded market with a switching cost that buyers learn to price. The middle, where the vendor operates something specific for you and the comparison is hard to run, is where the margin lives. You should expect the boundary of every profitable product to be exactly as ambiguous as the vendor can make it, and you should not be annoyed about it.

The question that decides a purchase is what happens at three in the morning. Something is wrong, and somebody has to answer: is this mine or theirs, can I see enough to tell, and if it is theirs, does anyone owe me anything. Every serious operational property of a service is a specific answer to a specific version of that question, and none of them is predicted by which of three words is on the datasheet.

Write the list out and it is short. Who decides capacity, and how quickly can it change. Who patches, and on whose schedule. Who designs for the failure of a zone, and who pays for the second one. Who guarantees the data survives, and what "survives" means when the deletion was yours. Who chooses when the version changes. And when it is slow, who can see why. Six questions, answerable for any product in about half an hour, and the answers vary wildly between two products both labeled the same.

Microsoft's own shared responsibility documentation makes the point unintentionally. It lays the three layers across the top of a matrix, then fills in the rows, and the interesting rows are the ones that do not move. Customer data, configurations, identities and accounts sit with the customer in every column, on-premises through SaaS, without exception. The layer moves the operating system and the physical hosts. It never moves the part that actually causes the incident.

So the honest reading of the whole scheme is that the vendor's own diagram admits the layer is a poor predictor of anything you will be woken up about. Two managed databases can differ on every one of the six questions. One hands you the upgrade window and keeps the failover decision; the other takes the upgrade and hands you a failover you have to trigger. Both are sold in the same aisle under the same word, and choosing between them on the word is choosing at random.

Visibility goes first, and quietly. On a machine you own you can attach a profiler, read the slow query log, count the file descriptors and watch the network. Each step up the stack removes one of those, usually without announcing it, and usually replacing it with a dashboard that shows the metrics the vendor found interesting. This is a fair trade most of the time; the metrics you are given are frequently better than the ones you would have built. It is only a bad trade on the day the problem is not one of them.

Upgrade timing goes second, and it is contractual. Azure supports three generally available minor versions of Kubernetes at a time, the latest and the two before it, publishes a removal date at least 30 days ahead, and gives you 30 days after removal before support lapses. Its own documentation puts it plainly: on 1.19 and later you can expect to upgrade at a minimum of once a year to stay supported. That is not a criticism, it is upstream's release cadence honestly passed through. It does mean the cadence of a system you did not write is now on your roadmap, permanently.

Diagnosis goes last, and it is the one people mind. The thing nobody anticipates is the day the service is simply slower and there is no mechanism available to you that explains it. You have latency, you have no explanation, and the only remaining move is to open a ticket and describe the symptom to somebody who can see the part you cannot. That is a genuine transfer of capability, not just of work, and it is the point at which an experienced team starts to feel the loss of the thing they gave up two years earlier for excellent reasons.

Take managed Kubernetes on the two largest clouds. Amazon meters the EKS control plane per cluster, by the hour, and its documentation says the architecture is why "Amazon EKS is able to offer an SLA for API server endpoint availability". Azure gives the AKS control plane away and sells the guarantee separately: the pricing page lists an optional Uptime SLA as its own meter, per cluster per hour, and then says it holds an internal goal above 99.5 percent for the API server whether or not you bought the SLA.

Read that carefully, because it is unusually candid. Azure is not selling you availability. It is selling you a financially-backed promise about availability that it intends to meet either way. One vendor has priced the thing, the other has priced the contract, and the same product category contains both. No amount of knowing that managed Kubernetes is "PaaS" gets you within a mile of that distinction.

The metering shape also bends the architecture, which is the part that outlasts the purchase. Per-hour pricing rewards consolidation and punishes idle capacity, so you get fewer, larger, longer-lived things. Per-request pricing rewards decomposition and punishes chatter, so an internal call that would have been a function invocation becomes a batch. Per-unit-consumed pricing, where the unit is the vendor's own abstraction, makes capacity planning a translation exercise in a currency only that vendor uses.

Which gives a rule I would actually apply in a review. If the meter measures something you have, the vendor is selling you a resource and the boundary is low. If it measures something you do, it is selling you an outcome and the boundary is high. If it measures something only the vendor can count, the boundary is wherever they say it is this quarter, and that is worth knowing before you sign rather than at renewal.

Moving up the stack is mostly rational, and it is not a preference. Running your own database means staffing the failure mode at two in the morning, forever, including the weeks when nobody is available. Most organizations cannot staff that well and know it, and buying the managed version is a correct decision made for an unglamorous reason. The mistake is not making the move. It is making it without writing down which of the six questions you just handed over, so that the first surprise arrives as a surprise.

Consider the repatriation argument, and who published it. The formulation everyone quotes is "The Cost of Cloud, a Trillion Dollar Paradox", by Sarah Wang and Martin Casado, published on 27 May 2021 by Andreessen Horowitz. Two things should be said in the same breath as the citation. It is a venture firm writing about infrastructure economics and naming optimization vendors inside the argument. And it explicitly says the point is not to argue for repatriation, which is the opposite of how it is usually cited.

It applies to a narrow band, and the narrowness is the interesting part. The worked example is Dropbox, which disclosed roughly $75 million of cumulative savings over two years in its February 2018 S-1 after moving the majority of its workloads to leased colocation. That is storage, at enormous scale, with volume that is steady and predictable years ahead. The line "you're crazy if you don't start in the cloud; you're crazy if you stay on it" is memorable because it is conditioned on scale and slowing growth, and almost every company quoting it is on the first half of the sentence.

Cost management became a profession because the bill became variable. The FinOps Foundation runs as a program of the Linux Foundation and reports over 7,300 individual members from more than 2,500 companies, with its own practitioner certification. An accounting practice acquiring a certification body in three years is not a fashion. It is what happens when a bill that varies by the hour meets an organization that approves budgets once a year, and neither side can change.

It is a decent first sort. When somebody says a vendor sells SaaS I know roughly what conversation is coming: a subscription, a tenant, an administrator's console, an integration question and a data export clause. That is genuinely useful before the meeting. The categories also give a shared vocabulary across procurement, finance, legal and engineering, four groups who otherwise share almost no words, and a common inaccurate map beats four incompatible accurate ones.

The alternative also has a cost, and it is the cost I keep understating. Evaluating every product on its own terms, asking the six questions of each, reading two vendors' upgrade policies properly, is a day of work per candidate. Most decisions do not deserve a day. An organization that ran this process on everything would be slower in a way that would show up long before the avoided incident did, and the people asking for a category are usually asking for a way to spend proportionate effort.

So the claim comes down, and further than I wanted when I started. The taxonomy is not wrong and it is not obsolete; it is a first sort being asked to serve as a decision, and it fails only in the second job. For anything small the category is enough. What I will not concede is the template version, where a requirements document asks whether an offering is IaaS, PaaS or SaaS and gets a word that two competing vendors will both answer identically while selling completely different things.

I want to be careful about pretending this is a discovery. NIST's authors were describing a market that existed and describing it well, and nobody drafting a definition in 2011 owed us a scheme that would survive a decade of product invention aimed squarely at the gaps between their categories. The definition did not decay. The thing it described moved, which is the ordinary fate of every good description of a live industry, and the failure is in the people still reading the 2011 map in 2022 rather than in the cartographers.

What replaces it is not another set of boxes. It is a question you can ask about anything, including the products that will exist next year and do not fit whatever taxonomy gets drawn to replace this one. When it breaks, whose phone rings, what can I see before I pick it up, and what am I owed if the answer is that it is theirs. Nobody has ever put that on a certification exam, and it is the only part of the purchase that survives the contract.