Custom Search
Tuesday, February 10, 2009

Operational Cost Transparency

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
A90%50%
B10%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).

2 comments:

enkiguy said...

When the title of your article came up in my search, my first thought was "oh, finally someone's discussing the elephant in the livingroom about Cloud Computing!" but it wasn't to be.

Cloud computing provides operational cost transparency in another way: by lumping all the operations costs into a single number (with the exception of deployment and management labor, which often incorrectly assumed to be much lower with cloud deployments.)

As a cloud vendor, what I run into most often is that people shop on price, but are comparing apples to oranges: they compare our service (or Amazon) to buying a server or to colocation. Yet buying a server doesn't represent operations costs at all: it's only the first of many. Colocation also doesn't represent them well because again the costs focus on the servER rather than the servICE. This is why, if you shop on price alone, Cloud always loses out. It also means that Cloud vendors have some education to do around accounting for operations costs. I know I spend at least 75% of my sales effort on education, often in the form of business consulting for my potential customers.

Those who choose cloud either see a critical requirement being met by its unique features, or they understand the cost structures of the alternatives well enough to see that there is an economic advantage to choosing a cloud deployment despite its apparently higher price.

-Eric Novikoff
ENKI
http://www.computingutility.com/

Jon Moore said...

@Eric: thanks for the comment. You are absolutely right that there is a difference between racking and maintaining hardware (the servers) and deploying and managing the software that runs on them. Hardware only accounts for 7% of server TCO.

My previous post on hardware deployment learning curves suggests that cloud computing vendors have a massive cost advantage over an in-home datacenter on this front. However, infrastructure-as-a-service vendors like AWS don't free you from that second phase--managing what software is running where.

Platform-as-a-service offerings like Google App Engine, Mor.ph, and others actually free you from a lot of traditional operating activities (and costs), so in my mind they are even more compelling solutions.

Post a Comment