As a solutions architect, I talk regularly to developers and architects about IaaS, PaaS, and SaaS. These terms, which are relatively new, can sometimes be confusing so I’d like to give a brief description of what they are and how they differ from each other.
As shown here, IaaS, PaaS, and SaaS stand for infrastructure, platform and software as a Service, respectively. The core idea behind ‘aaS’ is that you can focus on building products and services critical to your business and let other companies build and manage non-core services you need, whether as part of your own offering or just to run your business.
These days, you can take pretty much add ‘aaS’ to anything, like “data” (DaaS) and “integration platform” which introduces the potentially confusing “iPaaS” which differs from both IaaS and PaaS! In the last few years, new businesses have popped up providing X, whether it be a product, application, feature or anything really, as a service to other businesses or consumers.
Before we dive into what these 3 terms mean, let’s take a step back and look at how we got here. Life was simple when all developers had to worry about were monolithic applications running on-premises. As a company, you would either have your own datacenter or rent some space at a datacenter managed by another company. Your networking and sysadmin teams would make sure all the servers were properly connected and working for your developers to use. Your developers would build robust and scalable applications (hopefully) that got deployed to your servers. Simple, right?
Most mid-sized business and large enterprises, still manage their own servers and datacenters, but are adopting the cloud. For almost a decade most companies have realized they don’t want to be in the business of managing their own infrastructure (servers/datacenters) and would rather have someone else, such as Amazon or Google, do it for them. Startups these days are going straight to the cloud, which allows them to be extremely flexible and scalable amongst other things. This has led cloud providers such as AWS and GCP to provide you with servers and manage them for you – that’s infrastructure as a service!
For example, you can easily spin up Solace PubSub+ Event Broker software on a linux server using an Amazon AMI in less than a minute. Compare this to having to buy a server, set it up, install it in a datacenter, and deploy software on it. Depending on the size of the company, this can take weeks, if not months.
As companies started adopting IaaS and migrating to the cloud, it became apparent that it wasn’t so easy. A key benefit of the cloud is elasticity. It’s easy to spin up servers when demand is high and shut them down when demand is low, but, developing applications for your limited servers in your own datacenter is one thing. Developing applications to run in the cloud where your application might be deployed to hundreds of servers on peak days like Black Friday, accessible by way of the Internet or WAN links, might not be as stable as it is in your own private datacenter.
All of this came with a lot of overhead for developers, and for DevOps team which now had to build and manage cloud-native applications. This led to platform as a service which lets developers develop cloud-native applications and manage the overhead associated with orchestrating them. Popular PaaS offerings include AWS Elastic Beanstalk, Pivotal Cloud Foundry, Kubernetes and OpenShift. I recently blogged about how to deploy Solace’s broker in OpenShift.
As cloud migration has picked up, it has further fueled the build vs buy debate. Every company is faced with the option to either build something themselves and hence, have complete control over it or buy it from another company so they can focus on its core business at the cost of control. Additionally, while you might have the resources to build the product initially, you still have to dedicate significant resources to maintain and upgrade the product going forward. As a consequence, more and more companies are realizing that they would rather buy non-core products/software from other companies and focus on their core business. For example, you can use Solace Cloud to spin up a PubSub+ Event Broker without needing any hardware and have it managed by Solace.
The main difference between IaaS, PaaS, and SaaS is how much they abstract away from end-users. The end product is an application that you want to use. For that to happen, you need to manage: datacenters, servers, networks, virtualization, operating systems, runtime, storage, middleware, data, applications, and monitoring.
Here is a useful table which shows which parts are being abstracted away from the end-user in each model:
With so many options, it can be a little daunting to decide which one is the best for your company. Thankfully, you don’t have to pick just one. You can go with a hybrid model where your core applications will run on-prem in your own datacenter and the rest of your in-house applications will run on a PaaS such as OpenShift. You might also decide to have some database services run on cloud such as AWS Redshift. Finally, you might want to limit all your vendor software, such as HR/payroll management software (i.e. Workday), monitoring tools (i.e. New Relic), and event brokers (i.e. Solace), to SaaS.
Picking the right model comes down to how much flexibility you want and how little you want to manage. If a product is core to your business and you need to heavily customize it, then going with a SaaS model is not the right option. However, there is no need to have your own convoluted HR/payroll management system when a generic SaaS solution would suffice. Finally, you have to consider the sensitivity of these applications and the data they manage. Some applications manage “crown jewel” processes and information that you won’t want to trust to a SaaS.
As you can see, there are a lot of similarities and differences between IaaS, PaaS, and SaaS. If you are a developer, you must be familiar with all three and how they differ. As an architect, you may be responsible for deciding which model, or hybrid approach, is right for your company based on your requirements, and resources. Fortunately, you can pick which model works best for you for each of your applications. I hope I’ve helped you understand a little bit better which one might be right for you.