Why Accurate Application Maps Are Important

An Accurate Application Map is a Critical DevOps Asset

In Norway, there is a beautiful cliff next to a Fjord called Preikestolen. It averages 200,000 visitors every year. Lately, many of those tourists have mistakenly ended up in a small town about 20 miles away instead of the fjord. Why? Because their mapping apps are giving them wrong information.

In the case of tourists in Norway, the mistake “merely” wastes an hour of time, but it’s a cautionary tale about other things that have maps – like containerized microservice applications.
application map

I recently wrote about the 6 Pillars of Managing Modern Dynamic Applications, one of which is Automatic and Continuous Discovery. Continuous discovery is critical because it ensures your maps are always accurate, from containers and hosts, through middleware, to applications, APIs, services and traces.

Accurate Maps Deliver Better Understanding

An accurate application infrastructure map is a critical asset to the IT / DevOps teams responsible for deploying and maintaining applications in these environments.

Which Servers Are Live?
An accurate map shows you which servers (like Tomcat, MongoDB or Kafka) are running on specific hosts and containers, as well as the interdependencies between them.

When containers are created or destroyed, the map must reflect those changes. BUT it should have (and render) historical data, too.

Is the Application Running as Designed?
A complete (and accurate) application map helps you determine that production reality matches the intended operation. If you configured a cluster of six, are there actually six running? If one is missing, which one?

Managing Application Service Quality
To manage service quality, you must understand which individual components are part of any given service along with their communications and dependencies.

You want to know which services are composed of (or depend upon) instances of individual servers (like Java, Tomcat, Kafka, ZooKeeper, etc.):

  • Which, if any, of the above components are running in any given container?
  • How many of each component are deployed within that container?
  • Is a running serve (i.e., ElasticSearch) a single instance, part of a cluster, or part of an ElasticSearch service.

These are critical for your team to deliver good quality application service levels, and an accurate application map is the only way to always have the answers.

Challenges of Keeping Accurate Container / Microservice Application Maps

Remember the “good old days of 2012” when an application map was just a Visio diagram hanging on the data center wall. It was the reference for the application’s function. It was also usually inaccurate almost as soon as it was stuck on that wall.

Containerized microservice environments are even more difficult to map. That manually created application map is probably wrong before you even finish it. As a result, DevOps could setup a server incorrectly, or worse, try  to connect to a system that no longer exists .

That’s why automatic and continuous discovery is critical to successful delivery of high service quality applications. It’s the only way to ensure that maps are accurate (or live).

As components are spun up, they should be added to the live map. When a container is destroyed, it should disappear from the live map. Maps should be historically accurate so that you can walk “back in time” and render history. This also allows you to go beyond a simple state map to include copies of services traces and performance metrics.

The Problems of an Inaccurate Application Map

While those are some good examples of the value you get from having an accurate map, here are a few things that can happen when a map is wrong:

  • Invalid Tracing
    Imagine capturing the distributed trace of a slow request, only to find out that the second step (or what you THOUGHT was the second step) is blank – or worse, includes data from an invalid source or system.
  • Missing correlated information
    Imagine trying to tie an application slowdown to the requests from a tomcat cluster to a MongoDB cluster. You run your analysis and find that the database cluster you’re analyzing isn’t actually the cluster being utilized by the tomcat requests – and you can’t find that database cluster in your list of systems.
  • Troubleshooting Barriers
    A common application failure in complex applications is invalid servers being part of the call trace, such as database calls to a Dev Server. Other common failures include is using bad communication ports or passwords. While these are easy to fix, they are difficult to find. Inaccurate maps will lead you astray because the critical data point that can expose the problem isn’t there.
  • Incomplete Tracing
    Map components are missing because discovery is incomplete or the solution is difficult to deploy.  For example, other tools require extensions that have their own configuration and deployment lifecycle.
  • Complete Understanding
    A complete Map gives a complete and accurate overview. The Team is aware of everything, not some things. How many people actually KNOW  that ZooKeeper is a critical component of a Kafka Cluster.
  • Connected / Critical Value
    Knowing the number of dependencies on a single component or service. A single Geo-Location or Naming or Authentication  REST Service is called by every other service.

Managing applications critical to your business processes or revenue chain (or just require high availability) requires visibility, insight and understanding. Accurate application maps are critical for your team to understand how your critical applications are working for the business around the clock.