Here's a scenario. All your enterprise apps are running fine, as you expected. Maybe your…
kill your chances for success in the cloud
There’s been plenty written and predicted about the future of cloud and Software-as-a-Service, and it’s hard to argue with its benefits – for both organizations and users. However, to be successful in moving to the cloud, IT must pay close attention to the service levels users are getting from SaaS applications.
Obvious? Maybe not.
As many organizations make their first big move to the cloud with services like Office 365, a few common misconceptions – grounded in a general belief that once we move to the cloud, IT no longer owns direct responsibility for service levels – threaten to put them on a path to protracted outages and frustrated users.
The fact is that if your users can’t access a cloud-based service, they are not going to call the service provider. They are going to call the IT help desk (maybe you) directly and the IT team will be expected to fix whatever problem exists, ASAP. Users don’t care whether or not the problem is located in infrastructure owned and operated by their IT department, the ISP, or the cloud service provider. If they aren’t having a good experience, IT will take the heat.
How do you avoid this? Here are six myths that can derail your use of the cloud. Falling for them can put you on a path to protracted service outages and frustrated users.
“I don’t need to monitor. I have a guaranteed SLA from the provider.”
Your SaaS service provider is likely able to run their datacenters with higher availability than most IT organizations, but they are not 100%. Guaranties are great, but if you aren’t monitoring your SaaS service, how do you know that your SLA is actually being met? In addition, service level guarantees only cover outages that 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 described in my last blog post, the 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 my hosted Exchange before. 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 monitoring 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 types of 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 me 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 hold with the Microsoft 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 somebody 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.
Don’t be fooled by these monitoring myths. Moving to the cloud doesn’t mean monitoring goes away, but it does fundamentally change the requirements. You have to be able to monitor SaaS apps 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. By doing this, you have the ability to quickly detect, isolate, and resolve issues affecting cloud application performance before they negatively impact your users and your organization.