# Monolith to Microservices: Representing Application Software through
Heterogeneous GNN

Alex Mathai1 Sambaran Bandyopadhyay1111Sambaran is currently at Amazon
Science. Utkarsh Desai1222Utkarsh is currently at Google. All the authors were
affiliated to IBM Research when the work was conducted.&Srikanth Tamilselvam1
1IBM Research

###### Abstract

Monolithic software encapsulates all functional capabilities into a single
deployable unit. While there is an intention to maintain clean separation of
functionalities even within the monolith, this tends to get compromised with
the growing demand for new functionalities, changing team members, tough
timelines, unavailability of skill sets etc. Therefore, microservice
architectures are increasingly used as they advocate building an application
through multiple smaller sized, loosely coupled services, wherein each service
owns a single functional responsibility. But the challenges associated with
the automated separation of functional modules, slows down the migration of a
monolithic code into microservices.

Graphs are a natural choice to represent the software implementation
structure. Various software artifacts like programs and resources (tables,
files) become nodes in the graph and the different relationships they share -
like function calls, inheritance and resource access (Create, Read, Update,
Delete) can be represented as links in the graph. We reduce this traditional
application decomposition problem into a heterogeneous graph based clustering
task. Additionally, we support adding constraints to clustering. Extensive
quantitative and qualitative studies show that our approach is effective both
on object oriented and procedural language based monoliths.

##  1 Introduction

Monolith architecture is the traditional unified model for designing software
applications. Since it encapsulates multiple business functions or components
into a single deployable unit, it is easy for developers to violate the
modularity principle and still deliver fully functional applications. But such
applications become difficult to understand and hard to maintain as they age
because it increases complexity in understanding the application code and
predicting change impact Kuryazov et al. (2020).

Microservices Lewis and Fowler (2014); Thönes (2015) are seen as an
alternative. It aims to realize the software application as a package of small
services where each service is responsible for a single functionality. It
brings multiple benefits like efficient team structuring, independence in
development & deployment, enables flexible scaling and less restriction on
technology or programming language preference. Figure 1 shows the significant
differences between the two architectural styles for a sample e-commerce
software. But monoliths are prevalent in the market and are actively used by
many customers. Migrating from monolith to microservices is a labour intensive
task. It often involves domain experts, microservices architects and monolith
developers working in tandem to analyze the application from multiple views
and identify the components of monolith applications that can be turned into a
cohesive, granular service. They also need to work with constraints like the
exact number of microservices to be exposed and components that should
definitely be part of each microservices.

The software engineering community refers to this migration process as a
software decomposition task which has been an active area of research for more
than twenty years. Many works Mancoridis et al. (1998, 1999); Tzerpos and Holt
(2000); Harman et al. (2002); Praditwong et al. (2010); Ouni et al. (2012);
Alizadeh et al. (2018); Mahouachi (2018); Mazlami et al. (2017) leverage the
syntactical relationships between the programs and treated this decomposition
as an optimization problem to improve different quality metrics like cohesion,
coupling, number of modules, amount of changes etc. Fritzsc et al. Fritzsch et
al. (2018) presented a detailed survey on the different approaches for this
task. While the accuracy of these approaches has been evolving over time, they
have their drawbacks such as 1) reliance on external artifacts like logs,
commit history etc. 2) focus on only a subset of the programs 3) less
attention to non program artifacts like the tables, files 4) minimal
consideration for transactional data. Recently Jin et al. (2019) executed test
cases to extract runtime traces. Each execution is considered as a business
function and they try to cluster business functions. But this work relies on
access to runtime traces and complete coverage of test cases which cannot be
always guaranteed. Also, this work does not consider data entities for
decomposition.

Graphs are a natural choice to represent the application’s structural and
behavioral information Mancoridis et al. (1998); Desai et al. (2021). The
structural information consisting of different application entities such as
programs, files, database tables can be represented as nodes and their
different relationships such as calls, extends, implements between program to
program and different CRUD operations (create, read, update, delete
operations) that happen from program to data resources (table, file, queues)
can be represented as edges in the graph. Figure 2 captures the construction
of a heterogeneous graph from a sample java code. The behavioral information
of the application identified through the sequence of programs and data
resources that come together to support a business function can also be
captured as node/edge attributes. The monolith to microservices task can thus
be viewed as a graph based clustering task which involves 1) Learning a good
representation of the graph structure and 2) Using this learnt representation
for the clustering task. Additionally, constraints like what nodes should be
part of a cluster and what nodes should not be clustered together are
supported. Graph neural networks have achieved state of the art results for
multiple graph-based downstream tasks such as node classification and graph
classification Kipf and Welling (2017); Veličković et al. (2018); Xu et al.
(2019). Most graph neural networks follow message passing mechanisms where the
vector representation of a node is updated by combining its own features and
aggregated features from its neighborhood Gilmer et al. (2017). Recently Desai
et al. (2021) showed how the programs and its relationships in the application
can be represented as a graph and proposed a multi-objective graph convolution
network that combined node representation & node clustering by diluting
outliers. But since the framework did not consider application’s data
resources like database tables, files and the different relationships that
exists between programs & resources in the graph construction, the functional
independence property of microservices is not completely satisfied. Graph
neural networks have also been used recently for heterogeneous graphs Zhang et
al. (2019); Wang et al. (2019). However, existing heterogeneous graph neural
networks are not used directly to cluster the nodes of different types in a
unified framework.

Figure 1: (a) represents an e-commerce software following monolith
architecture. It contains five overlapping components and pointing to the
common table. Due to this the code for these components could easily get
mixed. (b) represents microservices view of the same e-commerce software. The
components are now independent maintaining their own DB and accesses others
through dedicated remote interfaces

In this work, we propose a novel graph neural network based solution to
refactor monolith applications into a desired number of microservices. The
main contributions of our paper are listed below.

  1. 1.

We translate the application software’s structural and behavioral properties
into a heterogeneous graph through nodes, edges and node/edge attributes.

  2. 2.

We introduce a novel heterogeneous graph neural network, referred to as CHGNN,
that enables the representation of data resources and programs and performs
constraints-based clustering in a unified framework.

  3. 3.

We show that inclusion of heterogeneous information generates better quality
microservices recommendations through four publicly available monolith
applications.

  4. 4.

We demonstrate that our approach is applicable to different programming
paradigms by showing improvements on Java and COBOL based applications.

Figure 2: Representing software implementation as a heterogeneous graph: (a)
Shows a class A that extends class S. A implements the extract() method where
it invokes class X read() method. The extract() method also has the @Api
annotation indicating that it exposes a service. We also notice class X
performing a READ operation on table OrderDB. (b) Shows the graph view of this
implementation with classes A, S, X as program nodes and database table
OrderDB as a resource node. Additionally, the different kind of dependencies
are represented as edges $e(A,S)$, $e(A,X)$, $e(A,Z)$ and $e(X,OrderDB)$

.

##  2 Methodology

Given a monolith application and constraints $S_{list}$ \- the list of $K$
seed sets from the subject matter experts (SMEs), we want to partition the
monolith into $K$ fairly distributed clusters where each cluster is a group of
programs and resources that perform a well-defined functionality. An ideal
cluster should exhibit high cohesion, i.e., have strong interaction within the
cluster and low coupling i.e., less interaction between clusters.

###  2.1 Converting Applications to Graph

We now describe our approach to represent an application as a graph. The
primary programming construct in different languages are different - a class
in Java and a program in COBOL. Hence, in the rest of this work, we refer to
classes or programs as simply programs for consistency. Consider a simple Java
application as shown in Figure 2. Each class or program in the application can
be represented as a Program node in the graph. Certain programs might also
access resources such as database tables, files or other data structures. Such
artifacts can be represented as Resource nodes in the graph. We denote the
combined set of Program and Resource nodes as $V$, the set of all nodes. We
also allow for multiple edge types. We establish an undirected CALLS edge from
Program node A to Program node B if there is method in the program A that
calls a method from program B. We also identify resource usage and create a
CRUD edge from Program node X to Resource node R, if the program X accesses
resource R. Static analysis tools333https://github.com/soot-oss/soot make the
call chains and resource usage within the application available by analyzing
the code. $E$ denotes the combined set of all edges between the various nodes
in the graph. The edges are unweighted and multiple method calls or resource
usages between two nodes are still represented by a single edge.

