Google network lord questions cloud economics
Does Amazon make sense at 100% use?
Vijay Gill — one of the brains that oversees Google's epic internal network — has questioned the economics of so-called cloud computing. Or least, the sort of cloud computing practiced by Amazon.com, whose EC2 service offers up instant access to compute power via the interwebs. If your infrastructure is in use around the clock, rather than just here and there, he argues, it may be cheaper to own and operate your own gear.
"Think of it as taking a taxi vs. buying a car to make a trip between San Francisco and Palo Alto," the Google senior manager of production network engineering and architecture writes on his personal blog. "If you only make the trip once a quarter, it is cheaper to take a taxi. If you make the trip every day, then you are better off buying a car. The difference is the duty cycle. If you are running infrastructure with a duty cycle of 100%, it may make sense to run in-house."
And to prove his point, the Google has put together a model that compares the costs of AWS and a colocation setup where you own the gear — at a 100 per cent duty cycle. The model assumes that managing AWS requires just as much effort as managing your own hardware, which may seem a stretch, but Gill backs this assumption with what seems to be a quote from a friend.
"You’d be surprised how much time and effort i’ve seen expended project-managing one’s cloud/hosting provider — it is not that different from the effort required for cooking in-house automation and deployment," the quote reads. "It’s not like people are physically installing the OS and app stack off CD-ROM anymore, I’d imagine whether you’re automating AMIs/VMDKs or PXE, it’s a similar effort."
Gill says his model errs on the high-end for colocation prices — "so the assumptions there are conservative," he says — but according to his calculations, AWS is still considerably more expensive. Here's his bottom line for one particular Amazon scenario here:
And the end result of the matching 100-per-cent-duty-cycle colocation setup:
You can browse the complete model here.
As one commenter on Gill's blog points out, the Google man uses Amazon's standard pricing for instances, rather than its "reserved pricing." If you know how many instances you're going to need, you can reserve them ahead of time at a lower price, and if you're assuming 100 per cent utilization, it makes sense to assume reserved instances.
The standard prices are for those moments when you need more juice right now. EC2 is short for Elastic Compute Cloud. It scales as you need it to scale. And as other commenters point out, Gill's model doesn't show the worth of Amazon's elasticity. "The 'elastic' component is a very appealing component of the EC2 (or any 'cloud') system," a commenter writes. "Being able to turn up/down single machines as needed is a huge capital expenditure burden that vanishes from the books, and hopefully the number of systems running then more closely matches income generated by those CPU cycles rather than just serving to warm up a big windowless building somewhere."
But again, Gill is assuming 100 per cent utilization. With his model, all CPUs cycles are needed. He's merely arguing that in such cases, colocation may be the better option. But in a way, his model may actually highlight the worth of EC2 and its elastic nature. How many data centers actually maintain a 100 per cent duty cycle? And as the duty cycle percentage drops, doesn't EC2 become cheaper and cheaper by comparison?
"Even a 40% reduction in traffic for 40% of the day (not unreasonable in services that cater to specific geographies) would start to make EC2 look a bit more competitive," one commenter argues. "I do agree that for sizable installations that see steady load, that a self-operated data center makes the most sense, but the devil is in the details on any calculations."
EC2 needn't suit everyone. Just some. ®
Welcome to 1970.
You can either pay a bureau and they own the overheads, shared across multiple customers not just you, but you still carry the risk and the responsibility when it doesn't work as intended.
Or you can put a PC on every desk, and pay way over the odds for the compute power and storage which sits idle for 99% of the time, and pretty software which is defective by design.
Or you can take control, do most of it in house, as far as possible with free software, and know exactly what you're getting for your money and maybe be able to fix it when it misbehaves.
Stuck in a time loop...
Anther savings is that if you're using Amazon you're stuck with a few different memory sizes of virts that you can get from EC2: 1.7GB, 7.5GB, 15GB, etc. If you need a bunch of 4GB virts then you're stuck buying 7.5GB RAM servers and trying to politically deal with bundling up apps on the same O/S instance, or else just wasting RAM.
You'll get better "compression" by being able to size the virts yourself by running your own internal cloud.
I've also been doing these calculations repeatedly because our board of directors seems to be infected with irrational lust for the cloud, and keep on determining that break-even on a cash-flow basis comes after about 3-4 months for 100% duty cycle instances -- so Vijay is probably being conservative at what can be achieved in the real world.
However, if your IT department spends millions on expensive enterprise-class tools and money is flying out the door to VMware, EMC, NetQOS and every other IT vendor out there, then it may be cheaper to go with the cloud -- but in going with the cloud you are getting Amazon's framework build on top of Xen and open source or in-house tools. You are not getting infrastructure engineered to "five 9's" you are getting infrastructure engineered to "you bet it'll fail -- so spin up another one!"
If you run the numbers on cloud and find that it makes economic sense, you should fire your IT staff and start over from scratch with people who understand cheap open source.
Is this really a surprise?
Anyone who's run the numbers on on-demand computing vs rolling your own knows that it's much cheaper to roll your own. The only place where on demand is cheaper is for bursted capacity... Yeah, people argue about staff overhead, but it's not like running on cloud services frees you to have no staff.
I guess the real problem is that people don't actually calculate the cost of things....