Academmia

Identify Appropriate Use Cases for IaaS, PaaS, and SaaS

az-900•beginner•

Cloud concepts

Identify Appropriate Use Cases for IaaS, PaaS, and SaaS

Short Summary

This lesson helps you choose between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) based on what a workload needs. You will use a simple mental model: how much control you need versus how much operational work you want the provider to handle. You will also learn how service types differ from deployment models (public, private, hybrid).

Learning Objectives

By the end of this lesson, you will be able to:

  • Identify when a scenario fits Infrastructure as a Service (IaaS).
  • Recognize when a scenario fits Platform as a Service (PaaS).
  • Select when a scenario fits Software as a Service (SaaS).
  • Apply “who manages what” clues (especially Operating System (OS) responsibility) to choose a service type.
  • Distinguish cloud service types (IaaS/PaaS/SaaS) from deployment models (public/private/hybrid).

Core Concepts

Cloud service types describe how a service is delivered and who manages which layers of the computing stack. The core difference between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) is the responsibility split between you and the provider.

IaaS gives you the most control. You typically run workloads on Virtual Machines (VMs) and manage what’s inside them, including the OS, patching, configuration, and installed software. The provider manages the physical datacenter, hardware, and physical security.

PaaS gives you a managed platform for your code. You deploy your application code to a provider-managed environment. The provider manages the infrastructure and the OS/platform components, while you focus on your application logic, configuration, and data.

SaaS gives you a complete application you use. The provider runs the entire service, including infrastructure, platform, and the application itself. You typically manage users, permissions, configuration within the app, and the data your organization stores in it.

A practical “control clue” for most scenarios:

  • If you must manage the OS, think IaaS.
  • If you deploy your code but do not manage the OS, think PaaS.
  • If you use a finished application, think SaaS.

Finally, service types are not deployment models. Service types describe who manages what. Deployment models (public, private, hybrid) describe where the cloud runs and who it is for. A workload can be IaaS/PaaS/SaaS regardless of whether it’s deployed in a public, private, or hybrid environment.

Practical Understanding

Practical Situation 1: Lift-and-shift with OS-level control

A company wants to move an existing on-premises server to the cloud with minimal changes. The workload depends on specific OS settings and needs administrator control.

How to think about it: This aligns with IaaS because OS-level control is the deciding requirement. In IaaS, you manage the OS and installed software, while the provider handles the physical infrastructure.

Common misunderstanding: “Because it’s in the cloud, the provider manages my OS.” In IaaS, OS patching and configuration are still your responsibility.

Practical Situation 2: Build and release fast without managing servers

A development team wants to ship a new web app quickly. They don’t want to install runtimes, patch operating systems, or maintain servers, and they want the platform to handle common operational tasks.

How to think about it: This aligns with PaaS. You deploy your code to a provider-managed platform and focus on application logic, configuration, and data, while the provider manages the OS and platform layer.

Common misunderstanding: “Anything managed must be SaaS.” PaaS can be highly managed too—the difference is that you are deploying and running your own code.

Practical Situation 3: Use a ready-to-use business application

A company needs a collaboration suite (email, chat, meetings, file sharing) or a Customer Relationship Management (CRM) system. They want to avoid installing, updating, and maintaining the application themselves.

How to think about it: This aligns with SaaS. You consume a provider-run application and focus on users, access, configuration within the app, and the data stored in it.

Common misunderstanding: “If it’s subscription-based, it must be SaaS.” Billing style isn’t the deciding factor; the deciding factor is whether you’re using a provider-operated application.

Practical Situation 4: Managed database for a custom application

A team needs a database for their own application. They want the provider to handle patching, backups, and availability features, while they design the schema and manage how the app uses the data.

How to think about it: This is typically PaaS, because a managed database is a platform component you use to build your solution. The provider manages the database engine and operations, while you manage the data model and how the application uses it.

Common misunderstanding: “A database service is SaaS because it’s managed.” SaaS is a complete application; a managed database is usually a platform service.

Common Pitfalls

  • Mistake: Treating one service type as the “best” default for all workloads. Correction: Choose based on the workload’s need for control versus how much operational responsibility you want the provider to handle.

  • Mistake: Confusing service types (IaaS/PaaS/SaaS) with deployment models (public/private/hybrid). Correction: Service types describe responsibility split; deployment models describe where the cloud runs and who it serves.

  • Mistake: Calling “deploying your code to a managed environment” SaaS. Correction: Deploying your code without managing the OS usually maps to PaaS; SaaS is a finished application you use.

  • Mistake: Forgetting to use the “who manages what” test. Correction: Start with the OS clue: OS responsibility suggests IaaS; provider-managed OS/platform suggests PaaS; provider-managed application suggests SaaS.

  • Mistake: Assuming an organization must pick only one model for everything. Correction: It is normal to mix IaaS, PaaS, and SaaS across different workloads.

Check Your Understanding

  1. Pick a workload you know. Do you manage the OS, deploy your own code, or use a finished app? What service type does that suggest?
  2. Explain the OS-based “control clue” in your own words and give one example where it changes your decision.
  3. Compare “lift-and-shift a legacy server” with “build a new app fast.” Why do these typically map to different service types?
  4. Explain why the statement “IaaS means public cloud” is incorrect.
  5. For a managed database used by your custom app, list what you manage versus what the provider manages, and identify whether it’s closer to PaaS or SaaS.

Further Reading