We now generate the node attribute matrix, corresponding to the Program and
Resource nodes of the graph. APIs exposed by applications are referred as
EntryPoint Specifications Dietrich et al. (2018), or simply, Entrypoints
(EPs). The methods invoked through these APIs are annotated with tags such as
@Api as shown in Figure 2. We refer to such methods as entrypoint methods and
the corresponding programs as entrypoint programs. Each entrypoint program can
thus be associated with multiple entrypoints through different entrypoint
methods. From an entrypoint method, we can obtain a sequence of invoked
methods and their corresponding programs using the execution traces of that
Entrypoint. If $EP$ is the set of Entrypoints in an application and $V_{P}$,
is the set of Program nodes, we can define a matrix $A^{|V_{P}|\times|EP|}$,
such that $A(i,p)=1$ if program $i$ is present in the execution trace of
entrypoint $p$, else $0$. Additionally, we define another matrix
$C^{|V_{P}|\times|V_{P}|}$ such that $C(i,j)$ is the number of Entrypoint
execution traces that contain both programs $i$ and $j$. If a program is not
invoked in an execution trace for any Entrypoint, we remove the corresponding
non-reachable Program node from the graph. Finally, classes or programs may
also inherit from other classes or programs or implement Interfaces. In Figure
2, class A inherits from class S. Although this establishes a dependency
between the programs, it is not a direct method invocation. Hence, this
dependency is not included as an edge in the graph, but as a Program node
attribute. Therefore, we define a matrix $I^{|V_{P}|\times|V_{P}|}$ and set
$I(i,j)=I(j,i)=1$ if programs $i$ and $j$ are related via an inheritance
relationship and $0$ otherwise. The attribute matrix for Program nodes is the
concatenation of $A$, $C$ and $I$, and denoted as $X_{P}$.

For Resource nodes, the Inheritance features are not applicable. The $A$ and
$P$ matrices are obtained by summing up the corresponding rows from the
respective $X_{P}$ matrices. The relationship between Program nodes and
Resource nodes is many-to-many and this formulation simply aggregates features
from all related programs into the resource. This gives us the resource
attribute matrix $X_{R}$. Each constituent matrix of $X_{P}$ and $X_{R}$ is
row-normalized individually. The final set of node attributes are denoted as
$X_{V}=\\{X_{P},X_{R}\\}$. The Edge attributes for CALLS edges is simply the
vector $[1,0]$ and there are no additional features. For CRUD edges, the
attribute vector represents the type of resource access performed. Since a
program can access a resource in more than one fashion, this is a $1\times 4$
vector, where each attribute represents the associated access type - [Create,
Read, Update, Delete]. Hence a program that reads and updates a Resource node
will have $[0,1,1,0]$ as the edge feature. The edge attribute matrix is
represented as $X_{E}$.

Thus, the entire application can be represented by a heterogeneous graph as
$G=(V,E,X_{V},X_{E})$. Let us assume that $\phi(v)$ and $\psi(e)$ denote the
node-type of $v$ and edge-type of $e$ respectively. Let us use
$\mathbf{x}_{v}\in\mathbb{R}^{D_{\phi(v)}}$ to denote the attribute vector for
the node $v$ which belongs to $D_{\phi(v)}$ dimensional space. Similarly,
$\mathbf{x}_{e}\in\mathbb{R}^{D_{\psi(e)}}$ is the edge attribute of the edge
$e$.

###  2.2 Proposed Heterogeneous Graph Neural Network

In this subsection, we aim to propose a graph neural network (GNN) which can
(i) handle different node and edge types in the graph, (ii) obtain vector
representation of both nodes and edges by jointly capturing both the structure
and attribute information, (iii) output community membership of all the nodes
in the graph in a unified framework. We refer the proposed architecture as
CHGNN (Community aware Heterogeneous Graph Neural Network). There are
different steps in the design of CHGNN as described below.

####  2.2.1 Mapping Entities to a Common Vector Space

Due to heterogeneity from different software artifacts, attributes associated
with nodes and edges of the input graph are not of same types and they can
have different dimensions. Such heterogeneity can be addressed in the
framework of message passing heterogeneous graph neural networks in two ways:
(i) Map the initial attributes to a common vector space using trainable
parameter matrices at the beginning Wang et al. (2019); (ii) Use different
dimensional parameter matrices while aggregating and combine information at
each step of message passing Vashishth et al. (2020). We choose the first
strategy since that makes the subsequent design of the GNN simpler and helps
to add more layers in the GNN. So, we introduce type specific trainable
matrices $W_{\phi(v)}\in\mathbb{R}^{F^{(0)}\times D_{\phi(v)}}$ for nodes and
$W_{\psi(e)}\in\mathbb{R}^{F^{(0)}\times D_{\psi(e)}}$ for edges $\forall v\in
V$ and $\forall e\in E$.

$\displaystyle\mathbf{h}_{v}^{(0)}=\sigma(W_{\phi(v)}\mathbf{x}_{v});\;\mathbf{h}_{e}^{(0)}=\sigma(W_{\psi(e)}\mathbf{x}_{e})$
(1)

where $\sigma$ is a nonlinear activation function. $\mathbf{x}_{v}$ and
$\mathbf{x}_{e}$ are the initial attribute vectors of node $v$ and edge $e$
respectively. $\mathbf{h}_{v}^{(0)}$ and $\mathbf{h}_{e}^{(0)}$ are considered
as $0$th layer embeddings for $v$ and $e$ respectively. They are fed to the
message passing framework as discussed below.

####  2.2.2 Message Passing Layers for Nodes and Edges

Message passing graph neural networks have achieved significant success for
multiple node and graph level downstream tasks. In this framework, we obtain
vector representation for both nodes and edges of the heterogeneous graph.
There are $L\geq 1$ message passing layers. We define the $l$th layer ($1\leq
l\leq L$) of this network as follows.

As the first step of a message passing layer, features from neighborhood are
aggregated for each node. In recent literature, it has been shown that
obtaining both node and edge representation improves the downstream
performance for multiple applications Jiang et al. (2019); You et al. (2020);
Bandyopadhyay et al. (2019). Following that, we also design the GNN to
exchange features between nodes and edges, and update the vector
representation for both. In each layer, we use two parameter matrices
$W_{1}^{(l)}\in\mathbb{R}^{F^{(l)}\times F^{(l-1)}}$ and
$W_{2}^{(l)}\in\mathbb{R}^{F^{(l)}\times F^{(l-1)}}$ to handle node and edge
embeddings respectively. For a node $v\in V$, its neighborhood information is
aggregated as:

$\mathbf{z}_{v}^{(l)}=\sum\limits_{u\in\mathcal{N}(v)}\frac{1}{\sqrt{d_{u}}\sqrt{d_{v}}}W_{1}^{(l)}\mathbf{h}_{u}^{(l-1)}*\sigma\big{(}W_{2}^{(l)}\mathbf{h}_{uv}^{(l-1)}\big{)}$
(2)

where $d_{u}$ and $d_{v}$ are the degrees of the nodes $u$ and $v$
respectively. $\frac{1}{\sqrt{d_{u}}\sqrt{d_{v}}}$ is used to symmetrically
normalize the degrees of the nodes in the graph Kipf and Welling (2017).
$\sigma()$ is a nonlinear activation function and $*$ is Hadamard (element-
wise) product. Next, the aggregated information $\mathbf{z}_{v}^{(l)}$ is
combined with the embedding of node $v$ to update it as follows.

$\mathbf{h}_{v}^{(l)}=\sigma\big{(}\mathbf{z}_{v}^{(l)}+\frac{1}{d_{v}}\mathbf{h}_{v}^{(l-1)}\big{)}$
(3)

