Commentary - It sounds like the beginning of a bad joke, and for those responsible for keeping an organization’s network up and running, the punch line is anything but humorous. A storage guy, a VDI (virtual desktop infrastructure) guy, an application guy and a network guy all come together to deliver a complex, end-to-end virtual desktop solution for a large public-sector customer and it doesn’t work. Who’s to blame?
The network guy, of course.
Sound familiar? If you work for a Managed Services Provider, there’s a better-than-average chance that you have experienced this situation many times. In fact, anyone responsible for running a network will probably recognize the scenario. In a complex multi-vendor environment, figuring out what’s wrong and who’s responsible is really, really hard. Laying blame, it seems, is much easier.
It’s kind of convenient to blame the network. Network problems are notoriously difficult to diagnose, they are frequently transient and can often be subjective. One person’s, “What’s taking so long?” can be another person’s, “We’re trying to properly diagnose the situation.” There are endless potential pain points in a network, so assuming that that’s where the problem exists may be a good guess. But it’s still just a guess. Add into this mix that routers and switches are now so complex and support so many features, that the chances of any one single person knowing how it’s supposed to function are slim, to say the least. In networking, there are always several shades of gray when trying to determine whether something is a “feature” or a “fault”.
As we enter an age where the network and IT are converging into one amorphous mass, the Ops Teams responsible for managing service delivery are inevitably going to become all-powerful. While IT remains mission critical, but massively complicated, we will see a new “Age of Operations” emerge, and the tools that help diagnose problems--and prove innocence along the way--are going to be invaluable.
The vast increase of employees who work from home, from the road or based long distances from corporate headquarters has given rise to the implementation of expansive virtual desktop implementations. As a result, the need for rapid, effective and highly accurate visibility into both the network and the IT infrastructure it supports has become critical to maintaining appropriate network response times. The need for increased visibility can be crystalized in a very real scenario:
An MSP is responsible for providing network to support a medium-sized VDI, and are a core part of a multi-vendor team, all responsible for delivering their respective parts of the project. Everything comes together as it should, and the implementation is launched on time. But within days, users are reporting unacceptable response times from the network. The team meets to trouble-shoot the problem and lays the blame squarely at the feet of the MSP. In the absence of any network visibility, the MSP dutifully responds by doubling the bandwidth. No fix. Then the bandwidth is quadrupled. Still, no fix.
Well, now what?
This is where a problem morphs into a pretty serious situation. Engineers from within the organization---or costly contracted engineers--now have to blindly dig around for who-knows-how-long to figure out why response times have slowed. With each failed solution, company resources are being wasted to solve a problem that could have been quickly remedied with proper visibility into the network.
In a VDI environment, any number of internal or external activities could be slowing the network down. In fact, the network could actually be working perfectly. Something as simple as end users developing a culture of plugging personal USB keys into their PC’s to view and share photos and music could absorb considerable available network resources, and balloon the desktop footprint, which is downloaded and uploaded every time a user logs in. Absent of 100 percent “under-the-hood” visibility, the network continues to take the blame, as time and money are wasted trying to fix it.
With an unobstructed view of the network, a situation as simple as this could be addressed in almost no time at all. Many organizations are so hyper-focused on bulking up the exterior of their networks that they fail to fully address concerns that affect the inside. The fact of the matter is, total visibility has to become a prerequisite with the growing implementation of VDI implementation. Today, the network is the business, and anomaly guesswork---even educated, highly-trained guesswork---just doesn’t cut it anymore. At some point every network will experience a marked slowdown or shutdown. When it does happen, how quick of a turnaround will your organization have in remedying the issue?
And who will they blame?
Tim Nichols is Vice President for Global Marketing at Endace.