What’s causing networks to feel “slow”?
In short, the growing abundance of cloud-based applications is adding more and more utilization to data links. There are also many more recreational apps being used on business networks than there were in the past. (Apparently, millennials don’t work for companies that don’t allow recreational app use!) More data traffic is causing congestion. This congestion results in performance issues for end users, which causes apps, and the network, to feel slow.
This is where network traffic visibility and control is crucial and where the array of “tools” such as APM and NPM fit in.
RMM / NPM
Remote Monitoring and Management (RMM) and Network Performance Monitoring (NPM) tools identify the endpoints and network infrastructure, and as well as some visibility of network traffic. Managing and monitoring IT assets such as servers, workstations, network devices, network subnets, installed apps and so forth is essential. However, whilst they will keep the infrastructure layer functioning, they will not explain why the network “feels slow” to end users. In fact, these products were originally developed for the LAN. However, they are now being retrofitted and used to try and solve WAN and internet problems. These products include Labtech, Kaseya, PRTG, SolarWinds, Auvik, Riverbed Cascade and many others. Some of these products provide limited visibility of WAN traffic but rely on NetFlow to do this. There are 10 significant limitations to be aware of when using NetFlow, adding another layer of complexity to manage (what it looks like in practice).
APM
Application Performance Monitoring (APM) tools identify why particular apps are not performing, but they don’t solve the entire network issue. Some limitations include:
- They are application-centric. They may tell you an application is underperforming, but won’t tell you why (e.g. they will tell you the Citrix delay is high but not because Joe from accounts is using Netflix and is consuming the link).
- They provide no insight into how end users are using the network (i.e., they have a narrow focus on applications, instead of actual end user’s behavior on the network).
- There are no holistic application usage trends, so they can’t help with capacity planning, baselining etc.
- They understand and report on a limited set of apps, and don’t provide a holistic WAN-wide view at Layer 7 through to end user and device-level detail.
- They can’t take corrective action, such as blocking unwanted applications, shaping low-priority applications or prioritizing business-critical applications.
- They can’t provide application-neutral end-to-end network-quality scoring (i.e., latency, delay, jitter, packet loss).
- They can’t help you understand the impact of all applications on the WAN or how an app performs on the LAN in order to assist with cloud migration strategies.
- They can’t provide real time second-by-second visibility into application usage on the network.
- They are often very expensive and complex to use.
What’s the solution?
MSPs absolutely need to hang on to their RMM tools, and in certain instances APM tools. But, they should complement this with WAN and internet visibility and control. Once they’re able to identify and control network traffic, they’ll be able to control congestion and ensure the ongoing performance of key business apps. The service tickets will disappear, enabling your sales team to get back on the front foot and talk to your customers about other products and services.
Check out our series on site reliability engineering tools for debugging!