$\mathbf{h}_{v}^{(l)}$ is considered as the node embedding of node $v$ at
$l$th layer. To update the embedding of an edge $(u,v)$, we use the updated
embeddings of two end point nodes and the existing embedding of the edge as
follows ($||$: concatenation of vectors):

$\mathbf{h}_{uv}^{(l)}=\sigma\Big{(}W_{3}^{(l)}\big{(}\frac{\mathbf{h}_{u}^{(l)}+\mathbf{h}_{v}^{(l)}}{2}\;||\;\mathbf{h}_{uv}^{(l-1)}\big{)}\Big{)}$
(4)

where $W_{3}^{(l)}\in\mathbb{R}^{F^{(l)}\times(F^{(l)}+F^{(l-1)})}$ is a
parameter matrix. This completes the definition of the layer $l$ of the
message passing network. Please note that the dimensions of the trainable
matrices $W_{1}^{(l)}$, $W_{2}^{(l)}$ and $W_{3}^{(l)}$ determine the
dimension of the embedding space of the nodes and edges.

To build the complete network, we first map the heterogeneous nodes and edges
to a common space using Equation 1. Subsequently, we use 2 message passing
layers ($l=1,2$) as encoders (compressing the feature space) and next 2
message passing layers ($l=3,4$; $L=4$) as decoders (decompressing the feature
space), with $F^{(0)}>F^{(1)}>F^{(2)}<F^{(3)}=F^{(1)}<F^{(4)}=F^{(0)}$. To map
the node and edge features to their respective input attribute space
$\mathbb{R}^{D_{\phi}(v)}$ and $\mathbb{R}^{D_{\psi}(e)}$, we again use linear
transformations followed by activation functions as shown below.

$\displaystyle\hat{\mathbf{x}}_{v}=\sigma(\hat{W}_{\phi(v)}\mathbf{h}_{v}^{(L)})\;;\;\;\hat{\mathbf{x}}_{e}=\sigma(\hat{W}_{\psi(e)}\mathbf{h}_{e}^{(L)})$
(5)

These reconstructed node and edge attributes are used to design the loss
functions as discussed next.

####  2.2.3 Design of the Loss Functions and Joint Clustering of Heterogeneous
Nodes

As we do not have any prior knowledge about which software artifact should
belong to which cluster, the problem is inherently unsupervised in nature. We
use three types of reconstruction errors as follows.

Node Attribute Reconstruction: We try to bring the initial node features
$\mathbf{x}_{v}$ and the reconstructed node features $\hat{\mathbf{x}}_{v}$
close to each other by minimizing $\sum\limits_{v\in
V}||\mathbf{x}_{v}-\hat{\mathbf{x}}_{v}||_{2}^{2}$.

Edge Attribute Reconstruction: With similar motivation as above, we minimize
$\sum\limits_{e\in E}||\mathbf{x}_{e}-\hat{\mathbf{x}}_{e}||_{2}^{2}$.

Link Reconstruction: Above two loss components do not capture anything about
the link structure of the heterogeneous graph. Let us introduce the binary
variables $a_{u,v}$ $\forall u,v\in V$ such that $a_{u,v}=1$ if $(u,v)\in E$
and $a_{u,v}=0$ otherwise. We want to ensure that embeddings of two nodes are
close to each other if there is an edge between them by minimizing
$\sum\limits_{u,v\in
V}\big{(}a_{u,v}-\mathbf{x}_{u}\cdot\mathbf{x}_{v}\big{)}_{2}^{2}$.

Unifying Node Clustering: The primary goal of our work is to refactor a
monolith application to microservices for an application software. After we
map the monolith to a heterogeneous graph, the goal can be achieved by
clustering the nodes of the graph. As the nodes are represented in the form of
vectors through the heterogeneous GNN encoder as discussed in Section 2.2.2,
one intuitive approach is to pass these trained embeddings to a clustering
algorithm as a post-processing step. But such a decoupled approach is always
suboptimal since the GNN is unaware of the end clustering objective. So in
this paper, we unify the clustering objective with the heterogeneous GNN as
follows.

The node embeddings at the end of encoding layers (i.e., $L/2$ layers) are
$\mathbf{h}_{v}^{(L/2)}$, $\forall v\in V$. We design a k-means++ objective
Arthur and Vassilvitskii (2006) by introducing two parameter matrices
$M\in\mathbb{\\{}0,1\\}^{|V|\times K}$ and $C\in\mathbb{R}^{K\times
F^{(L/2)}}$. $M$ is the binary cluster assignment matrix where each row sums
up to $1$. We assume to know the number of clusters $K$. $M_{vk}=1$ if node
$v$ belongs to $k$th cluster and $M_{vk}=0$ otherwise444To avoid cluttering of
notations, we use $M_{vk}$ instead of $M_{\text{index}(v)k}$, where
$1\leq\text{index}(v)\leq|V|$. $k$th row of $C$, denoted as $C_{k}$, is the
center of $k$th cluster in the embedding space. Node clusters and the
corresponding cluster centers can be obtained by minimizing $\sum\limits_{v\in
V}\sum\limits_{k=1}^{K}M_{vk}||\mathbf{h}_{v}^{(L/2)}-C_{k}||_{2}^{2}$.

Allowing seed constraints : As motivated in Section 1, real-world applications
generally have constraints provided by SMEs in the form of clustering seeds.
To incorporate such constraints in the training of CHGNN, we take a list of
seed sets $S_{list}=[S_{1},\cdots,S_{K}]$ as input, where each $S_{i}$ is a
set of seed nodes that must belong to the corresponding cluster
$\mathcal{C}_{i}$. With $S_{list}$ as input, we need to ensure two
requirements - 1) In the final output, every seed set ($S_{i}$) must belong to
a pre-determined cluster ($\mathcal{C}_{i}$) and 2) the embeddings of the seed
sets in different clusters must be as far apart as possible. To address the
first requirement we add hard constraints to our cluster assignment algorithm
. This can be seen in Algorithm 1 (Lines $15$-$17$), where for each seed
artifact, we assign the cluster manually. To address the second requirement we
add soft constraints to our clustering loss function. This is captured by
measuring the distance between the seed set centers ($\mathbf{SC}_{k}$) as
shown in Equation 7. As the distance should be maximised, we negate this
distance to maintain a minimization objective.

$\mathbf{SC}_{k}=\sum\limits_{i\in
S_{k}}\mathbf{h}_{i}^{(L/2)}/|S_{k}|,\forall k\in[1,\cdots,K]$ (6)

$Dist=-\sum_{k=1}^{K}\sum_{k^{\prime}=1}^{K}||\mathbf{SC}_{k}-\mathbf{SC}_{k^{\prime}}||_{2}^{2}$
(7)

Hence, the total loss to be minimized by CHGNN is:

$\displaystyle\underset{\mathcal{W},M,C}{\text{min}}\;\mathcal{L}=\alpha_{1}\;\sum\limits_{v\in
V}||\mathbf{x}_{v}-\hat{\mathbf{x}}_{v}||_{2}^{2}\;+\alpha_{2}\;\sum\limits_{e\in
E}||\mathbf{x}_{e}-\hat{\mathbf{x}}_{e}||_{2}^{2}$ (8)
$\displaystyle+\alpha_{3}\;\sum\limits_{u,v\in
V}\big{(}a_{u,v}-\mathbf{x}_{u}\cdot\mathbf{x}_{v}\big{)}_{2}^{2}$
$\displaystyle+\alpha_{4}\;(\sum\limits_{v\in
V}\sum\limits_{k=1}^{K}M_{vk}||\mathbf{h}_{v}^{(L/2)}-C_{k}||_{2}^{2}+Dist)$

where $\mathcal{W}$ contains the trainable parameters of the GNN described in
Section 2.2.1. $\alpha_{1}$, $\alpha_{2}$, $\alpha_{3}$ and $\alpha_{4}$ are
non-negative weight factors. We set them in such a way that individual loss
components contribute equally in the first iteration of the algorithm.

###  2.3 Training and Analysis

Algorithm 1 CHGNN

1:Input: Class dependencies, Transactions and $S_{list}$ \- the list of $K$
seed sets

