cancel
Showing results for 
Search instead for 
Did you mean: 

The Echo Chamber: Visibility and Mapping Webinar

Level 17

echo_chamber.jpg

("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.

8 Comments
bobmarley
Level 15

Thanks for the write up and ebook link Leon.

There's some pretty decent open source software called OpenDCIM for mapping the physical layer in the data center environment. We have had some good success with it.

It seems the go to tool for everything else is still Visio in my own experience.

ecklerwr1
Level 19

Mapping is an art form I would suggest... it's not something (like you said) that can all be automated.

david.botfield
Level 13

Thanks for the write up. Good Stuff.

vinay.by
Level 16

Cool write up

jkump
Level 15

It seems silly but being able to produce maps of processes and environments should be a basic skill for all system administrators.  I spent many years working with Industrial Engineers and in almost every meeting the first five minutes was to develop a map of the process or environment.  Given time, all these small maps made a very large map of the entire system or organization.  So, being able to diagram provides both you with an understanding of the system(s) as well as removes "tribal knowledge" to ensure continuity in supporting those system(s).

Awesome article and interesting food for thought.  Thanks for the ebook link as well.

mtgilmore1
Level 13

Helloooooooooooo 

Nice write up....  O wait, I hear an echo.

tinmann0715
Level 16

I remember way back in the day when Visio was its own program and not part of any Office suite. And network diagrams were treated as any other types of documentation. As soon as it was put to paper it was obsolete. And as ecklerwr1​ so eloquently stated... mapping is more of an artform than a science.

rschroeder
Level 21

If only there were a SW product that could do all the mapping we wish / need, in the ways we must have it, displaying only the amount of info we want . . .

About the Author
In my sordid career, I have been an actor, bug exterminator and wild-animal remover (nothing crazy like pumas or wildebeasts. Just skunks and raccoons.), electrician, carpenter, stage-combat instructor, American Sign Language interpreter, and Sunday school teacher. Oh, and I work with computers. Since 1989 (when you got a free copy of Windows 286 on twelve 5¼” floppies when you bought a copy of Excel 1.0) I have worked as a classroom instructor, courseware designer, desktop support tech, server support engineer, and software distribution expert. Then about 14 years ago I got involved with systems monitoring. I've worked with a wide range of tools: Tivoli, Nagios, Patrol, ZenOss, OpenView, SiteScope, and of course SolarWinds. I've designed solutions for companies that were extremely modest (~10 systems) to those that were mind-bogglingly large (250,000 systems in 5,000 locations). During that time, I've had to chance to learn about monitoring all types of systems – routers, switches, load-balancers, and SAN fabric as well as windows, linux, and unix servers running on physical and virtual platforms.