Networks Systems

Application Dependency Mapping

Application Dependency Mapping

So far in this series, we have covered Application Performance Monitoring. If you haven’t already, read part onepart twopart three, and part four. In the last post, we stressed the importance of mapping out all dependencies for our application. In this post, we will dig further into it and get a better understanding of what ADM (Application Dependency Mapping) is all about.

What Is It All About?

Application Dependency Mapping is far from a new concept. If you are like me, I remember the days when you would pay a company a very large sum of money to gather data into a spreadsheet that then became your application mappings. The data was compiled based on samples that were gathered in various ways. Often, by the time you received them, things had already changed; therefore, they were already out of date. The good thing is that we could gain a little better understanding of our applications going through this process.

So, how have things evolved since those days? Application dependencies have become much simpler to obtain. Even better, we can visualize them in real time. The tools and methods of gathering the data have advanced over the years.

These tools can monitor data flows over a certain period we determine in advance. Then we can generate visualizations of our application flows. With these visualizations, we can understand groupings of services, etc. We are able to see what devices communicate in a bi-directional fashion. This allows us to understand what applications are being provided, and what is consuming them. We can also uncover any potential security concerns as we dig in to the application flows. We may find that there are certain network ports exposed and/or being consumed and should be locked down.

Ultimately, our goal is to understand how our applications are linked to one another, which provides our application dependency maps. As you can see, these mappings will assist us in our application performance monitoring. As our application dependencies are mapped out, we can get the bigger picture of our applications.

How Do We Get Started?

How do we get started with ADM? In most cases, agents are used on endpoints. For network gear, either taps or built-in agents are used to capture the network flows. Once those are in place, the data will be aggregated and sent to a centralized solution, which will analyze the data. Once that data is analyzed, we can visualize our dependencies and flows. This is also a great opportunity to bring together all teams who support any of the components discovered. By bringing everyone together, we can collectively understand the results and determine what is important and what is not. The goal of our application dependencies is to ensure that what is needed is available, and what is not is blocked or disabled. This will depend on the security posture of the organization you work within, but it is good practice to take this approach. We will go into more on security around this topic in the next post, so stay tuned for that.

Depending on the solution used for analyzing the data to provide our application dependency mappings, there might be some very interesting things we can do with the data. Some solutions will allow you to create ADM profiles which can be versioned for rollback functionality. A solution like this provides the ability to analyze the data flows, present the dependency mappings, and allow you to create a profile with the communications in place and block the unnecessary ones. This is more security-focused, but good to point out here. The real value is that you can create an initial profile, and then later on, create a new updated profile and apply it. By having the ability to rollback, you can easily return to a known working profile on the off-chance something were to break. Another very interesting thing you might do is run through different scenarios using the analyzed data and see how those scenarios may affect your application. Depending on the amount of history data maintained you would have much more granularity in your scenarios. By having this ability, you can ensure that a new profile will not cause issues once applied.


We have only touched briefly on the benefits of using a solution to assist in our application dependencies. However, I hope the value is clear. There is much more to it, but this highlights initial value that can be provided. I mentioned a few times that certain topics were security-focused, and we will touch on those more in the next post.

Larry is a well-seasoned engineer with over 25 years of real-world experience in networking, compute, storage, virtualization, microservices, automation, Infrastructure as Code, and development. He is often referenced as the "floater" because of his ability to float between all pillars from deep level infrastructure and development. Larry is also very active on his contributions on GitHub, blogging, mentoring, and evangelizing. And most of all, his core belief is to "ALWAYS live outside of your comfort zone.”