2:Convert the application to a graph representation as defined in Section 2.1
and obtain the $V$, $E$ and $X_{V}$ and $X_{E}$.

3:Let $S_{list}$ be $[S_{1},\cdots,S_{K}]$. Hence each cluster
($\mathcal{C}_{k}$) has a mandatory set of seeds ($S_{k}$).

4:Let the list of clusters be $[\mathcal{C}_{1},\cdots,\mathcal{C}_{K}]$ and
the list of centers for each cluster be $[C_{1},\cdots,C_{K}]$.

5:Pre-train the heterogeneous GNN encoder and decoder (refer Training
Procedure in Section 3.4)

6:% Initialize the cluster centers as follows %

7:$C_{k}$ = $\sum\limits_{k\in S_{k}}\mathbf{h}_{k}^{L/2}/|S_{k}|$, $\forall
k\in[1,\cdots,K]$

8:for T iterations do

9: % Assign a cluster to each node %

10: for $v\in V$ do

11: if $v$ not in $S_{list}$ then

12: % Find closest centres for non-seeds %

13: Find the closest center ($C_{k}$) with Equation 9

14: Add $v$ to the corresponding cluster $(\mathcal{C}_{k})$

15: else

16: % Fix the cluster for seeds %

17: Find $S_{k}$ such that $v\in S_{k}$

18: Add $v$ to the corresponding cluster $(\mathcal{C}_{k})$

19: end if

20: end for

21: Update cluster centers with Equation 10.

22: Update the parameters of the heterogeneous GNN encoder and decoder by
minimizing Eq. 8 using ADAM.

23:end for

24:Output: Clusters and Cluster Centers

First, we pre-train the parameters of the GNN without including the clustering
loss component, i.e., setting $\alpha_{4}=0$ in Equation 8. We use ADAM
optimization technique Kingma and Ba (2014) to update the parameters of GNN.
Once the pre-training is completed, we use alternating optimization techniques
to update each of clustering parameters $M$ and $C$, and parameters of GNN
$\mathcal{W}$, while keeping others fixed. Using Lloyd’s update rule for
k-means Arthur and Vassilvitskii (2006), we update $M$ and $C$ as:

$M(v,k)=\begin{cases}1,\;\text{if\;}k=\underset{k^{\prime}\in\\{1,\cdots,K\\}}{\text{argmin}}||\mathbf{h}_{v}^{(L/2)}-C_{k^{\prime}}||_{2}^{2}\\\
0,\;\text{Otherwise}\end{cases}$ (9)

$C_{k}=\frac{1}{N_{k}}\sum\limits_{v\in\mathcal{C}_{k}}\mathbf{h}_{v}^{(L/2)}$
(10)

where $N_{k}=\sum\limits_{v\in V}M_{vk}$. Due to the presence of clustering
loss component in Equation 8, updating the parameters $\mathcal{W}$ of GNN can
pull the node embeddings close to their respective cluster centers further,
along with reconstructing initial node and edge attributes and the link
structure.

The forward pass of heterogeneous GNN takes $O(|E|)$ time since messages are
computed and passed over the edges of the graph. Link reconstruction component
in Section 2.2.3 takes $O(|V|^{2})$ time. This can easily be relaxed by
reconstructing only the existing nodes (i.e., when $a_{u,v}=1$) with some
negative samples for non-existing edges Grover and Leskovec (2016). Since the
number of nodes in the constructed heterogeneous graph which represents the
monolith, is typically not very large for most real world applications, we
reconstruct the full link structure.

##  3 Experimental Evaluation

Dataset | Description | Lang | #Class | #Resources | #Clusters
---|---|---|---|---|---
DayTrader | Trading App | Java | 111 | 11 | 6
PBW | Plant Store | Java | 36 | 6 | 5
Acme-Air | Airline App | Java | 38 | 6 | 4
GenApp | Insurance App | Cobol | 30 | 10 | 6

Table 1: Details about the monolith applications studied

###  3.1 Datasets (Monolith Applications) Used

| PBW (K=5) |  | Genapp (K=6)
---|---|---|---
| Mod ($\uparrow$) | S-Mod ($\uparrow$) | IFN ($\downarrow$) | NED ($\uparrow$) |  | Mod ($\uparrow$) | S-Mod ($\uparrow$) | IFN ($\downarrow$) | NED ($\uparrow$)
COGCN | 0.2013 | 0.1247 | 3.27 | 0.2222 |  | 0.3520 | 0.0918 | 1 | 0.6333
HetGCNConv | 0.2403 | 0.0401 | 3.4 | 0.9074 |  | 0.4988 | 0.1255 | 3.75 | 0.1833
CHGNN-EL | 0.2482 | 0.0528 | 3.6 | 0.6389 |  | 0.5155 | 0.1030 | 4.08 | 0.65
CHGNN | 0.2508 | 0.0413 | 3.67 | 0.8889 |  | 0.5031 | 0.1253 | 3.75 | 0.275
| ACME (K=4) |  | DayTrader (K=6)
| Mod ($\uparrow$) | S-Mod ($\uparrow$) | IFN ($\downarrow$) | NED ($\uparrow$) |  | Mod ($\uparrow$) | S-Mod ($\uparrow$) | IFN ($\downarrow$) | NED ($\uparrow$)
COGCN | 0.1763 | 0.1680 | 3.83 | 0.4 |  | 0.1741 | 0.0661 | 4.5 | 0.3374
HetGCNConv | 0.3439 | 0.0794 | 4.92 | 0.5185 |  | 0.1741 | 0.0747 | 7.2 | 0.5341
CHGNN-EL | 0.3153 | 0.0728 | 4.92 | 0.5185 |  | 0.1972 | 0.0516 | 6.22 | 0.6989
CHGNN | 0.3334 | 0.0681 | 4.92 | 0.6944 |  | 0.1884 | 0.0587 | 6.17 | 0.5699

Table 2: Performance of partitioning Monolith to Microservices (results
averaged over 3 runs)

To study the efficacy of our approach, we chose four publicly-available web-
based monolith applications namely Daytrader
555https://github.com/WASdev/sample.daytrader7, Plantsbywebsphere
666https://github.com/WASdev/sample.plantsbywebsphere, Acme-
Air777https://github.com/acmeair/acmeair and
GenApp888https://www.ibm.com/support/pages/cb12-general-insurance-application-
genapp-ibm-cics-ts. We chose these applications, as they show a good diversity
in terms of the programming paradigms and languages & technologies used.
Details of each monolith are provided in Table 1. We did not include DietApp
999https://github.com/SebastianBienert/DietApp/ in the baseline Desai et al.
(2021) since the public repository did not contain the stored procedure
scripts that explains the relationship between programs and the database
tables. Though our approach does not necessarily depend on the presence of
resources, we chose to study only on applications that have resources, to show
its contributions to the microservices generation process.

###  3.2 Constraints to clustering

For each application, we get the target number of microservices (K clusters)
and constraints of what entities each microservice (K seed sets) should
contain as inputs from the SMEs. Naturally, the seed sets cannot be
shared/overlap with each other. Typically the constraints include tables and
program entities that are central to the cluster. It acts as means to
guarantee functional alignment.

###  3.3 Quantitative Metrics

To perform a quantitative evaluation of the clusters, we use 4 established
graph metrics. They are 1) Modularity Newman and Girvan (2004) (Mod), 2)
Structural Modularity Jin et al. (2019) (S-Mod), 3) Non-Extreme Distribution
Wu et al. (2005) (NED) and 4) Interface Number Jin et al. (2019) (IFN). Mod
and S-Mod measure the clusters’ structural quality - higher values indicate
higher cluster modularity. NED and IFN are also desirable cluster properties.
The NED metric checks if the cluster sizes are evenly distributed and IFN
measures the cross-connections between clusters.

(a) Results for COGCN

(b) Results for CHGNN

Figure 3: Candidate microservices for PBW application : The clusters capture
the five business functions of PBW. The bounding circles indicate the
different resources (tables) owned by the clusters.The nodes in red fonts are
seeds provided by SME.

