3 Service Models: IaaS, PaaS, and SaaS

3.1 Start With the Layer Each Model Hands You

NIST describes three pillars of cloud computing. One is the service model. It has three forms: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). This chapter shows what each layer gives you and who runs the layers below it. It also explains how virtualization makes them work.

3.2 IaaS, PaaS, and SaaS as Building-Block Layers

Cloud service models describe what a provider runs for you. As you move from IaaS to PaaS to SaaS, the provider manages more of the stack. You give up some control in exchange for less work.

For example, a team can rent a server to run its own app, deploy that app on a managed platform, or use a ready-made app. The next table shows which jobs move to the provider in each case.

A runtime is the environment that executes an app, such as a Python interpreter. Middleware is software that connects an app to other services, such as a message broker or database. These sit between the app and the operating system. Their upkeep can fall to the customer or the provider, depending on the service.

3.3 Who Manages What: The Responsibility Bracket

Use the table to trace who runs each layer. Start with a self-hosted stack, then read across each row. The provider takes on more work as you move from IaaS to PaaS and SaaS. Actual contracts may divide duties differently, so check the terms of your service.

In a self-hosted stack, the user runs every layer. With IaaS, the provider runs the network, storage, servers, and virtual machines. The user still runs the guest OS, middleware, runtime, app, and data. With PaaS, the provider also runs the OS, middleware, and runtime. The user still runs the app and manages its data.

With SaaS, the provider runs the app and its data service. The customer still owns its data and must govern access, retention, and lawful use. A managed service does not remove the need to set permissions or check the provider's controls.

A hypervisor helps a provider share a physical server among virtual machines. Each VM has its own guest OS and apps. The hypervisor assigns and isolates resources on the shared hardware. Some cloud services also offer dedicated hardware, so not every IaaS resource must be a VM.

IaaS can help a new team avoid buying servers up front. A shop can add capacity for a seasonal surge and release it when demand falls. Scaling still needs planning: a slow network, a poor design, or a service limit can keep an app from meeting its target.

Look for five useful traits when assessing IaaS. Elasticity lets a team add or release capacity. Management tools show resource use and cost; portable interfaces can ease a move, though vendors differ. Availability and reliability matter for access to data and compute. Performance depends on the shared hardware and workload. Access controls let the team manage its resources. None of these traits guarantees perfect uptime, constant speed, or an easy move between clouds.

IaaS can use public, private, community, or hybrid cloud deployment. These terms describe who shares and governs the cloud, a separate choice from the service model. Rules for sensitive data may limit outsourcing. Latency, job placement, scaling, and OS upkeep also remain practical concerns for the user.

3.4 Under the Hood: PaaS Feature Stack and SaaS Multi-Tenant Architecture

PaaS gives a team a place to build and run its app without managing the platform underneath. A service may include an OS, runtime, database, storage, network access, hosting, support, and development tools. The provider updates the platform on its own schedule, so the team must check compatibility and service terms.

For example, a team that wants to deploy code without patching the OS can use PaaS. The provider runs the OS and runtime, while the team still fixes its app and manages its data. This saves platform work, but the team must work within the platform's limits.

SaaS moves the boundary further: the provider runs the finished app. Many SaaS products use multi-tenancy, where shared app components serve multiple customers while keeping their data separate. They may scale shared resources for many users and offer settings for each tenant. Shared settings can also let a provider change a feature for everyone.

With installed software, a customer may manage its own upgrades. A SaaS provider usually controls the release schedule, and the subscription may include updates. Terms vary: check device support, fees, and export options rather than assuming all services work alike.

SaaS can reduce upkeep, but the provider's control can limit customization. Moving data and workflows to another service can take effort. The customer must also assess privacy, security, and access controls for its data. Multi-tenancy requires effective isolation; sharing an app alone does not prove that isolation works.

3.5 Summary

IaaS gives you compute, storage, and network resources; you run the guest OS and app. PaaS also manages the platform, leaving you to run your app and handle its data. SaaS gives you a finished app run by the provider. A hypervisor can split one server into isolated VMs. In every model, check the service terms and keep track of your duties, especially data access and governance.

3.6 Key Takeaway

Name the layers you must run before choosing a service.

3.7 See Also

The previous chapter introduces the cloud model. The two IoT chapters apply these ideas to service choices and workload placement.