|By Patrick Carey||
|March 16, 2014 03:00 PM EDT||
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. If our cloud-based future is to come true though, we must pay closer attention to the service levels users are getting from Software-as-a-Service (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 the 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. 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.
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%. 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 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.
2. "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.
3. "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.
4. "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.
5. "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. What happens when the users report a problem? Where do you start to look? Do you immediately get on hold with 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.
6. "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.
As the rapid adoption of containers continues, companies are finding that they lack the operational tools to understand the behavior of applications deployed in these containers, and how to identify issues in their application infrastructure. For example, how are multiple containers within an application impacting each other’s performance? If an application’s service is degraded, which container is to blame? In the case of an application outage, what was the root cause of the outage?
May. 4, 2016 01:45 PM EDT Reads: 1,097
May. 4, 2016 01:45 PM EDT Reads: 1,311
May. 4, 2016 01:00 PM EDT Reads: 1,411
May. 4, 2016 12:47 PM EDT Reads: 176
May. 4, 2016 12:45 PM EDT Reads: 885
May. 4, 2016 12:45 PM EDT Reads: 1,243
May. 4, 2016 12:45 PM EDT Reads: 547
May. 4, 2016 12:30 PM EDT Reads: 1,063
May. 4, 2016 12:15 PM EDT Reads: 514
May. 4, 2016 12:15 PM EDT Reads: 557
May. 4, 2016 12:15 PM EDT Reads: 1,329
May. 4, 2016 12:00 PM EDT Reads: 1,140
May. 4, 2016 12:00 PM EDT Reads: 1,162
May. 4, 2016 12:00 PM EDT Reads: 1,032
May. 4, 2016 11:15 AM EDT Reads: 1,223