Cloud computing – still a bit too pricey for the average project

December 22nd, 2009 by mgkimsal Leave a reply »

I wrote this to Brian Hitney after we’d briefly touched on cloud computing in my podcast with him last week.  I thought I’d post it here for any reaction from the rest of the internet…


Another point on the economics that isn’t brought up is the cost of data transfer and data storage in the cloud, which is often more than you’d pay for ‘normal’ equivalents.

I’ve got a server that I lease and pay $84/month for.  Included in that I get 750 gig of transfer.

With azure, 12 cents per compute hour for 24 hours x 30 days = $86 - about the same base rate.  But… let’s say I’m pushing out between 150 and 200 gig of bandwidth per month.  200 gig at .15 cents extra is $30.  Factoring in I store about 40 gig of data on that server, that’s another $6.  To replicate my setup on Azure (or Amazon) would cost me about $38/month more, which is a 40% premium over what I can get in the ‘non-cloud’ marketplace. As my data needs scale up, the differential gets bigger.  EC2 pricing is roughly equivalent for storage and xfer, but the base computer rate is cheaper for linux images than for windows images.

There’s a big play to push ‘cloud’, and given the markup, I can see why.  The hardware is commodity, and is essentially a one-off investment, but the data xfer is the lifeblood, and I’m actually a bit fearful of putting so much reliance in the hands of just a few monolithic companies who will then charge us a premium to move our own data around.

If I had a huge amount of number crunching to do, without much data storage or xfer needs, current ‘cloud’ offerings make sense.  And for potential adjunct service in a pinch, or for testing.  But as a long term strategy investment, the pricing needs to change and/or there needs to be more value in the mix for my taste.

Share and Enjoy:
  • del.icio.us
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati
Advertisement

6 comments

  1. John McLaughlin says:

    Totally agree. Some of my clients are looking at the other end of the spectrum, digital image compositing, which measures data in terabytes, and throughput in GB/sec. A sustained throughput of 1GB/sec would cost upwards of $360/hr, and clearly swamps any savings on processing. With the CPU’s almost free, there’s plenty of room for an AWS competitor to establish a data throughput advantage.

    Its also very interesting that Amazon is allowing free incoming data transfers through June. A move to create captive data?

  2. mgkimsal says:

    As a followup to my conversation with Brian last week, I had a few more thoughts to share…

    http://www.theaeonsolution.com/security/?p=101

    I think this may be addressed over time, but does indicate that early adopters need to be much more selective about what they put out in the cloud.

    Actually, this is something I was trying to get across last week and I didn’t do a good job. Every data center is “the cloud”. I’ve got a server in Texas, and the entire world can hit it and interact with it. When they send data to it, it’s going “in the cloud” in a very real sense. It just happens to be that the ‘cloud’ their sending to has a very real, defined and finite set of resources to work with, whereas the azure/ec2/gae promise is “unlimited/infinite” resources at a request endpoint. The upside – infinite resources for potentially infinite cost(!) – has to be balanced against the tradeoffs of security, SLAs and so forth.

    What I’d like to see is “internal grid” computing for larger orgs, whereby they can create their own “app fabric” (to use the azure idea) by harnessing spare cycles from internal clients and spare servers. Plug in some more machines, and you’ve added more capability. This probably won’t come to fruition for many years, until we’re all comfortable with expressing our code and data as chunkable stuff. Eventually we’ll all be writing Erlang (or maybe MS Visual Erlang?) and we’ll have concurrency ‘solved’ to the extent that most problems will be written to be parallelizable(?) from the start, and we’ll save the serial processing optimizing issues for grey haired bearded linux-guru type people.

  3. Right now, I think it makes the most sense if you have a heavy traffic period followed by a longer quiet period. Turing up the dial for the holiday season if you’re a retail site, then back off when it ends, makes sense and can be cheaper than physical hardware. Everyone else though needs to do some hard math before jumping in.

    In the future, now that we have several big names in the space, the prices will drop. Once the market for early adopters has been soaked up, there will be a need to expand the market to other price tiers. In the mean time, roll your own “fabric” with 3 $5/mo hosting accounts and round robin DNS ;)

  4. brian says:

    A little late, but my original response via email :)

    Definitely correct on that and I agree. What I always find a bit humorous is that the cloud is always about “infinite” scale (or more appropriate uber scale) but when you factor the costs of storage — imagine if you’ve got tens of hundreds of GB of data … that’s some serious $$ both in terms of storage and delivery.

    Right now, IMHO, the big winners of using Azure (or other cloud) are corporate customers who favor the zero maintenance/simplicity. Previous teams I’ve been on (inside and outside of MSFT) I can see it being a big boon to productivity. The second case are for “insta-elastic” clients … one example that was used at PDC this year was a ticket vendor that had enormous spikes of volume when a new show went on sale. They can instantly scale to 5, 10, 20 servers, but for a short period of time. Perhaps a third case will be for those that also want edge-caching like Akamai.

    Sadly, for folks like you and me, I’m getting a “too rich for my blood” response universally. And grass roots success is necessary.

    What I’d like to see is a model perhaps akin to Google App Engine that charges for CPU consumption instead of CPU reservation like MSFT/IBM/Amazon. In fact, I thought that was what we were going to do until recently when pricing was announced, particularly because Azure is platform based.

    I’ve made the argument internally that a small biz site (in theory) may receive zero to a few requests during non-peak time — obviously the owner could opt to pull the site down but that’s not desirable.

    On the flip side, though, the VMs get direct hardware reservation to maintain the SLA. For corporations and particularly ecommerce, this is paramount. But for many, including individuals and small business, a little bit of SLA would be gladly sacrificed for CPU consumption model, particularly if you had multiple instances that were load-balanced.

    My hope is that this just the beginning w/ enough players that keep things competitive.

  5. mgkimsal says:

    I think long term there will be *some* more competitition. However, the immense capital to fund something like this means that for the foreseeable future we’ll have just a handful of players.

    When compared with the cost of *staffing* as well as purchasing or leasing some of the big hardware you can rent from azure/ec2/etc, it’s a comparative bargain. However, most startups don’t need that power (as you’re pointing out) and would probably offer the systems guy(s) a piece of equity in lieu of hard cash. I don’t think MS or Amazon will take equity in place of payment for my next project :)

Trackbacks /
Pingbacks

  1. links for 2009-12-23 « burningCat

Leave a Reply