[ Cloud Computing ] Re: Compute surface as a traded commodity?

Wholeheartedly agree on all your points including the last one.

-----Original Message-----
From: Tim Freeman [mailto:tfreeman@mcs.anl.gov]
Sent: Tuesday, December 16, 2008 2:39 PM
To: cloud-computing@googlegroups.com
Cc: JL Valente
Subject: Re: [ Cloud Computing ] Re: Compute surface as a traded
commodity?

On Tue, 16 Dec 2008 16:52:17 -0500
"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
-~----------~----~----~----~------~----~------~--~---