Cloud Application Performance Management via Nouns and Verbs
February 11, 2012
The cloud computing model of services-based computing has changed the way we not only ‘architect,’ ‘structure’ and ‘plan’ software applications, it has also changed the way we, subsequently, need to ‘deploy,’ ‘test,’ ‘monitor’ and ‘manage’ cloud-based applications.
Now that’s a lot of nouns (actually they’re mostly verbs too) relating to the actions we take upon our applications, so what do we really mean by these terms?
The fact is that cloud computing has become enough of a tangible reality to warrant the development of testing procedures that reside and operate inside the cloud…
Now all this talk of "inside the cloud" gets a bit woolly and out of hand, which is why I like to try to be more specific (if long winded) and say instead:
"Application testing must now migrate to a point where it is executed inside the data center housing the hosted instances of virtualized application servers and their supporting volumes of data, a Software-as-a-Service model known as cloud computing."
Okay so now we know in no uncertain terms what we are talking about – why bother testing in the cloud in the first place?
Why not just test on-premise, on "the ground" so-to-speak, with all the available resources (dummy data, emulators for mobile applications, etc.) that the unit testers need to put an app through its paces?
Why Test in Cloud Reason #1 – Load testing a cloud application on-premise never truly reflects the impact of real-world data volumes as they spike erratically. Actually, this is pretty much true for non-cloud-based applications, but it is a great truism for cloud apps too.
Why Test in Cloud Reason #2 – Testing inside the cloud model should generally always be quicker, more cost-effective and should pave the way toward higher-quality applications.
Why Test in Cloud Reason #3 – Performance validation inside post production environments can deliver "consumption-based" performance testing of Web 2.0 and mobile apps charged in an on-demand pay-per-use model. Yes – testing becomes more service-based; what else would you expect inside the cloud model?
What happens if I don’t test?
Failure to follow testing procedures commensurate with the "mission criticality" of the application (and data) in question can see the IT shop hit performance bottlenecks, which in turn can have a direct impact on business performance and the customer’s "time-to-market" (to use the marketing manager’s favored term) and make profits.
Composite Component Complexity
Given the rise of composite application architectures with many moving parts, cloud-based testing "in situ" can be an essential mechanism to identify points of failure prior to deployment.
If you are not familiar with "composite applications" as a term, these apps represent "aggregations of different user interface components" that are a) loosely coupled and b) then brought together to support the resulting need for inter-component communication.
Composite application components can then be deployed for additional reuse in other composite applications where relevant. So the picture (I hope) becomes much clearer now: testing cloud applications with an exhaustive approach to performance, security and robustness is a more complex undertaking than many managers and users might at first estimate it to be.