###  3.4 Baseline Algorithms and Experimental Setup

As converting a monolith application to a heterogeneous graph neural network
and applying them for clustering is a novel direction, we have designed most
of the baselines with motivations from existing works on graph representation
learning. They are discussed below.

COGCN Desai et al. (2021): In this baseline, the monolith application with
both program and resource nodes are converted to a homogeneous graph.
Subsequently, COGCN, which has GCN layers trained on reconstruction and
clustering loss, is applied on the homogeneous graph to obtain the micro-
services. Note that COGCN does not consider edge attributes and only updates
node embeddings in each layer.

HetGCNConv: Here, we create the heterogeneous graph as discussed in Section
2.1, but consider all the edges as of similar types. We map the heterogeneous
nodes to a common vector space as done in Section 2.2.1 by using node-type
specific parameter matrices $W_{\phi(v)}$’s. We then use the GCN convolution
model and train it by setting $\alpha_{2}$ to $0$.

CHGNN-EL : A variant of our proposed CHGNN where we drop the edge feature re-
construction loss from the optimization procedure by setting $\alpha_{2}=0$ in
Equation 8.

CHGNN : This is the complete model of CHGNN as proposed by us in this work.

Please note that COGCN is a homogeneous graph based approach. HetGCNConv and
CHGNN-EL are two variants of our proposed heterogeneous model CHGNN.
HetGCNConv only uses heterogeneous nodes but homogeneous edges. CHGNN-EL uses
both heterogeneous nodes and edges, but sets $\alpha_{2}$ to $0$.

Architecture Specifications : In each of these experiments, we use a two-layer
encoder and a two-layer decoder. The two encoder layers reduce the dimensions
from $F^{(0)}$ to $64$ and $32$ respectively. Similarly, the two decoders
increase the dimensions from $32$ to $64$ and then from $64$ to $F^{(0)}$.

Training Procedure : Before adding the clustering loss component, we pre-train
the model for $150$ epochs ($lr=0.01$), allowing the model to better
understand the application’s graph structure. For this first round of
training, we set
$\\{\alpha_{1},\alpha_{2},\alpha_{3},\alpha_{4}\\}=\\{0.4,0.2,0.4,0\\}$ for
CHGNN. Similarly, we set
$\\{\alpha_{1},\alpha_{2},\alpha_{3},\alpha_{4}\\}=\\{0.5,0,0.5,0\\}$ for the
others. We then add the clustering loss and train the model for another $150$
epochs ($lr=0.005$). During this second round of training, we set
$\\{\alpha_{1},\alpha_{2},\alpha_{3},\alpha_{4}\\}=\\{0.1,0.1,0.1,0.7\\}$ for
CHGNN. Similarly, we set
$\\{\alpha_{1},\alpha_{2},\alpha_{3},\alpha_{4}\\}=\\{0.1,0,0.1,0.8\\}$ for
the others. To generate the final cluster assignments for each application, we
use the latest values of $M(i,k)$ \- i.e. the value at the end of the
$300^{th}$ epoch. All experiments were run on a system with 32 GB RAM, a
6-Core Intel i7 processor and a 4 GB AMD Graphics Card.

###  3.5 Quantitative and Qualitative Results on Separating Micro Services

As depicted in Table. 2, our approach achieves a significant increase in the
key metrics (Mod and NED) when compared to the baseline - COGCN. In
particular, COGCN has the lowest Modularity (Mod) score for every application
when compared to the other models. The same trend can be seen in NED, where
COGCN has the lowest values for three applications. This shows that a
heterogeneous network generates more even distributions that have higher
functional coherence. However, COGCN performs the best in the IFN metric in
all applications. This is because COGCN tends to create highly skewed clusters
- with certain clusters having a majority of nodes and others having
relatively few. As a result, COGCN’s output often results in clusters with
lesser meaning and overloaded functionality (also evident in our qualitative
analysis). This tendency of COGCN also naturally inflates S-Mod which is based
on the combination of cohesion and coupling. In three of the four apps where
COGCN has the least NED score, S-Mod is significantly higher. When comparing
metric values amongst the ablations - HetGCNConv, CHGNN-EL and CHGNN, we
realise that there is no single model that outperforms on every metric for
every application. Based on the application topology, different models perform
better on different criteria. The average std deviation for Mod and S-Mod
numbers in Table. 2 is $(\pm 0.016,\pm 0.007)$, ($\pm 0.007,\pm 0.008$), ($\pm
0.018$, $\pm 0.018$) and ($\pm 0.0008,\pm 0.008$) for COGCN, HetGCNConv,
CHGNN-EL and CHGNN respectively (averaged across $3$ runs for each of the $4$
applications).

As a qualitative analysis, we study our predictions for the PBW application
and compare our results with COGCN. As seen in Figure. 3(b), we observe that
the algorithm with the help of seed input - $S_{list}$ identified five
functional clusters 1) Customer, 2) Order, 3) Inventory, 4) BackOrder and 5)
Supplier. The programs in each of the clusters clearly have very close
dependencies within the cluster and seem to be contributing majorly to the
common identified business function. This can be observed by both the edges
among programs within the clusters and also with the program names. Associated
with each cluster is a group of data nodes (dashed circled) that interact
closely with the programs in their cluster. As seen, the Supplier cluster has
supplier-table, Supplier, SupplierBean and Populate nodes. We also notice
similar patterns in Figure 3(a). However, unlike CHGNN, COGCN seems to create
very skewed clusters - with the majority of artifacts in the Inventory cluster
and three smaller sized clusters - Supplier, BackOrder and Customer. We also
find that many of the artifacts that actually belong to the Customer service
end up wrongly associated with the Inventory and Order service. From this, it
is evident that 1) CHGNN is able to correctly group programs and their
associated data resources and 2) Clusters in CHGNN are more evenly distributed
and more meaningful in nature when compared to COGCN. This observation has
been validated by one of our SMEs (R1) - CHGNN is better. Reason : The
clusters are more evenly distributed. Customer service came out well with
account management (AccountBean, LoginInfo, EmailMessage) contained in it.
Also in COGCN, Orderbean is assigned to OrderService, but it interacts more
with AccountBean. But Listproperties & ImageServlet in CHGNN are out of place.

More ablation and qualitative studies for the different applications are
presented in the supplementary material.

##  4 Conclusion

We motivated the need for migrating (with constraints) monoliths containing
programs and data resources to microservices. We proposed a novel
heterogeneous graph neural network that enables the representation of data
resources and programs, and jointly clusters nodes into micro-services. The
different quantitative and qualitative studies show, that including
heterogeneous information guarantees more even, functionally coherent and
independent microservices. In the future, we want to give more importance to
certain relationships like update over read and extends over implements. We
also aim to study the decomposition task at a more granular level from
programs to functions and tables to columns.

