When the Application Stops Flowing, What Next?
Don’t you hate it when you have a problem, but have no idea what is causing it? The water in my house stopped running recently. I have a well with a pump and a fairly complex system of pipes going through a water filtration and softening system. I had no idea why the water was not flowing, but it was obviously a major issue.
I checked the pipes and they all seemed ok. I cleaned the filter, and verified that the water filtration system was in good order. While I cannot physically inspect the pump because it is dozens of feet down a 4-inch well shaft, I did power-cycle it to ensure that it seemed to be working properly. Ultimately, I had to call a plumber/well specialist who, after inspecting the entire system, determined that my water pressure tank and switch needed to be replaced.
Whose fault is it, anyways?
We have the same problem in the application delivery world within IT networks. The applications and data are like the water running from the server to the end user. When someone complains that an application is not working within their expectations, it is often hard, if not impossible, to determine the specific cause of the problem quickly and easily.
The help desk may get a call from a user in a branch office complaining that the CRM is responding slower than usual. When that trouble ticket is forwarded to the network operations team to troubleshoot, where do they start looking? Is it a problem with the application server? Maybe it is the WAN connection to the branch office. Or it could be that the user having the problem has too many windows open and their PC is running unusually slow.
Not my problem
Even when a problem is localized, convincing the responsible team that they need to identify and resolve the issue can be a challenge. How often have you heard someone say that ‘It is always the network’ while the other team always says ‘Check the application servers before you get me involved’?
It is the job of the network operations team to collect the appropriate information to escalate the problem to the correct team to troubleshoot and fix. Unfortunately, the tools that they commonly have available are network and availability focused instead of looking at and measuring the performance of the applications.
Application performance visibility for network operations
The network operations team needs the tools and insight to understand IF an application is not performing as expected and WHY an application is under-performing. This means that they need the analytics from the application server infrastructure, the WAN/LAN to the user and the performance of the application at the user device.
This gives them enough information to move in the right direction to isolate the issue and determine the appropriate solution to fix the problem. In my case, if I had information on the water pressure in the various lines, the water level status of the pressure tank, and status of my filtration system, I could have saved considerable time and money getting my problem fixed.
For the typical network architecture, the application delivery controller (ADC) is in a perfect position within the application delivery path in between the servers and the users. Since the ADC is a reverse proxy managing all of the application connections and possibly inspecting and steering based on application content, it is well suited to provide information and insight into the nature of the application performance problems. With a little added functionality, the ADC can even provide details about server performance and client system statistics to further isolate the problem location.
It is great to have an architecture that works as designed, but it is even better to have one that can tell you what is wrong when it is not working as expected. Make sure that the different teams are all using the appropriate tools to monitor and manage the network architecture efficiently and comprehensively.
