No, but they're not cloud computing's direct target. There are several levels of abstraction before the customized "service" reaches the end user. You're right, the end user wants commodities delivered simply and reliably. The direct target of cloud computing (enterprises, xSPs) DO want complexity. In fact, the more complex the better for many...they trade the cost of complexity for the flexibility and differentiality of service. Then other direct users will prefer a cloud computer who more directly provides that 'simplicity', as long as the cost per GHzFSBMem is low and predictable.
We'll witness a pre-cambrian explosion of end user, middlemen, and cloud providers over the next fifty years. Eventually, natural economic selection will take its course. Those in each category able to project a long-term reality of customer satisfaction, profitability and shareholder value will eat or absorb the non-productive. And eventually, the productive will die as new niche players show better value prop, shareholder value and customer sat. End users will drive this natural selection process, depending on their group and individual needs.
Dave
Do end users really need to see this level of complexity? Internally, the cloud provider might want to base the charge rates on various measurements, such as CPU, memory, bus speed, etc. However, the end user will probably want something much simpler e.g. I want to run on a (virtual) single host or on a cluster or, even, I want 24x7 availability. Elastica uses a fairly simple system like this when you build an application to be deployed in their cloud. Anything more complex can make it overwhelming for anyone but the most sophisticated user.
To continue Ray Nugent's comparison of petroleum and West Texas sweet light, when I buy gasoline for my car, I get the choice of Regular or Premium at the pump. Now, I don't know what goes into the regular gasoline blend…how much is West Texas sweet light, or Brent light or Saudi heavy oil…and, guess what, I don't care. The regular gasoline is good enough for my 8-year old Jeep and that's all that I need to know. Similarly, end users don't want to be confused by a huge menu of CPU speeds, memory allocations, bus speeds, etc. – if you keep it simple, then they will get it (as long as they can upgrade to a different configuration if needed).
Paul.
From: cloud-computing@googlegroups.com [mailto:cloud-computing@googlegroups.com] On Behalf Of William Louth (JINSPIRED.COM)
Sent: Tuesday, December 16, 2008 12:59 PM
To: cloud-computing@googlegroups.com
Subject: [ Cloud Computing ] Re: Compute surface as a traded commodity?
I am not sure why we are looking for one single resource to meter. I would expect that various resource meters will be used as cost drivers in determining appropriate charges that will be passed up to the next layer on the cloud computing stack with each layer in the stack introducing its own meters derived partially from lower level meters - partially because there must be value added somewhere.
Once we get above the bare metal platform I expect to see more diversity in costing and billing approaches. Currently we seem to have carried over a large amount of baggage tied to current (legacy in this context) enterprise system/network management approaches that provide very coarse grain resource metering at the process level or data traffic pattern levels. I am confident this will change to more (user/software) activity based costing with the metering correlated to actual software execution performed on behalf of the user or cloud service. Unlike our opaque OS based process containers threads of execution in the cloud will operate as lawyers do today - billing the client context for every activity perform using various meters (wall clock time, number of photocopied sheets, number of letters dispatches with postage,........). Threads will not touch a resource unless they have a client billing code. This will never be possible with ESM/NSM because one cannot see the computing above it and the other below it.
http://www.jinspired.com/products/jxinsight/meteringthecloud.html
Kind regards,
William
Christopher Drumgoole wrote:Given the variances in CPU clock speeds, Gigahertz Hour is easier tocompare.---Chris Drumgoole-----Original Message-----From: cloud-computing@googlegroups.com[mailto:cloud-computing@googlegroups.com] On Behalf Of Pittard, RickSent: Tuesday, December 16, 2008 11:50 AMTo: cloud-computing@googlegroups.comSubject: [ Cloud Computing ] Re: Compute surface as a traded commodity?Actually, the price of a barrel of oil is for a very specific grade at aspecific location. The real prices vary depending on quality andlocation - maybe just like a CPU-hour should.Rick-----Original Message-----From: cloud-computing@googlegroups.com[mailto:cloud-computing@googlegroups.com] On Behalf Of Jim HoughtonSent: Tuesday, December 16, 2008 9:16 AMTo: cloud-computing@googlegroups.comSubject: FW: [ Cloud Computing ] Compute surface as a traded commodity?Interesting thread ... I had discussions with executives at a largeinvestment bank (one of the few still around today!) as far back as 2002when we were implementing large grids for risk & portfolio analysis thatleveraged 'scavenged' resources for some of the compute footprint. Iagreethis will happen, but interoperability is not the only obstacle.Placingsecurity off to the side - let's assume for the discussion someone hasalready overcome their technology or compliance hang-ups - there is amajorbusiness challenge to overcome.We all know what an ounce of gold, or bushel of corn, or a barrel of oilisaround the globe. So what is the equivalent unit of trade for computingcycles?Think before you answer ... 'CPU hour' just wants to jump off yourtongue,but as we all know not all CPU's are created equal (even by the samemanufacturer). Then of course there's memory, bus speed, networkbandwidth,network throughput, operating system, latency to/from your originationpoint, disk read/write speed ... I could go on and so can you. I've beenliving this for 6+ years working with clients who want to build internalutilities (clouds), and even there it's difficult to get agreement asthisforms the basis for what they are going to get charged for the resourcesthey consume. It's not much of a 'utility' if users got a flat annualallocation charge, is it? Yet that's by far the most common situationinlarge enterprises today.There's the closet economist in me who feels (hopes) someone will juststartsuch a market and soon thereafter the laws of supply and demand will settheappropriate prices. Those with high quality service will be sold outandcan increase their prices, with the reverse also true. However,especiallywith the current state of global economic affairs, I am doubtful it willhappen anytime soon. Nor do I think we can count on any standards forumtotackle such an issue, and the major vendors will undoubtedly look atnormalization (translate: commoditization) of their technologies as abadthing.Anyway, hopefully this provokes some thoughts - look forward to yourresponses.Jim_________________Jim HoughtonCTO and FounderAdaptivity, Inc.(845) 494-9419www.adaptivity.com-----Original Message-----From: cloud-computing@googlegroups.com [mailto:] On Behalf Of SimonPlantSent: Tuesday, December 16, 2008 7:03 AMTo: cloud-computing@googlegroups.comSubject: [ Cloud Computing ] Compute surface as a traded commodity?Bruce wrote:Will the "Cloud" ever become a pool of hosting providers who pitchtheirprices, SLA's and storage cost so customers will come to their "cloud"forservices?I foresee a time into the future where the compute surface isvirtualizedand standardized enough that hosting contracts can be traded as acommodityon a market, rather than the RFP type process we have today.Such agreement would allow business to place a deal on an exchange muchlikeFX today and get bids to run based on some parameters. IT hosters wouldprice the deal with a spread in the same way as a currency trade today,thedeal done in a matter of seconds and hosted for the duration of acontractwindow.If virtualization vendors deliver on their hybrid end-vision, this couldbea reality of packaging workloads with SLA manifests and using internetvMotion-type tools to migrate. It would fundamentally change the way wewrite software frameworks and applications themselves to be more selfcontained and highly standardized to achieve the best 'tradability'.Interoperability via standards between VM platforms, portability ofdata,code business logic and processes are all key to how we build out theCloud.Such openness may be a far extreme view, but would you want the oppositeview of the world where switching costs and lock-in are extremelyconstraining and we are forever stuck in a platform cycle ofdistribute-and-consolidate?Simon Plant
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to
cloud-computing-unsubscribe@googlegroups.com
To post job listing, send email to jobs@cloudjobs.net (position title, employer and location in subject, description in message body) or visit http://www.cloudjobs.net
To submit your resume for cloud computing job bank, send it to resume@cloudjobs.net.
For more options, visit this group at
http://groups.google.ca/group/cloud-computing?hl=en?hl=en
Posting guidelines:
http://groups.google.ca/group/cloud-computing/web/frequently-asked-qu...
This group posts are licensed under a Creative Commons Attribution-Share Alike 3.0 United States License http://creativecommons.org/licenses/by-sa/3.0/us/
Group Members Meet up Calendar - http://groups.google.ca/group/cloud-computing/web/meet-up-calendar
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment