Kevin Remde's IT Pro Weblog
These are probably not new acronyms to most of you.
“Acronyms? I thought you were just a really rotten spelller!”
These are the three delivery methods that we talk about when considering how to deliver, leverage, or purchase IT Services. When you are considering a software or technology solution to address some business need, you have choices. Do I buy it from some online service? Do I build it myself? Do I host the purchased software on my own servers and in my own datacenter, or do we rent space at another location? Who owns the server? Who owns the operating system? Who is responsible for securing our information? Who let the dogs out?
“Now I’m confused.”
For the few of you just starting out in your knowledge about all-things-cloud, here is a brief definition for you:
Software as a Service is where you buy the service. It offers little to no customization, but you don’t have to worry about configuration or maintenance or updates or hardware other than your connectivity to the online service you’re purchasing. Examples are BPOS / Office365 and Salesforce.com for business, or awesome consumer services like Zune Marketplace or XBOX Live.
Infrastructure as a Service is the case when you’re buying the space to manage your own infrastructure. You don’t have to worry about building servers or managing the virtualization layers, but you provide or define the OS, the applications, data, and so on. Examples of IaaS are hosters that give you the ability to upload or create your own virtualized servers running on their hardware. Another increasingly popular example is a “private cloud”, where a large enterprise supplies computing resources company business units in a hosted, self-service, measured, elastic way. (More about Private Clouds in a later post in the series).
Platform as a Service is a solution for simply providing the application or data, and the rest of the platform is automatically maintained for you. So now I don’t even have to worry about the operating system or platform my application is running on. I build the application, define and create the storage structures, and upload it onto the platform. I don’t have to worry about configuring load balancing or DNS. The platform has clearly defined security practices already in place. Upgrades to the platform are handled automatically. I pay only for what I use, and I can spin-up or spin-down instances of computing power as needed, without interrupting the availability of my potentially globally accessible application. The best example of PaaS I can think of is Windows Azure. I’ll be covering Windows Azure in a later post in this series.
“That helps a bit. It sounds like the choice is really about answering the question: ‘Who is responsible for what?’”
Exactly. To help make it really clear, the chart below breaks down the responsibilities, from the traditional-and-totally-on-premises solution on to the complete purchased software as a service idea, and pointing out which portions of the stack are your responsibility vs. those provided by the service provider.
“Great, Kevin. So which one do you suggest I choose?”
The point here is not to tell you which method is the right way to go in every case. And there is plenty of room for grey areas in-between. Sometimes the best solution is a combination (or even hybrid) of delivery methods. The decisions you make will be based on the applications or services or infrastructures you need to build and/or support, and what makes the most sense for your business; either financially, by compliance needs, performance, manageability, and so on.
Hopefully this quick primer at least gets you considering the many options out there, so that you’ll be better able to make and support a good decision the next time the choice is presented to you.
Make sure you check out part 4 tomorrow, where we go into greater detail about Software as a Service.