The long anticipated rise of cloud computing is finally taking hold, with analysts reporting more investment in public clouds than private clouds, and suggesting that half of all production applications will be running on public clouds in three or four years.

The allure of public clouds springs from advantages like improved service scalability, reduced operational costs, and an increased focus on business goals and strategies instead of the technology needed to pursue them. However, there is a cost to that flexibility and economy, in reduced visibility of application and infrastructure health. Without direct control over the cloud infrastructure itself, traditional application performance management (APM) tools may prove impractical to deploy and manage.

I recently read a story about a war of words between a leading platform as a service vendor and a disgruntled customer, who discovered that they weren’t actually getting the amount of virtual computing capacity that they had been told they were getting.

Putting aside the customer’s justifiable indignation at not getting the resources that they believed they were paying for, the real story for a cloud consumer here (or an APM Product Manager) is that the tools they were using to monitor their workloads didn’t really provide them with a complete story. Then, when the continued mystery warranted a deeper-dive tool, it appears that they were pressured or influenced into purchasing a particular cloud APM tool because of a relationship between that tool vendor and the PaaS provider.

This suggests (and logic supports) that customers are better off using objective APM tools when monitoring workloads on public clouds, whether those workloads are running on a Platform as a Service (PaaS) solution like Heroku, or an Infrastructure as a Service (IaaS) solution like Amazon or Rackspace.

We generally espouse such a practice to help a customer maintain a posture of portability, so they can nimbly move workloads around to different cloud platforms, yet maintain continuity in their real-time and historical view of application health, without having to train their eyes on a new health dashboard whenever they move their workloads. We can employ the slightly suspicious sounding argument that a customer should not necessarily rely on his service provider for monitoring tools, since that provider has a vested interest in painting a rosy picture. Even in the presence of SLAs, a cloud tenant with no access to the infrastructure is somewhat at the mercy of his provider for performance reporting. An APM solution that the customer can deploy and configure himself provides a level of “checks and balances” oversight.

It can be impractical for customers to deploy legacy monitoring tools when moving to public clouds, so there is a need for a solution that can be deployed within those public clouds, in their own little sphere of control where their application VMs reside. By adopting an elastic and scalable ­yet small and easy to deploy architecture, as well as the ability to embed additional monitoring technology into base VM images, this solution enables robust APM, even when users can only deploy simple Linux VMs to someone else's cloud.

Jim Young is Information Development Manager, IBM Cloud and Smarter Infrastructure

Related Links:

www.ibm.com