Before we meet the three letters, we need to understand the problem they were invented to solve.

What is cloud computing?

Cloud computing means using computing power, storage, and software over the internet, and paying only for what you use. The word “cloud” is just a friendly way to say “somewhere out on the internet, run by a provider.” You do not need to know which building the machines are in. You only need to know how to reach them.

It exists because owning computers is hard. Before the cloud, a company that wanted to launch a website had to buy servers, wait weeks for delivery, find a room with cooling and backup power, hire people to look after the machines, and guess how much capacity it would need. Guess too low and the site crashed on launch day. Guess too high and money sat idle in a cold room.

A short history

The idea of sharing big computers is old, going back to the 1960s. The modern cloud began in 2006, when Amazon Web Services launched its storage service (S3) and then its virtual server service (EC2). For the first time, anyone with a credit card could rent a server in minutes. Google App Engine arrived in 2008 and Microsoft Azure followed, offering ready-made platforms for developers. Meanwhile, Salesforce had been selling business software through a web browser since 1999.

By 2011 the industry had so many offerings that the United States standards body, NIST, wrote an official definition. It named three service models: Infrastructure as a Service, Platform as a Service, and Software as a Service. Those names stuck, and they are still the first thing people learn today.

Three layers, one idea

All three models share the same promise: let someone else handle the boring, heavy parts so you can focus on what makes your work special. They differ in how much they take off your plate.

• IaaS (Infrastructure as a Service) hands you the raw machines, storage, and network. You build everything on top.
• PaaS (Platform as a Service) hands you a ready-to-use platform. You bring only your code.
• SaaS (Software as a Service) hands you a finished application. You bring only your data and your users.

Public, private, and hybrid clouds

The three service models describe what you rent. A separate question is where it lives. In a public cloud, such as AWS, Microsoft Azure, or Google Cloud, the provider’s machines are shared by many customers, kept apart by software. In a private cloud, the machines serve only one organization, either in its own building or in a dedicated corner of a provider’s. A hybrid cloud joins the two, so sensitive records can stay in a private place while public websites run on shared machines.

You can have IaaS, PaaS, or SaaS in any of these settings. The service model tells you how much you manage. The deployment type tells you who shares the hardware with you. Mixing up the two is one of the most common mix-ups, so keep them in separate boxes in your head.

IaaS is the lowest layer. It gives you the machines and the wires, and trusts you to do the rest.

What it is

Infrastructure as a Service lets you rent basic computing resources over the internet. The main pieces are virtual machines (computers that exist as software on a larger physical computer), storage (places to keep files and disks), and networking (the private roads that connect everything). You choose how big each piece is and switch it on in minutes.

It exists because buying and housing hardware is slow and costly. With IaaS, a company can start a hundred servers on Monday for a big project and shut them all down on Friday. It pays only for the hours they ran.

What you manage and what the provider manages

The provider looks after the physical world: the building, the power, the cooling, the cables, the physical servers, and the software layer that slices one big machine into many virtual ones. You look after everything from the operating system upward. That includes installing updates (called patches), setting up security rules, installing your software, and keeping backups.

This is a lot of freedom, and it comes with a lot of work. If you forget to patch your operating system and an attacker walks in, that is on you, not on the provider.

The building blocks you get

Where IaaS is used

IaaS fits teams that need full control. Typical cases include moving an old application to the cloud without rewriting it, running software that needs a special operating system, crunching huge batches of data for a few hours, building test environments that appear and vanish, and keeping a backup site ready in case the main one fails.

A famous example is Netflix. The company began moving away from its own data centers in 2008, after a database failure stopped DVD shipments for days. By 2016 it had moved its customer-facing systems to AWS, using a huge fleet of rented machines that grows and shrinks with viewing demand. Netflix still delivers the video itself through its own network of servers placed inside internet providers, but the brains of the service run on rented infrastructure.

PaaS sits in the middle. The platform handles the plumbing, and you handle the creative work.

What it is

