Loading learning content...
Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) represent the canonical taxonomy of cloud computing service models. While we introduced these concepts previously, this page explores each model with the depth required to make informed architectural decisions and understand their operating systems foundations.
Think of these models as layers of abstraction in a distributed operating system spanning data centers worldwide. Each layer hides complexity from the layer above, enabling specialization—just as operating systems hide hardware complexity from applications, cloud service models hide infrastructure complexity from developers and users.
By completing this page, you will understand the architectural underpinnings of IaaS, PaaS, and SaaS; recognize their operating systems implications; identify appropriate use cases for each model; and develop a decision framework for service model selection.
Infrastructure as a Service delivers fundamental computing resources—compute, storage, and networking—as programmatically controlled services. IaaS is built upon the virtualization technologies we've explored throughout this curriculum, combined with sophisticated control planes that orchestrate resources at scale.
The IaaS Control Plane:
Every IaaS platform comprises two fundamental layers:
┌─────────────────────────────────────────────────────────────────┐
│ CONTROL PLANE │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ API │ │ Scheduler │ │ Resource │ │
│ │ Gateway │──│ Engine │──│ Manager │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ └───────────────┴───────────────────┘ │
│ │ │
├─────────────────────────┼────────────────────────────────────────┤
│ DATA PLANE │
│ ┌───────────────┴───────────────┐ │
│ ┌──────┴──────┐ ┌──────┴──────┐ ┌─────┴──────┐ │
│ │ Compute │ │ Storage │ │ Network │ │
│ │ Cluster │ │ Cluster │ │ Fabric │ │
│ │ │ │ │ │ │ │
│ │ ┌──┐ ┌──┐ │ │ ┌──┐ ┌──┐ │ │ ┌──┐ ┌──┐ │ │
│ │ │VM│ │VM│ │ │ │HD│ │HD│ │ │ │SW│ │SW│ │ │
│ │ └──┘ └──┘ │ │ └──┘ └──┘ │ │ └──┘ └──┘ │ │
│ └─────────────┘ └─────────────┘ └───────────┘ │
└─────────────────────────────────────────────────────────────────┘
Compute Virtualization Stack:
IaaS compute relies on hypervisors to multiplex physical servers across multiple virtual machines:
Type-1 Hypervisors in Production:
The Nitro Architecture (AWS Case Study):
AWS developed custom hardware (Nitro cards) to offload virtualization overhead from the CPU:
This architecture delivers near-bare-metal performance by eliminating hypervisor CPU overhead for I/O operations.
Start with general-purpose instances during development, then profile workloads to identify bottlenecks. CPU-bound → compute optimized. Memory pressure → memory optimized. I/O wait → storage optimized. The goal is matching instance characteristics to workload requirements at minimum cost.
Storage Virtualization:
IaaS provides multiple storage abstractions, each with distinct performance characteristics and OS interaction patterns:
Block Storage: Virtual disks that attach to VMs like physical drives. Examples: AWS EBS, Azure Managed Disks, GCP Persistent Disks.
/dev/sda, /dev/nvme0n1)Object Storage: Infinitely scalable storage for unstructured data. Examples: S3, Azure Blob, Cloud Storage.
File Storage: Managed NFS/SMB filesystems. Examples: EFS, Azure Files, Filestore.
| Aspect | Block Storage | Object Storage | File Storage |
|---|---|---|---|
| Access Method | Block device | HTTP API | NFS/SMB mount |
| OS Visibility | Block device | Application-level | Filesystem mount |
| Performance | Low latency, high IOPS | High throughput, higher latency | Medium latency |
| Scalability | Volume size limits | Virtually unlimited | Capacity tiers |
| Use Cases | Databases, boot volumes | Backups, media, data lakes | Shared storage, CMS |
| Consistency | Strong | Strong or eventual | Strong |
Network Virtualization:
IaaS networking relies on Software-Defined Networking (SDN) to create isolated virtual networks:
Virtual Private Cloud (VPC):
Virtual Network Interfaces:
Security Groups and Network ACLs:
Load Balancing:
Network bandwidth is often tied to instance size—larger instances get more network capacity. For high-throughput workloads, consider placement groups (cluster placement for low latency, spread for resilience) and enhanced networking (SR-IOV, ENA, DPDK) for bypassing hypervisor network stack overhead.
Platform as a Service abstracts infrastructure management, providing a complete development and deployment environment. PaaS platforms are essentially distributed operating systems for cloud applications—managing process scheduling, resource allocation, and inter-process communication across clusters of machines.
The PaaS Runtime Model:
┌─────────────────────────────────────────────────────────────────┐
│ DEVELOPER INTERACTION │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ git push │ docker push │ CLI deploy │ CI/CD pipeline │ │
│ └─────────────────────────┬─────────────────────────────────┘ │
├─────────────────────────────┼────────────────────────────────────┤
│ PLATFORM LAYER │
│ ┌─────────────────────────┴─────────────────────────────────┐ │
│ │ BUILD SYSTEM │ │
│ │ (Source → Container Image → Registry) │ │
│ └─────────────────────────┬─────────────────────────────────┘ │
│ ┌─────────────────────────┴─────────────────────────────────┐ │
│ │ ORCHESTRATOR │ │
│ │ (Scheduler, Service Discovery, Load Balancing) │ │
│ └─────────────────────────┬─────────────────────────────────┘ │
│ ┌─────────────────────────┴─────────────────────────────────┐ │
│ │ RUNTIME CONTAINERS │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ App │ │ App │ │ App │ │ App │ │ │
│ │ │ Pod 1 │ │ Pod 2 │ │ Pod 3 │ │ Pod N │ │ │
│ │ └────────┘ └────────┘ └────────┘ └────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ MANAGED SERVICES (Hidden from Developer) │ │
│ │ Databases │ Caches │ Message Queues │ Secrets Mgmt │ │
│ └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
PaaS Component Analysis:
1. Build Systems and Buildpacks: Buildpacks detect application type and construct container images:
2. Container Orchestration: The platform scheduler places containers on infrastructure:
3. Managed Services: PaaS platforms bundle common supporting services:
Serverless platforms scale to zero when idle, eliminating costs but introducing cold start latency. When a function is invoked after idle period, the platform must: allocate a container, download the runtime image, initialize the language runtime, and load your code. This can take 100ms to several seconds depending on language and dependencies.
Although PaaS abstracts the operating system, understanding OS concepts remains crucial for performance tuning, debugging, and making informed platform choices.
Resource Limits and Cgroups:
PaaS platforms use Linux cgroups to enforce resource limits:
┌────────────────────────────────────────────────────────────────┐
│ CONTAINER RUNTIME │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ YOUR APPLICATION │ │
│ │ │ │
│ │ Memory Limit: 512MB │ CPU Limit: 0.5 cores │ │
│ │ File Descriptors: 1024 │ Disk I/O: Throttled │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ CGROUP SUBSYSTEMS │ │
│ │ memory: 536870912 bytes max │ │
│ │ cpu: 50000/100000 quota (50%) │ │
│ │ pids: 100 max processes │ │
│ │ blkio: 10MB/s read, 10MB/s write │ │
│ └──────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
What happens when limits are exceeded:
Filesystem Semantics in PaaS:
Ephemeral Filesystems:
/tmp is usually writable but has size limits enforced by cgroupsRead-Only Layers:
Persistent Storage Options:
Process Model Constraints:
Software as a Service delivers complete applications to end users, with all infrastructure and platform concerns hidden. While SaaS consumers don't interact with operating systems, SaaS builders must master systems concepts to deliver reliable, scalable, multi-tenant applications.
The Multi-Tenancy Challenge:
Multi-tenancy—serving multiple customers from shared infrastructure—is the defining characteristic of SaaS. It introduces challenges at every layer of the stack:
┌─────────────────────────────────────────────────────────────────┐
│ MULTI-TENANT SAAS │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Tenant A │ │ Tenant B │ │ Tenant C │ │
│ │ │ │ │ │ │ │
│ │ 10 Users │ │ 1000 Users │ │ 100 Users │ │
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ SHARED APPLICATION LAYER │ │
│ │ (Authentication, Business Logic, APIs) │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ Tenant Context: Every request identifies tenant │ │ │
│ │ │ Row-Level Security: Database filters by tenant │ │ │
│ │ │ Rate Limiting: Per-tenant quotas enforced │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ SHARED DATABASE LAYER │ │
│ │ (All tenant data co-located with logical isolation) │ │
│ └──────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
| Model | Compute | Database | Isolation | Cost/Tenant | Complexity |
|---|---|---|---|---|---|
| Siloed | Dedicated instances | Dedicated database | Maximum | Highest | High ops overhead |
| Bridge | Shared compute | Dedicated database | High | Medium | Moderate |
| Pooled | Shared compute | Shared database, schema isolation | Medium | Low | Complex data layer |
| Row-Level | Shared compute | Shared tables, row filtering | Lower | Lowest | Requires careful design |
Noisy Neighbor Mitigation:
In pooled architectures, one tenant's workload can impact others. Mitigation strategies include:
Data Isolation Techniques:
WHERE tenant_id = ?Multi-tenant data isolation failures result in catastrophic security breaches. A missing tenant_id filter in a single query can expose one customer's data to another. Defense in depth: implement tenant filtering at multiple layers—API gateway, application code, database policies. Never rely on a single protection mechanism.
SaaS applications must handle unpredictable load variations—from quiet periods to viral growth. Scalability patterns leverage operating systems and cloud infrastructure capabilities:
Horizontal Scaling:
Adding more instances to handle increased load:
Vertical Scaling:
Increasing resources for individual instances:
Tenant-Aware Scaling:
Large tenants may require dedicated resources:
┌─────────────────────────────────────────────────────────────────┐
│ TIERED TENANT ARCHITECTURE │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ PREMIUM TIER │ │
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │
│ │ │ Tenant X │ │ Tenant Y │ │ Tenant Z │ │ │
│ │ │ Dedicated │ │ Dedicated │ │ Dedicated │ │ │
│ │ │ Resources │ │ Resources │ │ Resources │ │ │
│ │ └───────────┘ └───────────┘ └───────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ STANDARD TIER │ │
│ │ ┌─────────────────────────────────────────────────────┐ │ │
│ │ │ SHARED RESOURCE POOL │ │ │
│ │ │ Tenants A, B, C, D, E, F, G, H, I, J, K, L... │ │ │
│ │ │ (Hundreds to thousands of tenants) │ │ │
│ │ └─────────────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Shard-Nothing Architecture:
Choosing between IaaS, PaaS, and SaaS involves evaluating multiple factors. This decision framework helps architects make informed choices:
Decision Criteria Matrix:
| Criterion | Favors IaaS | Favors PaaS | Favors SaaS (Buy) |
|---|---|---|---|
| Team Expertise | Strong ops/infrastructure skills | Strong development skills | Limited technical team |
| Customization Needs | Extensive OS-level customization | Standard runtimes work | Commodity functionality |
| Compliance Requirements | Specific OS hardening required | Platform compliance sufficient | Vendor is compliant |
| Performance Requirements | Maximum control over tuning | Platform performance acceptable | Standard performance OK |
| Time to Market | Slower initial deployment | Rapid development | Immediate availability |
| Operational Budget | Can invest in ops team | Prefer managed infrastructure | Minimize ops entirely |
| Scale Characteristics | Predictable, optimizable | Highly variable | Unknown/variable |
| Vendor Lock-in Tolerance | Prefer portability | Accept moderate lock-in | Lock-in acceptable |
Common Patterns by Application Type:
Stateless Web Applications: → Strong candidate for PaaS. Buildpacks handle deployment, auto-scaling handles load, managed databases handle persistence.
Legacy Applications Being Modernized: → Start with IaaS (lift-and-shift), then progressively move components to PaaS as they're refactored.
Machine Learning Workloads: → IaaS for training (GPU instances, custom environments), PaaS for inference (managed serving platforms).
Internal Tools and Productivity: → SaaS wherever possible. Build vs. buy analysis usually favors buying for non-differentiating functionality.
High-Frequency Trading/Low-Latency: → IaaS or bare metal. Kernel tuning, network bypass, custom drivers required for extreme performance.
Most organizations use a mix of service models. Core infrastructure on IaaS, web applications on PaaS, and SaaS for commoditized functions (email, CRM, identity). The key is matching each workload to the most appropriate abstraction level.
The three primary service models represent layers of abstraction in cloud computing, each trading control for convenience and enabling teams with different skills and requirements to build effective solutions.
Looking Ahead:
We've explored the service model taxonomy in depth. Next, we'll examine how virtualization technologies power cloud computing—from hypervisors and paravirtualization to the container runtimes that enable modern PaaS platforms.
You now possess a comprehensive understanding of IaaS, PaaS, and SaaS architectures, their operating systems implications, and a framework for selecting the appropriate model for different workloads. Next, we'll dive into virtualization technologies that enable cloud infrastructure.