Hi! Comments inline. On 20/05/14 21:58, "Zane Bitter" <zbit...@redhat.com> wrote:
>On 20/05/14 12:17, Jay Pipes wrote: >> Hi Zane, sorry for the delayed response. Comments inline. >> >> You are assuming a public cloud provider use case above. As much as I >> tend to focus on the utility cloud model, where the incentives are >> around maximizing the usage of physical hardware by packing in as many >> paying tenants into a fixed resource, this is only one domain for >> OpenStack. > >I was assuming the use case advanced in this thread, which sounded like >a semi-public cloud model. > >However, I'm actually trying to argue from a higher level of abstraction >here. In any situation where there are limited resources, optimal >allocation of those resources will occur when the incentives of the >suppliers and consumers of said resources are aligned, independently of >whose definition of "optimal" you use. This applies equally to public >clouds, private clouds, lemonade stands, and the proverbial two guys >stranded on a desert island. In other words, it's an immutable property >of economies, not anything specific to one use case. This makes perfect sense. I¹d add one tiny bit though. ³Šoptimal of those resource will *eventually* occurŠ². For clouds, by rounding up to the nearest flavour you actually leave no space for optimisation. Even for the lemonade stands you¹d first observe what people prefer most before deciding on optimal allocation of water or soda bottles :) > >> There are, for good or bad, IT shops and telcos that frankly are willing >> to dump money into an inordinate amount of hardware -- and see that >> hardware be inefficiently used -- in order to appease the demands of >> their application customer tenants. The impulse of onboarding teams for >> these private cloud systems is to "just say yes", with utter disregard >> to the overall cost efficiency of the proposed customer use cases. +1. I¹d also add to add support of legacy applications as another reason for the "utter disregard² > >Fine, but what I'm saying is that you can just give the customer _more_ >than they really wanted (i.e. round up to the nearest flavour). You can >charge them the same if you want - you can even decouple pricing from >the flavour altogether if you want. But what you can't do is assume >that, just because you gave the customer exactly what they needed and >not one kilobyte more, you still get to use/sell the excess capacity you >didn't allocate to them. Because you may not. Like I said above, if you round up you most definitely don¹t get to use the excess capacity. Also, where exactly would you place this rounding up functionality? Heat? Nova? A custom script that runs before deployment? Assume the tenant doesn¹t know what flavours are available, because template creation is done automatically outside of the cloud environment. > >> If there was a simple switching mechanism that allowed a deployer to >> turn on or off this ability to allow tenants to construct specialized >> instance type configurations, then who really loses here? Public or >> utility cloud providers would simply leave the switch to its default of >> "off" and folks who wanted to provide this functionality to their users >> could provide it. Of course, there are clear caveats around lack of >> portability to other clouds -- but let's face it, cross-cloud >> portability has other challenges beyond this particular point ;) >> >>> The insight of flavours, which is fundamental to the whole concept of >>> IaaS, is that users must pay the *opportunity cost* of their resource >>> usage. If you allow users to opt, at their own convenience, to pay only >>> the actual cost of the resources they use regardless of the opportunity >>> cost to you, then your incentives are no longer aligned with your >>> customers. >> >> Again, the above assumes a utility cloud model. Sadly, that isn't the >> only cloud model. > >______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - Dimitri _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev