"Without rock-solid service-level agreements that include substantial financial penalties for nonperformance, trusting our core applications to cloud providers just doesn't seem worth the risk," says one respondent. That's all well and good, but responsibility goes both ways. Look in the mirror and repeat after me: "We need to measure our internal traffic and bandwidth levels before even contemplating any--or any additional--cloud expansion."
A key requirement to getting this data is monitoring your existing traffic and connectivity. Surprisingly, however, many organizations have no overall monitoring in place for their internal operations. John Drew, director of managed services at GreenPages, says that less than 30% of the clients he works with have systems in place to monitor their internal networks.
"Most just tend to ignore internal performance until there's a problem, then do wholesale infrastructure upgrades when they start to have problems, which typically makes the issue go away, for a while," Drew says.
If you don't understand what's going on inside your network, you're going to be starting with incorrect data to judge your cloud. Baseline tracking is a must, regardless of your cloud plans. Take your pick of vendors--the field is large and includes CA, Hewlett-Packard, NetIQ, and NetQoS. This tracking will set the basic framework for monitoring and can expand beyond your location and into your applications themselves. Check out Michael Biddick's review of nine APM suites.
2. Work With Your ISP
We're frankly surprised that service providers get such a universally bad rap. It must be the fact that they're the first people we think of when there's an Internet issue--kind of like swearing at Bill Gates when Office crashes.
In reality, your connectivity provider can be invaluable in helping you understand, monitor, and troubleshoot cloud applications, yet surprisingly, many IT groups never even ask for assistance. That's too bad, because providers usually have a multitude of services that can help IT proactively monitor traffic. For example, a regional bank that was experiencing major performance problems with its cloud application enlisted its ISP out of desperation after weeks of slowdowns. The provider was able to leverage its monitoring tools to isolate the issue upstream at the cloud provider, not the client site or the ISP.
Remember, the ISP's primary job is to provide a pipe. It typically doesn't care what you use it for. SLAs are triggered by specific outages, not performance metrics for particular sites or apps.
If you're not sure where problems are originating, ask for data flow monitoring, including protocol analysis. The ISP likely already has the tools; it won't necessarily provide the service for free, but it will cost a fraction of purchasing the capabilities yourself.
One other tip: Monitor your connections from a remote location. A simple traceroute should be able to outline the full connectivity path beyond your provider. Set up baseline router monitoring to watch your site, the provider, and the next two hops. You can configure this mapping from both your main office and a remote site.
We're surprised how many cloud providers are caught telling fibs when they claim performance bottlenecks originate in customers' lines. It's important to document monitoring results so you can pin down the cloud provider or ISP when a slowdown is on its end.