Infrastructure-as-a-Platform (IaaP), to join all the other "as a" acronyms that are difficult to keep straight. If technology could just hold still for a few years, everybody could get up to speed on all the terminology. Alas, that's not going to happen anytime soon. If you're new, or new-ish, to cloud services you're probably a bit muddy on what all the different "-as-a-Service" terms are. Want to know your SaaS from your PaaS and your IaaS?There's a new one born every minute. I don't mean the P.T. Barnum quote, I mean acronym. Today it seems to be
Here's a quick primer on the differences between Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS). Those who work in IT are likely to know what SaaS, PaaS, and IaaS are. But a lot of folks who encounter the "aaS" terms have had no introduction.
Software-as-a-Service (SaaS) has been around in one form or another for years. It just wasn't always called SaaS. For example, Webmail? It's SaaS, even if most people don't think of it as such. Note that, on occasion, you'll find "Storage-as-a-Service" but not often.
So what is it? SaaS is an offering, usually Web-based but not always, where a company provides a service like Webmail, customer relationship management (CRM), accounting, payroll services, collaboration or any other type of service in an on-demand fashion. This is in contrast to providing software as a "shrinkwrapped" solution or any other scenario where a customer buys or licenses software and runs it on their own computers.
With the SaaS model, you're basically buying or using the solution without having to tend to the software in any way. Fire up a browser, log in, and go. The development, maintenance, updates, backups and so on are the responsibility of the provider. The downside, of course, is that the development, backups, updates and so on are the responsibility of the provider. This means that you exchange the responsibility for those things and place them in the care of a vendor. If the vendor falls down on the job here, you may be out of luck – since the ability to handle those problems will be out of your control.
Another consideration is data portability. Can you get your data out of the vendor's solution and move it elsewhere? In the case of some SaaS, it's a Hotel California – you can check in any time you like, but you can never leave.
Here's a few good, and popular, examples of SaaS:
- Google Docs
- The 37signals suite – Basecamp, Highrise, Backpack and Campfire
- Salesforce customer relationship management (CRM)
The list goes on and on. Odds are if you're at all active online, you've used SaaS solutions. The next two are a bit newer, and you may or may not have encountered these.
Not quite as familiar as SaaS, but gaining in popularity, is the Platform-as-a-Service (PaaS).
Lots of developers and organizations want to write applications without having to worry about all the underlying infrastructure. For instance, Ruby on Rails and Django are enormously popular rapid application development frameworks. They allow developers to put up Web applications in a fraction of the time that it would have taken without those frameworks, in the bad old days of the early 2000's.
That's the good news. The bad news is that developers then had to worry about scaling the applications and managing hosting and all that. This gets very complex – you have to worry about how many servers to provide, how to handle load balancing, failover, managing the operating system that the software is deployed on. Security updates and dependencies for software – it can be a major headache.
To cut down on the complexity, some companies are now offering PaaS solutions that let developers target the platform they want without managing it themselves. For example, there's Heroku, which started with Rack compatible hosting but has now expanded quite a bit to add Python, Django and much more.
Not that PaaS removes all the headaches. Developers have to worry about how their applications are optimized to get the best pricing on services like Google App Engine.
The PaaS model started focusing on very specific platforms like Ruby on Rails, or PHP, but the providers are starting to expand to encompass a wider range of options. Engine Yard acquired Orchestra to add PHP support for example, and Google App Engine has been expanding its support as well. There's also Red Hat's OpenShift which offers Java, PHP, Python, Ruby and Perl.
Another reason PaaS is attractive is that it gives organizations much more flexibility in terms of moving away from the service. If you're using Salesforce or 37signals, you may not be able to easily pick up and leave. If you have a Ruby on Rails app, it's easier (though not entirely trivial) to move to another provider that provides Ruby on Rails. If you're using Google App Engine, you may have some Google-specific things that require rewriting or porting your app to another service, but it's easier than getting your data out of a SaaS provider and moving it to another SaaS provider.
For organizations that want to write their own software, but ignore the infrastructure layer, this is the way to go.
Next up, we have Infrastructure-as-a-Service (IaaS). Here you move down the stack to companies that provide, well, infrastructure.
The prime example of this would be Amazon Web Services (AWS). Instead of providing a platform or ready made software, they provide utility computing service. For example, AWS has the Elastic Compute Cloud (EC2) that lets users spin up virtual machines "in the cloud." You can run instances of Linux, Windows and other operating systems. They're provided as a service, so companies don't have to worry about managing the hardware and infrastructure that goes along with it.
Sometimes this is called Hardware-as-a-Service (HaaS), but we probably won't call it that here on ReadWriteCloud. Let's not muddy the waters any more than necessary.
The advantages are pretty clear – IaaS lets organizations and developers spin up compute power without a lot of investment. It also removes a lot of IT headaches that go along with maintaining anything from a single service to a datacenter.
The primary disadvantage is control, of course. You have more control than with PaaS or SaaS services, but it's still not quite as direct control as having your own hardware and network. If the provider has, say, network issues – you're not really able to resolve those on your own.
Note that IaaS is not limited to buying services from a provider. Your IT department can provide IaaS (or PaaS, or SaaS) internally as well via private clouds. For example, you might use VMware's vCloud/vSphere solutions or something like OpenStack.
Finally, one of the latest terms/trends that hasn't caught on too widely (but might) is Infrastructure-as-a-Platform (IaaP). What the deuce is that?
Basically, the concept of IaaP is providing cloud infrastructure that can be dynamically scaled the same way that applications can scale on PaaS. IaaP is more of a buzzword than a technology, though.
Note that there are combinations of the various "aaS" options from different providers, so this is just a general overview of "aaS." But that's "aaS" in a nutshell. Any questions?