IaaS, PaaS & SaaS

There are three ways to have bread. You can grow the wheat, mill it, and bake — owning every step and every failure. You can buy the dough and bake it yourself, letting someone else handle the parts that are tedious and easy to get wrong. Or you can buy the loaf. All three end in bread; they differ only in how much of the work you kept, and the right choice depends entirely on whether you are a farmer, a household, or simply hungry.

Cloud service models are the same decision applied to the stack you met in Class One. Back then you were shown seven layers and a red line of accountability, and told plainly that the line would move — that you would draw it three more times in this class. Here they are. IaaS, PaaS and SaaS are not three products. They are one stack with the line drawn at three different heights.¹

The higher the line sits, the more the provider carries and the less you touch. What never changes — and this is the callback worth tattooing on — is the top of the stack. In every model, your data and your identities stay above the line. You can rent the baking; you cannot rent being the one accountable for what comes out.

It helps to name the two dials so you never confuse them again. The service model — this class — is a statement about how much of the stack you manage. The deployment model — Class Five — is a statement about where it physically runs and who else shares the hardware. They turn independently: you can run IaaS in a private datacentre or PaaS in a public cloud, and every combination is legal. When an interviewer asks whether App Service is "public or private," they are not testing your recall; they are checking whether you know the question mixes two dials that have nothing to do with each other. Keep them apart and this whole phase stays simple.

One more framing before the picture, because it is the frame that pays your salary. Moving up the stack is not moving toward "better" — it is moving work off your plate in exchange for freedom you give up. Each rung deletes a category of chore and, in the same motion, deletes a category of choice. The engineer's job is not to climb as high as possible; it is to stop climbing at the exact rung where the chores you shed stop being worth the choices you surrender. That rung is different for every workload, which is the whole reason this class ends where it does.

IaaS

Infrastructure as a Service. You rent virtual machines, disks and networks; the provider runs the hardware and virtualisation, and everything above — operating system, patches, runtime, application — is yours.

IaaS is the closest thing to the server you used to buy, minus the loading dock. You choose the size, install the operating system, and from that moment you own its upkeep: the security patches on the second Tuesday of the month, the disk that fills silently, the runtime that needs upgrading, the backup that must be tested rather than merely configured. In exchange you get near-total control — any operating system, any software, any peculiar dependency a fifteen-year-old application insists upon.

That control is the reason to choose it and the price you pay for choosing it. Control is not a trophy; it is a to-do list. Every layer the provider hands back to you is a layer you are now on call for. IaaS earns its keep when a workload genuinely needs that latitude — a legacy application, a licence bound to a specific environment, software the managed platforms will not host — and quietly punishes you when it does not, by handing back chores you never actually wanted.

On Azure the canonical IaaS building blocks are Azure Virtual Machines for compute, managed disks for their storage, and a Virtual Network to put them on — the exact trio you will wire together by hand in Phase Two. What "you own the OS" means in practice is precise and unglamorous: you pick the image, you sit inside the monthly patch cycle, you watch the disk so it does not fill at two in the morning, and you configure the network security rules that decide what can reach the machine at all. Azure runs the hypervisor, the physical host and the datacentre beneath; the line stops there, and everything above it has your name on the on-call rota.

Know the cases that genuinely earn IaaS, because they are the ones an interviewer will probe. A vendor application certified only on a specific operating-system build. A licence bound to a particular machine or MAC address — Campux's POS batch job, precisely. Software the managed platforms simply will not host, or a kernel-level agent that needs privileges PaaS never grants. In each, the control is not indulgence; it is the requirement. Outside those cases, reaching for IaaS "to be safe" is how a small team ends up staffing a datacentre it went to the cloud to escape.

Watch the billing shape too, because it is the other half of the trade. An IaaS virtual machine bills for the time it exists, running or idle — a box you rent by the hour whether or not anyone is using it. That is fine for a workload that is busy most of the time and a slow leak for one that spikes and sleeps: Campux's storefront would sit near-idle every January, paying full rate for capacity nobody touches. Keep that picture handy, because it is exactly the weakness the next rung's serverless billing is built to remove.

PaaS

Platform as a Service. You deploy your code and your data; the provider runs the operating system, the runtime, the patching and the scaling machinery beneath it.

PaaS raises the line one notch, and that single notch is where most modern workloads want to live. You bring the application and its configuration; the platform absorbs the operating system, the runtime, the patch cycle and the tedium of scaling. Azure App Service, Azure SQL Database and Azure Functions are all PaaS — you hand over code or queries, and the second-Tuesday patch is somebody else's calendar entry.

Control is a cost, not a prize.

The reason PaaS "usually wins" is that most teams do not actually want to administer an operating system; they want their software to run, scale, and stay patched without a human remembering to. PaaS trades a slice of control for a large reduction in chores, and for the majority of applications that is the trade that pays.² It has limits — less freedom to install arbitrary software, occasional constraints on runtime versions — but for a storefront that needs to survive a November peak without a team babysitting virtual machines, those limits are a fair price. You will spend Phase Two putting Campux's storefront exactly here.

Serverless — PaaS at its logical end