## References

  * Alizadeh et al. [2018] Vahid Alizadeh, Marouane Kessentini, Mohamed Wiem Mkaouer, Mel Ocinneide, Ali Ouni, and Yuanfang Cai.  An interactive and dynamic search-based approach to software refactoring recommendations.  IEEE Transactions on Software Engineering, 46(9):932–961, 2018\.
  * Arthur and Vassilvitskii [2006] David Arthur and Sergei Vassilvitskii.  k-means++: The advantages of careful seeding.  Technical report, Stanford, 2006.
  * Bandyopadhyay et al. [2019] Sambaran Bandyopadhyay, Anirban Biswas, M Narasimha Murty, and Ramasuri Narayanam.  Beyond node embedding: a direct unsupervised edge representation framework for homogeneous networks.  arXiv preprint arXiv:1912.05140, 2019.
  * Desai et al. [2021] Utkarsh Desai, Sambaran Bandyopadhyay, and Srikanth Tamilselvam.  Graph neural network to dilute outliers for refactoring monolith application.  In Proceedings of 35th AAAI Conference on Artificial Intelligence (AAAI’21), 2021.
  * Dietrich et al. [2018] Jens Dietrich, François Gauthier, and Padmanabhan Krishnan.  Driver generation for java ee web applications.  In 2018 25th Australasian Software Engineering Conference (ASWEC), pages 121–125. IEEE, 2018.
  * Fritzsch et al. [2018] Jonas Fritzsch, Justus Bogner, Alfred Zimmermann, and Stefan Wagner.  From monolith to microservices: A classification of refactoring approaches.  CoRR, abs/1807.10059, 2018.
  * Gilmer et al. [2017] Justin Gilmer, Samuel S Schoenholz, Patrick F Riley, Oriol Vinyals, and George E Dahl.  Neural message passing for quantum chemistry.  In Proceedings of the 34th International Conference on Machine Learning-Volume 70, pages 1263–1272, 2017.
  * Grover and Leskovec [2016] Aditya Grover and Jure Leskovec.  node2vec: Scalable feature learning for networks.  In Proceedings of the 22nd ACM SIGKDD international conference on Knowledge discovery and data mining, pages 855–864, 2016.
  * Harman et al. [2002] Mark Harman, Robert M Hierons, and Mark Proctor.  A new representation and crossover operator for search-based optimization of software modularization.  In GECCO, volume 2, pages 1351–1358, 2002.
  * Jiang et al. [2019] Xiaodong Jiang, Pengsheng Ji, and Sheng Li.  Censnet: Convolution with edge-node switching in graph neural networks.  In IJCAI, pages 2656–2662, 2019.
  * Jin et al. [2019] Wuxia Jin, Ting Liu, Yuanfang Cai, Rick Kazman, Ran Mo, and Qinghua Zheng.  Service candidate identification from monolithic systems based on execution traces.  IEEE Transactions on Software Engineering, 2019.
  * Kingma and Ba [2014] Diederik P Kingma and Jimmy Ba.  Adam: A method for stochastic optimization.  arXiv preprint arXiv:1412.6980, 2014.
  * Kipf and Welling [2017] Thomas N. Kipf and Max Welling.  Semi-supervised classification with graph convolutional networks.  In 5th International Conference on Learning Representations, ICLR 2017, Toulon, France, April 24-26, 2017, Conference Track Proceedings. OpenReview.net, 2017.
  * Kuryazov et al. [2020] Dilshodbek Kuryazov, Dilshod Jabborov, and Bekmurod Khujamuratov.  Towards decomposing monolithic applications into microservices.  In 2020 IEEE 14th International Conference on Application of Information and Communication Technologies (AICT), pages 1–4. IEEE, 2020.
  * Lewis and Fowler [2014] J. Lewis and M. Fowler.  https://www.martinfowler.com/articles/microservices.html.  2014\.
  * Mahouachi [2018] Rim Mahouachi.  Search-based cost-effective software remodularization.  Journal of Computer Science and Technology, 33(6):1320–1336, 2018\.
  * Mancoridis et al. [1998] Spiros Mancoridis, Brian S Mitchell, Chris Rorres, Y Chen, and Emden R Gansner.  Using automatic clustering to produce high-level system organizations of source code.  In Proceedings. 6th International Workshop on Program Comprehension. IWPC’98 (Cat. No. 98TB100242), pages 45–52. IEEE, 1998.
  * Mancoridis et al. [1999] Spiros Mancoridis, Brian S Mitchell, Yihfarn Chen, and Emden R Gansner.  Bunch: A clustering tool for the recovery and maintenance of software system structures.  In Proceedings IEEE International Conference on Software Maintenance-1999 (ICSM’99).’Software Maintenance for Business Change’(Cat. No. 99CB36360), pages 50–59. IEEE, 1999.
  * Mazlami et al. [2017] G. Mazlami, J. Cito, and P. Leitner.  Extraction of microservices from monolithic software architectures.  In 2017 IEEE International Conference on Web Services (ICWS), pages 524–531, 2017.
  * Newman and Girvan [2004] Mark EJ Newman and Michelle Girvan.  Finding and evaluating community structure in networks.  Physical review E, 69(2):026113, 2004.
  * Ouni et al. [2012] Ali Ouni, Marouane Kessentini, Houari Sahraoui, and Mohamed Salah Hamdi.  Search-based refactoring: Towards semantics preservation.  In 2012 28th IEEE International Conference on Software Maintenance (ICSM), pages 347–356. IEEE, 2012.
  * Praditwong et al. [2010] Kata Praditwong, Mark Harman, and Xin Yao.  Software module clustering as a multi-objective search problem.  IEEE Transactions on Software Engineering, 37(2):264–282, 2010\.
  * Thönes [2015] Johannes Thönes.  Microservices.  IEEE software, 32(1):116–116, 2015.
  * Tzerpos and Holt [2000] Vassilios Tzerpos and Richard C Holt.  Accd: an algorithm for comprehension-driven clustering.  In Proceedings Seventh Working Conference on Reverse Engineering, pages 258–267. IEEE, 2000.
  * Vashishth et al. [2020] Shikhar Vashishth, Soumya Sanyal, Vikram Nitin, and Partha Talukdar.  Composition-based multi-relational graph convolutional networks.  In International Conference on Learning Representations, 2020.
  * Veličković et al. [2018] Petar Veličković, Guillem Cucurull, Arantxa Casanova, Adriana Romero, Pietro Lio, and Yoshua Bengio.  Graph attention networks.  In International Conference on Learning Representations, 2018.
  * Wang et al. [2019] Xiao Wang, Houye Ji, Chuan Shi, Bai Wang, Yanfang Ye, Peng Cui, and Philip S Yu.  Heterogeneous graph attention network.  In The World Wide Web Conference, pages 2022–2032, 2019.
  * Wu et al. [2005] Jingwei Wu, Ahmed E Hassan, and Richard C Holt.  Comparison of clustering algorithms in the context of software evolution.  In 21st IEEE International Conference on Software Maintenance (ICSM’05), pages 525–535. IEEE, 2005.
  * Xu et al. [2019] Keyulu Xu, Weihua Hu, Jure Leskovec, and Stefanie Jegelka.  How powerful are graph neural networks?  In International Conference on Learning Representations, 2019.
  * You et al. [2020] Jiaxuan You, Xiaobai Ma, Yi Ding, Mykel J Kochenderfer, and Jure Leskovec.  Handling missing data with graph representation learning.  In H. Larochelle, M. Ranzato, R. Hadsell, M. F. Balcan, and H. Lin, editors, Advances in Neural Information Processing Systems, volume 33, pages 19075–19087. Curran Associates, Inc., 2020.
  * Zhang et al. [2019] Chuxu Zhang, Dongjin Song, Chao Huang, Ananthram Swami, and Nitesh V Chawla.  Heterogeneous graph neural network.  In Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, pages 793–803, 2019.

##  5 Supplementary Material

###  5.1 Hardware Requirements

All experiments were run on a system with 32 GB RAM, a 6-Core Intel i7
processor and a 4 GB AMD Graphics Card.

###  5.2 Training Details

All training details have been specified in Section 3.3. This includes the
values of different hyper-parameters like $\alpha_{i}$ and learning rate
($lr$). We also detail the training strategies used for successful
convergence. All the experiments on the considered applications take around 6
minutes for completion.

###  5.3 Notations Used

We summarize the notations in Table 3.

Notations | Explanations
---|---
$G=(V,E,X_{V},X_{E})$ | Input heterogeneous graph
$e=(u,v)$ | An edge between two nodes
$X_{V}$ | Set of node features
$X_{E}$ | Set of edge features
$\phi(v)$ and $\psi(e)$ | Node and edge types respectively
$\mathbf{x}_{v}\in\mathbb{R}^{D_{\phi(v)}}$ | Initial attribute vector for the node $v$
$\mathbf{x}_{e}\in\mathbb{R}^{D_{\psi(e)}}$ | Initial attribute vector for the edge $e$
$\mathbf{h}_{v}^{(l)}$ | Embedding of node $v$ in layer $l$
$\mathbf{h}_{e}^{(l)}$ | Embedding of edge $e$ in layer $l$
$\hat{\mathbf{x}}_{v}$ | Reconstructed attribute vector for the node $v$
$\hat{\mathbf{x}}_{e}$ | Reconstructed attribute vector for the edge $e$

