3 Service Models: IaaS, PaaS, and SaaS
3.1 Start With the Layer Each Model Hands You
The previous chapter’s NIST three-pillar model named “service models” as one of its three axes, with three members: Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service. This chapter builds that pillar in full: what each layer actually delivers, who manages what beneath it, and the virtualization mechanism that makes any of it possible in the first place.
Not the same question as the sibling chapter: Cloud Service Models for IoT asks “which responsibility boundary should this IoT workload use, and what review record proves it?” This chapter asks the question underneath that one: “what is IaaS, PaaS, and SaaS, mechanically, before any IoT decision gets made?” Read this chapter first if the terms themselves are not yet solid.
3.2 IaaS, PaaS, and SaaS as Building-Block Layers
Each service model is defined by how much of the stack the provider hands you as a finished product, versus how much you still assemble yourself. Working from the most raw layer to the most finished:
Infrastructure-as-a-Service (IaaS)
“Contains the basic building blocks for cloud IT and typically provides access to networking features, computers (virtual or dedicated hardware), and data storage space.” (Amazon) IaaS provides servers/compute, storage, network, and operating system as rentable primitives. Named examples: Amazon EC2, GoGrid, iland, Rackspace Cloud Servers.
Platform-as-a-Service (PaaS)
Lets a consumer execute consumer-created or acquired applications onto cloud infrastructure without managing that infrastructure directly, while still controlling the deployed application through the platform’s own configuration options. “Removes the need for organizations to manage the underlying infrastructure… and lets you focus on the deployment and management of your applications.” (Amazon) Named examples: Windows Azure, Google App Engine.
Software-as-a-Service (SaaS)
Delivers a finished, running, managed product. “Software as a Service provides you with a completed product that is run and managed by the service provider… referring to end-user applications.” (Amazon) The end user does not possess control of the cloud infrastructure at all. Named examples: Google Apps, Salesforce, Learn.com.
Each definition above names two things: what the provider gives you, and what you no longer have to build yourself. That trade is the entire anatomy of a service model – everything else in this chapter is detail on top of that one trade.
3.3 Who Manages What: The Responsibility Bracket
The clearest way to see the difference between the three models – and the traditional, fully self-hosted alternative they all replace part of – is a single table naming who manages each layer of the stack. This is the strongest reuse candidate in the whole source deck for a reason: it answers “what am I actually buying?” in one look.
Read down any one column and the pattern is the boundary line moving upward: Traditional puts everything on the user. IaaS moves networking, storage, servers, and virtualization to the provider. PaaS moves the operating system, middleware, and runtime up too, leaving only applications and data with the user. SaaS moves everything, including applications and data ownership of the running product, to the provider – though as the sibling IoT-focused chapter stresses, “provider-managed” is never the same thing as “no longer the user’s responsibility to configure, verify, or secure.”
Underneath IaaS specifically, the mechanism that makes “the provider owns virtualization” possible is the hypervisor. A traditional physical server runs one operating system directly on hardware, with one application stack on top of that OS. A virtualized server inserts a hypervisor between the hardware and the operating systems: the hypervisor runs on the hardware, and multiple virtual machines – each with its own guest operating system and application – run on top of the hypervisor, sharing the same physical hardware without being aware of each other. This is the working methodology behind every IaaS provider: the user rents server time, software, data-center space, or network equipment; the cloud service provider handles resource management; the whole arrangement is an outsourced, on-demand service.
IaaS earns its place for reasons that show up directly in the source material’s own examples: new businesses can operate without investing in computer hardware at all; the model scales for rapidly growing businesses, and specifically for fluctuating demand – the deck cites Flipkart and Amazon during festival-season traffic spikes as the canonical case; it suits new business-model trials where the cost of guessing wrong on hardware would be prohibitive; and it minimizes the capital expense that would otherwise gate an entrepreneur starting on a limited budget.
IaaS also carries five named essential characteristics of its own, distinct from (but built on top of) the five NIST characteristics from the previous chapter:
Scalability and Elasticity
Dynamic scaling of required infrastructure resources; large-scale allocation or release in a short span of time, with no variation in system performance while scaling in or out.
Manageability and Interoperability
Clients get total control of the virtualized resources they hold, with a pre-configured allocation facility, running-status monitoring, and a usage-and-billing system that records use and calculates payment.
Availability and Reliability
Stored data can be retrieved at any time without failure; clients can access computational resources without failure; computation and communication are uninterrupted.
Performance and Optimization
High utilization of physical resources across different clients; high computing power enabled through parallel processing over a large physical pool; dynamic configuration of virtual resources to optimize deployment.
Accessibility and Portability
An easing facility for clients to control, manage, and access infrastructure resources, and to easily reallocate or duplicate resources already allocated to them.
IaaS can be obtained through the same deployment categories the previous chapter previewed – public cloud (shared infrastructure, self-service basis), private cloud (private infrastructure, access-controlled), and hybrid cloud (a blend of the two) – a topic a later chapter in this module returns to in full. And IaaS has real, named limits: regulatory approval sometimes blocks outsourcing the storage and processing of sensitive data (the source material’s own example is medical records); network latency can degrade expected performance; users may need automated decision-making for job scheduling against available resources; seamless scaling independent of traffic variation is not automatic to get right; and developers are still exposed to low-level system details that PaaS and SaaS are specifically designed to hide.
3.4 Under the Hood: PaaS Feature Stack and SaaS Multi-Tenant Architecture
PaaS’s working model is what makes “you still control the application, but not the infrastructure” concrete: it lets users create software applications using tools the platform already offers, provides pre-configured features customers can simply subscribe to, gives the provider responsibility for supporting the managed infrastructure and applications, and keeps those services regularly updated with new features on the provider’s own schedule rather than the consumer’s. A PaaS offering is, in practice, a named bundle of nine features:
Operating System
Server-Side Scripting Environment
Database Management System
Server Software
Support
Storage
Network Access
Tools for Design and Development
Hosting
The business case for that bundle is the mirror image of IaaS’s: teams get access to key middleware services without worrying about the underlying complexity of managing individual hardware and software elements, get easy access to development and deployment tools, and are freed from managing those tools individually. Where IaaS trades capital expense for operational responsibility, PaaS trades a further slice of operational responsibility for narrower application-level control.
SaaS sits one layer further up again, and its architecture is described by three named properties rather than a feature list:
Scalability
Maximizes application concurrency and optimizes the shared pool of resources – threads, network connections – behind a single running product serving many customers at once.
Multi-Tenancy
An architectural shift away from isolated, single-tenant applications: one running instance accommodates users from multiple organizations simultaneously, transparently to all of them, while still distinguishing each tenant’s own data.
Configurability
A single application on a single server is allocated in parallel to many users; customizing the application for one customer changes it for others too, which is why SaaS products keep separate data spaces per user even while sharing one configuration surface.
Set side by side, the practical difference between owning software the old way and consuming it as SaaS is a six-row comparison worth keeping as a checklist:
The trade-off is real, not one-sided. The same architecture that gives SaaS its advantages also produces four named limitations: centralized control (the provider decides the update schedule and feature set, not the customer); switching cost (migrating a multi-tenant product’s data and workflow elsewhere is nontrivial); limited flexibility (deep customization conflicts with a shared, multi-tenant codebase); and data security and privacy (customer data lives inside a provider-controlled, multi-tenant environment by design).
3.5 Summary
IaaS, PaaS, and SaaS are three points on the same trade: how much of the stack the provider runs for you, versus how much you still run yourself. The responsibility bracket makes that trade literal, layer by layer, with the boundary line moving from virtualization (IaaS) to the operating system and runtime (PaaS) to the entire application and data layer (SaaS). Underneath IaaS, a hypervisor is what lets one physical server host many isolated virtual machines. PaaS packages a nine-item feature bundle – OS, scripting environment, DBMS, server software, support, storage, network access, dev tools, and hosting – on top of that infrastructure. SaaS architecture adds scalability, multi-tenancy, and configurability, which is exactly what produces both its advantages over traditional software and its own named limitations: centralized control, switching cost, limited flexibility, and data security and privacy.
3.6 Key Takeaway
“Managed” is not a single amount – it is a specific, named boundary you can read straight off the responsibility bracket. Before calling anything IaaS, PaaS, or SaaS, name which row of that table moves from your column to the provider’s.
3.7 See Also
Cloud Computing: Origins and the NIST Model
The previous chapter in this module: the NIST definition and three-pillar model this chapter’s service-model pillar builds on.
The applied companion chapter: turns this chapter’s IaaS/PaaS/SaaS anatomy into an IoT responsibility-boundary decision with a review record.
Cloud Computing Fundamentals for IoT
Workload placement by timing and data constraints, once the service-model anatomy here is solid.