With SaaS, IT no longer owns responsibility for service levels, right?

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

If Software-as-a-Service (SaaS) is the future we have to pay closer attention to the service levels users are getting.  Obvious?  Maybe not. The fact is if users can't access a cloud-based service they are going to call IT, not the service provider. Users don't care if the problem is located in infrastructure operated by IT, the ISP or the cloud service provider.

Here are six myths that can derail your use of the cloud, all of them grounded in a general belief that once we move to the cloud IT no longer owns direct responsibility for service levels. Falling for them can put you on a path to protracted service outages and frustrated users.  In addition, I try to shed light on what's needed to fill in some of the gaps that exist when it comes to monitoring SaaS applications:

* "I don't need to monitor. I have a guaranteed SLA from the provider."  Your SaaS service provider is likely able to run their data centers with higher availability than most IT organizations, but they are not 100%.  Service level guarantees are great, but if you aren't monitoring your SaaS service, how do you know your SLA is actually being met?  In addition, service level guarantees only cover outages the provider can control, i.e. their own networks, servers and applications, not any of your infrastructure and not the Internet service providers that connect you. You're on your own to monitor and manage those.

* "I don't need my own monitoring tools.  I use the service provider dashboard."  As with the guarantees themselves, service health dashboards only cover the service provider's infrastructure, not the end-to-end service.  These dashboards provide generic information that may or may not be relevant to your users and may not be up to date. Remember, they are built to be general status communication tools, not real-time monitoring solutions.

* "I didn't monitor your previous hosted email service. Why monitor Office 365 now?"  Consuming apps from the cloud is not the same as consuming managed/hosted services.  Managed Service Providers (MSPs) and Hosters are often running dedicated infrastructure for you and monitor those services on your behalf.  Those services often extend to provide monitoring and management of your on-premise infrastructure as well.  While there are managed service providers offering value-added services around Office 365, if you buy directly or through a reseller, you have to monitor the solution yourself.

* "My existing tools monitor my cloud apps as well as my on-premise apps."  Not really.  Most traditional systems management solutions (e.g., CA, BMC, Tivoli, System Center) are designed to monitor systems where they have direct access to the applications, servers, log files and SNMP messages. They are not built to monitor services where the majority of the service infrastructure lies outside the IT periphery.  Network management tools tend to focus on low level protocol and network device monitoring and diagnostics, and are not built to monitor user experience.  Both of these tools can be difficult and costly to use.

On the other end of the spectrum, Web monitoring solutions often either run generic protocol tests or run from the providers' locations rather than within your own network.  None of these solutions can provide active, end-to-end monitoring of service performance and user experience from behind your firewall to the service provider and back.

* "I don't need to monitor.  My users tell you when they are having problems." This may be okay for some less critical applications, but for most organizations these days, communication and collaboration apps like email are mission critical.  If the service is down, so is your company.  So what happens when the users report a problem?  Where do you start to look?  Do you immediately get on the Office 365 support line?  It's probably not even a Microsoft problem.

Speed to resolution is key.  You want to be notified before users are impacted and when an issue is identified you want to isolate it and get it resolved as quickly as possible.

* "Moving to the cloud means monitoring is someone else's problem, right?"  The cloud provides many CapEx and OpEx benefits for IT; e.g., fewer servers and apps to directly manage and house. It also provides built-in world-class features, service, and security, regardless of budget and staffing. However, local IT is still on the hook for the quality of service realized by users.  When a user has an issue they will call you, not Microsoft.

Moving to the cloud, doesn't mean monitoring goes away, but it does fundamentally change the requirements. You need to monitor these solutions, but you need to look at different approaches, ones that are designed to meet the needs of the cloud.  You have to be able to monitor and troubleshoot infrastructure you cannot touch - the end-to-end service delivery chain from your premises, through the various Internet service providers, to the application provider and back.

To do this you need to take a global view of the cloud service, tracking performance measurements from multiple access points.  By comparing these measurements, you have the ability to quickly detect, isolate, and resolve issues affecting cloud application performance before they negatively impact your users and your organization. The more monitoring points you have the better your ability to do this.  It's difficult for smaller organizations to accomplish this level of visibility on their own, but as adoption of cloud applications grows, you'll begin to see new solutions that pool resources across multiple customers, and provide this level of visibility to any SaaS consumer.