Microservice Dependency Analysis Tool — Trust me; you need this

If you are reading this article, I am assuming that you are either in the process of implementing microservice architecture or you are thinking about it.

The microservice architecture has a lot of advantages and I am not going to talk about that; there is plenty of material about this topic that you can find on different blogs and also on YouTube.

The disadvantage of the microservice architecture is that it can easily get out of control because of the quantity of the moving pieces. You have to have a way of managing it. Therefore, you need the following:

• * Capability built into the architecture to find all the configuration about microservices and their versions deployed in each environment.
• * A tool that takes the above mentioned configuration (per environment), calculates the dependency among all microservices (and their versions) and displays this via graphs and/or or in a readable text/html format.
• * An easy mechanism of measuring real-time calls among all microservices.

Here is a more detailed list of the tool mentioned above:

• * Overall dependency graph between microservices
• * Microservice A depends on the following microservices (text/html version)
• * Microservice A depends on the following teams (text/html version)
• * Team 1 depends on the following microservices (text/html version)
• * Team 1 depends on the following teams (text/html version)

We talked about the WHAT; let’s talk about the WHY.

Why do you need this?

First, you need it to paint the big picture. Don’t underestimate the value of the big picture. Even if you are not doing the architecture work on daily basis, you still need to paint the big picture in the territory of your team and the teams that you are dependent on and the teams who are your clients.

You also need this to do impact analysis. The impact analysis is something you may do when you receive new requirements or when you have a problem in production (from usability or security point of view). This is where every second is crucial as your customer satisfaction is at stake and your revenue is at stake.

What about the HOW?

There are many different ways you can implement this. The most important advice is that you start simple and you can keep it simple. Build something, use it, then make it reusable and making it reusable may mean that you are buying a piece of software or a library that does this or fully building it in-house. For example, if Python and Boto3 library is something you use deploy your cloud infrastructure and deploy application code, you may choose Python as the programming language and building these type of tools is less costly and easy to evolve as you are getting more mature in your microservice architecture.

Thank you for reading this article. Please subscribe and read some of my other articles.

Almir M.