Two steps to get you out of the network vs. application double bind

When performance slows down, how do you identify the real culprit?

The term "double bind" refers to an instance where a person receives two or more conflicting messages, each of them negating the other. Addressing one message creates a failure in the other, and vice-versa. A double bind is an unsolvable puzzle resulting in a no-win situation.

As a federal IT professional, you’ve probably come across a double bind or two in your career, especially in regard to your network and applications. The two depend on each other but, often, when something fails, it’s hard to identify which one is at fault.

Let’s say the live video feeds or data your colleagues have come to rely on have slowed to a crawl. Is it the network, or an application? If it’s the latter, but you try fixing the network, not only will you not solve the problem, you could waste hours of time. Likewise, attacking the problem from an application perspective could result in many hours being spent weeding through the mass of applications you currently have in a fruitless effort to find the culprit – only to discover it was a network problem after all.

Unlike a true double bind, though, this puzzle actually has a two-step solution:

Step 1: Check out your network

Throughout history, whenever things slow down, the first reaction of IT pros and end-users alike has been to blame the network. So let’s start there – even though any problems you might be experiencing may not be the poor network’s fault.

Still, you won’t know that for sure without first monitoring the overall performance of your network. Employ application-aware monitoring and deep-packet inspection and analysis technology to identify mission-critical applications that might be creating network issues. This can help you figure out if the aforementioned video and data sluggishness is a network or application problem. If it’s a network problem, you’ll be able to quickly identify how to attack it, patch it and keep on rolling.

What if it’s not the network? That’s where step two comes in.

Step 2:  Monitor your application stack

Like other organizations, federal agencies have become reliant upon hundreds of applications. Each of these applications is responsible for different functions, but they also work together to form a central nervous system that, collectively, keeps things running. Coupled with a backend infrastructure, this application stack forms a critical yet complex system in which it can be difficult to identify a malfunctioning application.

Solving this challenge requires cultivating an application-centric yet holistic view of your entire application stack, which includes not just the applications themselves, but the components that make them tick. This means getting an unfettered view of individual applications, plus all the components that help them operate efficiently, including the systems, storage, hypervisors and databases that make up the infrastructure.

Consolidating management of your infrastructure internally and maintaining control of your application stack (as opposed to relying on partners) can help. As cloud efforts ramp up, agencies are increasingly outsourcing their application management. While that can be highly cost-effective, and take some responsibilities off your plate, there’s something to be said for maintaining an internal level of involvement and oversight. This approach gives you the control you need to more easily pinpoint and quickly address problems.

Of course, the best way to remediate issues is to never have them at all, but that’s not entirely possible. What you can do is mitigate the chances for problems by weighing performance against financial considerations before making changes to your network or applications.

For example, for many Defense Department agencies, the move to the cloud model is driven primarily by the desire for cost savings. While that’s certainly a benefit, you cannot discount the importance of performance when it comes to compute, storage and networking technologies, which are just as important.

These early considerations – combined with a commitment to network monitoring and a complete application stack view – can save you tons of money, time and trouble. Not to mention keeping you out of some serious binds.