The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jonathan Allen on Nov 18, 2009
Cloud computing is a game changer for developers. Not because it requires a new architectural model, that is driven as much by fads and fashion as it is by actual hardware requirements. Nor is it the seemingly endless capacity with near-perfect scalability that the cloud is promising. The game changer is how poorly performing code now has a real price in hard currency.
Since personal computers replaced time shares, performance has been a nice to have. Generally speaking, either the application performance is good enough for the hardware it is running on or it isn’t. You don’t gain anything by dropping your peak CPU utilization from 90% to 81%, expect perhaps a small discount on your electric bill.
With the cloud platform, dropping your CPU utilization by 10% directly translates to a 10% reduction of you monthly bill from your cloud provider. For example, Windows Azure costs 12 cents per machine hour of computational time. Using this knowledge and a good profiler, you could literally say a certain block of code is costing the company X dollars per month.
Once the cost of poorly performing code is know, companies can then make economically sound decisions on whether or not to spend time and money to fix it. Simply by comparing the monthly cost of the code with the salary of a developer tasked with improving it, engineering managers can say with certainty how much time can be spent before the laws of diminishing returns kick in.
The performance=money equation will also bring dynamically typed languages into sharp focus. If we have truly reached the time where dynamically typed languages are “fast enough”, then that will be reflected in the price for renting cloud servers. If, on the other hand, production costs start to skyrocket then there will be irrefutable evidence that a statically typed language is in order. But of course this will have to be decided on case-by-case and project-by-project basis.
Mobile and the New Two-Tiered Web Architecture
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
While I agree with your premise that poorly performing code costs more (and like that it has been called out that way!), I do have one nit to pick:
CPU Time != Machine Time
I remember back in my green screen days on IBM big iron when you were billed for the time the actual processor was used. One of my 'accomplishments' in those days was to rewrite an application such that the CPU cost was an order of magnitude lower.
Fast forward 20-some years, and I was using Amazon EC2 to host some applications. Even if the application was completely idle and didn't issue a single call to the CPU, I was getting billed for the machine time. To be honest, I like that model better since it's much, much easier a concept to grasp - if the instance is up, the meter is on.
Dave Rooney
The Agile Consortium
Upon rereading the documentation on Windows Azure, I have to agree that it currently follows the EC2 model. So maybe things won't be so cut an dry after-all.
Well, it depends on how an application is running.
If you're using an instance as a server, essentially a virtual host, then there you're just changing the billing model for hosting.
If, however, you fire up an instance, run an application, grab the results and shut down the instance, application performance is much more important and your assertion is quite correct.
Dave Rooney
The Agile Consortium
I think Google App Engine might charge by CPU time. They do have a CPU quota on operations (presumably to curtail runaway applications) but I think you can pay to increase that quota.
A Unified Approach to Performance Management and Cost Management for Cloud Computing
www.jinspired.com/products/jxinsight/meteringth...Cloud Computing with JXInsight Probes
JXInsight Probes provides an activity-based costing (ABC) solution that assigns costs to applications, services and components based on resource consumption. The probes runtime meters the usage of resources by applications, services and components from within the cloud allowing IT service management to combine key performance indicators (KPI) from both application performance management and cost management domains into a single management model. The probes runtime dynamically maps the software activity to service cost centers and the usage of one or more resources to meters. It enables organizations to recharge (charge back) cloud computing costs to departments within an organization via the mapping of request processing patterns to service profiles.
Simply by comparing the monthly cost of the code with the salary of a developer tasked with improving it, engineering managers can say with certainty how much time can be spent before the laws of diminishing returns kick in.
This is a terrific reason to shut down non-performing assets, restructure non-performing teams, and downsize non-performing individuals. I can foresee this being used by middle management to justify their continued employ at the expensive of development positions but has little to do with the quality of the developer, the quality of the code being improved, or the cost to the organisation of an application that doesn't meet the business needs. CPU Time != Business Benefit.
Further reading on this.
williamlouth.wordpress.com/category/cloud-compu...Summary
">
Cost management is important for companies using cloud computing as a platform for application delivery as it provides a framework for planning and controlling decisions related to such services in terms of service value and computing cost. It also serves to help cloud computing vendors to deliver resources in a cost effective manner whilst maximizing value. Finally, knowledge of costs is required to make intelligent decisions related to cost-justified service quality.
CPU Time != Business Benefit.
That is why we have cost-benefit analysis. But if you have not got a clue to the cost of a service then how does one effectively manage the business.
By the way in JXInsight Probes technology you can create multiple meters some cost based some benefit based. Meters need not be technical system counters then can represent higher level business execution constructs. In addition your probes can have multiple costs centers some operational and others not.
Irrespective of the cloud providers billing mechanism you should still be metering an application based on common resource meters including those related to cloud interactions otherwise you have an uphill struggle in deciding whether another cloud platform would offer cost savings. Billing != Metering but Metering ~=> Billing.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
9 comments
Watch Thread Reply