What are IaaS, PaaS and SaaS?

Published in 2011, the US National Institute of Standards and Technology (NIST) defined cloud computing and set out three "service models": Infrastructure as a Service, Platform as a Service and Software as a Service. Over the last 10 years, these have become standard terminology when talking about the cloud. But what do they actually mean?

What is Infrastructure as a Service (IaaS)?

The NIST states that Infrastructure as a Service (IaaS) provides "processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (eg host firewalls)."

Essentially, you're doing what you've always done, but doing it in someone else's data centre. In the IaaS model, you're creating a software-defined network and then launching servers in that network. Your responsibilities include patching the operating system, hardening the operating system, securing access to the hosts, paying any license fees (you may be able to rent the license fee by the hour as well and pay for it in your cloud bill), patching the application software and securely configuring the network. The cloud vendor is responsible for the underlying hardware.

The main benefit of IaaS is that you no longer have to guess how much capacity you need, or even buy any servers upfront. If you suddenly need more servers to deal with a seasonal burst of traffic, you can get them at the click of a button. There are other benefits as well:

1. Ease of experimentation: Your servers are no longer precious resources that are depreciated over several years, they are temporary resources. Stand up a virtual machine (VM), run an experiment and then tear it down again when you're done.
2. Automation: Access to these resources is achieved via API calls to the cloud vendor, which means they can be scripted. You can have a script that defines what your infrastructure looks like, so you can repeatably and reliably create the same infrastructure and then tear it down again. This is known as Infrastructure as Code (IaC).

Infrastructure services also typically include features such as auto-scaling, to automatically increase the size of your fleet of servers to meet increased demand, and then reduce the size of the fleet when demand drops again, and services around DNS resolution and connecting your on-premise data centre to your cloud network.

The payment model for compute IaaS is typically by the hour (or, depending on the vendor and operating system, by the second). You will also be charged for data transfer in various dimensions. Storage is typically charged per GB.

What is Platform as a Service (PaaS)?

According to NIST, Platform as a Service (PaaS) deploys "onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment."

The key difference between IaaS and PaaS is your level of control and responsibility. You have less control but you also have fewer responsibilities; the vendor is responsible for patching operating systems, and so on.

I think that at the time the NIST definition was published, the intent of PaaS was to cover services like Digital Ocean, Google App Engine and Azure Web Apps, however, the usage of the term PaaS seems to have shifted somewhat. Say your application needs a database behind it, which I'm sure it does. You could use IaaS and stand up a server, install your database software of choice on it, and use it. And you'd be responsible for patching the operating system and the database engine, etc. Or you could just say, "Dear cloud vendor, could you give me a database engine, please?" and have them be responsible for all those things. Some people will say that what I'm actually describing here is DBaaS (DataBase as a Service) but as that's not a part of the NIST definition, and nor indeed are any of the plethoras of XaaSes, I tend to lump it in with PaaS – the cloud vendor is providing you with platform services.

What is Software as a Service (SaaS)?

The NIST definition of Software as a Service (SaaS) states that the "capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (eg web-based email) or a program interface. The consumer does not manage or control the underlying cloud infrastructure including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings."

Once again, the key difference here is your level of responsibility and control. You have absolutely no access to or control over the underlying infrastructure, but therefore absolutely no responsibility for that infrastructure. Your responsiblity is to control who is allowed to do what, some configuration settings and possibly some customisations if the SaaS allows for those.

I think most people see this as referring to end-user software as a service, like Office 365 and Salesforce. But let's broaden that definition to include things like database software as a service, or message queueing and brokering software as a service, or authentication software as a service, or whatever-as-a-service and see where it takes us.

Payment for SaaS is typically per user, for things like O365, or per API call for things like pre-trained machine learning models.

Going back to my database as an example, I effectively have three options:

1. Go with IaaS and spin up a virtual machine in the cloud and install my database software of choice. I am responsible for everything, including making the database highly availabe or fault tolerant, back-ups, etc. All the "undifferentiated heavy lifting" that everyone who owns a database has to do, but it doesn't differentiate me from my competitors. I'm also paying for it by the hour, every hour, 24/7.
2. Use a PaaS database as a service, like Amazon RDS, Azure SQL or Google Cloud SQL, where the vendor stands up a VM for me and gives me limited access to it and gives me options like specifying back-up windows and making it highly available (with a standby server and auto-failover), meaning I can focus on things like optimising my queries and storage structures. As with IaaS, I'm paying for the database by the hour and possibly paying a little more.
3. Find a "fully managed" SaaS database that meets my needs and just use talk to it using the vendor's APIs. In this instance, I will effectively be paying for what I use, so a database sitting behind a line of business applications that's only in use from 9 to 5pm won't cost me anything when it's not in use (although it should be pointed out that I could "pause" or temporarily take offline IaaS and PaaS databases and save some money).

That third option is very attrative to me, because it means I don't have to worry about any servers at all and I should be getting very granular pricing. There's an increasingly popular buzzword doing the rounds right now – "repatriation" – where people are bringing their cloud workloads back on premise because it turned out it wasn't as cheap as they thought it was going to be. And that's because they're not embracing the full cloud mindset, they're hovering somewhere between IaaS and PaaS with maybe a little bit of SaaS. Utility pricing only works if you're switching stuff off when you're not using it.

The Cloud Native Maturity Model (CNMM)

Something I've come across recently is the CNMM. Set out in a recent book, Cloud Native Architectures by Arora et al, it talks about three axes of maturity:

• Cloud Native Services
• Application Centric Design
• Automation

Each axis is a continuum, which will continue to get longer as more vendors provide more features and services. On the Services axis, if you're using what the authors refer to as "building block services", which maps loosely to IaaS, you're at the start of the axis. If you're using what the authors refer to as "managed service offering", which I'm mapping to PaaS, you're further along the axis. And if you're using "advanced cloud native managed services", which maps to my definition of SaaS above, then you're well on the way to maturity.

What I like about this model is that keyword "maturity". No-one is saying that just using those building block services is wrong. Indeed, if you've got an entire data centre to migrate by next week, then just taking what you're doing on-prem and doing it in the cloud is probably your best option in the short term. But as your organisation becomes more mature in the cloud, it should be looking to move along that axis, start swapping out servers for managed services to truly unlock the benefits of the cloud. The Great Virtualisation Revolution was simply a case of shifting from bare-metal to virtual machines. The cloud revolution rewards a complete shift in mindset.

For completeness, the Application Centric Design continuum starts from using modern application design principles to microservice architecture, instrumentation, security, parallelisation and event-driven applications. The Automation axis starts at configuration management and goes through automated patch management, auto-scaling and monitoring all the things, out to cutting-edge services like AI-ops and predictive scaling.

If you're interested in stepping up your organisation's use and understanding of cloud services, get in touch. We also have a full range of cloud and virtualisation courses.