Service models: IaaS, PaaS and SaaS

Suppose Majid's lab wants a small web app to track the papers everyone is reading. There are four ways to get it running. Option A: buy servers, rack them in a room on campus and run everything, the classic Legacy IT setup. Option B: rent virtual machines on Amazon EC2 and install the app on them. Option C: push the code to Google App Engine and let Google run it. Option D: subscribe to a ready-made paper tracker and just log in. The app the lab members see is the same in all four cases. What changes is how many layers of the stack the lab runs itself, and how many it hands to a Cloud service provider (CSP).

That observation is the whole idea of a service model. The lecture draws the stack as nine layers, from the bottom up: Data Center, Networking, Storage, Server, Virtualization, Operating Systems, Databases, Security and Applications. A service model is a statement about where one horizontal line sits on that stack. Everything below the line is the provider's job, and everything above it is yours. Reading the slide diagrams, the number of customer-managed layers takes four values, one per model:

The three model names come from the NIST cloud definition, NIST SP 800-145 (Mell and Grance, 2011), which defines exactly three service models: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Each definition starts with the same phrase, "the capability provided to the consumer is", which tells you what NIST is really describing: what the customer is handed, and therefore what the customer is left to manage. The Berkeley "Above the Clouds" report makes the same point as a spectrum: utility computing offerings "will be distinguished based on the level of abstraction presented to the programmer and the level of management of the resources", with Amazon EC2 at one end and Google AppEngine at the other.

Moving the line up has a price and a payoff. The payoff is less operational work: fewer things to patch, back up, monitor and replace. The price is control. You can no longer pick the kernel, tune the database or install an unusual library, because those layers are no longer yours. Microsoft puts it in one sentence: "In an on-premises datacenter, you own the whole stack. As you move to the cloud, some responsibilities transfer to Microsoft."

Start with what launching an Amazon EC2 instance actually looks like. You pick an instance type, which AWS describes as one of "various configurations of CPU, memory, storage, networking capacity, and graphics hardware". You pick an Amazon Machine Image (AMI), a template that includes the operating system, say Ubuntu. You attach an EBS volume for persistent disk, and you set a security group, which AWS calls "a virtual firewall". A minute later you have what AWS calls "a virtual server", billed On-Demand per second with a minimum of 60 s. From that moment on, patching Ubuntu, installing PostgreSQL and hardening SSH are your jobs.

That is Infrastructure as a Service (IaaS) in practice. The provider runs the five bottom layers, Data Center, Networking, Storage, Server and Virtualization, and hands you a Virtual machine (VM). You run the four top layers: Operating Systems, Databases, Security and Applications. NIST phrases it as the capability to "provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications". The consumer "has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls)." You get those resources through On-demand self-service and pay for them as a Measured service.

The resources an IaaS provider rents come in three families:

• Compute: CPU, GPU and RAM, enough to execute arbitrary tasks, from a web server to a model training job.
• Storage: block, file and object storage, three different shapes for data described below.
• Networking: virtual routers, switches and load balancers that connect your machines to each other and to the internet.

Three shapes of storage

Students often treat the three storage types as three speeds of the same disk. They are three different ways of addressing data. Block storage splits data into "fixed-sized blocks", each with its own address, and the server mounts the whole thing as a volume, exactly like a raw disk; AWS calls this EBS. File storage keeps data as files in hierarchical "directory trees" on network-attached storage that many clients can share at once; AWS calls this EFS. Object storage keeps data as "discrete units called objects", each with its own metadata, in "a flat namespace" where "the object's unique identifier provides the address". You reach objects through an HTTP API, not a mount; AWS calls this S3.

What you still own

The Berkeley report explains why this division is so natural for IaaS. An EC2 instance "looks much like physical hardware, and users can control nearly the entire software stack, from the kernel upwards". It exposes "raw CPU cycles, block-device storage, IP-level connectivity". That freedom has a cost: because the provider cannot know how your software behaves, it is "inherently difficult for Amazon to offer automatic scalability and failover". Scaling and recovery stay largely your design problem. Azure's equivalents are Azure Virtual Machines, Azure Disk Storage and virtual networks.

Now deploy the lab's paper tracker, a small Python web app, to Google App Engine or Azure App Service. You upload the code and a short configuration file. The platform provisions servers, keeps the operating system and the Python runtime patched, routes traffic, and adds or removes instances as demand rises and falls. Azure adds continuous deployment from your repository and staging slots, so you can test a release before swapping it into production. That is the "development, testing and delivery" lifecycle the slide mentions, and you never logged into a server.

That is Platform as a Service (PaaS). The provider manages every layer up to and including the runtime, and you manage your application. NIST defines it as the capability to "deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider". The consumer does not control "network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment." Google describes App Engine as "one of the fully managed, serverless platforms for developing and hosting web applications at scale" that scales instances automatically "based on demand". Microsoft describes App Service as a way to run "web applications, mobile back ends, and RESTful APIs without worrying about managing the underlying infrastructure", in .NET, Java, Node.js, Python or PHP, with "automatic OS/runtime management and patching".

Why PaaS can scale for you

On IaaS, the provider cannot safely clone your VM, because it does not know what state lives inside it. PaaS solves that by asking you to build the app in a particular shape. The Berkeley report notes that AppEngine enforces a "clean separation between a stateless computation tier and a stateful storage tier", and that its automatic scaling and high-availability mechanisms "rely on these constraints". Because any request can go to any copy of the stateless tier, the platform can add copies under load and remove them when traffic drops, which is Rapid elasticity handled by the provider. The price of that convenience is constraint: you work within the supported languages, libraries and storage services, and moving off the platform later can mean rewriting parts of the app, a form of Vendor lock-in.

KFUPM gives every student email through Microsoft 365. Students open Outlook in a browser or the phone app; administrators manage accounts and security settings in the Microsoft 365 admin center. Nobody at KFUPM installs, patches or backs up a mail server. That is Software as a Service (SaaS): the provider runs the entire application, and you use it.

NIST defines SaaS as the capability to "use the provider's applications running on a cloud infrastructure", accessible "from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface". That reliance on Broad network access is why SaaS works on any laptop or phone. The consumer does not manage the infrastructure, "or even individual application capabilities, with the possible exception of limited user-specific application configuration settings." AWS adds that SaaS is "in most cases" made of "third-party end-user applications": email, office suites, CRM, video calls.

What never leaves the customer

Here is the twist the slides miss. Even when the provider runs every layer of the stack, some responsibilities stay with the customer in every model, SaaS included. Microsoft's shared responsibility matrix makes this explicit: "For all cloud deployment types, you own your data and identities." Google says the same in its own words: "In SaaS, we own the bulk of the security responsibilities. You remain responsible for your access controls and the data that you choose to store in the application."

Read the matrix row by row. Customer data, configurations and settings, and identities and users stay "Customer" in all four columns. Microsoft adds a short list that is always retained by the customer, whatever the model: data, endpoints, accounts, and access management such as role-based access control, multifactor authentication and conditional access. Client devices show up as shared under SaaS because Microsoft can provide some device management capabilities, but endpoint protection and compliance on the laptop or phone are still yours. If a student account is phished because MFA was never enabled, the provider did not fail; the customer did.

Classifying any service

Exams like to name a product and ask for its model. One question settles almost every case: what am I handed, a machine, a runtime, or a finished app? A machine you install software on (EC2, Google Compute Engine, Azure Virtual Machines) is IaaS. A runtime you deploy code onto (App Engine, Azure App Service) is PaaS. A finished application you sign in to (Gmail, Microsoft 365) is SaaS.