Over the past several weeks we have been discussing some of the mistakes made in early cloud deployments. As a refresher, here are the issues we outlined:

1. Not understanding the business value
2. Assuming server virtualization is enough
3. Not understanding service dependencies
4. Leveraging traditional monitoring
5. Not understanding internal/external costs

This week, we're exploring the problems associated with leveraging traditional monitoring solutions in a Cloud delivery paradigm.

There is a common assumption that leveraging a Cloud operating model will save money. We won't debate the accuracy of this statement (tune into our next installment for that discussion!). For the purposes of this discussion, we'll assume it's true. But if that's the only benefit who, besides your CFO, really cares? Everyone wants to save money, but if you told a critical business customer that you were going to adopt a new computing model that would save money but introduce risk, do you think they would be supportive? Probably not: they wouldn't find the risk/reward ratio acceptable. In order to shift that ratio, you need to improve the quality of the service(s) offered; otherwise you've simply lowered the cost of an increasingly commoditized service.

Even today, many enterprises rely on their end users to notify them of service outages or slowdowns (sometimes referred to as brownouts). When they finally become aware of a critical issue, the typical diagnostic approach entails getting the individuals responsible for each technology silo to circle up on a conference bridge until the problem is isolated and resolved. The Cloud makes this remediation process difficult to execute: good luck getting your Cloud provider on that bridge! Cloud makes the underlying infrastructure supporting an application/service fluid, rendering traditional resource-based monitoring tools useless in a diagnostic process.

In today's increasingly complex IT environment, CIOs must invest in real-time monitoring, metering and logging that incorporate an application and services performance and health discipline. If you've been around long enough to recognize this as a drumbeat from 10 years ago during the dot.com expansion, you're partially right but there are some key differences. Consider the example of a simple transactional application - back then you had some web servers, some application servers, and a database... if you were really sophisticated a link to some legacy system to check inventory before taking an order. It was ‘clean' - in your datacenter, or hosted entirely by an external provider. Contrast this to a similar application today: probably a mashup with services from external security providers, checking inventory from a handful of suppliers, end-user visibility into the fulfillment process, and real-time delivery information from the shipper of your choice. Where are those servers, the data stores, and what's the network that connects them all? Can you detect problems before hearing from users? Better yet, how about a slowdown...do you know where to look?

The tools available to help you provide premium services to your business consumers on commodity infrastructure have advanced dramatically over the past few years. Some are capable of accurately predicting future performance problems without the typical (and often unreliable) approach of monitoring static thresholds. However, tools alone can't fix this - what would your operations team do if notified there would be an outage in 90 minutes, get another cup of coffee?

The point we are making is that traditional enterprise systems management (ESM) approaches are no longer sufficient - applications must be instrumented independently of the physical resources they are running on. Operations teams need to understand true service expectations and the business policies/priority of multiple applications. They must have the tools to help them detect deviations from normal behavior, and the expertise to understand if that deviation is a business change or the symptom of a problem. Ideally, they need dynamic execution management tools (informed by the monitors) to shift application resource assignments before a user notices the problem.

As you plan to adopt Cloud operating models, don't just think about the physical resources. Take the time to upgrade your ESM tools and processes to ensure users get both the cost savings and improved user experience that Cloud can offer.