"JL Valente" <jlvalente@cittio.com> wrote:
> As usual on this group we have very different camps and opinions which makes
> the whole debate quite useful. But again I don't think that this an either/or
> proposition. It depends who the "end user" is really. Some of the ones we are
> dealing with go deep and require serious metrics and understanding of what
> they are really getting from their cloud provider.
MAybe from a sales perspective, but if we are truly talking about getting 'IaaS
units' traded as a commodity in some future, it probably better be just one,
agreed-upon set of metrics.
I think we have a general consensus that this involves much more than hardware
stats, including external-to-the-host factors like latency and throughput
in/out of the facility and internal choices like VMM versions and
configurations (with both versions and configurations, there are a LOT of
precarious things that will affect performance).
I don't see how it could be done without a set of comprehensive benchmarks
routinely run on the providers (hopefully by auditors we can trust).
Tim
>
> ________________________________
>
> From: cloud-computing@googlegroups.com
> To: cloud-computing@googlegroups.com
> Sent: Tue Dec 16 15:02:25 2008
> Subject: [ Cloud Computing ] Re: Compute surface as a traded commodity?
>
>
> From Paul Moxon:
> [if you keep it simple, then they will get it]
>
> I agree with Paul. From a cloud-computing, sales engineering perspective,
> price is based on what you can offer customers, not what it costs the company
> to provide such services. The latter has to be quantified to ensure
> profitability, but no matter how much the 'processing-markup' if you have
> what customers don't want, or do have what they want but make the process to
> complex, you will loose customers and slow down the migration to 'the cloud'
> overall. That doesn't help anyone's bottom line.
>
> What the company I work for does is create a formula, with multiple
> components that averages what a single 'seat' or 'user' will consume with the
> hosted application they've purchased. There will be statistical outlyers (in
> the case of AV, these may be part of the formula), but overall it needs to be
> reasonable and reaslistic. Then they charge the customer in 'seat' tiers
> (1-1000, 1000-3,000), annualized (can be monthly) and so on. This has so far
> proven to be both manageable and profitable, and includes lots of SMB and
> Enterprise sized customers...
>
> So as an SE, I would work it backwards - from the end-customer to the
> hardware - Price the applications, support model and so on. For example: I
> just bought a home. I have one utility provider, but am charged by the
> 'application' (DirectTV, Internet, Phone, etc.). In this example, the utility
> provider is charging Megawatt hours, which is obviously where this thread was
> starting, but I think it's folly to separate the two, when the same company
> can Provide both the Applications and the Power to run them. All the cloud
> provider have to do is package OEM'ed solutions. Both Sprint and AT&T have
> dived in head first with this model for the last year or so.
>
> Standardizing on GHz/hour or other hardware based metric is wrong, in MHO,
> because the applications that are hosted in the cloud will have different
> efficiency ratings. This may matter to the cloud provider, but the
> end-customer can care less - and the sales person selling the
> application/services can care less, and so on. Infrastructure costs will not
> be a factor, at least in the short term.
>
> Customers also don't care how you provide the service - except for the part
> they interface with. In Paul's example, the only part he would care about is
> the price of fuel, the location of the gas station and so on. Nobody cares
> about oil refinement, oil discovery costs, or the trucking of refined fuel to
> the gas station. The same should be true of services provided in the cloud.
> If the customer has to think to much about it, what is the advantage of
> moving from CPE ot the cloud anyway??
>
> Daniel Scafuto
>
>
>
>
>
>
> On Tue, Dec 16, 2008 at 11:26 AM, Paul Moxon <paul@moxonsonline.com> wrote:
>
>
> 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 to
> compare.
>
> ---
> Chris Drumgoole
>
>
>
> -----Original Message-----
> From: cloud-computing@googlegroups.com
> [mailto:cloud-computing@googlegroups.com] On Behalf Of Pittard, Rick
> Sent: Tuesday, December 16, 2008 11:50 AM
> To: cloud-computing@googlegroups.com
> Subject: [ Cloud Computing ] Re: Compute surface as a traded
> commodity?
>
> Actually, the price of a barrel of oil is for a very specific grade
> at a specific location. The real prices vary depending on quality and
> location - maybe just like a CPU-hour should.
>
> Rick
>
>
> -----Original Message-----
> From: cloud-computing@googlegroups.com
> [mailto:cloud-computing@googlegroups.com] On Behalf Of Jim Houghton
> Sent: Tuesday, December 16, 2008 9:16 AM
> To: cloud-computing@googlegroups.com
> Subject: FW: [ Cloud Computing ] Compute surface as a traded
> commodity?
>
> Interesting thread ... I had discussions with executives at a large
> investment bank (one of the few still around today!) as far back as
> 2002 when we were implementing large grids for risk & portfolio analysis that
> leveraged 'scavenged' resources for some of the compute footprint. I
> agree
> this will happen, but interoperability is not the only obstacle.
> Placing
> security off to the side - let's assume for the discussion someone has
> already overcome their technology or compliance hang-ups - there is a
> major
> business challenge to overcome.
>
> We all know what an ounce of gold, or bushel of corn, or a barrel of
> oil is
> around the globe. So what is the equivalent unit of trade for
> computing cycles?
>
>
> Think before you answer ... 'CPU hour' just wants to jump off your
> tongue,
> but as we all know not all CPU's are created equal (even by the same
> manufacturer). Then of course there's memory, bus speed, network
> bandwidth,
> network throughput, operating system, latency to/from your origination
> point, disk read/write speed ... I could go on and so can you. I've
> been living this for 6+ years working with clients who want to build internal
> utilities (clouds), and even there it's difficult to get agreement as
> this
> forms the basis for what they are going to get charged for the
> resources they consume. It's not much of a 'utility' if users got a flat
> annual allocation charge, is it? Yet that's by far the most common situation
> in
> large enterprises today.
>
> There's the closet economist in me who feels (hopes) someone will just
> start
> such a market and soon thereafter the laws of supply and demand will
> set the
> appropriate prices. Those with high quality service will be sold out
> and
> can increase their prices, with the reverse also true. However,
> especially
> with the current state of global economic affairs, I am doubtful it
> will happen anytime soon. Nor do I think we can count on any standards forum
> to
> tackle such an issue, and the major vendors will undoubtedly look at
> normalization (translate: commoditization) of their technologies as a
> bad
> thing.
>
> Anyway, hopefully this provokes some thoughts - look forward to your
> responses.
>
>
> Jim
> _________________
> Jim Houghton
> CTO and Founder
> Adaptivity, Inc.
> (845) 494-9419
>
> www.adaptivity.com
>
> -----Original Message-----
> From: cloud-computing@googlegroups.com [mailto:] On Behalf Of Simon
> Plant
> Sent: Tuesday, December 16, 2008 7:03 AM
> To: cloud-computing@googlegroups.com
> Subject: [ Cloud Computing ] Compute surface as a traded commodity?
>
> Bruce wrote:
>
>
> Will the "Cloud" ever become a pool of hosting providers who
> pitch
>
> their
> prices, SLA's and storage cost so customers will come to their "cloud"
> for
> services?
>
>
> I foresee a time into the future where the compute surface is
> virtualized
> and standardized enough that hosting contracts can be traded as a
> commodity
> on a market, rather than the RFP type process we have today.
>
> Such agreement would allow business to place a deal on an exchange
> much like
> FX today and get bids to run based on some parameters. IT hosters
> would price the deal with a spread in the same way as a currency trade today,
> the
> deal done in a matter of seconds and hosted for the duration of a
> contract
> window.
>
>
> If virtualization vendors deliver on their hybrid end-vision, this
> could be
> a reality of packaging workloads with SLA manifests and using internet
> vMotion-type tools to migrate. It would fundamentally change the way
> we write software frameworks and applications themselves to be more self
> contained and highly standardized to achieve the best 'tradability'.
>
> Interoperability via standards between VM platforms, portability of
> data,
> code business logic and processes are all key to how we build out the
> Cloud.
>
>
> Such openness may be a far extreme view, but would you want the
> opposite view of the world where switching costs and lock-in are extremely
> constraining and we are forever stuck in a platform cycle of
> distribute-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-questions
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
-~----------~----~----~----~------~----~------~--~---
Posts
No comments:
Post a Comment