Utility Model of Consumption & Allocation

[Jian Zhen]

There are 5 principal characteristics defined on page 16 and 17. I
generally agree with all except #5, Utility Model of Consumption &
Allocation.

My question is what if a "cloud" does not offer the "pay-by-the-bite"
model? Is it no longer a cloud? How do we define "pay-by-the-bite"?
What if it's based on a resource pool model? or a MRC model?

I know many service providers and ISVs aren't necessarily think AWS's
pricing model is the only way to go, including the guys from Eucalyptus.

So I am wondering whether this is really a defining characteristics of
clouds.

[Hoff]

Perhaps "pay" is not the correct word?

Consumption and allocation are fairly straightforward and I think are
absolutely Cloud characteristics. Regardless of whether it's "paid"
for
versus "accounted" for is a valid semantic differentiation.

So I think the criteria is correct, but perhaps the example appeared
too
specific and limiting?

If I added sections on chargeback or simple allocation, would that
suffice?

/Hoff

[Jian Zhen]

Alright...@beaker says I must respond here, which I was planning to
anyway :)

So I think the main point is that we need to ensure pricing model does
not become a defining characteristic.

There are three modes of consumption that I see. First it's allocation-
based consumption. Example would be EC2 where you allocate a VM with a
certain amount of CPU/memory and you pay for that allocation.

Second and an extension to the first model would be a resource pool
model. In this case, a resource pool, say 5 GHz of CPU and 10GB of
memory, is allocated, and you can spin up as many VMs as you like to
consume that pool of resource. This model is an extension of the first
because it's still based on allocation. The advantage of the second
model is that you have much better control over the resource pool and
if you know your applications well (e.g., the amount of CPU/memory
they consume), this will be much more cost effective. Both of these
models require customers to pay for the allocated resources.

The third model is a true utility model of consumption. This model
does not require any allocation or resource pool and the cloud would
simply allow you to use resources as needed. For example, your
application may only use 300 MHz of CPU and 200MB of memory during
normal operations and that's all you pay for. If the application
spikes to use 1 GHz of CPU and 3 GB of memory for a period of time,
you pay for that also. This model is a lot more unpredictable but
could potentially be a lot cheaper than the previous two.

So maybe change the title to "Utility or Allocation-based Consumption"
and clarify the different models in the text?

[Hoff]

This isn't about a "pricing model" but rather how resources are
allocated and consumed. I think
I may have confused things, however.

I bet if I didn't include the second paragraph (the example) which
detailed how AFTER allocation
and consumption we dealt with how accountability (and thus payment)
can be reconciled, you might
not have brought this up.

Payment wasn't the focus. How resources are allocated and consumed
(dynamically) is.

I am uncertain that I truly understand your point. At first I thought
you were arguing about using the
notion of "payment" at all, but all three of your examples involve the
same, so the
utility model of consumption and allocation seems to fit exactly your
definition.

Again, I can certainly expand the examples describing what
"allocation" means
(such as yours below,) but I am still at a loss for why I would change
the criteria
from "Utility Model of Consumption & Allocation" to "Utility or
Allocation-based Consumption"

/Hoff

[Niall Inglis]

While including CPU cycles and memory usage, dont forget the other consumables like bandwidth usage. Although as a consumer you probably have an all-you-can-eat agreement for internet bandwidth, your ISP is paying their ISP by the GB for what you are eating through their interconnect agreements. Any cloud provider who doesn't consider the cost of data delivery around their cloud is going to lose out and inter-cloud data transfer charges will encourage sticking with one provider.

Niall

[Jian Zhen]

Perhaps you are right, the criteria can be what you have and
allocation and consumption are the right words. So if we can remove
the indication of billing model (pay-by-the-bite) then I think it's
fine.

Jian

[ubergeeken]

Jian, I like the three models defined here and see a potential fourth
that is a hybrid of #2 and #3. The model listed in #2 in which a set
CPU and memory would now be considered the CPR (Commited Processing
Rate/Requirement). This would be charged based on use for the life
cycle of the environment.
To this hybrid model also add the features of #3 as follows-. Over
subscription of CPU and memory EPR (Excessive Processing Rate) would
be a scaled and charge based on the % above the CPR. Costs MUST be
controllable here, so I propose that the EPR only be charged against
pre-paid credit system. If no credits are "in the bank" then the
operations are capped to the CPR.
The hybrid that I've proposed here is similar to what you may in a
frame-relay circuit CIR/PIR. To that extent I can see a credit system
for EPR of the Cpu/memory and/or bandwidth used by the consumer.
Greg Guilmette

On May 9, 7:14 pm, Jian Zhen <zhe...@gmail.com> wrote: