Cloud Service & Deployment Models

Cloud Service & Deployment Models describe how much of the technology stack a team manages itself versus consumes as a ready-made service, and where that infrastructure physically runs.

At a glance

• What it is: a spectrum of managed responsibility (IaaS → PaaS → SaaS) crossed with a spectrum of location/ownership (public, private, hybrid, multi-cloud).
• Why it matters: it determines who is on the hook when something breaks at 2am, and how fast a team can ship versus how much control they retain.
• For developers: before reaching for a VM, check whether a PaaS or serverless option already covers the same need — every layer you self-manage is patching, scaling, and security you now own.
• When to use it: at the start of any new workload, before choosing specific products.
• When not to use it: don’t re-decide this for every feature within an already-established platform — decide it once per workload, not per sprint.
• Prerequisites: none — this is the entry point for the whole discipline.

Mental model

graph LR
    IaaS["IaaS: rent raw servers"] --> PaaS["PaaS: rent a managed platform"] --> SaaS["SaaS: rent the finished product"]

Moving right along this spectrum trades control for reduced operational burden. A separate axis — public, private, hybrid, or multi-cloud — decides where that infrastructure runs and who else shares it.

Step-by-step walkthrough

1. Describe the workload’s operational profile (traffic pattern, team size, compliance needs).
2. Rule out SaaS if the workload needs custom logic that no existing product provides.
3. Prefer PaaS or serverless over IaaS unless a specific technical constraint requires low-level VM/OS access.
4. Decide public vs. private/hybrid based on data residency, existing on-premises investment, and regulatory constraints.
5. Document the decision and its constraints so future teams don’t silently drift to a different model.

Worked example

Northwind’s customer support team needs a returns-processing capability and is deciding whether to build it in-house or buy it.

• Input: a mature SaaS returns-management product exists, covering roughly 90% of the required workflow; building in-house would mean a new service plus ongoing maintenance.
• Process: the team maps required capabilities against the SaaS product’s feature set, confirms the remaining gap — a custom fraud rule — can be handled via the product’s API/webhook extension points rather than justifying a full in-house build, and checks data residency requirements against the vendor’s hosting regions.
• Output: Northwind adopts the SaaS product for the core workflow and builds only the small custom fraud-rule integration in-house — most of the “build” scope disappears, and the team owns far less infrastructure than an IaaS/PaaS build would have required.

Common use cases

Use case	When to use	Notes
Greenfield internal tool	PaaS or serverless first	Minimal ops overhead for the team
Legacy app needing OS-level access	IaaS	Accept the added patching/ops burden as a deliberate tradeoff
Regulated data residency requirement	Private or hybrid cloud	May limit which regions/services are available
Avoiding vendor lock-in	Multi-cloud	Increases operational complexity — use selectively, not by default

Advanced details

• Shared responsibility model: the cloud provider secures “of the cloud,” the customer secures “in the cloud” — that responsibility line shifts as you move from IaaS toward SaaS.
• Multi-cloud isn’t free: the real cost is duplicated tooling, skills, and monitoring across providers — default to a single cloud unless there’s a specific business driver.
• Hybrid cloud often exists as a transitional state during an on-premises-to-cloud migration, not a permanent target architecture.

Quick reference

Term	Meaning
IaaS	Rent raw compute/storage/network, manage the OS and above yourself — e.g. Azure Virtual Machines
PaaS	Rent a managed platform (e.g., a web app service); provider manages OS/runtime — e.g. Azure App Service, Azure SQL Database
SaaS	Rent the entire finished application — e.g. Dynamics 365, or a third-party returns-management product
Public cloud	Shared infrastructure owned and run by a cloud provider
Hybrid cloud	A mix of on-premises and public cloud, connected together
Multi-cloud	Using more than one public cloud provider

Troubleshooting

Symptom	Likely cause	Fix
Team spends more time patching servers than building features	Workload uses IaaS where PaaS/serverless would suffice	Re-evaluate against a PaaS or serverless option
A simple app is deployed across three cloud providers	Multi-cloud adopted without a clear driver	Consolidate unless there’s a demonstrated regulatory or redundancy need
Compliance audit blocked by unclear data location	Hybrid/multi-cloud adopted without documenting data residency	Document and enforce data residency per environment

Check your understanding

• If a workload’s traffic is bursty and mostly stateless, why might serverless beat a VM even before considering cost?
• What’s the real cost of “just in case” multi-cloud adoption, beyond the cloud bill itself?

Related pages

Part of Introduction to Cloud & Infrastructure Architecture. See also Landing Zone Design for how a chosen model gets provisioned with guardrails, Compute & Container Platforms for the compute layer specifically, and the Glossary for term definitions.