When you go on a trip somewhere, you always take a map. When I was growing up, that map came in the form of a road atlas that was bigger than I was. I remember spending hours in the car with my parents tracing out all the different ways that we could get from where we were to where we wanted to be.
Today, my kids are entertained by GPS and navigation systems that have automated the process. Instead of spending time drawing out the lines between cities and wondering how to get around, they can simply put a destination into the application and get a turn-by-turn route to where they want to go. Automation has made a formerly difficult process very simple.
In much the same way, many systems professionals find themselves mapping out applications the "old fashioned" way. They work backwards to figure out how applications behave and what resources they need to operate effectively. While it's not hard to find dependencies for major things, like database access and user interfaces, sometimes things slip through the cracks. One of my favorite stories is about a big Amazon Web Services outage in 2017 that saw the AWS status lights continually lit green
because they were hosted on AWS and were inaccessible during the outage. Status lights aren't a critical function of AWS, but it is a great example of how manual application dependency mapping can cause unforeseen problems.
Thankfully, the amount of data generated by applications today allows for solutions that can automatically detect and map applications and infrastructure. Much like the change from road atlases to GPS, the amount of good data at the disposal of application developers allows them to build better maps of the environment. This application mapping helps professionals figure out where things are and how best to identify problems with applications on a global scale. This could mean dependencies located in one availability zone are affecting application performance on the other side of the country, or even on the other side of the world.
How can we take full advantage of these application maps? For that, we really need context. Think back to our GPS example. GPS in and of itself doesn't do much more than pinpoint you on a map. The value in GPS is that the data feeds applications that provide turn-by-turn navigation. These navigation systems are the context on top of the location data. Rather than simply printing out directions from a website, the app can take us right to the front door of our location.
So too can contextual application mapping help us when we need to troubleshoot bigger issues. By offering additional data about applications above and beyond simple port mapping or server locations, we can provide even more rich data to help figure out problems. Think about a map that shows all the availability zones on a map that then overlays things like severe weather alerts or winter weather advisories. The additional context can help understand how mesoscale issues can affect service and application availability.