Cisco Blogs
Share

Network Dependency Mapping Helps Clean Up Our Application Portfolio


July 22, 2015 - 0 Comments

My team is moving hundreds of applications to our new Application Centric Infrastructure (ACI) platform, and network dependency mapping is the first step in this migration. Most of Cisco IT’s applications are three tiered with web and middle tier residing on the same Java Virtual Machine (JVM) connecting to a database.

A typical application may have one or more JVMs that connect to one or more databases. Sometimes the databases internally connect to other databases. Over the last five years, we have heavily invested in Services Oriented Architecture (SOA) and thus have JVMs running web services. These web services are consumed by one or more user interfaces (UI). Some of these applications have jobs that run on our Cisco Tidal Enterprise Scheduler (TES).

An application is a complex beast with several upstream and downstream dependencies, and lots of connectivity between various virtual machines or bare metal servers hosting databases, application servers, web-servers, TES, etc.

We use a home-grown tool called EMAN (Enterprise Management) to manage this complexity, and monitor the applications and their endpoints. The data from EMAN is used by an IT Application Portfolio tool, which displays a clean representation of the dependency data. Here are a couple of screenshots from the IT Application Portfolio tool for one of our applications. Each of the nodes on the tool can be drilled down. The last leaf of each branch leads to the underlying server description.

aci-blog1

aci-blog2

 

Some of our applications have been around for two decades or longer. Over time, a tool may not be synchronized with the application because endpoints and dependencies might have been added, updated, or removed but the data wasn’t captured in the tool.

Why is it critical to validate the dependencies? If we miss any dependency, either some part of the application or the whole application might not work when we migrate the application to our ACI platform. The dependencies are validated manually. We rely on development engineers who work regularly on an application to perform the validation. For applications that don’t have any development work going on and are purely in support-only mode, we rely on support engineers to validate the dependencies.

During the course of our validation, engineers on my team found about 10 percent of the 171 applications being migrated needed updates to their dependency record. With a large number of applications, two levels of coordination are involved to ensure accuracy. ACI Primes, such as myself, coordinate with the lifecycle managers responsible for each service. In turn, the lifecycle managers coordinate with development and support engineers.

The dependency mapping validation process helped us clean up the application portfolio. We marked the applications that are candidates for end of life and ensured that all the infrastructure components of our applications are accurate. It took us two months to complete dependency mapping for 171 applications. Simultaneous database consolidation impacted the mapping process, so at any given time, we were 90 percent done with a 10 percent delta to ensure that changes from the moving targets were captured. And it all was time well spent.



In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.