Decision room · Cloud Computing
Choose a delivery model for a fictional appointment service by comparing responsibilities and constraints instead of memorising definitions.
Start with the business or technical outcome
IaaS, PaaS and SaaS become clear when the same business need is viewed through each operating model. A confident choice requires more than a feature list: it requires constraints, evidence and a clear trade-off. A clinic needs online appointments, reporting and staff access but has limited engineering capacity and strict availability and privacy expectations.
Service-model labels describe different distributions of responsibility, not quality levels. A SaaS product can be the strongest fit when requirements are standard; IaaS can fit specialised control; PaaS can accelerate custom development within platform constraints.
Compare the complete service: identity, data, application change, monitoring, backup, scaling, patching, support and exit. Acquisition price alone hides internal operating effort.
What to understand before opening the tool
NIST describes IaaS, PaaS and SaaS as service models. In practice, providers package boundaries differently, so contract and product documentation matter more than a label.
Shared responsibility remains. Even with SaaS, the customer usually owns user access, data use, configuration and governance. With IaaS, the customer manages more of the stack and needs corresponding skills.
Requirements Canvas
Use it for: separate standard needs from differentiating custom behavior Keep as evidence: prioritised must and should list
Responsibility Matrix
Use it for: assign provider and customer duties per option Keep as evidence: reviewed RACI
Cost Model
Use it for: include subscription or usage plus staff, support and migration Keep as evidence: range with assumptions
Decision Record
Use it for: score fit and preserve rejected alternatives Keep as evidence: conditional recommendation
Use a responsibility matrix, three solution sketches, weighted decision record and recommendation with conditions as the decision test. Define the constraints before comparing options, then explain which factor carried the most weight. A sound recommendation can be conditional: one option may fit a small learning environment while another suits a regulated or high-volume workload.
Work through the decision sequence
Hold business requirements constant, sketch each model and compare the responsibility boundary honestly.
- Define the scenarioSet users, workflows, data sensitivity, integrations, availability and change needs.Checkpoint: Approved requirements baseline.
- Sketch SaaSMap standard product capabilities, configuration, integration and vendor controls.Checkpoint: Fit-gap list and contract questions.
- Sketch PaaSDesign the custom application while accepting platform runtime and service constraints.Checkpoint: Architecture and developer responsibilities.
- Sketch IaaSInclude operating system, middleware, deployment, patching, scaling and recovery ownership.Checkpoint: Full-stack operations map.
- Score the optionsWeight non-negotiable security, functionality and recovery before convenience.Checkpoint: Transparent score with sensitivity check.
- Recommend conditionallyState the selected model, reasons, assumptions, exit triggers and next validation.Checkpoint: One-page decision record.
Avoid scoring every criterion equally. Security, correctness and recoverability may be non-negotiable; convenience and speed can then be evaluated inside those boundaries.
Options worth comparing before you act
Use the table to compare responsibility, not to claim one model always offers more value.
| Dimension | IaaS view | PaaS or SaaS implication |
|---|---|---|
| Infrastructure control | Customer configures compute, network and much of OS stack | Provider absorbs more infrastructure decisions |
| Application freedom | Broad control with broad maintenance duty | PaaS constrains runtime; SaaS constrains product behavior |
| Patching scope | Customer patches more layers | Provider patches more platform or application layers |
| Team skills | Needs infrastructure and platform operations | Needs integration, configuration and vendor governance |
| Exit effort | Images and data still require migration planning | Platform APIs or SaaS export may affect portability |
Trade-offs hidden by a quick answer
A familiar label can conceal product-specific limitations and customer duties.
- Treating SaaS as zero administration: Identity, configuration, data governance and adoption still need owners.
- Calling PaaS portable by default: Managed APIs and runtime assumptions can create switching work.
- Ignoring staff cost in IaaS: Operating, securing and recovering the stack are part of total cost.
- Selecting by feature count: Prioritise critical workflow and control fit over long checklists.
- Using fixed responsibility assumptions: Verify the exact provider service and contract boundary.
Turn the exercise into credible portfolio evidence
Build three one-page solution sketches for the clinic scenario and a weighted comparison. Cite the provider-neutral NIST definitions, then explain where real products blur the neat categories.
Include an exit question for each option. This shows architectural thinking across acquisition, operation and eventual change.
Explain it clearly in an interview
Avoid reciting definitions only. Use the clinic need to explain how control, delivery speed, staffing and responsibility shift across the models.
Peer review before calling the work complete
Ask another learner to inspect the result without watching you build it. Give them the original scenario—a clinic needs online appointments, reporting and staff access but has limited engineering capacity and strict availability and privacy expectations.—and the evidence pack, but not your intended conclusion. They should be able to trace the input, identify the main decision and locate the proof of the output. If they cannot, improve the labels, timestamps or explanation instead of adding decorative screenshots.
Use this acceptance condition during the review: The same requirements are used for all options, customer duties remain explicit, cost includes operating effort and the recommendation lists assumptions that could reverse it. Record one question the reviewer raised and the change you made in response. That small feedback loop makes the IaaS vs PaaS vs SaaS exercise more credible, easier to maintain and easier to explain under interview questioning.
Questions learners ask
Is SaaS always cheaper than IaaS?
No. Cost depends on scale, licensing, customisation, staff effort, integration and service requirements.
Does PaaS remove operations?
It reduces responsibility for certain platform layers, but application reliability, data, access and service configuration remain.
Can one solution use all three models?
Yes. Organisations often combine SaaS business tools, PaaS application services and IaaS for specialised workloads.
Which model gives the most control?
IaaS generally exposes more infrastructure control, along with greater customer responsibility.
Use current product guidance
Menus, fields, permissions and service behavior can change between product versions or tenant configurations. Check the NIST cloud computing definition before applying version-sensitive steps in a live environment.
Build the complete skill path
Learn cloud service models, architecture, migration, resilience, security and cost decisions through provider-neutral scenarios and practical labs.
Final perspective
The real value of IaaS vs PaaS vs SaaS is the ability to complete a controlled task and defend the result with evidence. A learner who can show the input, explain the decision, verify the output and describe one realistic exception demonstrates far more than someone who has only memorised a menu path or definition.