Cloud Computing Fundamentals: IaaS, PaaS, SaaS and Shared Responsibility

A physiotherapy clinic has run on one tower server in a back-room cupboard for six years. It hosts the appointment website, a patient database and the shared drive. Last month the cupboard overheated, the website went offline for a day and nobody on staff knew how to restore the database. The owner now says, "Put it in the cloud." That sentence hides four very different decisions, and this lesson is about telling them apart.

What "cloud" actually means

Cloud computing means renting computing resources (servers, storage, databases, networking, software) over the internet from a provider who runs the hardware in large data centres, and paying for what you use. The definition that most standards bodies converge on lists a handful of characteristics, and it is worth knowing them because they explain why the cloud differs from simply "someone else's server".

• On-demand self-service: you create a server or database yourself, in minutes, without filing a purchase order.
• Elasticity: capacity can grow and shrink with demand instead of being sized once for the busiest day of the year.
• Resource pooling: many customers share the provider's hardware, kept apart by software isolation.
• Metered billing: usage is measured, usually by the second, hour, request or gigabyte, and you pay for it.
• Broad network access: everything is reachable over standard network protocols, which is also why security matters so much.

Three service models: how much do you manage?

The famous acronyms describe how much of the technology stack the provider takes off your hands. Imagine the stack as layers, from the building up to the data your patients see. The more layers the provider runs, the less you can customise and the less you must operate.

IaaS (Infrastructure as a Service) rents you virtual machines, disks and networks; you install and patch everything above the hypervisor. A virtual machine you log into is IaaS. PaaS (Platform as a Service) rents you a place to run your code: you upload an application and the platform handles servers, operating system updates and often scaling. A managed database service, where you create tables but never patch the database engine, sits in this layer too. SaaS (Software as a Service) is finished software you use through a browser: hosted email, a booking system, a payroll tool. You configure it but do not run it. The bottom row never changes: in every model your data and who may see it stay your problem.

The shared responsibility model

Every major provider describes the same split in different words. The provider is responsible for the security of the cloud: facilities, hardware, the virtualisation layer and the managed services' internals. You are responsible for security in the cloud: how you configure what you use, who you let in, and what you put there. The boundary moves with the service model, which is exactly what the table shows. On a virtual machine you must patch the operating system; on a managed database the provider patches the engine but you still decide who can connect to it.

Working through the clinic's decision

The clinic needs four things: staff email and calendars, an online booking site, a patient database and a shared drive for letters and scans. Rather than choose "the cloud" in one go, take each need and ask which model removes work the clinic is bad at. A short written record keeps the reasoning visible, and it is also exactly what you would put in a design document at work.

Need 1: staff email + calendar
  Option A: run a mail server on a rented VM (IaaS)
  Option B: hosted business email (SaaS)
  Choice : B. Nobody here should patch a mail server or fight spam filters.
  We still own: user accounts, MFA, who can read whose mailbox.

Need 2: online booking website (custom, small)
  Option A: VM running web server + app (IaaS)
  Option B: platform that runs our app code (PaaS)
  Choice : B. We write the app; the platform patches the OS and restarts it.
  Trade-off: less control over server settings; some platform lock-in.

Need 3: patient database
  Option A: database installed on a VM (IaaS)
  Option B: managed database service (PaaS)
  Choice : B. Backups, patching and failover are provider features.
  We still own: schema, who can connect, encryption settings, data retention.

Need 4: shared drive
  Choice : SaaS file storage with per-folder sharing rules.
  We still own: sharing links (default to "named people only").

Review point: re-check costs after 3 months; revisit PaaS limits if the app grows.

Notice what the clinic did not choose: renting virtual machines for everything, which would have recreated the cupboard server in someone else's building and kept all the patching work. IaaS is the right choice when you need control that higher layers do not offer, such as a special operating system, unusual software, or a lift-and-shift of an existing system you cannot change. For most small teams, the higher up the table they can go, the less they have to operate.

Cloud deployment models in one paragraph

The service models above are about what you rent. Deployment models are about where it runs. Public cloud is shared provider infrastructure (what people usually mean by "the cloud"). Private cloud is cloud-style infrastructure dedicated to one organisation, in its own data centre or hosted for it. Hybrid connects the two, for example keeping a regulated database on premises while the website runs in a public cloud. Multi-cloud uses more than one public provider; it is often chosen for resilience or negotiation but multiplies the skills and tooling you need.

Common mistakes

• Treating the cloud as a bigger cupboard. Rebuilding every on-premises server as a VM keeps all the patching duties and adds a monthly bill. Symptom: the team is busier after migration, not less busy.
• Assuming the provider backs up your data. Many services keep copies for their own resilience but do not restore a table you deleted by mistake unless you enabled backups. Symptom: a "we thought it was backed up" meeting after an accidental deletion.
• Confusing SaaS convenience with data ownership. Before adopting a SaaS tool, find out how you can export your data and what happens to it if you leave.
• Skipping access controls because "it is private". Resources reachable from the internet by default are found by automated scanners quickly. Symptom: unexplained traffic or login attempts in the first days.
• Using vendor-specific terms as if they were universal. Every provider names the same ideas differently; learn the concept first, then map the names.

How this shows up in real projects and interviews

Interview questions at this level are usually "explain IaaS, PaaS and SaaS with an example" and "what does shared responsibility mean?". A good answer gives one concrete example per model and states the boundary: the provider secures the cloud, you secure what you put in it. In real work, the model you choose per component is a recurring design decision: engineers often start at the highest layer that meets the requirement and only drop lower when they hit a limit. For how these building blocks combine into larger designs, see System Design.