One member of the PaaS family carries its own name on the exam, and earns it. Serverless — Azure Functions is the canonical example — means you hand the platform a function rather than an application, and the platform runs servers you never see, size or patch: it allocates them when an event arrives, scales them with the load, and scales them to zero when the work stops. The billing follows the same shape — you pay per execution rather than per hour of a machine sitting ready, which is why a function that fires only when Campux's November orders arrive can cost close to nothing in January. It is still the PaaS family by the test that matters: the line sits in the same place, your code and data above it, everything else below.¹ Put the two billing shapes side by side and the appeal is obvious: the IaaS box from the last section bills for every idle hour, while the serverless function bills only for the milliseconds it actually runs. A tidy-orders job that fires a few thousand times in November and almost never in January costs real money on an always-on VM and rounding-error pennies as a function — the meter follows the work instead of the clock. That is the same elasticity argument from Class Two, now expressed in code rather than servers. When an examiner asks you to describe serverless, say those three things — no servers to manage, scale to zero, pay per execution — and you have said all of it.

Where PaaS pushes back

PaaS is not a free lunch, and pretending it is gets junior engineers into trouble the first time an abstraction leaks. You give up the freedom to install arbitrary software on the host, you accept the runtime versions the platform is willing to offer, and you live inside its quotas — a request-per-second ceiling, a connection cap, an execution-time limit that is invisible at low load and abruptly fatal at ten times it. The failure mode is distinctive: everything works in testing, then a real peak arrives and the platform enforces a limit you never knew you had. The skill is not avoiding PaaS; it is reading the limits before the peak, so the day you outgrow a tier is a slider you move on purpose, not an outage you explain afterward. A managed platform trades your operational freedom for the provider's operational competence — a trade that pays for most workloads and quietly costs you for the few with genuinely unusual needs.

SaaS

Software as a Service. You use a finished application over the internet. The provider runs all of it; you bring only your data, your users and your configuration.

SaaS is buying the loaf. Microsoft 365, Salesforce, a payroll system reached through a browser — you do not deploy code or manage a runtime, you sign in and use software someone else builds, runs and patches. The line sits at its highest here, leaving you only the two layers that can never be delegated: your data, and the question of who is allowed to see it.

Which is precisely why the "we own nothing" objection misreads the model. You still own the two layers that matter most — and they are the two that breach. A misconfigured sharing setting, a departed employee whose access was never revoked, a mailbox rule quietly forwarding invoices to an outside address: none of those are the provider's to prevent. SaaS removes the chores of running software; it does not remove the responsibility for your data and your identities. That responsibility does not delegate, in any model, ever.

Make the split concrete with Campux's own Microsoft 365. Microsoft runs the mail servers, the software, the patching, the datacentre — the entire application. What stays with Campux is the configuration and the accounts: who is a member of which group, which files are shared with the whole internet versus the finance team, whether a departed employee's mailbox was actually disabled, whether multi-factor authentication is enforced or merely available. Every one of those is a setting on Campux's side of the line, and every large SaaS breach you will read about lived in exactly that column — a public bucket, an over-shared drive, a token that was never revoked. The provider was not breached. The tenant was misconfigured. Learning SaaS well means learning that "someone else runs it" and "someone else is accountable for it" are two different sentences, and only the first is true.

The most common mistake at this point is to pick a model for the whole organisation — "we're a PaaS company," "we're going all-IaaS for control." A company is not one workload. The correct unit of decision is a single system, and a healthy estate almost always runs all three models at once.

The on-prem column is there for contrast: every cell says You, which is where Campux's closet started, and reading left to right you can watch the provider take over the stack one layer at a time. Read the bottom three rows across all four columns. They say You every time — your settings, your data, your identities.³ That is Figure 2 from Class One, restated as a table: the line moves, the top never does. Note the split the table makes that the figure cannot: in SaaS the provider runs the application, but how it is configured — who can share what, which rules forward where — never stops being yours.

So how do you actually choose, workload by workload? Not by preference, and not by which acronym sounds most modern. You choose by asking three questions in order and stopping at the first "yes." The order matters: it starts from the highest rung — the least work — and only descends when a real requirement forces it. That is the discipline behind "PaaS usually wins" made mechanical.

Read against the ladder, the Azure catalogue stops being a wall of names and becomes three shelves. Learn one exemplar on each and you can place almost anything by asking which it most resembles.

IaaS · Azure VM

A machine you size, patch and secure yourself, on Azure's hardware. Reach for it only when a requirement forbids the rungs above — a machine-bound licence, an unusual OS, kernel-level software.

PaaS · Azure App Service

You deploy the storefront's code; Azure runs the OS, the runtime, the patching and the scaling. The default rung — most web workloads want to live here and should have to justify leaving.

SaaS · Microsoft 365

A finished product Campux signs into. Microsoft runs all of it; Campux owns only its data, its accounts and how the thing is configured — the two layers that never delegate.

When the three boxes turn out to be a spectrum

Hold the three names loosely enough to survive the messy catalogue, because the real world lives in the gaps between them. Someone will ask whether containers "are" IaaS or PaaS, and the honest answer is between: a container on a VM you patch leans IaaS; the same container on a fully managed platform leans PaaS; a serverless function is PaaS pushed to its logical end. A "managed" open-source database sits a notch above the version you host yourself. None of this breaks the model — it is the model, used with the honesty that the line moves in fine gradations, not just three jumps. So when a service resists a tidy label, stop arguing about the box and ask the one question that always decides it: which layer do you stop being responsible for? Answer that and you have placed the thing, whatever the marketing calls it.