How to use statistics to overcome challenges when moving to microservices

Agile software development has been dominant in software engineering for years. Its methods have helped teams manage work and perform efficiently while delivering high-quality results. Microservice architecture is one of the approaches that implements the Agile practices:

Microservice architecture is a style of structuring large complex products as a collection of individual services that can be developed and maintained independently, making the software more flexible and increasing its scalability.

While microservices may seem as a silver bullet upfront, nothing comes easy. The migration can result in deployment challenges as well as make global testing and debugging more difficult. Apart from purely technical side effects, it requires a cultural shift in organizations and strong project management.

In this article we focus on the challenges related to the management of microservices and describe the ways to overcome them using aggregated data and statistics:

We’ll teach you how to turn your Confluence instance into a full-fledged BI tool and how to:

• identify dependencies between teams 
• see if there is a lack of collaboration between members
• find pilot teams to implement new processes in
• check if you are actually moving away from the monolith.

Imagine now that you have a hostel marketplace application where people can find and book a stay. Recently you’ve decided to migrate to microservices, so now the whole application is split into independent services, each having its own repository, and you need to organize your teams and the processes the right way.

Resolve dependencies and build the teams

When done correctly, microservices work so that you can build, test and deploy them without affecting each other. To achieve that you need to recognize and then eliminate dependencies between the teams.

For that purpose you can build the following graph and see the distribution of contributors on the project level:

The graph shows the number of commits made by users, so you can identify service owners, see the interactions between the members of different teams, and spot deviations in terms of who does what, e.g. if there is somebody from the team A working on the team B’s service. The latter can result in delays in the development process and an increase of idle time caused by lags in communication between the developers.

The same graph can also indicate the anti-patterns in teams’ culture. Being a member of an independent team can help developers work more effectively. But some teams just lack the concept of collaboration. So instead of having the work distributed among the developers, it happens that only the so-called “service owner” ends up working on his microservice. In addition to a drop in the morale of the developer, this may affect the quality of the code as there is nobody to review it.

You can use this graph to find services led by one person and then make informed decisions to improve the team culture.

Experiment without risk

The variable development processes and independence are clear benefits of microservices architecture. Teams don’t have to align with the others and that allows you to test and implement new processes without paralyzing the workflow even if something goes wrong. This way you can try to introduce new practices to improve the quality of your software, such as unit testing, code review, pair programming, you name it.

To start the implementation of the new processes it’s important to find the teams that have been operating efficiently and are currently active. The number of commits and pull requests can be used as an indicator of the active state.

The two following graphs will help you to find pilot teams to hold experiments:

The graphs show the activity of the teams by month for the last quarter, indicating the number of commits and pull requests respectively. Now you can compare the results and find the teams that have a lot of commits and none or few pull requests — those will be your perfect candidates.

See the monolith breaking

Moving from the monolithic systems takes a lot of effort so it’s important to keep track of where you are in this journey. Apart from staying motivated as you see the changes (or not yet), you need to make data-driven decisions to improve the processes and lend support to your teams.

To get the full picture you may use the graph that shows the changes in the codebase:

It displays the number of lines of code deleted and added around the project. Using this information you can see the breaking of the monolith: if the number of lines of code deleted is increasing steadily for the monolithic repo while more and more lines of code are being added to the new microservices repos, then you are going the right way.

Make the data work for you

While migration to microservices may seem costlier in terms of the amount of work for managers, that is the investment that will pay you back with faster development processes, increased scalability and adaptability. And we hope to make your way easier here. 

The tips described in this article will help you gain more visibility into the current state of the processes and unleash the potential of your teams. Using the Awesome Graphs for Bitbucket app as a data provider and the Table Filter and Charts for Confluence app to aggregate and visualize the data, you will get the functionality that is on par with dedicated BI software platforms.

Want to know how to build the graphs and charts from the article? Read our step-by-step guides and try yourself!