Cloud models, and where a server workload lives

Why this matters

Not every server an administrator looks after is in their own building. Some run as virtual machines in a cloud provider's data centre, some services are bought complete from a provider, and many organisations run a mixture. The choice of where a workload lives changes what the administrator is responsible for, how it is paid for, and what can go wrong.

This lesson covers the service models, which describe how much of the stack a provider runs, the deployment models, which describe who shares the infrastructure, the financial difference between buying servers and renting them, the shared responsibility model that divides security duties, and what changes in day-to-day administration once a workload moves.

The lesson

IaaS, PaaS and SaaS, and who manages which layer

A server workload is a stack of layers: the physical facility and hardware, virtualisation, the operating system, the runtime and middleware, the application, and the data. The service models describe how many of those layers the provider manages.

• Infrastructure as a service (IaaS) provides virtual machines, storage and networking. The provider runs the facility, hardware and hypervisor; the customer installs, patches and manages the operating system and everything above it. It is the closest to running your own server, and the model most server work moves to. Examples include virtual machines in AWS EC2, Azure or Google Compute Engine.
• Platform as a service (PaaS) provides a managed environment to run code or data in: a managed database, or an application platform. The provider also manages the operating system and runtime; the customer manages the application and its data. There is no server to patch, and also less control.
• Software as a service (SaaS) provides a complete application, such as hosted email or office software. The provider manages everything except the customer's data, users and settings.

A useful rule: the further from IaaS, the less the customer maintains, and the less they can change.

Public, private, hybrid and community clouds

The deployment models describe who the infrastructure is shared with.

• A public cloud is run by a provider and shared by many customers, each isolated from the others. It offers enormous capacity with no hardware to buy.
• A private cloud serves one organisation, either in its own data centre or hosted for it. It gives the self-service, on-demand style of cloud with dedicated infrastructure and more control, at the cost of owning and running it.
• A hybrid cloud combines the two, connected so workloads and data can move between them. An organisation might keep sensitive systems in its private environment while using public cloud for websites or extra capacity at busy times, sometimes called cloud bursting.
• A community cloud is shared by several organisations with common needs, such as government bodies or healthcare providers subject to the same regulations.

Many organisations are hybrid without having planned it: servers on premises, email in SaaS, and a few virtual machines in a public cloud.

Capital against operating cost, and what moves between them

Buying servers is capital expenditure (CapEx): a large payment up front for equipment that is owned, depreciated over several years and sized for the peak load expected over its whole life. Much of that capacity sits unused for most of that time.

Cloud services are operating expenditure (OpEx): regular payments for what is used, with no purchase up front. Capacity can be added in minutes and removed when it is not needed, which is why cloud suits workloads that vary, or new projects whose size is unknown.

Neither is simply cheaper. A server that runs flat out for five years is often cheaper to own; the same workload rented around the clock can cost more over that period. Cloud costs also include things that are easy to overlook, such as storage that is never deleted, and egress charges for data transferred out of the provider's network. The cloud rewards workloads that are switched off or scaled down when idle, and punishes ones that are simply moved over and left running at full size.

The shared responsibility model

Moving to the cloud does not hand over responsibility for security. It divides it, and the shared responsibility model sets out the split.

The provider is always responsible for security of the cloud: the physical data centres, the hardware, the network and the virtualisation layer. The customer is always responsible for security in the cloud: their data, who has access to it, and how the services they use are configured.

The layers in between depend on the service model. With IaaS, the customer patches and secures the operating system, configures firewalls and security groups, and manages the applications. With PaaS, the provider takes over the operating system and runtime. With SaaS, the customer still manages user accounts, permissions and the data itself.

The line matters because many cloud breaches are not failures of the provider at all, but of the customer's side: storage left open to the public internet, weak administrator passwords without multifactor authentication, or a virtual machine that was never patched. The provider will not fix those, because they are not the provider's responsibility.

What changes for the administrator when a workload moves to the cloud

Moving a server to IaaS removes some jobs and changes others.

Gone: replacing failed disks and power supplies, firmware updates, rack space, cooling and cabling. The provider handles the hardware.

Still there: patching the operating system, backups, monitoring, user accounts and application support. A virtual machine in the cloud needs the same care as one on premises.

New or different:

• Management is through a portal, command-line tools and APIs, and access to that management plane is powerful: an account that can delete every server must be protected with multifactor authentication and least privilege.
• Networking is software-defined: virtual networks, subnets and security groups replace physical switches and firewalls.
• Cost is part of the job, tracked continuously, because an oversized or forgotten server keeps charging.
• Connectivity becomes a dependency: users and on-premises systems now reach the server over the internet or a VPN, so latency and the link itself matter.
• Backups are not automatic. The provider keeps the platform running, but protecting the customer's data remains the customer's responsibility, as the backup lessons later in the course cover.