Table 3: Different notations used in the paper

###  5.4 Qualitative Study

In this section, we cover the job profile of the participants, details on how
the study was conducted and the feedback on the microservices recommendations.
We also provide a detailed comparative analysis on three of the applications
covering two programming paradigms.

###  5.5 Participants Profile

To study the efficacy of the microservices recommendations, we requested
participation from four software engineers to analyze four applications. On an
average, the participants had industrial experience of 13 years in different
software engineering roles. All the four participants had prior working
experience on Java programming language. Two of the participants also had
experience with working on COBOL applications. Two annotators (R1 & R2) who
had an understanding of COBOL took an average of 4 weeks to understand the
GenApp application before they participated in this study. Two other
annotators (R3 & R4) spent an average of 2 weeks to understand the three Java
based applications before they participated in this study.

###  5.6 Study Instructions

For each application, we provided the instructions shown in Figure. 4 to the
respective participants. The application specific details like the application
code reference and clustering outputs (the microservices recommendations -
available as jsons and sunburst chart images) are mentioned in each
instruction. As an example, Figure 5 captures the sunburst chart for the CHGNN
and COGCN approaches that were presented to R3 & R4.

We thank you for agreeing to evaluate our work. Please go through the monolith
application (https://www.ibm.com/support/pages/cb12-general-insurance-
application-genapp-ibm-cics-ts) to make yourself familiar with the
implementation structure. In addition, we are available to give an overview of
the application capabilities and explain how the function works through
different artifacts in the application. Below we have provided two sunburst
charts, namely genappblind1.png and genappblind2.png showing the microservices
recommendations for GenApp as clusters. Cluster boundaries can be identified
by the big gap between them. Each label is a program/resource artifact in the
GenApp application. To differentiate between the two, resource names have a
suffix like “-table, -res or -db2table”, or else, a prefix like ”db2- or
vsam-”. The lines going across indicate the dependencies between the nodes.
Incase you find text to be an easy way to understand the clusters, we have
additionally, provided two json files genappblind1.json and genappblind2.json
corresponding to the two sunburst charts. Please go over the two different
results and tell us which clustering output seems to be more
modular/independent and whether the artifacts within each cluster are closely
related. Additionally, you can also mention the reasons behind your selection.

Figure 4: Sample qualitative study instruction for the participant. Details like code repository link, cluster images and jsons are updated for the different applications Application |  Language |  Reviewer Selection |  Reviewer Reasons
---|---|---|---
GenApp |  COBOL |  CHGNN |  R2. Blind 1 - Pros : 1) Does a good job with the ’ksdscust’ cluster and the db2-customer cluster Cons : 1) Too much chatter between the ’policy’ clusters… 2) One policy cluster is data-heavy… and the other is business-logic heavy… we might as well make them one big cluster… but then, the original code already had that.. so, what’s the point? Blind 2 - Pros : 1) Does a good job with the ’ksdscust’ cluster, the db2-customer cluster, the ’ksdspoly’ cluster 2) The chatter across clusters is not heavy… so, orchestration of these as services would be able to better handle peak loads with all the load balancing and stuff Cons : 1) The ’DB2-policy’ cluster has too many things going on there.. It will be resource intensive as a service, I believe 2) If your system has more policy activity than customer activity, this would go down faster than Blind 1. But, if I have to pick a preference, I would still pick Blind-2 because it would work better more times than Blind-1… and it is a better option to go for further re-architecture in future
Daytrader |  Java |  CHGNN |  R3. I choose Cluster 2. Recommendations are evenly distributed compared to cluster1. In Cluster 2, holdingejb-table which is accessed only by TradeDirect/TradeSLSBean is grouped with one its dependency. I feel it is justified that TradeDirect is with accountejb-table and not with holdingejb- table. Cluster 2 also looks more functionally aligned, Orderservices has come out with OrderData, orderejb-table, orders filter,orderdatabean. Similarly Account services has its most dependent artifacts in Cluster 2 compared to Cluster 1.
CHGNN |  R4. Blind 1 : TradeSLSBean and TradeDirect are clubbed in the same cluster along with AccountDataBean which looks very out of place. Also, the large cluster which contain more than 50% of the classes could be better refactored. There are also some isolated classes and resources which could have been better arranged. Blind 2 : This is not necessarily a very good clustering, but it still groups classes much better. There is a clear separation of functionality for OrderData and AccountData. The clusters are also somewhat evenly sized.
PBW |  Java |  CHGNN |  R3. Cluster 2 is better. Reason : The clusters are more evenly distributed. Customer service came out well with account management (AccountBean, LoginInfo, EmailMessage) contained in it. Also in Cluster 1, Orderbean is assigned to OrderService, but it interacts more with AccountBean. But Listproperties and ImageServlet in Cluster 2 are out of place.
CHGNN |  R4. Blind 1 : Order Service and Inventory Service seem to be a bit overloaded. Blind 2 : Overall the clusters are mostly well separated and map more closely to the functionality they represent.
Acme-Air |  Java |  CHGNN |  R3. I would prefer Cluster 2. Cluster 2 has all the functionalities well seperated.. Especially session management service, customer service.. Booking service dependencies with flight is also well captured. Comparatively, Cluster 1 didn’t separate functionalities to be called as independent service
CHGNN |  R4. Blind1 : The seeds are put in a separate cluster in most cases and the rest of the classes are all part of a single cluster. There is clearly no separation of functionality. Blind2 : There are clear clusters corresponding to Authentication, Flight, Booking and Customer/CustomerService. This is easily the better of the two results.
Table 4: With seed constraints - For all the four applications, the reviewers
chose the microservices recommendations by CHGNN over COGCN.

###  5.7 Assets

The following public Applications - Daytrader
101010https://github.com/WASdev/sample.daytrader7, Plantsbywebsphere (PBW)
111111https://github.com/WASdev/sample.plantsbywebsphere, Acme-
Air121212https://github.com/acmeair/acmeair and GenApp
131313https://www.ibm.com/support/pages/cb12-general-insurance-application-
genapp-ibm-cics-ts are used for this study. All of them are Apache Licensed
assets. We used the PyTorch Geometric
141414https://github.com/rusty1s/pytorch-geometric framework for model
implementation which is released as MIT License.

###  5.8 Qualitative studies

For the study, we requested each participant to compare the results from COGCN
to our CHGNN model through the json and sunburst chart images provided. We
anonymized the model details in the inputs. Overall, we found that the
participants had a greater agreement with the microservice recommendations
produced by CHGNN than those produced by COGCN. Table 4 captures the
participants’ comments for their selection for each of the applications they
evaluated. The participants pointed out scope for improvements in the CHGNN
recommended clusters and they had their own suggestions about how certain
programs or tables could be moved to a different service. However, compared to
the COGCN model, they recognized that CHGNN produces more acceptable and
accurate clusters. Additionally, we provide our own detailed qualitative
analysis of the results for one application from each of the programming
paradigms - Java (OOP) and COBOL (procedural). From the feedback received, we
are positive that our work helps the developers to get closer to the ideal
microservices design and can substantially reduce their migration effort. This
highlights the importance of factoring in resources in addition to programs
for clustering and the efficacy of our heterogeneous network.

###  5.9 Authors’ Comparative analysis

(a) Results for CHGNN

(b) Results for COGCN

Figure 5: Acme-Air application Sunburst charts (a) and (b) representing the
microservice recommendations using CHGNN and COGCN models respectively.

(a) Results for CHGNN

(b) Results for COGCN

Figure 6: GenApp application Sunburst charts (a) and (b) representing the
microservice recommendations using CHGNN and COGCN models respectively.

####  5.9.1 Authors’ Comparative analysis on acme-air

Acme-Air is an application that captures key functionalities in managing an
airline called ”Acme Air”. It contains overall 38 nodes which includes 32 java
programs and 6 db tables. Figure 5 shows the output from the two models for
acme-air application. We list below the differences between the two
recommendations made by CHGNN and COGCN and provide reasons why CHGNN’s output
is a closer recommendation to ideal microservices.

  * •

