("The Echo Chamber" is a semi-regular series where I reflect back on a talk, video, or essay I've published. More than just a re-hashing of the same topic, I'll add insights as to what has changed, or what I would say differently if I were doing it today.)
Back in March 2018, I gave an
online talk about monitoring, mapping, and data visualizations in general titled, "
If an Application Fails in the Datacenter and No Users Are On It, Will it Cut a Ticket?" If you'd like to listen to the original, you can find it online here:
http://video.solarwinds.com/watch/GUHjEnraRAJCKYMDHkDK8D.
The talk focused on the power that visualization has in our lives as humans navigating the world, but more importantly as IT practitioners practicing our craft. It looked at how the correct visualization can transform raw data not just into "information" (meaningful data that has a context and a story) but further into action.
Looking back now, I realize that I missed a few opportunities to share some ideas—and I plan to correct that in this essay.
What Is a Map, Anyway?
In the webinar, I focused on several methods of visualization and how they help us. But I never quite defined the essential features that make a map more than just a pretty picture. For that, I'm going to turn to the preeminent voice speaking about maps as they relate to technology and business: Simon Wardley (@SWardley on Twitter). In short, he states that a picture must portray two things to be a map: position and movement.
The best example of a map that doesn't look like a map but IS one, according to Mr. Wardley's definition, is a chess board. If you showed a picture of a chess game at any point in play, it would convey (for those who can read it) both the current position of pieces and where each piece could potentially move in the future. Moreover, to someone VERY familiar with the game, a snapshot of the current board can also provide insight into where the pieces were. All with a single picture. THAT is a map: position and movement.
With that definition out of the way, the next missed opportunity is for me to dig into the specific different types of network maps. In my mind, this breaks down into three basic categories: physical, logical, and functional.
Mapping the Physical
Mapping the actual runs of cable, their terminations, etc., may be tantalizing in its concrete-ness. It is, in fact, the closest visual representation of your "true" network environment. But there is a question of depth. Do you need every NIC, whether it has something plugged in or not? How about pin-outs? How about cable types? Cable manufacturers? Backup power lines? And of course, it's nearly impossible to generate this type of map automatically.
Mapping the Logical
Most network maps fall into this category. It is less interested in the physical layer than the way data connections behave in the environment, and therefore more accurately represents the movement of data even if you can't always tell how the cabling work.
Mapping the Functional
This type of map is the one your users and systems administrators want to see: one that represents the way application traffic logically (but not physically) flows through an environment. That said, as a network map, it's sub-optimal because application servers aren't always physical. The depth of the map is in question, and it's purposely obfuscating the network infrastructure in favor of showing data flows, so it's usefulness to network engineers is minimal.
For IT practitioners, the question that sits at the core of ALL of this—when to use maps, what kinds of maps to use, what tools to use to make those maps—is a single question:
"What will create those maps automatically, and keep them updated with ZERO effort on my part?"
Because, in my humble opinion (not to mention experience), if a map has to be manually built or maintained, it is more likely NOT to get built and it is almost certainly NOT going to be maintained, which means it is out of date almost as soon as it's published.
And take it from me, having a map that is wrong is worse than having no map at all.
As a side note, I recently revisited these themes in a larger way as part of a new SolarWinds eBook -
Mapping Network Environments, which you can find
here.
