The Big Three: IaaS, PaaS, and SaaS
First, let’s talk about the Big Three, which actually have official recognition from the National Institute of Standards and Technology (PDF) (NIST). Here they are, in increasing level of refinement/abstraction.
IaaS: Infrastructure as a Service. This is raw infrastructure – unadorned servers, load balancers, routers, firewalls, storage networks, etc. When you just fire up a fresh virtual server with nothing but an operating system, this is infrastructure. (And how do you pronounce this gem? The consensus seems to be “eye-azz” because the alternative is really awkward.)
PaaS: Platform as a Service. This is an environment pre-configured and intended to assist you in building a known thing. For instance, a company might advertise “CMS X Hosting,” with a preconfigured environment, ready with database services, all the right ports open, and a build job ready to deploy your stuff from source and produce an installation of CMS X. This is a platform, designed to let you build on it. The key is that you don’t need to care about the infrastructure – in many cases, you know nothing about the actual servers and storage that make it possible.
SaaS: Software as a Service. This is a vendor that delivers you the services of a piece of software. The most interaction you’ll likely have with it is to log into a web interface and do some configuration and maybe a little uploading. You interact with the software and know nothing about either the infrastructure or the platform.
Do you notice how those three definitions build on each other? Each level assumes the levels before it.
With IaaS, you’re the closest to the metal – you know about everything, and probably manually configured all of it (you nerd).
A PaaS environment certainly has infrastructure underneath it, but you’re abstracted away from all of it. You have all the tools to build the thing you want to build – whether it be an ASP.NET app, a Node app, an Episerver-powered website, whatever – but you don’t know the specifics of how that environment happens.
A SaaS environment is another level removed: you don’t even know how this magic software happens. There’s infrastructure, and a programming platform and environment, but you’re happily oblivious and you usually just click around an interface to achieve some goal.
In a conversation this week, Seth Gottlieb from Lionbridge helped put it in context like this.
A sysadmin can immediately relate to IaaS. They see the value and can be productive using it.
A programmer can immediately relate to PaaS.
A power user can immediately relate to SaaS.
At each level, the prior levels become like your parents’ sex life – you grudgingly concede that it exists in some form, but you really don’t want to know anything else about it and you would gladly pay money to not have to ever think about it.
Complication: Confusion of PaaS and SaaS
In the web development world, some of the stuff we refer to as “SaaS,” as actually “PaaS.” In general, we overuse the “SaaS” moniker.
The major push from vendors in the last few years is to get your websites in their environments, which means you build, but they host in a incubated environment designed specifically for their software. This is a platform on which you build stuff. These platforms have little or no value in their unadorned state.
There is SaaS in the CMS world, but it’s limited to systems that literally let you log in and interact with the environment as a software service. I’m thinking about systems like Squarespace and Wix. You don’t build in these environments. You simply use them.
And I’m wondering if this is the dividing line for PaaS and SaaS – do you build in it? The P in PaaS is “platform,” and a platform is a thing that supports another thing. If nothing ever sat on a platform, you’d wonder what it was for. So, if something is an environment in which we build, then it’s a platform.
Here’s an example of climbing up this ladder with Drupal:
IaaS: If you want a Drupal site, there’s nothing stopping you from getting a server at Amazon Web Services (AWS) and loading up Apache, MySQL, PHP, and whatever else you need, changing DNS and launching. You are now running on IaaS. AWS has provided the infrastructure, but you turned it into a platform and you loaded the software.
PaaS: Alternately, you could call up Acquia. They provide a platform called Acquia Cloud. This is a bunch of servers at AWS (you don’t care about the specific servers, remember, you just trust that there’s a bunch of them up there), and they’ve set them all up to run Drupal with a bunch of value-added stuff like search and really good dev ops and deployment models, which, with Drupal, can be tricky.
SaaS: Finally, if we step back in time a year, you could have used the now-defunct Drupal Gardens. These were preconfigured Drupal instances you could get by just creating an account and providing a credit card number. Naturally, there was a limited number of things you could do with them (they only had a handful of the most popular modules), and you couldn’t deploy any of your own code, but they were simple and quick.
(Related to this: Nasdaq just announced customized investor relation sites for its listed companies. Sign up for the service, and they’ll generate a custom, Acquia-hosted Drupal install, just for you. In effect, they have a SaaS product that stamps out PaaS environments which is recursive as hell.)
Finally, James Norwood from Episerver helpfully pointed out that differentiation between PaaS and SaaS it might come down to questions of tenancy: do you share your system with anyone else? If you don’t, then this is likely IaaS or PaaS. If you do, then it’s almost always SaaS.
It’s tough to share a building platform with anyone else because it’s easy to make a mistake and jack the environment up for everyone. Eventually, the vendor starts to segregate more and more, and the end of that line might be a completely sandbox, interfaced system which becomes multi-tenant SaaS.
Complication: Differentiating Between IaaS and PaaS
The big challenge for a lot of PaaS vendors is getting customers to understand the different between IaaS and their PaaS offerings. People are still in the mode of thinking about “hosting.” Basic hosting is infrastructure. But vendors are now “wrapping” hosting in a plethora of value-added services, which ostensibly bumps them up a notch to become a platform.
I talked to David Aponovich from Acquia, and he said this:
We see organizations investigating Drupal and Cloud and they’ll talk with Acquia and say, “So, we’ve decided to use Drupal over Sitecore and Adobe, but why do I need Acquia when I can just do a DIY on Amazon AWS?” And we say, well what about this, this and this, and they realize, “Oh, this isn’t just AWS infrastructure-as-a-service, there’s a lot more services and automation here – it’s a platform-as-a-service for my Drupal applications, not just services for infrastructure and hosting.” The development and a management services such as provisioning, deployment staging, and security are important.
Episerver has a PaaS product call the Digital Experience Cloud Service. Norwood articulates the benefits of it above and beyond “just” the IaaS that Azure offers:
At the end of the day, anyone can host a virtual machine on anyone’s public cloud (AWS, Azure, etc), and it will run, but it’s sort of just hosting in the old sense of the word. Episerver and many of our partners can sell you a license and then host and/or manage it for you on a public cloud, but that’s it.
With the approach Episerver invested in over two years ago now, we elected to go deep into the Microsoft Azure PaaS so we could unlock the benefits of the platform for customers as well, such benefits include elastic scalability, pay for use consumption, and application level SLAs above the infrastructure SLA. If your bet is to support every public cloud, as a vendor you get more reach, but if you go deep into the PaaS layer it’s the customer who benefits too.
That “crossing of the threshold” between IaaS and PaaS is something that vendors are having to sell people on, every day. Many people are still programmed to think in terms of simple hosting. It remains to be seen how well that definition changes.
As an integrator, I get a little annoyed with the “cloud” moniker, because it doesn’t mean anything, colloquially. In a strictly technical sense, “cloud computing” has a NIST definition (same link as above), but for most people, “cloud” just means “not my problem.”
At Blend, we host for lots of our clients. In this sense, we are as “cloud” as anything else because we make all their hosting problems go away. We host on infrastructure that we rent from AWS – pure infrastructure. But if we wrapped all that stuff in a bunch of Blend propriety stuff and created a gorgeous little incubator in which a website could thrive and grow, well, now we’re moving to a “platform.”
If you have “managed hosting,” that means someone else babysits it. Is that someone else the final value-add of the “platform”? Hosting yourself would be at the infrastructure level, but if someone else manages it for you and provides value-add on top of that (and you would hope they did, or else what would be the point), does the combination become a “platform”?
(There’s a much larger post here about how vendor PaaS platforms have encroached considerably on integrator’s service offerings, and there are some bad feelings as a result. But we’ll tackle that on another day.)
More fundamental to this particular complication is where we draw the line between infrastructure and platform. I remember getting servers back in the day with Plesk or CPanel loaded on them. These control panels managed dozens of other services on the machine – everything from FTP to SMTP. In this sense, did we have a platform?
Coming back to the idea of value-added services as the thing which moves us from infrastructure to platform, was all the stuff offered by CPanel- or Plesk-enabled servers enough to say we made that leap? They seem to think so – both their websites refer to their offerings as a “platform.”
Complication: Wedged Between PaaS and SaaS…Framework-as-a-Service?
Of course, you knew this would get blurry because it always does –
We build on platforms, but “building” is a vague term. We tend to think of building as having a completely self-contained codebase which we then push up to another environment. We even run these things locally, and when they’re running to go, we deploy them to some parallel environment.
But there are SaaS-ish (there’s always an “-ish”) systems that allow a limited amount of “building.” Take Coredna for example (yes, the capitalization is weird – it’s “Core D-N-A”). This is an ostensibly SaaS CMS system. I got a demo last week and I genuinely enjoyed what I saw.
Here was the best part –
Templating is not by configuration. This is not a “drag stuff around” system, like Squarespace or a Wix. In Coredna, you legitimately get templates written in Smarty, and you can use these to power your site. You can even point Coredna at your Git repo, and it will pull your templates from there, so you can work in an honest-to-goodness IDE.
This was refreshing to see, and I commend them for it.
More to the point: with an architecture like this, you get some form of pseudo-development or “building.” Smarty, for its part, supports looping and conditionals, which are two of the hallmarks of a logically complete language. Furthermore, Smarty knows if you’re fielding a GET or POST request, which means you could conceivably post forms back and do stuff accordingly.