Service models: IaaS, PaaS and SaaS

When Jordan first looked at the cloud providers' websites, the number of services was overwhelming. AWS alone lists more than two hundred, and Azure and Google Cloud are not far behind. The way through the list is to sort services by how much of the work the provider takes on and how much is left to the customer. That sorting gives the three classic service models from the NIST definition: infrastructure as a service, platform as a service and software as a service, usually shortened to IaaS, PaaS and SaaS.

Each model draws the line between provider and customer in a different place. Choosing a model is really choosing how much control you want and how much work you are willing to do. More control means more responsibility; less responsibility means accepting the provider's choices. Ridgeline already uses all three models without having named them, and the wholesale site will use at least two.

The stack of responsibilities

Any running application depends on a stack of layers. At the bottom are the physical data center, its power and cooling, and the network that connects it. Above those sit the physical servers, storage and network equipment, then the virtualization layer that divides them into virtual machines. Each virtual machine runs an operating system. On top of the operating system sits the runtime and middleware, such as the Python interpreter, a web server or a database engine. Then comes the application itself, and finally the data and the user accounts that the application holds.

On premises, the organization manages every one of those layers. In the cloud, the provider takes over the bottom layers, and the service model decides how far up the provider's responsibility reaches. The diagram below is the most common picture in cloud training, and it is worth memorizing.

Look at the top layer in every column. Whatever the model, the customer remains responsible for its own data and for who has access to it. A SaaS provider runs the whole application, but if a Ridgeline employee shares a spreadsheet of customer addresses with the whole internet, that is still Ridgeline's problem.

Infrastructure as a service

With IaaS, the provider supplies the raw building blocks: virtual machines, block storage disks, virtual networks and load balancers. The customer chooses the operating system, installs and patches it, installs the runtime and the application, and configures everything. IaaS feels most like owning servers, except that the hardware is someone else's and you can create or delete it in minutes.

IaaS is the right choice when you need full control: a particular operating system version, software that must be installed in a specific way, or an existing application moved from on premises without changes, which is often called lift and shift. The cost of that control is work. Somebody must apply security updates to every virtual machine, monitor its disk space, configure its firewall and back it up. The main IaaS compute services are Amazon EC2, Azure Virtual Machines and Google Compute Engine.

Platform as a service

With PaaS, the provider also runs the operating system and the runtime. The customer brings application code and data, and the platform handles servers, patching, scaling and often load balancing. Jordan could hand the wholesale application's Python code to a PaaS and let the platform worry about which servers run it.

PaaS is attractive for small teams because it removes most of the maintenance work. Nobody at Ridgeline wants to spend Sunday mornings patching operating systems. The trade-off is reduced control: you must accept the platform's supported languages and versions, its limits on memory and run time, and its way of doing things. Moving an application from one PaaS to another can take real effort, which is called lock-in. Examples include AWS Elastic Beanstalk, Azure App Service and Google App Engine, and managed databases such as Amazon RDS, Azure SQL Database and Google Cloud SQL are usually counted as PaaS too, because the provider runs the database engine and the customer only manages databases, tables and users.

Software as a service

With SaaS, the provider runs a complete application and the customer simply uses it, usually through a web browser or a mobile app. The customer configures settings, manages user accounts and owns the data, but never sees a server. Email services such as Microsoft 365 and Google Workspace, accounting packages, customer relationship management systems and Ridgeline's own point-of-sale and online shop platforms are all SaaS.

SaaS involves the least technical work and the least control. If the vendor changes a feature, the customer gets the change. If the vendor has an outage, the customer waits. SaaS is usually priced per user per month, which makes costs predictable. For most common business functions, from email to payroll, SaaS is the default choice for a small business, and building your own would make little sense.

The everyday comparison

A popular way to remember the models is the pizza comparison, adapted here for coffee. Brewing at home from beans you roast yourself is on premises: you own the roaster, the grinder, the machine and the cups. Buying Ridgeline's roasted beans and brewing them at home is like IaaS: someone else did the heavy industrial part, but you still grind, brew and clean up. Ordering a coffee to take away is like PaaS: the cafe runs the equipment and you just choose what you want and carry it. Sitting down in the cafe and being served is like SaaS: everything is handled for you, and you only decide what to order and who to share it with.

Like all comparisons it breaks down if pushed, but it captures the essential point: each step up hands more of the work, and more of the decisions, to someone else.

More things as a service

The success of the three main models produced many more acronyms. Functions as a service, or FaaS, runs small pieces of code in response to events, such as a new order arriving, and charges only for the milliseconds the code runs; lesson 9 covers it under the name serverless computing. Containers as a service, sometimes CaaS, runs packaged applications called containers without managing servers. Database as a service, storage as a service and desktop as a service describe themselves. Backup as a service and disaster recovery as a service handle copies of data and standby systems. Security vendors sell firewalls and identity services as a service.

You do not need to memorize every acronym. The useful habit is to ask the question behind all of them: for this service, which layers does the provider run, and which do I run? Once you know that, you know what you must patch, monitor, back up and secure.

# Which layers does the customer manage under each model?
LAYERS = ["facilities", "hardware", "virtualization", "operating system",
          "runtime", "application", "data and access"]
PROVIDER_UP_TO = {"on premises": -1, "IaaS": 2, "PaaS": 4, "SaaS": 5}

for model, top in PROVIDER_UP_TO.items():
    customer = LAYERS[top + 1:]
    print(f"{model:<12} customer manages {len(customer)} layer(s): {', '.join(customer)}")

on premises  customer manages 7 layer(s): facilities, hardware, virtualization, operating system, runtime, application, data and access
IaaS         customer manages 4 layer(s): operating system, runtime, application, data and access
PaaS         customer manages 2 layer(s): application, data and access
SaaS         customer manages 1 layer(s): data and access

LAYERS = ["facilities", "hardware", "virtualization", "operating system",
          "runtime", "application", "data and access"]
PROVIDER_UP_TO = {"on premises": -1, "IaaS": 2, "PaaS": 4, "SaaS": 5}

def manager(model, layer):
    # find the layer's position and compare it with PROVIDER_UP_TO[model]
    return "customer"

print(manager("PaaS", "operating system"), manager("IaaS", "operating system"))

Choosing a model for the wholesale site

Jordan and Sam listed what the wholesale site needs: a small web application written in Python, a database of customers, prices and orders, storage for invoices as PDF files, and sign-in for wholesale customers. They then went through each piece, asking what model would give enough control with the least maintenance.

For invoicing and email they chose SaaS without much discussion: Ridgeline already uses a SaaS accounting package that can produce invoices, and Ridgeline's email is SaaS. For the database they chose a managed database service, which is PaaS, because Sam did not want to patch and back up a database server himself. For the application they considered IaaS, a virtual machine Jordan would configure, against a platform that runs Python code or containers. They chose a container platform, covered in lesson 9, because it gives Jordan control over the Python version and libraries while leaving the servers to the provider. Only one piece remained a virtual machine: a small server to receive data from Kai's roast logger, because the logger's software needs a particular operating system setting.

The result is typical. Real systems are rarely pure IaaS or pure SaaS; they combine models, choosing for each part the model that gives just enough control. A common rule of thumb is to prefer SaaS, then PaaS, then IaaS, moving down only when the higher model cannot do what you need.

def saas_monthly(users, base, per_user):
    return 0

def break_even_users(base, per_user, build_monthly):
    # smallest users where saas_monthly(...) > build_monthly
    return None

print(saas_monthly(12, 40, 9), break_even_users(40, 9, 180))