Cloud Migration: Understanding IaaS vs PaaS vs SaaS

One of the most intuitive ways to understand cloud service models is the pizza analogy. Imagine you want to eat pizza. You have four options, each representing a different level of effort and control:

On-premises (make everything yourself): You grow the tomatoes, make the dough, build the oven, and cook the pizza. You control every aspect, but you also do all the work. In IT terms, this means owning and managing your own servers, storage, networking, operating systems, middleware, and applications in your own data centre.

IaaS (ingredients provided): Someone provides the ingredients and the oven, but you still assemble and cook the pizza yourself. In IT terms, the cloud provider gives you virtual machines, storage, and networking. You manage the operating system, middleware, runtime, and applications.

PaaS (kitchen provided): You walk into a fully equipped kitchen with ingredients ready. You just need to add your own toppings and recipe. In IT terms, the provider manages the infrastructure, operating system, and runtime. You deploy your application code and data.

SaaS (pizza delivered): The pizza arrives at your door, ready to eat. You have no control over the recipe, oven, or ingredients, but you do not need any of that. In IT terms, the provider manages everything. You simply use the software through a web browser or app.

IaaS provides virtualised computing resources over the internet. The provider manages the physical data centre, networking, storage hardware, and hypervisor layer. You get virtual machines that you can configure with any operating system, install any software on, and manage as if they were physical servers, but without the capital expense of buying hardware.

Common IaaS examples include Microsoft Azure Virtual Machines, Amazon EC2, and Google Compute Engine. You are responsible for patching the OS, configuring firewalls, managing backups, and maintaining the applications running on those VMs. IaaS gives you the most control but also the most operational responsibility.

IaaS is billed primarily on a pay-as-you-go basis, charged by the hour or second of compute time, gigabytes of storage consumed, and data transferred. You can reduce costs with reserved instances (committing to one or three years) or spot/preemptible instances for workloads that can tolerate interruption.

PaaS provides a managed platform for developing, running, and managing applications without the complexity of maintaining the underlying infrastructure. The provider handles the operating system, runtime, middleware, and scaling. You focus on writing code and managing your data.

Examples include Microsoft Azure App Service, AWS Elastic Beanstalk, Google App Engine, and Heroku. PaaS offerings often include built-in features like auto-scaling, load balancing, SSL certificate management, and deployment pipelines, significantly reducing operational overhead. Developers can deploy code directly from a Git repository and let the platform handle the rest.

PaaS is ideal for organisations that want to focus on application development rather than infrastructure management. However, it comes with trade-offs: you have less control over the underlying OS and runtime versions, and some legacy applications may not be compatible with the platform's constraints. There is also a risk of vendor lock-in if your application relies heavily on provider-specific services.

SaaS delivers fully managed software applications over the internet. The provider handles everything: infrastructure, platform, application code, updates, security patches, and availability. Users access the software through a web browser or thin client, typically on a subscription basis.

Examples include Microsoft 365, Salesforce, Google Workspace, Xero, and Slack. SaaS eliminates the need for installation, maintenance, and infrastructure management entirely. Updates are rolled out automatically by the provider, ensuring all users are always on the latest version.

A critical concept in cloud computing is the shared responsibility model. Security and management responsibilities are divided between the cloud provider and the customer, and the split varies by service model. Understanding this division is essential for avoiding gaps in your security posture.

With IaaS, the provider secures the physical infrastructure, but you are responsible for the OS, network configuration, identity management, application security, and data protection. With PaaS, the provider also manages the OS and runtime, so your responsibility narrows to application-level security and data. With SaaS, the provider manages almost everything, but you remain responsible for user access management, data classification, and account security (such as enforcing MFA).

When moving workloads to the cloud, there are three primary migration strategies, often called the "three Rs":

Lift-and-shift (rehost): Move the existing application to IaaS with minimal changes. The application runs on a cloud VM instead of an on-premises server, but the architecture remains largely the same. This is the fastest migration approach and works well for getting out of an ageing data centre quickly, but it does not take advantage of cloud-native features like auto-scaling or managed services.

Re-platform: Make targeted optimisations during the migration without changing the core architecture. For example, you might move a web application to an Azure VM but replace the self-managed SQL Server database with Azure SQL Database (a PaaS service). This approach captures some cloud benefits such as managed backups and automatic patching without a full rewrite.

Re-architect (refactor): Redesign the application to be cloud-native, typically breaking a monolithic application into microservices, using serverless functions, managed databases, and container orchestration. This provides the greatest long-term benefits in scalability, resilience, and cost efficiency, but requires the most development effort and time.