Why your legacy monitoring solution leaves you hanging in the cloud
Recently we conducted a study asking IT teams about their current and planned use of cloud apps and services within their organizations. You can view the full results of the cloud trends survey here. The responses we received are very interesting and we’ll be publishing the full results of that survey soon.
|One particular point that stands out is that less than 20% of the respondents feel like their existing tools do a good job managing their cloud-based apps. The rest are at the very least ambivalent about their existing tools with more than 20% feeling that their existing tools just aren’t up to the task.
Why is this? The Systems Management software market is mature and solutions from Microsoft, HP, CA, and BMC have been on the market for years. A look at their portfolios shows a wide range of sophisticated tools to manage everything from software distribution, to monitoring, to IT workflow and help desk activities.
Surely these tools should also be able to effectively manage cloud-based apps and services, right?
As it turns out, they don’t. Here’s why.
Infrastructure Ownership and Access
Prior to the cloud, IT’s management responsibilities didn’t extend much beyond the walls of the building, or for larger organizations beyond the periphery of their corporate area network, and the systems management tools were built and optimized with that basic assumption. As an administrator I managed MY servers in MY datacenter on MY network. I had the luxury of having direct access to network, storage, and compute nodes that produced ample amounts of log files or SNMP messages. All I needed were tools that could tap into those data feeds, alert me when something happens that I care about, and maybe correlate logs from multiple systems so I could search for and identify trends.
|But with cloud all that has changed and in fact, much has gone away. Yes, if I run my apps on an IaaS provider like AWS or Azure, I can still access app and even OS logs, but below the OS I’m blind. I can’t directly access hardware or any of the network nodes.
If I use SaaS apps I don’t even get this. They’re completely black box. There are no log files to access, no SNMP messages to listen to, and most likely not even a management API to interface with.
If your tools rely on these mechanisms, you’re stuck.
The Convergence of Application Management and Network Operations
For many organizations, the IT team is segregated into 3 basic camps: desktop management, application management, and infrastructure operations. The infrastructure team manages everything from the OS/VM down; the servers and network. They also tend to be the ones who manage security and Active Directory.
The apps team gets their machines from the ops team and from that point on they install, manage, and monitor their apps. If users experience a problem with the app, the apps team uses their tools to look for reported errors from the application. If those errors point to network issues, they contact the ops team, who use their own tools (which provide a lot of low level information about the network but don’t really know anything about the applications running on the network) to try and hunt down the problem. For traditional on-premise apps, the user device, access network, and application likely all reside on the same network, so between the apps tools and the ops tools, the teams can usually find and fix whatever issue exists quickly.
|With cloud-based apps everything changes. IT moves out of the role of infrastructure owner/operator into the role of service consumer/coordinator. It’s the application as a service that must be monitored and maintained, and that service is built on a complex web of networks, servers, and other services, most of which fall outside the organization’s firewall.
An application admin has to have insight into the health of the application service itself as well as the networks and services (like Active Directory Federation Services) that are key to the delivery of that application service. That wall between the apps and ops teams no longer works.
We see this a lot. An IT team will get stuck trying to find a problem affecting SaaS app performance. Neither the application admins, nor the network admins have a full view of the service delivery chain, so they go back and forth pointing fingers and guessing haphazardly trying to find the root cause.
We call this “chasing ghosts.” You don’t have time to chase ghosts.
The Agility Mismatch
Have you ever stood up and deployed one of these traditional systems management solutions? The fact that there is a healthy industry of consultants and system integrators with official certifications and ISO-9000 compliant project plans tells you something. It’s not for the faint of heart.
It’s not that these tools are poorly engineered or designed to be arbitrarily complex. They evolved into their complexity as the sophistication and complexity of on-premise enterprise applications and infrastructure management exploded over the past decade. It’s that same complexity explosion (and the drag it has put on IT agility) that is driving many organizations to the cloud.
In fact, nearly 50% of respondents indicated that agility was a key driver for their move to the cloud, while less than 40% pointed to costs.
So, if your goal is agility you need to make sure your IT management tools are as agile as the apps and services you plan to manage with them. If new apps and services come into your portfolio and are updated by the providers on a weekly basis, a management tool stack that updates every 12 months doesn’t do you much good.
It’s time to look beyond the tools that evolved out of complexity to ones that are born in the cloud.
Performance Monitoring in a Cloud Era
With SaaS, the “service delivery chain” stretches across many service providers, datacenters and networks, with constant changes in access servers and network routes. It’s simply not feasible to have a solution that can find, much less directly access every service node you depend on.
This is why synthetic testing of cloud-based apps and services is essential. In many cases web pages or a public API may be the only way you have to access these services. By measuring performance of these synthetic tests and analyzing the lower level network transaction data you can detect and alert on transaction errors and over-threshold response times. When you look at trends over time you can start to identify other anomalies and cyclical issues.
This is a fundamentally different application management mindset. As apps move into the cloud, application monitoring and performance management look less like surgical probing and more like big data / business intelligence analysis. However, it’s important to make sure you have a sufficient pool of data to analyze. Measuring from a single point certainly isn’t enough. All but the largest corporations lack the number and geographic distribution of access points needed to effectively use just their own data to pinpoint problems outside their networks.
This is where the CloudReady model of crowdsourced monitoring data pays off. When you aggregate and analyze data across hundreds or thousands of global monitoring points it becomes possible to do this type of end-to-end root cause analysis of cloud app performance issues. It’s not just a new monitoring tool. It’s a completely different way of monitoring application performance, born in the cloud and designed specifically for the needs of the cloud.
See for yourself. Start a 15-day free trial to begin monitoring your cloud. It only takes 5 minutes to get started. Not ready to try? Sign-up for our free Cloud Health Report newsletter, which brings you weekly insights into the performance of Office 365, Gmail, and other cloud apps based on data from the crowd – our global network of performance monitors deployed by our customers in their networks.