Start with one application
Imagine a small shop that needs a website and staff email. It could rent a virtual machine and install its own website software. It could put its own website code on a managed app platform. Or it could use a finished website product. These are three ways to divide the work between the shop and a provider.
A service model describes which tasks you manage and which tasks the provider manages. The names are IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service). Read them as “rent the computing infrastructure,” “use a platform for your code,” and “use a finished application.” The sections below explain each one.
Before reading the diagram: an operating system (OS), such as Windows or Linux, runs a computer. A patch is a software update.
A runtime is software that executes application code, such as Python or .NET.
Data permissions decide who can read or change information. Account access decides who can sign in and what they can do. Those are different tasks.
Ada wants to sell bread, not repair an oven. She can rent a kitchen and maintain its equipment, use a bakery that operates the ovens while she supplies the recipe, or buy finished loaves. Each choice leaves a different amount of work with her. Campux’s website has a similar choice: manage a VM’s operating system, deploy code to a managed platform, or buy a finished application. The analogy introduces the responsibility boundary; it does not mean the provider takes ownership of your customer data or access decisions.
Service models describe what you consume and which operating tasks you retain. IaaS provides infrastructure you configure, PaaS provides a managed platform for your application, and SaaS provides a finished application. The stack diagram is a useful starting point, but the actual service contract and deployment determine the details.1
Moving from IaaS toward SaaS generally transfers more infrastructure and application operation to the provider. You still govern your data, user access, customer settings and client devices. Provider duties remain too: shared responsibility is a division of tasks, not a claim that one side alone can prevent every failure.
Keep two questions separate. The service model describes the service and operating boundary. The deployment model describes who the cloud is provisioned for and how environments are combined. Physical ownership, private networking and a public endpoint are related design choices, not interchangeable definitions. App Service remains a public-cloud PaaS offering when you restrict its network access; that access question is still worth asking.
More management by the provider can reduce your work, but it can also constrain customization. Compare the workload’s functional requirements, compatibility, security, recovery, costs and team skills. The useful choice is the service that meets those requirements with an operating burden you can support.
IaaS — maximum control, maximum chores
- 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.
With IaaS you choose a supported VM image or bring a supported image, size the machine, and configure the guest operating system (Windows or Linux inside the VM) and application. You own the patching policy, application updates, access controls, backups and recovery tests. The provider operates the physical host (the real computer) and virtualization (the software that creates virtual computers). You get more guest-level control, within the platform’s supported systems and limits.
IaaS can fit software that needs guest OS control or rehosting — moving an application to another environment with minimal changes to its code. Confirm support, licensing and workload compatibility before deciding. A machine-bound licence does not automatically become valid on an Azure VM; the fictional POS job from Class Three stays on its existing physical machine pending agreement.
Azure Virtual Machines, managed disks and virtual networks are useful IaaS examples. Azure can offer automation for guest patching, but selecting and validating a patching policy is still a customer responsibility. “Customer-managed” describes ownership of the task; it does not require a person to install every update manually.
Compare a VM with the managed services that support your application’s requirements. Kernel access or a specific supported OS may favor a VM; existing tools and a migration deadline may favor rehosting. A managed platform may support more customization than you expect, so verify the current capability rather than rejecting it from the acronym alone.
For pay-as-you-go Azure VM instance usage, running and stopped-but-allocated machines are billed; deallocated instances are not billed for instance usage. Disks and some networking resources can still incur charges. Reservations or other commitments need separate review. A VM does not bill for compute merely because its resource exists: inspect its power state and the full bill. See VM states and billing.
PaaS — a managed platform for your application
- PaaS
- Platform as a Service. You deploy an application or data onto a managed platform. The provider manages the host OS and platform; your code, configuration, dependencies and operational choices still need ownership.
App Service, Azure SQL Database and Azure Functions are PaaS examples in Azure’s service-model guidance. They transfer host management to Microsoft while keeping application and data decisions with your team. A managed service can reduce maintenance work; its label does not promise automatic scaling, a particular bill or a workload availability target.
Control is a cost, not a prize.
App Service is a candidate for the fictional storefront because the team wants managed web hosting. Verify its chosen deployment, plan, runtime support, network access, scaling configuration and recovery behavior before accepting that choice.2 A container packages an application with the software it needs. If you supply a custom container, you still build and update the runtime and libraries (reusable code) inside that package; Microsoft manages the underlying host.
Serverless — run code without managing its server
Serverless describes an approach in which you focus on code while the service manages the execution infrastructure. Azure Functions is an event-driven example. Its billing and scaling depend on the hosting plan: Flex Consumption offers on-demand execution, with separately charged always-ready capacity if configured; Premium keeps minimum ready capacity; Dedicated uses App Service plan pricing. Scale-to-zero and a zero idle bill are not universal serverless guarantees. Storage, networking and monitoring can also cost money. Check Functions hosting options before estimating.
Where PaaS pushes back
A managed platform still has limits, supported versions and configuration choices. Review timeouts, connections, quotas, region support and scaling behavior for the selected plan. Test peak demand and failure recovery. Some changes need a larger plan; others need application changes or a different service. You remain responsible for that assessment.
SaaS — use a finished application
- SaaS
- Software as a Service. You use a provider-operated application, such as Microsoft 365. You manage the customer-controlled settings, data governance, users and access; the provider operates and secures its service.
SaaS is buying the loaf: you use a finished application rather than host the application yourself. Microsoft 365 is an example. The provider handles service operation and updates; customers still configure sharing, account lifecycle, access policies and the devices used to reach it.
Customer errors such as excessive sharing or stale accounts can expose data. Provider vulnerabilities and other failures are also possible. Avoid saying that every SaaS breach is a tenant misconfiguration or that the provider has no prevention duties. Good operation combines provider capabilities with customer configuration and monitoring.
In the fictional Microsoft 365 tenant, Campux assigns owners for access reviews, account removal, MFA policy, sharing rules, retention and incident response. Microsoft operates the mail service and its underlying infrastructure. Security features can help the customer detect or prevent mistakes; they do not remove the need to configure and verify the controls available in the chosen licence.
Play it through
Three minutes, one question asked of five workloads: who patches the operating system underneath this? Sort them between you and Azure in any order; a wrong bin bounces back and tells you what it would have cost. It plays on its own and stops when it needs your hands.
Choose per workload, not per company
Choose a service for each workload, while keeping sensible shared standards for identity, monitoring and deployment. An estate may use several service models; it does not need all three to be healthy. The model helps assign tasks, and the specific service determines the actual controls.
| Layer | On-prem | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Physical hosts & network | You | Provider | Provider | Provider |
| Network security controls | You | You | Shared | Provider |
| Virtualisation | You | Provider | Provider | Provider |
| OS & patching | You | You | Provider | Provider |
| Runtime & middleware | You | You | Service-specific | Provider |
| Application security / operation | You | You | Shared | Shared |
| Client devices | You | You | You | Shared |
| Configuration & settings | You | You | You | You |
| Customer data governance | You | You | You | You |
| Identity & access | You | You | You | You |
This is an orientation table, not a replacement for a service responsibility matrix.3 “Shared” means the parties own different tasks. A provider-managed application still has customer settings and access controls. A custom-container runtime is customer work even when its host is managed. Assign an owner and a verification method to the actual task rather than relying on the row color.
Start by asking whether a finished product meets the need. If you need your own application, compare supported managed platforms with infrastructure you operate. OS-level control may favor IaaS; a compatible managed platform may favor PaaS. Figure 2 identifies candidates, which still need a cost, security, performance and recovery review.
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 VM with customer-managed guest OS, application and network controls. Confirm the supported image, software and licence; provider host management does not waive those checks.
- PaaS · Azure App Service
- A managed web-hosting candidate. Microsoft manages the host; you manage application configuration, code and dependencies, including a custom image if used. Verify scaling, cost and recovery.
- SaaS · Microsoft 365
- A finished application. Microsoft operates the service; Campux manages customer settings, data governance, accounts, access and client-device protection.
When the three boxes turn out to be a spectrum
Containers are packaging, not a service model. A container on your VM retains guest-host responsibilities; a managed container service transfers some of those tasks. In either case you own the image’s code and dependencies. Functions may be described more specifically as functions as a service, while remaining a PaaS example in this introductory Azure taxonomy. Inspect the actual management boundary.
One company, three models
Assume a reviewed App Service plan fits the storefront. A separate reporting application on a permitted Azure VM illustrates IaaS: the team manages its guest OS. Staff email uses Microsoft 365, illustrating SaaS. The POS batch job from Class Three remains on its existing physical machine while the licence is unresolved; calling a proposed VM “IaaS” would not resolve that contract.
Three service examples show different operating tasks. Document which tasks Campux owns, which Microsoft owns, and which need both parties. The later classes develop those controls; the model name alone does not implement them.
Zoom out: every layer you hand off is control traded for chores you keep
You can place a workload on the IaaS–PaaS–SaaS ladder. Now reason about what each rung does to the whole system, because moving up the stack changes not just who patches, but who can answer when it breaks.
Provider-managed hosts reduce some maintenance work. Keep enough application, networking and runtime knowledge to diagnose timeouts, cold starts and limits, and know when to involve provider support.
Managed services can couple an application to APIs, limits and supported versions. Compare their benefits with a tested export or replacement path rather than assuming every higher-level service has more lock-in.
The service model changes the task list. Identify the likely constraint for this workload—team capacity, compatibility, performance, cost or service limits—and verify it in the selected plan.
A managed service can save operating effort and introduce migration costs later. Price both possibilities; neither its future replacement cost nor IaaS’s lifetime cost follows from the model label.
A PaaS default sized for today — a tier, a connection cap, a request limit — is invisible at low load and fatal at ten times it. Which of them is a slider you move, and which is a re-platform?
The engineer who ships is asked "which service?" The engineer who gets promoted is asked "and what does that rung cost you the day it leaks?" — and has already found the abstraction's edge.
How much of the stack do you want to own?
When asked whether to run a database server, compare the required capabilities, supported licences, performance, recovery and operating work. A managed database may fit; a VM may fit a different requirement. Hand the team a responsibility map and acceptance criteria alongside the recommendation.
Move the same shop across three boundaries
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Need: storefront code + customer orders VM: team operates guest OS Managed web platform: platform operates supported runtime Finished shop software: supplier operates application
Write who patches the guest OS in each model.
For each model, name who grants staff access and decides how customer data is used.
Choose a model for custom storefront code; explain one requirement that might change it.
On your own: Campux wants an email newsletter tool it will not customise at all. Which model fits, and who still decides how subscriber data is used and which staff can see it?
Check your reasoning after you finish
On your own: finished software (SaaS) fits a tool you will not change. The supplier runs the application, but Campux still decides how subscriber data is used and who on staff gets access. On a VM the team patches its OS; in the managed platform or finished service that underlying work belongs to the provider. Customer access and data decisions remain with Campux. A supported custom app can fit PaaS; an unsupported OS dependency may require a VM.
Examination
Four graded drills and two unscored situations. Try your reasoning before revealing the model response. Practice preserves the first-attempt score; the lesson game can save progress in this browser.
A. Azure Virtual Machines are IaaS: Microsoft operates the host infrastructure; the customer manages the guest OS and application. Patching may be automated, but the customer still owns the policy. A self-managed VM elsewhere is not automatically cloud merely because it is virtualized.
C. Microsoft 365 is SaaS. Campux retains data governance, customer configuration, account lifecycle and access controls, while Microsoft operates and secures its service. SaaS reduces application-hosting tasks; it does not remove customer duties or provider duties.
App Service, Azure SQL Database and Azure Functions. These are PaaS examples in Azure’s introductory service-model guidance. SQL Server installed on a customer-managed Azure VM is IaaS; Microsoft 365 is SaaS. Within each model, inspect the service and deployment to assign detailed tasks correctly.
SERVICE-MODEL ASSIGNMENT — Campux migration
1. Storefront on Azure App Service ............ PaaS
2. Reporting app on an Azure VM ............. IaaS
3. Staff email on Microsoft 365 .............. SaaS
4. Orders database on Azure SQL Database ..... IaaS
Line four. Azure SQL Database is PaaS. Microsoft manages its engine and underlying host; customers still configure data access, application use and other customer controls. SQL Server installed on a customer-managed Azure VM is a different deployment with a different task list.
Consider the consequence. Labelled IaaS, that database gets a work item to "patch the OS monthly" that no one can ever action, an on-call expectation for a layer Microsoft already owns, and a security review that hunts for a server that does not exist. A wrong model label quietly manufactures phantom chores and phantom accountability. Getting the label right is what makes the responsibility map true.
Price the operating tasks. Ask which guest-level controls the director needs, and which workloads need them. Compare patching, runtime updates, scaling, monitoring and recovery effort with the managed alternatives. Use measured estimates and assign owners rather than inventing a staffing cost.
Test both designs. App Service scaling depends on the chosen plan and configuration; VM scaling can also be automated. Neither model guarantees survival of a peak. Test demand, budgets and failure behavior before promising the business a result.
Recommend the fit. Select a supported service that meets the workload’s requirements with an operating burden the team can sustain. Resolve licensing separately; the POS contract still does not permit the proposed migration.
Use a consistent method. An estate can use several models while sharing standards for identity, monitoring and deployment. Different task boundaries are reasonable when the workloads need them.
Separate the examples. App Service is the storefront’s managed candidate. A permitted reporting VM illustrates IaaS guest management. The physical POS server is retained while its licence is unresolved; it is not a cloud VM just because the course discusses IaaS.
Give them the reusable rule. Start with requirements, compare supported services, price the complete design and assign responsibilities. More provider management can reduce chores; it still needs verification.
Five things worth carrying out of this class
- IaaS, PaaS and SaaS are one stack with the accountability line drawn at three heights — not three separate products.
- The line rises from IaaS to SaaS, but never above your data and identities. The top of the stack is yours in every model.
- IaaS retains guest-host work; PaaS transfers host management but keeps application, configuration and dependency work.
- SaaS removes the software chores, never the responsibility for your data and who can reach it.
- Choose per workload with shared operating standards. An estate may use several models; it does not need all three.
- See Choose an Azure compute service for service candidates and the finer distinction between PaaS and functions as a service. A candidate still needs workload assessment. ↩
- The App Service overview describes supported built-in stacks and custom containers. Read the chosen deployment’s patching, scaling and plan documentation before assigning tasks. ↩
- Microsoft’s responsibility matrix includes shared application, network and device tasks. Its governance guidance is not a substitute for the service agreement. Data and identity duties retained by the customer do not erase provider duties. ↩
Draw the shared-responsibility line for IaaS, PaaS and SaaS, and say which of the three a job posting is really asking about.
Play the lesson above to stamp this class.
Next: public, private, hybrid — and which one your first job actually runs.
Next · Public, Private, Hybrid →