[nikcub]

There is a perverse conflict with platform service providers - the worse your scheduler performs the more profitable your service will be.

You replace intelligent request scheduling with more hardware and instances, which you charge the user for.

How much investment is there in platform service providers towards developing better schedulers that would reduce the number of instances required to serve an application? That answer, in this case, is "not a lot"

The incentives between provider and user are not aligned, which is why I am more inclined to buy and manage at a layer lower with virtual machines.

Edit: AppEngine went through a similar issue. Here is an interesting response from an engineer on their team:

https://groups.google.com/forum/#!msg/google-appengine/y-LnZ...

[praptak]

> There is a perverse conflict with platform service providers - the worse your scheduler performs the more profitable your service will be.

I think the practical significance of this kind of incentives is overrated. The company I work for does outsourcing work, paid by hour. Do they have incentives to make me produce less so that their customers pay for more hours? Theoretically. Do they act on it? Hell, no - there is competition and customer satisfaction matters.

[quahada]

The business of government contracting shows these conflicts of interest are real and lead to Billions of $ of waste annually.

There is plenty of competition for government work, but there are many ways to game the system even in the rare truly open/fair competitive bids.

[chc]

That's because competition for government work is not really based on customer satisfaction in the same way it is in other industries AFAIK.

[nostrademons]

In theory, the service provider could just switch to a better scheduler and raise their rates to compensate, since the TCO for a customer would go down correspondingly. Their costs go down, their profits go up, and customers still benefit.

Prices are usually determined more by competition than by technical factors. Unfortunately, there's a fair bit of lock-in to PaaS vendors, which is the real reason I'd be skeptical about building a business on them. The nice thing about the VM layer is there's a well-documented, public API between your code and the platform, so when your service provider raises their rates, you can switch to another one or operate your own hardware.

[jules]

What you could do is price based on the value you provide.

You could price per request that you serve for your customers. Of course that just puts the perverse incentive on your customers, since now the service provider is bearing the cost of a nonoptimized application. The client doesn't care much about the weight of a single request, since the cost to him is the same (well except for latency).

So what you could do is define a 'typical request' by running a suite of open source web application on the service provider. This way you see how much hardware is required for a given throughput of 'typical requests'. Put a price tag on that. Now pricing also becomes much clearer for the customers: they know that if their application's requests are roughly of the same weight as open source web application X, Y and Z, and if they serve N requests per month, then their cost will be roughly N*(price of 1 typical request) per month.

Now the service provider has the incentive to optimize its hardware and services, because then it can run more typical requests at the same cost. The client has the incentive to optimize his application, because then he will use fewer typical request units, and hence pay less.

You could also determine the cost of a typical request by averaging over all of your clients' applications, instead of a suite of open source applications.