OneNoughtOne
0/273
Loading content...
Read aloud is unavailable in this browser.
Cloud computing has fundamentally transformed how organizations design, deploy, and scale software systems. At the heart of this transformation lies a deceptively simple question: How much of your infrastructure stack do you want to manage yourself, and how much do you want the cloud provider to handle?
The answer to this question determines which cloud service model you adopt. The three canonical models—Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)—represent a spectrum of control versus convenience, responsibility versus abstraction.
Understanding these models isn't merely academic. Every architectural decision you make in the cloud—from choosing where to run your containers to selecting a database solution—is implicitly a decision about where you want to sit on this spectrum. Get it wrong, and you'll either drown in operational overhead you didn't need to carry, or find yourself constrained by abstractions that don't fit your requirements.
By the end of this page, you will thoroughly understand each cloud service model—IaaS, PaaS, and SaaS—including their technical underpinnings, operational implications, cost structures, and appropriate use cases. You'll gain the vocabulary and conceptual framework needed to make informed decisions about cloud architecture.
Before diving into individual service models, we must understand the principle that underlies all cloud computing: the Shared Responsibility Model. This model defines the boundary between what the cloud provider manages and what you, the customer, must manage.
In traditional on-premises computing, your organization is responsible for everything—from the physical building and electrical supply to the operating systems and applications. Cloud computing allows you to offload portions of this responsibility stack to the provider, but it's crucial to understand exactly which portions.
| Layer | Description | Traditional (On-Prem) | IaaS | PaaS | SaaS |
|---|---|---|---|---|---|
| Physical Facilities | Data centers, power, cooling, physical security | Customer | Provider | Provider | Provider |
| Physical Hardware | Servers, storage arrays, network equipment | Customer | Provider | Provider | Provider |
| Virtualization | Hypervisors, virtual machine management | Customer | Provider | Provider | Provider |
| Operating System | OS installation, patching, configuration | Customer | Customer | Provider | Provider |
| Runtime/Middleware | Language runtimes, web servers, containers | Customer | Customer | Provider | Provider |
| Data | Application data, databases, backups | Customer | Customer | Customer | Provider* |
| Applications | Application code, business logic, integrations | Customer | Customer | Customer | Provider |
Even in SaaS, you retain responsibility for what data you store and how you use it (compliance, data governance). The provider manages how the data is stored and protected technically. This distinction is critical for regulatory compliance.
Why does this matter architecturally?
Every layer you control is a layer you must:
Conversely, every layer the provider controls is a layer where:
Infrastructure as a Service (IaaS) provides virtualized computing resources over the internet. The cloud provider manages the physical infrastructure—servers, storage, networking, and the virtualization layer—while you control everything from the operating system upward.
Think of IaaS as renting virtual data center equipment. You get raw computing power, storage capacity, and network connectivity, but you're responsible for installing, configuring, and maintaining everything that runs on top of this foundation.
Operating an IaaS environment requires significant engineering investment. Consider what happens when you deploy a web application on IaaS:
Initial Setup:
Ongoing Operations:
IaaS gives you maximum control, but control comes with toil. A small startup using IaaS to run a simple web application might spend 40% of engineering time on infrastructure operations rather than product development. The question isn't 'Can we manage this ourselves?' but 'Should we?'
IaaS pricing is typically based on resource consumption:
Compute Costs:
Storage Costs:
Network Costs:
Hidden Costs:
Platform as a Service (PaaS) provides a complete development and deployment environment in the cloud. The provider manages infrastructure, operating systems, middleware, and runtime environments—you focus solely on your application code and data.
Imagine IaaS as renting an empty commercial kitchen where you bring all your own equipment. PaaS is more like renting a fully-equipped kitchen: the ovens, mixers, and refrigerators are already installed and maintained. You just bring your recipes (code) and ingredients (data).
PaaS offerings vary widely in their level of abstraction and flexibility:
Traditional PaaS (Application Platforms):
Container-Based PaaS:
Serverless PaaS (Function Platforms):
Kubernetes-Based PaaS:
The operational experience with PaaS is dramatically different from IaaS:
Initial Setup:
Ongoing Operations (what you DON'T do):
What you DO focus on:
PaaS platforms are designed around the 12-Factor App methodology. Applications that follow these principles—stateless processes, configuration via environment variables, dependency declaration, port binding, etc.—deploy to PaaS with minimal friction. Applications that violate these principles (e.g., local file storage, hardcoded configuration) require significant refactoring.
Software as a Service (SaaS) delivers fully functional applications over the internet. The cloud provider manages everything—infrastructure, platform, and the application itself. You simply use the software through a web browser or API.
Extending our kitchen analogy: if IaaS is an empty commercial kitchen and PaaS is a fully-equipped kitchen, then SaaS is ordering delivery from a restaurant. You don't cook at all; you consume a finished product.
From an architectural perspective, SaaS represents the decision to buy rather than build. Instead of developing and operating your own email system, CRM, or collaboration tools, you subscribe to pre-built solutions.
While SaaS might seem outside the scope of system design, it plays a critical role in modern architectures. Most systems of meaningful complexity integrate with multiple SaaS components:
Common SaaS Categories in Architecture:
These aren't peripheral tools—they're load-bearing components of production systems that would each require significant engineering investment to build in-house.
Each SaaS dependency is an implicit architectural decision. You're trading development speed and operational simplicity for external dependencies and potential vendor lock-in. Senior architects spend significant time evaluating which components to build, which to buy, and which to adopt as SaaS.
Architects must understand how SaaS components integrate into their systems:
API-Driven Integration:
Webhook-Based Integration:
SDK Integration:
Embedded Components:
Deep SaaS integration creates tight coupling. Wrapping SaaS interfaces behind abstraction layers in your code allows easier migration if needed, but adds development overhead. The decision to abstract depends on the criticality of the component and the likelihood of switching.
Now that we've examined each model in depth, let's compare them across multiple dimensions that matter for architectural decisions.
| Dimension | IaaS | PaaS | SaaS |
|---|---|---|---|
| Control Level | Maximum | Moderate | Minimal |
| Operational Burden | Highest | Low-Medium | Minimal |
| Customization | Unlimited | Within platform constraints | Configuration only |
| Scaling Complexity | Manual/semi-automated | Automatic | Provider-managed |
| Time to Deploy | Weeks-months | Hours-days | Minutes-hours |
| Engineering Expertise Required | Infrastructure + Application | Application only | Usage + Configuration |
| Vendor Lock-in Risk | Low-Medium | Medium-High | Highest |
| Cost Predictability | Variable (usage-based) | Variable (often usage-based) | Often predictable (subscription) |
| Portability | Highest (standards-based) | Medium (some proprietary) | Lowest (data extraction challenges) |
The three models represent points on a fundamental spectrum:
More Control, More Work │ │ Less Control, Less Work
IaaS │ PaaS │ SaaS
◄───────────────────────┼───────────────────────────────┼──────────────────────►
│ │
You manage: Everything │ You manage: Code + Data │ You manage: Configuration
above VM │ │ + Usage
There's no universally 'correct' position on this spectrum. The right choice depends on:
Most production systems use multiple service models simultaneously. You might run your core application on PaaS, use IaaS for a specialized batch processing cluster, and integrate with numerous SaaS providers for authentication, payments, and email. The skill isn't choosing one model—it's choosing the right model for each component.
When evaluating which cloud service model to adopt for a given workload, work through this decision framework:
For most teams building new applications: Start with PaaS. It provides the fastest path to production with reasonable flexibility. Move to IaaS only when you hit specific constraints that PaaS can't satisfy. Use SaaS aggressively for anything that isn't your core domain.
Let's examine how production systems typically combine multiple service models:
A typical e-commerce platform might use:
IaaS Components:
PaaS Components:
SaaS Components:
This hybrid approach optimizes each component: critical performance needs get IaaS control, standard workloads use PaaS efficiency, and non-core functions leverage SaaS expertise.
A B2B SaaS company might architect their system as:
IaaS Components:
PaaS Components:
SaaS Components:
Notice the common pattern: IaaS for specialized/compliant workloads, PaaS for core application logic, and SaaS for everything outside the core product domain. This hybrid approach has become the default architecture for modern cloud applications.
We've explored the three fundamental cloud service models in depth. Let's consolidate the key takeaways:
What's next:
With a firm understanding of the service model spectrum, we'll next explore Managed Services—the fully-managed building blocks within each cloud provider that let you assemble cloud-native architectures without reinventing fundamental components.
You now understand the fundamental cloud service models—IaaS, PaaS, and SaaS—including their technical characteristics, operational implications, and appropriate use cases. You can evaluate architectural decisions through the lens of the shared responsibility model and the control-convenience tradeoff.