Why Cloud Infrastructure Pricing Is Absurd 191
itwbennett writes "Two reports out this week, one a new 'codex' released by 451 Research and the other an updated survey into cloud IaaS pricing from Redmonk, show just how insane cloud pricing has become. If your job requires you to read these reports, good luck. For the rest of us, Redmonk's Stephen O'Grady distilled the pricing trends down to this: 'HP offers the best compute value and instance sizes for the dollar. Google offers the best value for memory, but to get there it appears to have sacrificed compute. AWS is king in value for disk and it appears no one else is even trying to come close. Microsoft is taking the 'middle of the road,' never offering the best or worst pricing.'"
Doesn't seem that absurd (Score:5, Informative)
Re:Doesn't seem that absurd (Score:1, Informative)
As long as I get physical access to my server and a guarantee that the server isn't shared with others, sure..
I don't think 'cloud' means what you think it means.
Hidden performance when on the cheap (Score:5, Informative)
One very important aspect to pay attention to is the advertised performance service you will get. CPU cycles, size of memory, volume of storage, amount of networking bandwidth are all sure to be price points and advertising points. I would encourage everyone to pay attention to any fine print about:
*dedicated vs shared CPU. The biggest problem with CPU sharing is that CPU cycles are scheduled to be shared on over subscribed "cloud" providers, which helps lower cost. Oversubscribed CPU cycles causes CPU wait time, which means that your "cloud" CPU may need to wait X amount of time to be scheduled for your N CPU cores that you are paying for. Let's say that you have 8 CPU's, you may need to wait for 8 CPU's to be unused on the physical host your are on before you get to do any work at all. If you have 1 or 2 CPU's than this is far less of an issue. The greater the core count the bigger the issue.
*Memory ballooning. Memory is one of the most easily over subscribed resources in "clouds". To cut costs Memory is allocated to you at, let's say 12GB. But you only use 6GB. On the back end you are really only given 6GB. Going further let's say that you have 12GB, use only 6GB, but only have 4GB actively in use by your application. There are memory scheme's out there that will write the 2GB that you do not use very often to disk(think swapping intelligently).
*Disk IO speeds. Storage can be really cheap or really expensive depending on how it is architected. Pay attention to any fine print talking about what the storage consists of and if you have any kind of dedicated Disk IO. The cheapest "cloud storage" provider may be offering a product that works great for highly cached low transaction websites. But that same provider may give poor performance for a high rate of disk transaction logging server, or high transactional application.
*bandwidth limitations. Pay attention to quality of service limits. Pay attention to bandwidth sharing, do you get full advertised bandwidth to the internet or do you get "up to bandwidth" limits. Network connections to other servers that are co-hosted could be as fast as 40+GB/s. If it matters to your application ask if there are higher bandwidth connections between co-hosted servers.
*backups, service uptimes, service failure compensation, riders on the contract that talk about lower temporary performance in the event of a hardware failure. Options for expansion of resources(hot or cold).
Re:get used to the monthly payment (Score:5, Informative)
I think a lot of people here are massivly underestimating the total cost of a unit of computing resources when they run it in their own machine rooms. It's not like your machine room is any more efficient to operate than Amazon's. In fact, it's probably massively less efficient unless you're a pretty big operation. The only cost they have that you don't have is "profit for Amazon."
Re:meow meow f1rst p0st (Score:5, Informative)
Nope, but I do have to deal with it on a daily basis...
Cloud pricing is insane (and insanely complex) because otherwise the vendor wouldn't make any real money off of it.
Take AWS for instance. Sure, the spot pricing is cheap as hell. Well, it would be, if they didn't charge you $0.11/GB-hour for storage, a penny-fraction for every 10,000 GET requests you receive (and a similar price for every 1,000 PUT/form requests), and a zillion other nickel-and-dime charges that turn a forecasted $300/mo. estimate into a $3200/mo. OpEx ( for five moderately-busy servers w/ a small DB... basically a smallish-sized commercial website).
I know this because I just inherited one of these. My predecessor promised cheap, I'm stuck with managing expensive (and am moving the #$@! thing back into our existing colo space as soon as I can practically do so...)