On Prem, IaaS, Paas and SaaS
Before I rant about the way cloud providers are taking over everything, I figured a primer on what the cloud really means is in order. Basically when we talk about "the cloud" we mean that data is stored a collection of servers that don't really know, or care, what's running on them.
Storage for your photos might be "cloud" because they're scattered in "buckets" in AWS, but a Storage Area Network is a Storage Area Network no matter if you host it on your own servers on upload them to a cloud service provider. The only difference is who manages that infrastructure.
Say you want to develop and deploy a web application like Jokeindex
. You have a few choices:
Buying a server and hooking it up to a dedicated internet connection is how we started this adventure. Jokeindex.com was originally running on my Windows 98 PC at the end of a DSL line -- you don't do that anymore, but companies like Dropbox1
, Target and Walmart2
are building their own data centers (not a bunch of Windows 98 boxes either). The idea is that if you're responsible and know how to manage servers, you might as well own your own.
This is the most complicated way to host anything because you have to manage everything
. At the end of the day most companies don't have the resources to build, maintain, and properly manage a data center or server farm of their own, but if they do, they have 100% control of what they own.
Infrastructure as a Service (IaaS) means you're renting servers. This is how the "cloud" started -- now you don't have to worry about blown capacitors, keeping gas generators fueled up in case the power goes out, or even how old those boxes are that are running hot and loud 24/7.
When we retired the server room in the basement of my office and we moved Jokeindex out to "the cloud" we just set up a debian server. Suddenly hardware, power, routers, switches and cables were a thing of the past. All we had to worry about was picking an Operating System, installing all the software and dependencies the website needed, runing security patches and updates regularly, oh and tweak the firewall settings and monitor how much CPU and memory we were using in case we need to rent a bigger instance...
If you're a software developer, you're probably not a hardware guy, so you hire that hardware part out. But... if you're a software guy, why are you still futzing with Operating Systems? Which brings us to...
Say you're a java developer. You just want a place to deploy your code without worrying about hardware or operating systems. Drop On-prem, drop IaaS and enter Platform as a Service.
Tools like AWS Lambda
take care of all that patching under the hood. They install the dependencies for a Java environment. They take care of scaling and routing traffic.
They also limit you in odd ways. If you're a Database Admin and you move from your own SQL server to one on AWS' RDS
you suddenly find out you aren't a DB Admin anymore -- those super admin tools are reserved for Amazon's employees. You find you have to work around the limitations enforced by the service provider, and that your software is becoming less portable. If you're using dyanmoDB because it's a cool PaaS tool, you're going to be in a world of hurt when you try to move back to MongoDB.
Or maybe not a word of hurt, but you'll also find PaaS limits you in other ways so you have to make workarounds. And all these PaaS tools are billed by the hour and by the storage and by the transfer -- you start building work arounds, you start adding time to the meter for all the extra bits and bobs you have to build to make it work.
Now say you aren't a developer at all. All this CPU and OS and DB stuff is just alphabet soup. You want a tool, not a software development stack, so you use something like Gmail for your email rather than standing up your own Postfix server. You use Wordpress.org rather than download Wordpress and installing it on your own servers.
There are a lot of reasons to use a SaaS provider for business functions -- the idea that we can just roll our own is usually based more on business ignorance than engineering arrogance but both mean you're building and supporting something in your own ivory tower silo.
But the other side is true too -- if I need a tool and I really do have unique business requirements, locking myself into a SaaS tool like Salesforce
At the end of the day, the reason to use one or the other is always going to be driven by business need, but, I have a few rules I like to put in front of the whole infrastructure question:
1) Is it portable?
The more you get tied to a single company, the more they own you. I like to build applications on portable tools -- they don't have to be open source, but they have to be able to be installed somewhere else
. I've heard the argument "Well if Amazon goes down we have bigger problems" but that argument is like saying "I'm putting all my money IBM"
You should always have your data backed up and have the ability to run your systems outside the vendor's infrastructure. Even SaaS tools like Wordpress.com have ways to export and move to another platform. If information really is the currency of business, you need to be able to cash out anytime.
2) Do you have the expertise?
I understand the idea that a company doesn't want to have to reinvent the wheel. You may not have a proper operations team to understand how to manage servers on-prem or even instances in an IaaS data center.
But let's be honest -- this stuff is complicated. Buying into a PaaS model requires a different kind of expertise. The architectural bugaboos that might bite you on the come in really hard and fast. Not only that, you don't own the infrastructure
so you can't change it if you need to. If you suddenly run against a limit of a PaaS tool, you're going to have to stop, regroup and rebuild. Which brings me to the final question...
3) What does it really cost?
Dropbox left AWS because it turned out to be a LOT cheaper to run their own data center. Moving the servers out of my basement and into a cloud service saved huge amounts of time and money for my small org.
It depends on what you're doing -- I actually hate the vague recommendations you get from a lot of consultants, but at the same time, I hate even more the "THIS is the ONE WAY to do X." To me that's a way of closing your eyes, letting the vendor wrap their tentacles around you and not actually solving the business problems that make your company... yours
1. Why Dropbox decided to drop AWS and build its own infrastructure and network
2. Target And Wal-Mart May Move Away From AWS, Will Amazon Be Affected?
Share this article:
Be sure to see my blog over at Cloudenity. This week's topic:
The Physical Impossibility of Migrating to the Cloud