An Unofficial Guide to Whatever-as-a-Service

If there’s one overwhelming trend in IT in the last decade it’s that no one wants to sell you anything anymore, they just want to rent it to you. Consequently, almost anything will run “-as-a-service” these days.

SaaS is commonplace as a term, but it’s been over-used to apply to basically anything you do “in the cloud.” In the last few years, other variations on the phrase have been creeping in: namely PaaS and IaaS, but there are many, many others, and some other variations that should exist, but don’t.

The basics are simple. But, like anything, nothing stays basic and there are…complications.

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.

At this level, we’re clearly “building” something. We’re working with code. We’re looping and we’re evaluating conditionals and we’re probably pushing the boundaries of a front-end developer and actual involving some server-side development logic. In some senses, this isn’t even “templating” anymore.

We’re building on Coredna in this sense, are we SaaS or PaaS? Clearly, Coredna exists as a discrete piece of software into which we authenticate and do stuff, but it also depends on a significant amount of code-building which we do outside the system.

I asked Sam Saltis, the founder of Coredna where he saw the system fitting in:

I see it as a SaaS platform. For me a PaaS still means that every site is a unique instance of business logic, sharing a common infrastructure. With Coredna we we have a common infrastructure like PaaS but we also have a common pre-built software layer that everyone uses.

In some senses, an argument could be made that this is PaaS, and Coredna is simply the top of the stack. It’s the thing that sits above Apache on the stack. It’s the final step in the “platform,” much like someone could argue that the ASP.NET MVC assemblies sit above IIS in a .NET platform. You have to ask the question, “how far do you have to develop the stack for the system to ‘graduate’ from PaaS to SaaS?”

(Beyond templating, I’m wondering when a SaaS system will take a deeper leap into scripting. There’s sandboxed JavaScript capabilities that are just begging to be put to use in allowing editorially scripted responses to events. I’ve even written one editorial scripting language – Denina – though it’s purely output-focused.)

And this is where we get to definitional bias: who decides where we draw the lines between the (1) infrastructure, (2) platform, and (2) software? Who decides where the “platform” ends?

There are a lot of systems that are easy to classify as SaaS, but are useless without a significant amount of site-building that looks an awful lot like programming. In these situations, the line between what’s the platform and what’s the software get blurry. Where do you draw the line between a piece of software and a code library?

In the end, something like Coredna sits in a weird space: it’s either “flexible SaaS” or “rigid PaaS.” How about something new – Framework-as-a-Service (FaaS)?

It’s clearly more constrained than a platform, but more configurable than simply software. Into this category, we might put other systems which support pseudo-development, like SharePoint Online (especially when combined with a development toolkit like Akumina) and Shopify, which you can manually template much like Coredna.

Complication: Component-as-a-Service

As the “as-a-service” suffix began to gain steam, we suddenly had vendors coming out of the woodwork laying claim to the model. I’ve seen:

• Content-as-a-Service

• Search-as-a-Service

• Information-as-a-Service

• Business-Process-as-a-Service

“As-a-service” has become a moniker for “anything you don’t own but you pay a subscription fee for.”

Many of these are things you might use in the building of something else. In this sense, they invert the above models. Instead of the subscription target being something you build “in” or “on,” the subscription target becomes a smaller component of a larger conceptual thing you’re building elsewhere.

Rather than a subscription being the over-arching framework, the subscription becomes a cog in a larger machine. Generically, we might call these things “Component-as-a-Service” (CaaS; because “Service-as-a-Service” sounds weird).

Let’s consider “Content-as-a-Service.” This is a suffix to which a number of headless CMS vendors are trying to lay claim. The idea is that content is a smaller part of a larger application, and you can abstract that away to a service.

I asked Artas Bartas over at Contentful if they considered themselves SaaS or PaaS, and this was his response:

I’d say Contentful is a SaaS offering. The way I see it, PaaS is a use-case agnostic platform that allows you build a wide range of applications without worrying about managing dependencies. Dev-focused SaaS platforms, on the other hand, are more selective in the types of use-cases they support and therefore, limit the range of applications you can build on top.

And this might be where we dip into the burgeoning world of “micro-services,” which is a paradigm of development whereby you divide your monolithic application into a bevy of tiny services, each doing one thing. Once you begin subscribing to these services, rather than building them, then you start looking around for “whatever-as-a-service.”

With Component-as-a-Service, we might be closer to fulfilling – on a grand scale – Eric Raymond’s dream of the Rule of Modularity from The Art of Unix Programming:

Developers should build a program out of simple parts connected by well-defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features.

Conclusion

For many years, a guy named Shiva Ayyadurai (who’s married to Fran Drescher, weirdly) has claimed that he invented email. In fact, he sued Gawker Media and won a sizable settlement because Gizmodo said that he didn’t. However, many people feel that the recently departed Roy Tomlinson invented email. The debate rages.

But here’s the thing: to decide who “invented email,” you have to decide what email is. The argument becomes one of definitions, not necessarily actions.

The concept of “email” exists on a spectrum of functionality, from some encoded characters moving from one computer to another, all the way through the huge, bloated email clients we have today. At what point along that scale of innovation could someone step back and say, “yep, there it is – that’s this thing called ‘email’ and I just invented it.” The definition of a thing presumes a minimum set of requirements necessary to achieve that thing. Who decides those minimums?

I have no doubt that Ayyadurai invented something, but opinions differ on exactly what that thing was. He clearly believes his innovation can be summed up by the label of “email,” but not everyone agrees. To some, more features and functionality were required to cross the “line of definition” that constitutes email.

And the same is true of “whatever-as-a-service.” Agreeing what “whatever” is can be tricky, so splitting hairs about what constitutes infrastructure, platform, or software is subjective – even more so when you add concepts like “component” and “framework,” as we discussed above. Different people have different “lines of definition,” and arguments can be made regarding which lines a particular vendor crosses or falls short.

So, asking a vendor whether or not their offering is IaaS, PaaS, SaaS, CaaS, or FaaS is basically soliciting an opinion of where they see their product fitting on a disputed range of functionality, based on how they intend for their customers to use it.

Whether or not the marketplace agrees with that assessment is another matter entirely.