The Future of Business Is in the Cloud, The Future Is Now
There’s been plenty written and predicted about the future of cloud and Software-as-a-Service, and it’s hard to argue with the benefits – for both organizations and users. However, to be successful in moving to the cloud, IT must pay close attention to the quality of service users are getting from SaaS applications, the Service Level Agreements (SLAs) they get from their vendors, and monitoring SaaS end-user experience.
You’re Still on the Hook for Monitoring SaaS Apps, Uptime and Outages
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.
SaaS Monitoring Myth #1:
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 agreements 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.
Cloud Monitoring Myth #2:
I don't need my own monitoring tools. I use the service provider dashboard
Server provider status dashboards, RSS feeds and other provider notifications only cover the service provider’s infrastructure, not the end-to-end service. These dashboards provide generic information across all of their tenants and those updates may not be relevant to your users and are likely not to be up to date. Remember, they are built to be general status communication tools, not real-time monitoring solutions.
SaaS Monitoring Myth #3:
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.
SaaS Monitoring Myth #4:
My existing tools monitor my cloud apps as well as my on-premise apps.
No, 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 web 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.
Cloud Monitoring Myth #5:
I don't need to monitor. My users tell me when they are having problems
This may be okay for 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.
Mean-time-to-resolution (MTTR) for cloud outages 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. If the provider is telling you its fixed, you want to confirm it automatically.
SaaS Monitoring Myth #6:
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 host. 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 (QoS) and Quality of Experience (QoE) realized by users. When a user has an issue they will call you, not Microsoft.
Don’t be fooled
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.