Operational Cost Transparency
Categories [ Cloud Computing Economics ] Tags [ Amazon Web Services, cost, Google App Engine, pricing, ROI ]
Cloud computing providers have gained a lot of attention based on their ability to provide massive economies of scale in server deployment; however, their pay-as-you-go billing methods (e.g. Amazon EC2 and S3, Google App Engine) actually provide something of far more strategic value to a business: operational cost transparency.
This actually works best for web sites and web services built according to RESTful design principles: namely, "everything is a resource" (i.e. everything gets a URL) and "use the standard HTTP methods", which basically boils down to: your HTTP access logs contain pretty much all the information needed to understand what's going on under the hood of your application in production. If you are clever, you can develop individual features or products to have their own sets of URLs--this lets you vertically partition your services according to URL.
Normally, vertical partitioning is a way to provide scalability for your application, so that you can easily allocate hardware resources to different aspects of the application independently. Doing this at the URL level by lumping related functionality under a common URL prefix lets you do layer 7 load balancing across a set of hardware. If you have a sufficiently virtualized data center (perhaps rented from a cloud computing vendor like Amazon Web Services), then you can actually allocate servers on a per feature basis.
If you couple this with a well-provisioned web analytics system like Omniture or Google Analytics, you can now map individual feature usage to actual resource usage (in terms of HTTP request traffic). If you then couple this with the usage-based billing from your cloud computing vendor, you get a very realistic ROI picture of your application's features. This provides valuable feedback on your revenue forecasting process for new development, but also lets you identify losing features that can be successfully cut (particularly if they add significantly more to system complexity or operational cost than they do to overall ROI).
For example, consider these two features:
| Feature | % revenue contributed | % operating costs |
|---|---|---|
| A | 90% | 50% |
| B | 10% | 50% |
If you simply removed feature B, your overall profitability nearly doubles (up 80%)! You'll take a small (10%) hit to revenue, but you'll free up 50% of your operating budget for a new venture. In an economic recession where new or additional funding is scarce, this may be the major avenue you have available for funding new products. At the very least, the cost transparency gives you enough information to make an informed strategic decision.
As we mentioned in a previous post, new development can also make use of operational cost transparency, whether by prototyping and using a usage cost profiler, or by contemplating a cloud deployment using a basic architecture, traffic estimates, and some quantitative analysis. Even if you don't ultimately deploy to a cloud vendor due to internal security or operational control concerns, they are a convenient way to become cognizant of operational costs which are too often ignored (as in development methodologies where development effort is the primary measurement of cost, like many agile methods) or undifferentiated on a per-feature basis (i.e. we may know overall operational costs of an application due to staffing and hardware needed, but we may not be able to break that down into more granular information).