CHGNN extracts very evenly sized clusters compared to COGCN. This ensures that
each microservice has a self-contained functionality.

  * •

COGCN has three clusters with only two elements and one extremely large
cluster. This makes the small clusters meaningless and overloads the large
flight cluster

  * •

CHGNN is able to pull many relevant programs for each cluster - AddressInfo is
pulled into customer service, Session Loader is pulled into session manage
service etc.

  * •

Due to the large flight service in COGCN’s output, many programs unrelated to
the flight service exist. Thus, the flight service is overloaded.

  * •

One drawback in CHGNN’s output is that it clusters FlightService in the
booking microservice. Although FlightService has connections with
BookingServiceImpl, it should have been aligned with FlightServiceImpl and
Flightloader in the Flight/Airport microservice.

####  5.9.2 Authors’ Comparative analysis of dayTrader

DayTrader is an application built around the paradigm of an online stock
trading system. The application allows users to login, view their portfolio,
lookup stock quotes, and buy or sell stock shares. It contains a total of 122
nodes which includes 111 java programs and 11 db tables. Figure 7 shows the
output from the two models for the DayTrader application. We list below the
differences between the two recommendations made by CHGNN and COGCN and
provide reasons why CHGNN’s output is a closer recommendation to ideal
microservices.

  * •

In CHGNN’s output, we see that the different functionalities are spread fairly
evenly with functional alignment.

  * •

In contrast, COGCN’s output has an uneven distribution, with the quote service
covering more than $50\%$ of the nodes.

  * •

CHGNN’s outputs have clean separations with respect to functionality -
Tradesetup which includes TradeConfig and TradeBuild are together along with
AccountDataBean and Account-ejb table. The Order service which includes
OrdersFilter, OrderData, OrderDatabean, Orderejb-table are correctly clustered
together. The Holding-ejb table which is only accessed by the two key
controllers - TradeDirect and TradeSLSBean, has correctly been clubbed with
TradeSLSBean. While its other dependency TradeDirect is assigned with its key
dependent Trade setup programs. Similarly report generation which is handled
by PingServlet2pdf is clubbed separately. Thus, overall, our approach manages
to get closer to ideal microservices that 1) Have programs that are
functionally coherent and 2) Have key dependent files and resources that
closely interact with these programs.

  * •

In COGCN’s output, we do not see as much functional coherence amongst the
programs in a cluster.

(a) Results for CHGNN

(b) Results for COGCN

Figure 7: DayTrader application Sunburst charts (a) and (b) representing the
microservice recommendations using CHGNN and COGCN models respectively.

####  5.9.3 Authors’ Comparative analysis on GenApp

Figure 6 showcases the resulting clusters for GenApp by CHGNN and COGCN
models. Functionally, GenApp is an application that creates insurance policies
and processes customer-claims. Hence it has two types of databases and
datasets - the customer database & customer dataset, as well as a group of
policy databases (house, motor, vehicle etc.) and a policy dataset. This
entire codebase is broken into two main logical groups (containing code and
data) - the $1^{st}$ deals with customer acquisition and the $2^{nd}$ deals
with policies bought and claimed by customers. It is implemented as a
monolithic COBOL codebase that contains $30$ program nodes and $10$ resource
nodes. Hence, on the whole, resource nodes contribute to $25\%$ of all
available nodes in the software. After running COGCN and CHGNN on Genapp, we
carefully analyse both outputs and observe the following differences between
the two results.

  * •

We notice that both COGCN and CHGNN are successfully able to identify and
isolate the Customer Dataset and Customer Database services.

  * •

However, unlike CHGNN that partitions the policy functionality into two clean
services - Policy Dataset and Policy Database. COGCN mixes some functionality
of both clusters together. As seen in COGCN’s output, the policy dataset -
vsam-ksdspoly has been mixed with other policy tables.

##  6 Without Seed Constraints

We also experiment with CHGNN by not specifying the seed constraints and note
down the results in this section. One of the drawbacks of using a GNN without
seed constraints, is that we cannot guarantee a clean separation of the
application’s distinct functionalities. As a result, there are instances where
the GNN outputs a cluster that may have more than one functionality. Hence the
clusters obtained from the GNN without seed constraints may not be cleanly
differentiable.

We show the reviewer’s qualitative analysis of these clusters in Table 5. In
this analysis as well, all reviewers agree that CHGNN is a better microservice
recommender than COGCN. We additionally show the clusters generated for Genapp
in Figure 8. As depicted in Figure 8, we see that CHGNN has better formed
clusters than COGCN, as it is able to cleanly separate between the customer
and policy functionality. But COGCN ends up mixing some functionalities of
customer and policy together. However, both results are still inferior to the
results in Figure. 6.

(a) Results for CHGNN

(b) Results for COGCN

Figure 8: GenApp application Sunburst charts (a) and (b) representing the microservice recommendations using CHGNN and COGCN models respectively. Application |  Language |  Reviewer Selection |  Reviewer Reasons
---|---|---|---
GenApp |  COBOL |  CHGNN |  R1. I have analysed both sets of outputs on 3 aspects. A) Number of datasets or tables correctly grouped in the cluster (more the better), B) Number of programs in the cluster that are incorrectly placed (less the better) and C) Number of clusters that do not have a well defined function (less the better). On all 3 aspects, I find that the blind1.json is a better result.
CHGNN |  R2. In Blind-1, my biggest problem is that TESTC1 comes with a Policy cluster. In Blind-2, my main problems are 1) LGAPVS01 is grouped wrong. 2) LGACDB02 and Customer-Secure table are grouped wrong 3) All tables are grouped together and LGAPVS01 is thrown in as a bonus. Relatively speaking, Blind-1 is far better.
Daytrader |  Java |  CHGNN |  R3. Keysequence, KeysequenceDirect, keygen table are all together. TradeSLSBean and TradeDirect which are common in functionality are put together. Blind2 has a very large cluster with tables like keygen packed together which looks wrong. But still Blind2 also should be improved to group TradeConfig and TradeAction
CHGNN |  R4. Overall I think it is a good separation of functionality, I could associate a name with each cluster to some extent. Only a few things bothering me: most db tables end up in the same cluster as TradeDirect, but since TradeSLSBean is also present here, it probably makes sense. Also the ping classes assigned to the cluster with Order and Holding data seem a bit random.
PBW |  Java |  CHGNN |  R3. Reason : supplier service came out well with its db contained within it. Inventory, Shopping and backorder which are closely connected are clubbed together with inventory and backorder table together. Also in Blind2, there is no good explanation for catalogmanager and emailmessage
CHGNN |  R4. In Blind 1, there are clear Supplier, Inventory/Backorder and Customer clusters with the only issue being customer-db moved to a different cluster. Blind 2 on the other hand has no clear separation of clusters. Inventory/Backorder and Shopping seem mixed up.
Acme-Air |  Java |  CHGNN |  R3. Reason : Customer service came out as a well separated cluster. I find that unlike Blind2 it didn’t mix the booking with authentication service. At a first glance, I was confused why FlightService abstract class is separated from FlightServiceImpl and kept with BookingService. But BookingService seem to have dependency only to the only FlightService implemented method getFlightByFlightId.
CHGNN |  R4. Flight and Customer clusters look more complete in Blind 1 and other clusters look better overall. In Blind 2, the customer table seems misplaced and the bottom left and bottom right clusters seem to be a bit overloaded.
Table 5: Without seed constraints - For all the four applications, the
reviewers chose the microservices recommendations by CHGNN over COGCN.

##  7 Limitations

Like we discussed in the conclusion section, the current method works on the
program and resource level but the decomposition task can be studied at a more
granular level from programs to functions and tables to columns. Also, we had
to limit our study to only four medium sized applications as it takes 3-4
weeks for a software developer to understand the implementation structure of
the application and provide feedback for the generated recommendations.
However, based on the positive feedback from the qualitative analysis, we
believe that our approach can significantly reduce developers’ effort in
finalizing the ideal microservices design for the migration activity.