« The Cloud's Kicking Mike D's Butt | Main | Virtual Infrastructure Optimization and Virtual Infrastructure Assurance »
Tuesday
Mar102009

Pricing, Costing and Cost-tuning PaaS

Geva Perry posts an interesting piece about perspectives on how the cloud pricing models might affect application architectures. 

One of the more interesting thoughts this kicked off for me is that a well-instrumented, granular IaaS or PaaS platform offers the application architect and the IT manager a reasonable means of regular evaluation of application efficiency.  If used as such, the detailed bill from your *aaS provider becomes a means of providing successive visits to the cost-efficiency of your app based on real usage.  As Geva puts it, "...your real-time bill from your cloud provider will scream at you if a certain aspect of your application is particularly expensive, and it will do so at a very granular level, such as database reads and writes."

This starts to suggest that, as both an architect's iterative refinement tool and as an IT manager's cost-management / SLA tool, a dashboard that calls out major changes or the loci in an application that have responsibility for the greatest absolute cost or greatest variation in cost (based on usage patterns) would be a very useful product (... no doubt, delivered as a service!). 

Does anyone currently provide this kind of application cost monitoring, tied specifically to the architectural modules that make up a cloud based application?

Thinking Out Cloud: Cloud Pricing and Application Architecture

  1. It's a pay-per-use model. Any optimization of resource utilization, big or small, will yield cost-savings proportional to the resource savings.
  2. It is typically component based pricing. In AWS, for example, there are separate charges for CPU/hours, incoming and outgoing data charges for the servers, separate charges for the use of the local disk on the server (EBS), charges for storage (storage volume and bandwidth), charges for the message queue service, etc.
  3. You get a real-time bill broken down by exact usage of components (at least on AWS).

In other words, whether you were planning on it or not, your real-time bill from your cloud provider will scream at you if a certain aspect of your application is particularly expensive, and it will do so at a very granular level, such as database reads and writes. And any improvements you make will have a direct result. If you reduce database reads and writes by 10% those charges will go down by 10%.

This is, of course, very different than the current prevailing model of pricing by discrete "server units" in a traditional data center or a dedicated hosting environment. Meaning, if you reduce database operations by 10%, you still own or rent that server. The changes will have no effect on cost. Sure, if you have a very large application that runs on 100 or 1,000 servers, tan such an optimization can yield some savings and very large-scale apps generally do receive a much more thorough cost analysis, but again, typically as an afterthought and not at such a granular level.

, ,

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.