Cloud Computing Fundamentals
Software as a Service (SaaS)
The service model where the provider runs the entire application and you just use it, from Gmail to Salesforce to Slack, and the multi-tenant architecture that makes running one application for millions of customers affordable.
- Define Software as a Service (SaaS) using the NIST framework
- Explain multi-tenancy and why it makes SaaS pricing possible
- Identify what a SaaS customer can and cannot configure
- Distinguish genuine SaaS from a locally installed, subscription-priced application
You already used SaaS today
You did not install a mail server this morning. You did not patch an operating system, provision a virtual machine, or write a line of code. You typed a password into a browser, and your inbox was already there, running on hardware you have never seen, maintained by a team you have never met. That is Software as a Service, and unlike the last 2 lessons, you almost certainly used it before you finished breakfast.
The NIST definition, in practice
NIST defines SaaS as the capability to "use the provider's applications running on a cloud infrastructure," reachable "through either a thin client interface, such as a web browser... or a program interface." The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
That exception is doing real work in the sentence. You cannot install a plugin on Gmail's servers or change which programming language Salesforce is written in. You can set up an email filter or customize a Salesforce dashboard. The application itself, and everything beneath it, belongs entirely to the provider.
Who manages what, complete
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Networking, servers, virtualization | Provider | Provider | Provider |
| Operating system, runtime | You | Provider | Provider |
| Application code | You | You | Provider |
| Data and user configuration | You | You | You |
Data and your own configuration are the one row that never moves. Every other layer eventually crosses to the provider by the time you reach SaaS.
Multi-tenancy: the architecture that makes this affordable
A SaaS vendor is not running a separate copy of Gmail for each of its billions of users. Gartner describes multitenancy as software where a single instance serves multiple customers, logically isolated from each other but physically sharing the same infrastructure underneath. Your inbox and a stranger's inbox run on the same application instance, the same servers, with the provider's software guaranteeing neither of you can see the other's data.
That sharing is exactly what makes SaaS pricing work. Spreading one application instance across millions of tenants is dramatically cheaper per customer than running a dedicated copy for each one, which is why a SaaS subscription usually costs a small fraction of what building and hosting the same application yourself would.
Real products, by category
| Category | Examples |
|---|---|
| Email and productivity | Gmail, Microsoft 365 |
| Customer relationship management | Salesforce |
| Team communication | Slack, Zoom |
| File storage and collaboration | Dropbox, Google Workspace |
The misconception: a subscription is not the same thing as SaaS
It is tempting to call anything billed monthly "SaaS." It is not. A boxed application you install on your own laptop, and personally keep updated, does not become SaaS just because its license renews every month. The test is not the billing model, it is who runs it and where. If the provider hosts, patches, and operates the application on infrastructure you never touch, and you reach it through a browser or an API, it is SaaS. If you installed it yourself and you are the one applying its updates, it is not, no matter how the invoice arrives.
Where this leaves you
SaaS is the end of the handoff that started with IaaS: the provider now runs the operating system, the runtime, and the application itself, and the only thing left on your side of the line is your data and your own settings. You have now met all 3 service models individually. The next lesson puts them side by side and gives you the boundary an exam actually tests: not what each one is, but which one a scenario is describing.