Add a Comment Now - We Want to Hear From You
Okay, hard decision time. Do I go grab the very last ticket to see “Watchmen” at the last showing tonight alone, or do I spend a sleepless night tossing and turning, while having nightmares about blue men and conspiracy theorists as I wait to see “Watchmen” with my friends the next day?
Ha Ha! Just kidding! I don’t have any friends!
It should not surprise anyone that I have read Watchmen, that I consider it the most culturally significant work of comic fiction produced since William Hogarth’s “A Rake’s Progress.” But it also speaks to me on a personal level. That is, the core themes of “Watchmen” have quite a lot to do with network performance.
Okay, maybe “network performance” isn’t as much on a “personal level” so much as it would be some sort of romantic relationship, or spiritual experience. But it’s still important. Anyway…
Who, indeed, watches the watchmen? For example, carriers claim that by going to MPLS you would get better performance. But there’s not a lot of data provided by the service providers to verify those performance gains. Without that ability to quantify how the carrier network is performing, you have no idea of providers are living up to their service level agreements – or whether you’re better off switching to MPLS in the first place.
Additionally, without watching carefully, you can have well meaning IT teams affecting the network – changes which seem trivial to an application developer may actually cause major repercussions to the network traffic - generating and transmitting graphics required for a CAPTCHA, for instance, when previously you were only dealing with a text-based application.
The most extreme case we’re familiar with is when one team of application developers flipped a single flag in the database, making a graphics field available to the user, sending 1 MB worth of graphics per page on the application. This one “little” change caused network traffic to balloon dramatically over a single night.
It is not that carriers or application developers are mean or untrustworthy – just that they may not know the impact of what they do on the network; and as such, you should.
This means, of course, monitoring the overall round-trip time from end-to-end on an application by application basis, and monitoring for sudden changes in the network.
Comments
I couldn't agree more. Having sold application development tools and software configuration management I understand the potentially massive implications of "minor" changes (New York stock Exchange, Space Shuttle etc.) . Now that I'm in the Network and Application Monitoring/Management space I'm horrified at how everyone points the finger at the poor Network team when application performance degrades. In order to maintain critical business services (and the infrastructure that underpins them) performing at an acceptable level of service we need a new breed of monitoring tools that correlate application performance metrics, with end user experience and network (hardware) performance and that provide early warning of degradation. For example, when "rate of change" in a key metric breaches a pre-defined threshold the relevant support people can be alerted (before the users start complaining). There also needs to be better control over change, and analysis of performance both before and after change. The ability to correlate Performance with Change would be a major advance for many Network and IT Managers and add value to their monitoring activities. When something as simple as a tick in a box can have devasting consequences it shows how little control the vendors of Application Software have over the performance of their suites when they are tailored to the needs of a specific customer (whoever does the tailoring).
Posted by: Emilio Peire | March 19, 2009 05:22 AM