Platform as a Service gives developers a ready-to-use environment for building, running, and managing applications. You do not rent a machine and then set it up. Instead, you hand the platform your code, and it figures out where to run it, how to keep it alive, and how to add more copies when traffic grows.

It exists because many developers do not want to spend their days fixing servers. A developer’s real job is to build features that customers love. PaaS removes the chores that stand in the way: installing operating systems, applying security patches, setting up load balancers, and wiring up deployment steps.

What the platform does for you

• Looks after the operating system. It installs updates and security fixes without you lifting a finger.
• Provides the runtime. A runtime is the environment your code needs to run, such as the right version of Java, Python, Node.js, or .NET.
• Scales automatically. When more visitors arrive, it starts more copies of your app. When they leave, it removes the extras.
• Handles deployment. You push your code, and the platform builds it and releases it, often in a few minutes.
• Offers add-ons. Databases, caches, message queues, and logging tools can be attached with a few clicks.

Well-known PaaS products

The catch

The workshop is convenient, but it has house rules. The platform decides which programming languages are supported, which versions you may use, and how your app must be packaged. If your application needs a strange operating system setting or special hardware, a PaaS may say no. You also depend on the platform’s design: if it has a limit on how long a request may run, your app must live with that limit.

Many teams accept these rules happily. A small team at a young company can ship a product in days instead of months. As the company grows and its needs become unusual, it may later move some parts down to IaaS for more control.

SaaS is the layer most people already use every day without knowing its name.

What it is

Software as a Service means a finished application that you use through a web browser or a mobile app, usually paying a monthly or yearly subscription. There is nothing to install on a server, nothing to patch, and nothing to scale. The provider runs the whole thing and gives every customer access.

It exists because most organizations do not want to build their own email system, their own accounting tool, or their own customer database. These problems are already solved well. It is cheaper and faster to subscribe to a good product than to create one from scratch.

Everyday examples

Gmail and Google Workspace for email and documents. Microsoft 365 for Word, Excel, and Teams. Salesforce for managing customers. Slack for team chat. Zoom for video meetings. Dropbox for file sharing. Atlassian’s Jira Cloud for tracking work. Shopify for running an online shop. If you open it in a browser, log in, and your data is waiting, it is almost certainly SaaS.

Salesforce is a good story. When it launched in 1999, its slogan was “The End of Software,” because customers no longer had to buy discs, install programs, and hire people to run servers. The company grew into one of the largest software firms in the world by proving that businesses would trust a browser with their most important data.

How SaaS is different from the other two

With IaaS and PaaS you build something. With SaaS you configure something. You change settings, create users, design forms, and connect other tools, but you do not change the underlying program. Another important difference is that SaaS is almost always multi-tenant. That means many customers, called tenants, share the same running application, while the software keeps each customer’s data separated. We will see how that works in a later chapter.

The clearest way to tell the three models apart is to ask one question: which layers do I look after, and which does the provider look after?

The responsibility ladder

Every computer system is built from layers stacked on top of each other. At the bottom are the physical machines. At the top is the application that people actually use. The table below shows who is responsible for each layer when you run everything yourself (called on-premises) and in each of the three cloud models.

Notice the row in the middle: your data is always yours to protect, in every model. Even with SaaS, you decide who may see it and how long to keep it. This one row causes more real-world security problems than any other.

A quick comparison

How they stack on each other

The three models are not rivals so much as floors in one building. A SaaS product like Slack is built by developers using platform tools, which in turn run on rented infrastructure. Slack itself runs on AWS. So when you chat with a friend on a SaaS app, you are standing on the top floor of a building whose lower floors you never see.

