Matter isn’t created or destroyed
23 Apr
You’ve got an application. Maybe a bunch of applications. You’ve heard that the “cloud” is the place for these things today, so hooray, that’s done. Then you read discussions on corporate cost efficacy, or untold other random things, and the buzz is so loud you can’t hear yourself think loud enough to figure out anything.
Step back, just for a second. At the most basic level, that collection of apps is gonna run on some hardware. Somewhere. No matter how fancy, when pushes comes to shove, it’s got some physical folded sheet-metal somewhere. Basic part II: Folded sheet-metal is all the same. WHAT! I know, I know. HP, IBM, Dell, Sun (er, Oracle), are dying to not make this true, but it is. It’s all the same. Yes, there are differences, and they are important to the technicians running this stuff, it won’t make a damn bit of difference to your application. You spend $3K, you get $3K worth of performance. Spent $30k, you’ll get something better/faster/more reliable. For the same price backet, all the vendor’s differences are 95% the same. Some people care about the 5%, some don’t. Most don’t.
So it’s all the same, and you only care about your app. Sadly, between caring about your app and getting it to run, there are some other concerns. You care about nice things like reliability. Or response times. Or # of credit card transactions. And getting those things requires some complexity. Maybe more hardware. Or some fancy programs. Maybe some additional people time. None of it’s rocket science, and frankly, it’s all been done a million times before. Specify what % uptime you want, how many customers you really want, and there’s a solution for that. Let’s say you decide you want decent uptime, protection from SPOF (single point of failure), and have a small-ish app that has only 5,000 light users. Easy peasy, let’s get you two servers, setup some kind of failover arrangement, and you’ll probably be fine. Yeah, it’s a bit tricky to get this setup, but it’s just tricky, not actually hard.
Now you want to do this in the cloud. You look at moving it to Amazon EC2. You’re team runs the numbers, and SHOCK and HORROR, it’s MORE EXPENSIVE than your in-house team. OF COURSE IT IS. They’ve got the same computers. They’ve got the some damn fancy software, but if you’re doing the same thing on someone else’s equipment, it’s going to cost more. This shouldn’t surprise anyone. And if that’s what you’re looking at, you’re an idiot.
The point of the “cloud” (and for this example, while I’m using EC2, please don’t limit your thoughts to them. This could be any provider, in-house or outside. It could be higher level like Google App, plain old IaaS, or something new we haven’t thought of) isn’t doing the same thing the same way. It’s about the flexibility it offers. The new way you can do things.
So first thing first. Were those two servers 100% loaded the whole time before? No? Great, so why not go with a smaller resource pool. Either in house with Virtualization, or just use some smaller instance in the cloud. What’s that, you don’t like “sharing” your resources with others? Get over it. Whatever excuse you have, you’re wrong, you just don’t realize it yet. I’ve spoken with companies who don’t trust VLANs (a way of putting two networks onto a single cable, VERY useful in any real datacenter) for no good reason. They’re doomed. The technical constraints are getting taken down daily.
Great, so now we’ve got better utilization. That’s step #1. Now my app is doing well. Really well. The latest stupid congressional bill is requiring everyone in the company to use this thing 10x as much, and I can’t handle the load! Oh, you’re in the cloud? You can provision new resources in 2 seconds instead of 2 weeks or months? Hey, that’s worth something! Even if I was on my old dedicated machines (so much cheaper, remember!) they couldn’t handle this load. I’d be dead if I had to wait for new HW to show up and get provisioned and…
Wait, the app is getting so much attention, my trivial failover mechanism isn’t sufficient. I need a real disaster recovery plan. Maybe something in two datacenters, in case California really does fall off into the ocean. How much would it cost you to spin up a new datacenter again? Why not let someone else do it for you, and pay a bit more per CPU hour?
And this is all just in an IaaS world. Why are you even bothering with virtual computers. Chances are all you really care about is the application. Why not just use some PaaS provider, who can do all the sysadmin work for you. Rails has a great ecosystem here already, with some truly amazing companies like Heroku out there. Google has python covered. Even java now. Now you’ve just cut out a whole huge chunk of management cost in house. And it turns out it’s even cheaper per app since you’re sharing even more now.
This isn’t rocket science. Hardware costs are fixed. Everyone is adding their own technology costs on top. The more fancy goo, the more it costs on a per CPU cycle basis. You save money through efficiency, be it using less resources or getting quicker agility. That’s it. There is no magic in the cloud. It’s just another way of making your life easier. If you actually try and use it as it’s intended, and not just shove your existing inefficient ways of doing things up into someone else’s outsourced HW farm.
Sphere: Related Content