Decrypting Buzzwords Series, Part 2: SaaS/PaaS/IaaS
With dramatically few exceptions, everything in the Cloud that anyone can interact with comes in forms of either Software as a Service (“SaaS”), Platform as a Service (“PaaS”), or Infrastructure as a Service (“IaaS”). Here’s how I look at it from a layered approach:
In the image above I take the unique approach of explaining each service by listing the things that aren’t needed with each.
IaaS
In the above picture, it’s listed that Infrastructure as a Service (IaaS), does not need either electricity nor a computer or hard drive. This is illustrated in my prior post about the Cloud in general. Infrastructure as a Service is typically used to build out software exclusively, meaning that the main end users of this service are generally developers.
For example, if I make a script that will push my computer to its limits (you can tell this if your computer slows down and you can hear the fan spinning), I can run the script on Amazon EC2 (a computer hosted at one of Amazon's computer warehouses), so my computer isn’t affected and I can continue to work without any limitations. An important point on this is if my script will take more than one computer of power, I’d need to “rent out space” on the appropriate amount of computers to run this script.
Imagine an app that sends emails, integrates, and stores data like Klaviyo. If any one computer tried sending emails to one million people at once, it’d need so much power it’d burn out. In order to send an email to that many users, for example it may take upwards of a hundred computers. This immediately would bring business problems for the application. Klaviyo would need to find a warehouse to store all of those computers, hire a large IT department to maintain and secure the computers, and pay the electricity bill for those computers. On top of that, if more emails need to be sent, Klaviyo would need to purchase even more computers to store in the warehouse. Instead of doing that, Klaviyo can just pay a company like Amazon Web Services to do all the heavy lifting for them, and frees up the company to work on the cutting edge features of its application.
PaaS
PaaS is mainly used by developers to create software without worrying about security issues or running into limitations on the computers they’re “renting” from the cloud (in IaaS, users only rent out a fixed quantity of computing power). An example of PaaS is AWS Lambda; this service manages the computer power needed by the end user.
For example, if I use IaaS for a website and expect 100 visitors a day, I pay a hypothetical rate of $100/day to “rent out” a computer to host the site. If 1000 visitors come on my site on a given day, my one computer won’t be able to support that volume, causing my site to crash. However, if I host a site on PaaS with Lambda, I pay purely based on the amount of computing power used. For example if my rate is $1 per visitor, and I have 100 visitors, I’ll pay $100. On the next day, if I have 1000 visitors, Lambda automatically adjusts the amount of computing power my site has access to in order to support the extra volume, and I pay $1000 for the day (these are hypothetical numbers; in reality this model makes Lambda cheaper than an IaaS service).
This case study from iRobot demonstrates what Lambda does in more detail. In 2015, iRobot released a vacuum that was connected to the internet through an associated app. This app at the time was hosted using IaaS (renting out computer space on Amazon’s computers rather than owning their own). On Black Friday, more users accessed their app than iRobot prepared for.
To visualize this, imagine iRobot rented out 100 computers, to handle 10,000 users accessing the app. On Black Friday, instead of 10,000 users accessing the app, 20,000 users did. This overwhelmed the 100 computers and they did not have a backup plan, which caused perceived technical issues.
In order to prevent that from happening again, iRobot moved to a PaaS service called Lambda. With Lambda, they no longer need to “rent out” the 100 computers to handle a specific amount of users like the above example. It automatically finds available computer space for iRobot and runs the program on top of it.
This way, they never again have to worry about slowing down or renting out an appropriate amount of computers.
SaaS
SaaS, which is the most well-known of the three, is the whole application as a service. Not only is the computer and database hosted somewhere else, but the user interface and entire platform is built out by the vendor (the vendor which owns the platform is often a different organization than the organization hosting the computers and databases that run the platform).
The best way to describe this is by comparing two applications that just about everyone knows, Google Sheets and Microsoft Excel. One is SaaS and one is, in technical terms, a self-hosted application.
Let's use the graphic in this article to go over what each does and doesn’t have to mark each as either SaaS or a self-hosted application.
Excel:
IaaS: ❌
Accessing Excel is done from the user’s own computer, not someone else’s, and saved in the user’s applications folder.
PaaS: ❌
Saving files in Excel means users are storing data in their own hard drive and taking up space on their computer.
SaaS: ❌
The user interface is saved in the application on the users computer. What really makes it obvious that Excel is not SaaS is that it’s not accessible from the internet, only inside of the application (This is for traditional Excel, Office 365 is considered SaaS).
Sheets:
IaaS: ✅
Accessing Sheets is done through a web browser, indicating that this is hosted via the internet, rather than the user’s own computer.
PaaS: ✅
Files are saved inside the web browser, which indicates that the user’s own computer is not responsible for storage.
SaaS: ✅
The user interface is available through the web browser and the authentication methods are handled by the software. This indicates that this software is fully supported by the vendor on someone else’s computer (in the cloud).
This is a simplification of what’s happening in the backend, but it’s an accessible representation of how this all works. To level up even further from a technical perspective, I suggest reading Amazon’s own documentation for a deeper dive.