flowchart LR
    U["You, the customer"] --> SaaS["SaaS: finished app
Gmail, Salesforce"]
    D["Developers"] --> PaaS["PaaS: ready platform
Heroku, App Engine"]
    A["Admins and architects"] --> IaaS["IaaS: raw infrastructure
EC2, Azure VMs"]
    SaaS -. runs on .-> PaaS
    PaaS -. runs on .-> IaaS
    IaaS --> HW["Provider data centers
servers, storage, network"]

The diagram reads from left to right. On the far left are the different kinds of people. Each kind of person walks into a different floor. Customers use the finished app. Developers build on the platform. Architects and administrators work directly with infrastructure. The dotted lines show that higher floors usually stand on lower ones, and everything finally rests on the provider’s physical data centers.

Now let us open the box. What parts does each model contain, and how do they fit together?

Regions and zones: the foundation under everything

Every big cloud provider divides the world into regions, which are geographic areas such as “Mumbai” or “Frankfurt.” Inside each region there are several availability zones. A zone is one or more data centers with their own power, cooling, and network. Zones in the same region are close enough to talk to each other very fast, but far enough apart that a fire or power cut in one does not take down the others.

Why does this matter? If you place your system in only one zone, one bad day can stop it. If you spread it across two or three zones, it can survive the loss of a whole building. Placing systems near your users also makes pages load faster, and some countries have laws that say certain data must stay inside their borders.

A typical IaaS setup

Let us picture a small online shop built on IaaS. The owner rents a private network, puts a load balancer at the front door, runs several virtual machines that hold the shop software, and attaches a database and disks. Because the owner chose every piece, the owner must also connect and protect every piece.

flowchart TB
    subgraph VPC["Your Virtual Private Network"]
        LB["Load Balancer"]
        VM1["Virtual Machine 1"]
        VM2["Virtual Machine 2"]
        DB["Database Server"]
    end
    Internet["Internet users"] --> LB
    LB --> VM1
    LB --> VM2
    VM1 --> DB
    VM2 --> DB
    VM1 --> Disk1["Block Storage Disk 1"]
    VM2 --> Disk2["Block Storage Disk 2"]
    DB --> Backup["Object Storage for backups"]

Follow the arrows from the top. Visitors on the internet reach the load balancer first. The load balancer picks a healthy virtual machine and passes the visitor along. Both machines read and write to the same database. Each machine has its own disk, and the database sends copies of its data to cheap object storage so a backup exists if something breaks. The load balancer is also what lets you add a third or fourth machine later without visitors noticing.

A typical PaaS setup

On a PaaS, most of those boxes disappear from your view. The platform owns them. What remains is a cleaner pipeline that moves your code from your laptop to the users.

flowchart LR
    Dev["Developer pushes code"] --> Build["Build system"]
    Build --> Pack["Packaged application"]
    Pack --> Run["Managed runtime"]
    Router["Platform router and load balancer"] --> Run
    Users["Users"] --> Router
    Run --> Addon["Managed add-ons: database, cache, queue"]
    Scaler["Autoscaler"] --> Run
    Run --> Metrics["Built-in logs and metrics"]
    Metrics --> Scaler

The developer pushes code. The build system turns it into a packaged application. The platform starts the package inside a managed runtime and connects it to the router, which receives user traffic. Add-ons such as a database are attached as services. The autoscaler watches the metrics coming out of the runtime and adds or removes copies as needed. Notice the loop at the bottom: the platform watches itself and adjusts itself.

A typical SaaS setup

From the outside, a SaaS product looks like a single website. Inside, it usually has a front end (what you see), an API layer (the doorway that the front end and other programs use), a business logic layer (the rules of the product), a data layer (where customer data lives), and a tenancy layer that keeps customers apart. It also offers integrations, which are ready-made connections to other tools, so your SaaS apps can talk to each other.

The magic of the cloud is sharing. Many customers use the same physical machines, yet none can see the others. Here is how that is done.

Virtualization: one machine, many computers

Virtualization is the technique that lets one physical server pretend to be many separate computers. A special layer of software called a hypervisor sits between the hardware and the virtual machines. It hands out slices of the processor, memory, and disk to each virtual machine, and it makes sure no machine can peek into another’s slice.

Real providers have refined this a lot. Amazon’s Nitro system, for example, moves much of the virtualization work onto dedicated hardware cards, so more of the main server’s power goes to the customer and less to the hypervisor. It builds on a widely used open technology called KVM. Google Compute Engine also uses KVM. Earlier generations of EC2 used a different hypervisor called Xen.

Containers: lighter than virtual machines

A virtual machine carries a whole operating system. A container is lighter. It packs an application with just the files and settings it needs, and several containers share the same operating system underneath. Containers start in seconds and use less memory.

Most PaaS products run your code in containers. When you push your code, a tool often called a buildpack looks at it, works out which language you used, gathers the right runtime, and produces a container. A scheduler then decides which machine in the platform’s big pool has room for it, and a router sends visitors to it. If the machine fails, the scheduler quietly starts a new copy elsewhere. This is why developers on a PaaS rarely get woken up by a dead server.

How a platform decides when to scale

Autoscaling sounds like magic, but it follows simple rules that you can understand. The platform keeps watching a few numbers, such as how busy the processors are or how many requests are waiting in line. When a number crosses a limit you chose, for example “processors above seventy percent for five minutes,” the platform starts another copy of your application. When the number falls well below another limit, it removes a copy.

The waiting period matters. Starting a copy takes time, and removing one too early can cause a wobble when visitors return. Good rules react quickly to a rush but slowly to a lull. Think of a lifeguard who blows the whistle the moment the beach fills up, but waits a while before sending the extra staff home.

Multi-tenancy: how SaaS shares one application

In a multi-tenant system, many customers share one running copy of the software. This is what makes SaaS cheap. The provider updates one application, and every customer gets the update at the same time. But sharing is only safe if every request is checked.

flowchart TB
    T1["Customer A"] --> GW["API Gateway and Login"]
    T2["Customer B"] --> GW
    T3["Customer C"] --> GW
    GW --> App["Shared Application Servers"]
    App --> Check["Tenant Check on every request"]
    Check --> DB["Shared Database with a tenant ID on every row"]
    Check --> Cache["Shared Cache with tenant-based keys"]
    Check --> Files["File Storage with tenant folders"]

Here is the flow in words. Customers log in through the gateway. The gateway proves who they are and which company they belong to. The shared application servers handle the request, but before touching any data, a tenant check makes sure the request only reaches that company’s rows, cache entries, and files. A single mistake in this check could expose one customer’s data to another, which is why SaaS companies invest heavily in testing it.

Three ways to separate tenants

Let us follow one visitor’s request from the browser to the data and back, then follow the life of an application from birth to retirement.

Following one request

Imagine you open an online shop that runs on the cloud. Your browser first needs to find the shop’s address. It asks a system called DNS, which works like a phone book for the internet. Then it sends the request to the shop’s front door, usually a load balancer. The load balancer passes it to a healthy server. The server reads and writes data, builds the page, and sends it back the same way.

sequenceDiagram
    participant U as User
    participant D as DNS
    participant L as Load Balancer
    participant A as App Server
    participant S as Database
    U->>D: Where is the shop address
    D-->>U: Here is the address
    U->>L: Request the page
    L->>A: Forward to a healthy server
    A->>S: Read and write data
    S-->>A: Result
    A-->>L: Page built
    L-->>U: Page delivered

The path is almost the same in every model. What changes is who looks after each stop. On IaaS you built the load balancer, the servers, and the database. On PaaS the platform operates them. On SaaS, all the stops belong to the provider, and you only see the final page.

The life of an application

Every application goes through stages. The effort you spend on each stage depends on the model you chose.

The lifecycle of data

Data also has a life: it is created, stored, used, backed up, archived, and finally deleted. In IaaS you decide where each copy lives and how long it stays. In PaaS the database add-on helps with backups, but you decide the retention rules. In SaaS the provider stores the data, yet you remain responsible for deciding what goes in, who can see it, and how to get it out. Always ask, before signing up for a SaaS product: “If I leave, can I export my data in a usable form?”

No model is best for everything. Each one trades something for something else.

IaaS

PaaS

SaaS

How you pay in each model

Money works differently on each floor of the building. With IaaS, you pay for the resources you switch on, usually counted by the second or the hour: machine time, disk space, and the amount of data that leaves the provider’s network. Providers also offer discounts if you promise to use a steady amount for one or three years, or cheaper “spare capacity” machines that can be taken back with short notice.

With PaaS, you usually pay for the size and number of running application copies, plus add-ons such as databases. The price is simple to read, but it often includes a premium for the work the platform does for you. With SaaS, you pay a flat fee per user per month, often with tiers that unlock more features. The invoice is easy to predict, yet it grows every time you add a person, so a large company should review its seat counts regularly.

The key habit is to compare the total cost, not just the line on the bill. A cheap machine that needs a full-time engineer to look after it may cost more than an expensive platform that needs nobody.

The trade-off triangle

Three forces pull against each other: control, convenience, and cost. IaaS gives you the most control but demands the most work. SaaS gives you the most convenience but the least control. PaaS sits in between. Cost depends on scale: at a small size, the convenient options are cheaper because you do not need a big operations team. At a very large size, the raw options can be cheaper because you can tune them to your exact needs.

The cloud is not automatically safe or unsafe. It is safe when both sides do their part.

The shared responsibility model

Cloud providers describe security as a partnership. The provider secures the cloud itself: the buildings, the hardware, and the basic software that runs everything. The customer secures what they put in the cloud: their data, their accounts, and their settings. The line between the two moves as you go from IaaS to SaaS, exactly as the table in Chapter 5 shows.

The most important protections

Who holds the keys

Encryption turns readable data into scrambled data that only a secret key can unlock. In most cloud services the provider manages the keys for you by default, which is simple and safe for many uses. For stricter needs, providers let you create and control your own keys inside a special protected service, so you can switch off access to your data by disabling the key.

Think of a safe-deposit box at a bank. The bank holds the vault, but you hold the key to your own box. The more sensitive the contents, the more you want to be the one holding that key and the less you want to trust a copy lying around somewhere. Whichever approach you choose, keep keys and passwords out of your source code and out of places where many people can read them.

What usually goes wrong

Most cloud breaches are not caused by the provider’s walls being broken. They are caused by misconfiguration: a storage bucket left open to the public, a password left at its default, an access key pasted into a public code site, or a firewall rule that is too wide. In 2019, a large bank in the United States, Capital One, suffered a major data theft after an attacker took advantage of a misconfigured web application firewall on its AWS setup. The cloud itself was not broken. A setting was wrong.

Security in each model

• IaaS: You protect the operating system, the network rules, the software you installed, and your data. This is the largest list.
• PaaS: You protect your code, your secrets (passwords and keys), your data, and who may deploy to the platform.
• SaaS: You protect user accounts, permissions, sharing settings, and connected third-party apps. Many SaaS leaks come from files shared with “anyone with the link.”

You cannot fix what you cannot see. Monitoring is how you keep an eye on a system you do not physically touch.

Three kinds of signals

Metrics are numbers measured over time, such as how busy the processor is or how many requests arrived per minute. Logs are written records of events, such as “user logged in” or “payment failed.” Traces follow a single request across many services so you can see where time was spent.

The four golden signals

Google’s site reliability engineers popularized four simple signals that tell you whether a service is healthy. They apply to almost any system.

The fourth signal is saturation, which means how full your resources are. A server that is ninety-five percent busy has no room for a surprise.

The flow of monitoring data

flowchart LR
    Src["Apps, machines, platform, SaaS audit logs"] --> Col["Collectors and agents"]
    Col --> Store["Log and metric storage"]
    Store --> Dash["Dashboards"]
    Store --> Rules["Alert rules"]
    Rules --> Pager["On-call engineer"]
    Pager --> Fix["Investigate and fix"]

What you can watch in each model

• IaaS: Everything. Install agents on your machines, watch disk space, memory, processor use, network traffic, and operating system logs. Tools like Amazon CloudWatch, Azure Monitor, and Google Cloud Monitoring help.
• PaaS: Application-level signals. You see request times, error rates, and application logs, but not the machine underneath.
• SaaS: Very little of the inside. You rely on the provider’s status page, uptime promises (called service level agreements, or SLAs), and audit logs that show who did what in your account.

Setting goals: SLIs, SLOs, and SLAs

Numbers are only useful when you know what a good number is. Reliability teams use three related terms. A service level indicator, or SLI, is something you measure, such as the share of requests that finish in under half a second. A service level objective, or SLO, is the goal you set for that measure, such as “ninety-nine point nine percent of requests are fast enough.” A service level agreement, or SLA, is the formal promise a provider makes to customers, often with refunds if it is broken.

An SLO gives your team a shared definition of “good enough.” If you are well inside the goal, you can take risks and ship new features. If you are close to missing it, you slow down and fix reliability first. When you buy SaaS, read the provider’s SLA with care, because it tells you what you can count on and what you must plan for yourself.

Do not forget cost

Money is also a metric. Cloud bills grow quietly, so set budgets and alerts. Most providers can send a warning when spending crosses a limit you choose. Tagging every resource with a team name or project name lets you see who is spending what, which turns a confusing bill into a helpful map.

A pattern is a proven recipe. An anti-pattern is a mistake so common that it earned a name.

Patterns that work

The stateless idea deserves a closer look. A stateless server does not remember anything about you between requests. All memory lives in a shared database or cache. That means any copy of the server can serve any visitor, so adding or removing copies is easy. It is like a bank with many identical tellers who all read from the same customer records, rather than one teller who keeps your file in a private drawer.

Anti-patterns to avoid

These habits separate calm cloud teams from stressed ones.

Habits worth building

Common mistakes

• Leaving storage open to the public. Always check sharing settings after creating a bucket or a shared folder.
• Believing the provider backs up everything for you. Many SaaS tools keep data safe from hardware failure, but not from your own mistake, such as deleting a folder. Ask what restore options exist.
• Using one giant account for everything. Separate production from testing so a slip in testing cannot touch real customers.
• Choosing by fashion. Picking a tool because it is popular, not because it fits the need.
• Ignoring data location. Placing personal data in a region that breaks a legal rule.
• Skipping the cleanup. Forgetting old test machines, disks, and snapshots that keep costing money.

Real companies show how the three models are chosen and mixed in practice.

A typical growth story

Picture a small company that starts as three friends with an idea for a delivery app. On day one they use SaaS for email, documents, chat, and accounting, because they have no time to run any of that. When they build their product, they use a PaaS so they can ship quickly. As they grow to millions of users, they start using IaaS pieces for special needs: custom databases, heavy data processing, and tighter cost control. Along the way they keep using SaaS for everything that is not their core product. Most real companies end up with a mix of all three.

The industry has added many “as a Service” flavors. Knowing them helps you read cloud menus with confidence.

More flavors of “as a Service”

These sit between the big three. For example, FaaS and CaaS are platform-like, because the provider hides the machines. A managed database is a small piece of PaaS that you attach to IaaS or PaaS applications.

A simple way to choose

When facing a new need, ask a few questions in order. The first answer that fits usually points to the right layer.

flowchart TD
    Start["A new need appears"] --> Q1{"Does a ready-made product already do the job?"}
    Q1 -- Yes --> SaaS["Choose SaaS"]
    Q1 -- No --> Q2{"Do you need control over the operating system or special hardware?"}
    Q2 -- Yes --> IaaS["Choose IaaS"]
    Q2 -- No --> Q3{"Are you building custom software your team will maintain?"}
    Q3 -- Yes --> PaaS["Choose PaaS"]
    Q3 -- No --> SaaS

Quick answers to the questions people ask most.

The whole guide in a few lines.