The Art of Writing Software

Cloud Computing Cost Profiler

Categories [ Cloud Computing Economics ] Tags [ Agile software development, Amazon Web Services, cost, Google App Engine, incremental funding method, profiling, ROI ]

On Tuesday, William Louth posted an article describing what he calls Activity-Based Costing (ABC)--essentially a profiler for testing a cloud computing implementation. He describes hooks that can be applied around API calls to services like a Google App Engine platform or an Amazon Web Services S3-style service. In turn, when you run a test implementation, you can gather a recording of the API calls you make and get an understanding of how much your implementation will cost in terms of cloud computing charges.

This in itself is a very useful tool, especially when used in conjunction with a rigorous product development process. One such method is the Incremental Funding Method (IFM), which is an ROI-based prioritization scheme for agile software development. This method requires placing a (projected) revenue impact for implementing a feature; it also requires a cost estimate on the feature. Unfortunately, I think far too often development teams provide an estimate simply in terms of level of effort (e.g. story points), without including a formal analysis of operational cost. While this provides one measure of the cost involved in developing the feature, it does not provide a complete picture, often leaving product owners with incomplete information (they assume the feature will simply be "deployed to production").

If you are considering deployments or development on cloud computing infrastructure, you are almost forced to consider operational costs up front. This can be done at two levels: once, with traffic estimates, as an architectural proof-of-concept, and then again, using a profiler like Mr. Louth's to validate the cost models once the implementation is complete. This can save you from what looked like a profitable feature (because easy to implement) but is actually revenue negative (because costly to operate).

I think more development tools like Mr. Louth's are needed (his works for Java, against some mock cloud services), and will no doubt be implemented by the development community in due time. Kudos to Mr. Louth for a great idea.