When migrating from a monolithic to a microservice-based architecture, one need to know patterns and antipatterns in order not to propagate old practices learned from centralized systems to a new structure where services are independent and distributed. We select 5 known antipatterns in microservices-based solutions and propose an algorithm for detecting them automatically. In a first round, all classes, methods and imports are registered and associated to its location in the source code. In a second round the usage of these resources is mapped and antipatterns are detected. The algorithm is also responsible for generating visual output of how resources are used in the project, so the developers can manage how resources are distributed in different files or concentrated in few ones. The solution can avoid common mistakes when deploying microservices-based projects and can help project managers to get an overview of the system as a whole. The algorithm is tested in a well-known open source project revealing possible improvements and resource allocation information.
Microservices are now becoming a well known model for software engineers and
architect. It resembles divide and conquer approach in which a monolithic
software or system is decomposed into independent services 1. Currently,
microservices are adopted by big organizations such as Linked In, Amazon, Soundcloud
and Netflix. These microservices are small and autonomous services [
The monolithic software are being in use since computers are introduced.
These software are not only specific for a single task but perform each and
every step required for a particular function. In these type of applications the
developers have a broad access to a source code. In addition, all the dependencies
that are common have a single set. In short monolithic applications are adopted
because of [
Google still uses this monolithic architecture in which the whole code for the
project is available in one single repository. This code is accessible by 20,000
engineers and consist of 2 billion lines of code [5, ?]. However, Monolithic
applications are hard to scale up both organizationally and technologically as the
whole team works on the same code stored in same database. The problem with
these application is, a small change in any part might have impact on the other
parts2. The redeployment of such application can take hours. Sometime for new
developers, go through the whole code is not an easy task. In short, Monolithic
applications are expensive, slower and even difficult for new developers to
understand the whole code[
In order to improve the design and architect various principles are adopted.
The earliest principles being adopted are Information hiding [
Now migrating from monolithic to microservices, one cannot only face certain
technology related issues but issues related to processes, strategy and
organization. There are problems while migrating for which a solution is available, but
that solution does not work well in these circumstances. 3. The reuse of a
software is a productive technique, having mixed success. There are a number of
anti patterns emerge while analyzing the reusability failure [
Some of the well known anti patterns are: 4 – Everything Micro: Among the common anti patterns is everything micro.
This type of anti pattern is common to enterprise organization. In this case one huge data store is available for all the microservices. The main challenge with this type of anti-pattern is keeping track of the data.
3 https://microservices.io/microservices/antipatterns/-/the/series/2019/06/18/microservicesadoption-antipatterns.html 4 https://dzone.com/articles/microservices-anti-patterns – Break the Piggy Bank: Another most common anti pattern is break the piggy bank. When an existing application is refactoring to microservices.
The refactoring is risky and can take several hours if not days. – We are Agile: Shifting from waterfall software development to agile software development. Initially, the team start implementing a small initial version of agile-fall. In this type, it is just like merging parts together that become worst after time.
The text is structured as follows. In a first section, we present the selected anti-patterns to be detected, and a short description of how the algorithm was implemented to detect them. In the following one, we present a methodology for retrieving a general structure of a microservice-based project in terms of resources, and bring two metrics for measuring closeness and betweenness of complex networks. We then present a case study, applying the algorithm to an open source project, pointing out its anti-patterns and a general description. We conclude by evaluating the proposition and proposing some future work. 2
We have selected some of the anti-patterns from an online list5.
– Ambiguous Service - It refers to the situation when microservices interface
elements are named inappropriately [
and services hence the incoming as well as the outgoing coupling is high for
bottleneck services. In addition, due to large number of external clients the
response time is also high. Consequently, due to huge traffic the availability
of these services is also low6. We propose detecting it by mapping the number
of different contexts in which the same service is requested.
– Bloated Service - A service having one large interface which consist of many
datatype parameters. All of them perform different operation with
cohesion [
Apart of detecting anti-patterns, we propose a methodology for retrieving the general structure of the project in terms of resources. A good solution should distribute resources along different files (library imports, method calls, etc.). In order to achieve this, we have modeled the project as a complex network, in which resources are represented by nodes and the paths by their usage.
A general description of the network is given by two metrics, Closeness and Betweenness: Closeness Centrality (C) of a node in the network is the reciprocal of the sum of the shortest path distances relative to all other nodes. 6 http://sofa.uqam.ca/resources/antipatterns.php#Bottleneck%20Service 7 http://sofa.uqam.ca/resources/antipatterns.php#Bloated%20Service 8 http://sofa.uqam.ca/resources/antipatterns.php#Service%20Chain 9 http://sofa.uqam.ca/resources/antipatterns.php 10 http://sofa.uqam.ca/resources/antipatterns.php
C(u) =
n − 1 vn=−11 d(v, u) (1) (2)
The d(v, u) is the shortest path between v and u and n is the number of nodes in the graph. High values for closeness represent central nodes in the network. Betweenness Centrality (B) is the measure of the centrality of a node in a network, and can be calculated as the proportion of shortest path between node pairs that pass thought one node of interest.
CB(v) =
s∕=t∕=v∈V αst(v) αst αst is the number of shortest paths from s to t, and αst(v) is the number of shortest paths from s to t that pass through node v. Nodes with high betweenness centrality are central in the network and attract the information flow. 4
As a case study, we analyzed Spinnaker project source code11 for detecting the selected anti-patterns and retrieve its general structure. We assume services implemented as classes and a handcrafted set of words as forbidden for being used as class or method names. The code is available for reproducing the experiment12.
In a first round, the proposed algorithm iterates through every file inside the project folder for detecting classes and imports names (in this case it is adjusted for detecting only .py files). In a second round it applies a regular expression for detecting occurrence of classes and its methods along the project and store all occurrences in a dataframe. We differentiate between methods declared inside classes from the ones declared outside. This provide sufficient information for evaluating services independently.
We have detected 3 hard-coded IP addresses and 82 version numbers. The project imports 86 different libraries, as showed in Figure 2 . We have detected three methods named as delete, now and run, considered as inappropriate.
We set the maximun size of a class name as 30, as well as for methods, for considering it too long. We have detected 3 methods and 13 classes with too longs names. An example of a method name is determine subprocess outcome labels, and of class name GcsArtifactStorageConfiguratorHelper. We argue that a name with 30 characters long is not exactly big, but was selected as a threshold here as an example.
We count the number of parameters for each method for detecting too big interfaces (it was not possible to detect how many types in the case of python language). We set 5 arguments as the maximun allowed, and detected only one method, names start subprocess. 11 https://github.com/spinnaker/spinnaker 12 https://github.com/rcaborges/microservices-antipatterns
As the last anti-pattern, we detect methods and classes instantiated from too many files. We set a threshold of 30 as a big number of files, and found 35 files associated to a method called init argument parser, 61 files associated to a class named ConfigError, and 31 files associated to UnexpectedError.
Regarding the general structure of the project in terms of resources, we build a network out of the information acquired in the previous phase. Each node represent one specific resource, ex. classes, and the connection between nodes are formed when two files use the same resource, ex. instantiate the same class.
Figure 1 show with logarithmic scale the fraction of nodes for each value of degree for the case of classes declared inside the project. Few classes were found in too many files, and most of them were detected in one single file. The shape of the curve indicates regular distribution along the files in the project.
Another information about the general structure of the project that may help project managers are the closeness and betweennes of the resources in the project. High values of closeness indicate resources that are close to others, and high values of betweenness represent resources used by too many files, located in the center of the network.
ConfigError was detected as having highest closeness and betweenness, and seems to be a widely used class along the project. Resources with high values of betweenness represent high risk, once it is central to the project and its failure would impact great part of the system. It is worth mentioning that most of top 10 closeness indexes are configuration classes that need to operate in many different contexts inside the project.
Figure 2 shows the visualization of both networks, imports and classes, as described earlier. It is possible to notice that libraries are imported from quite many files inside the source code. Classes, on the other hand, show a more sparse usage among the files, as expected for a good microservice architecture. 5
An algorithm was presented for detecting anti-patterns in microservices based solutions. We have selected 5 anti-patterns and tried to detect them automatically in order to avoid potential failure points when migrating from monolithic architectures. We have also proposed a framework for describing the general structure of the project in terms of resource consumption, which should help project managers with a general overview.
We still need to consider the situations where classes are imported with different names, in this case there should be a proxy for considering extra calls for the original class.
We have simply detected IP addresses and version numbers, without providing any further analysis of the context these are happening. As a future work we plan to improve the algorithm so it can differentiate, for example, a request from a declaration of an IP address, or keep track of version numbers for suggesting consistency.