Introduction

The monolithic approach to application design was the beginning of the rapid evolution of distributed systems. The application components of a monolithic code are tightly connected and have a big codebase. The size and complexity of the application are both constrained by monolithic architecture. SOA has developed as a result of the growing complexity of enterprise systems, business objectives, and the necessity to create distributed applications [8]. Service oriented architecture (SOA) has been widely used in designing large enterprise applications in the last two decades. It was developed mainly to address the deployment and scaling problems with monolithic systems. All of the system’s components are designed as services in the SOA design approach to developing applications [18]. A service is a reusable piece of software code that performs a range of business operations, which can be basic or complex depending on the needs of the company. SOA is a method of integrating numerous software components that use the Enterprise Service Bus (ESB) as a communication channel [32]. The backbone of SOA is the ESB, which aids in the provision of middleware system functions. The ESB operates as a mediator between the service requestor and the provider, providing a high-performance and scalable platform. SOA gained popularity as web services evolved, which is a common application of SOA ideas [19]. Web services are internet-based services that may be established, accessed, and found through the use of communication protocols such as XML-based SOAP and WSDL. HTTP and REST protocols are used by web services to transport messages over the internet. The three main components of the web services architecture are the service provider, service consumer, and service registry. A single web service may be utilised by several clients at the same time and is simple to implement.

Despite its popularity for application development, SOA has a few design and deployment issues [23]. Due of its dependency on other services and tight connection to the ESB, upgrading a single service necessitates the re-deployment of numerous components. Delivering many services leads to a monolithic deployment strategy, which has an influence on the company [9]. In addition, as the complexity of continuously changing business requirements rises, the application becomes complex and harder to manage as the size of SOA services becomes monolithic. Since SOA follows centralised control, scaling such monolithic applications is a bottleneck [30]. Overloaded services can be expanded horizontally by creating numerous copies of the same service, but the hardware cost rises. Moreover, web services exchange messages using complicated and heavyweight protocols such as SOAP.

Microservices emerged as a new architectural solution that employs cloud-based containers for deployment to address these shortcomings in traditional systems [15]. It is a design pattern in which each service is a tiny, loosely linked, scalable, and reusable service that can be built and deployed separately [28]. Each service should only do one task and have its own database and deployment infrastructure. Microservices exchange data using communication protocols such as HTTP/REST and JSON. Microservices, unlike SOA, may be implemented independently since there is no centralised governance and no reliance on middleware technology. Scaling on-demand microservices is simple when using cloud-based containers [14]. Microservices design fits well with the DevOps philosophy since each work is split down into little components and the SDLC is completed separately [27]. DevOps and agile approaches necessitate rapid application design and deployment to production.

To clearly understand the concepts of monolithic, SOA, and microservices architectures, a diagram is presented in Fig. 1. A monolithic system contains a single enormous unit of code, and when it comes to SOA, the massive codebase is partitioned into coarse-grained services. The services in SOA are further partitioned to generate fine-grained services in microservices.

Fig. 1
figure 1

Understanding of monolithic, SOA and microservices architectures

Full size image

Due of the multiple benefits of microservices architecture, software architects are starting to transition their old systems to this design [26]. Numerous companies, including Netflix, Amazon, and Twitter, have begun to use this architecture in new applications [24]. Because microservices have just recently evolved, there is a great deal of interest in both business and academics to investigate the tools, technologies, and programming languages utilised in this design. However, some software architects are uncertain about whether or not to adopt this new paradigm, as they are unfamiliar with the benefits and drawbacks of adopting microservices [26]. However, academic research into microservices is still in its early stages, with relatively little work comparing and evaluating microservices against SOA.

The remaining part of the paper is organized as follows. The necessary background information is discussed in “Background”, and the preliminaries are presented in “Preliminaries”. The details of the chosen application, along with the service graphs, are discussed in “Experimental study”. Results and discussion are presented in “Results and discussion”, and “Conclusion” concludes the paper.

Background

There are some technical variations between SOA and microservices application design and implementation methodologies. Microservices design is based on sharing as little as possible, and share as much as possible is the idea of SOA [29]. For communication between services, SOA relies on heavyweight middleware and enterprise service bus, but microservices depends solely on lightweight protocols. The REST and HTTP protocols are used for the exchange of messages and JSON as a data interchange format in microservices [11]. SOA uses WSDL and SOAP protocols for the exchange of messages. Microservices use the concepts of smart endpoints and dumb pipes, as well as the choreography over orchestration technique [5]. There is also a necessity to evaluate and study both the architectures with respect to performance, scalability, and deployment, according to various research [6, 12, 13]. The security of the applications is also a crucial factor to consider while comparing [25].

In the literature, the comparison of SOA with microservices has been addressed from several viewpoints. The authors of [7] presented the applicability of patterns proposed for SOA to microservices architecture. Microservices patterns are not new, and most patterns that are applicable to SOA are also applicable to microservices. This cannot, however, be called a comparison of the two architectures. In [8, 9], the theoretical contrasts between the two approaches in terms of characteristics are discussed. The distinctions are discussed from both research and industry viewpoints. The authors in [16, 17] have proposed techniques for estimating the effort required for migration from SOA to microservices architecture. Their studies signifies that migration to microservices is inevitable. A study on the best practices for migrating legacy applications to microservices has been proposed in [22]. In [23], the author presents a similar comparison of distributed systems like client and server, SOA, and microservices. There has been a greater focus on comparing SOA with microservices in terms of communication protocols, message frameworks, and service discovery.

To the best of our knowledge, no analysis of the impact of upgrading an SOA-based application to a microservices design has been done. Hence, in this work, we use change propagation probability (CPP) and architectural stability metrics to assess the impact on the application while migrating it to the new style.

Preliminaries

Service Graph

We define the service graph as a formal model that reflects any service-based application. We design a service graph by examining the APIs to collect the inputs and outputs. Because services are the core component of both SOA and microservices designs, we utilize this service graph to compare the two architectural styles. The service graph (SG) is a formal graph that is used to visualise the interactions and relationships between the services in an application. Figure 2 depicts the generalised form of a service-based application as a service graph.

Fig. 2
figure 2

Service graph representation

Full size image

Definition 1

Let G(V, E) be an service graph with n nodes, where each node represents a set of services in the application, and the edges between the nodes indicate the interactions or dependencies that each service has with other services in the application.

Let V = {\(s_1\),\(s_2\),\(s_3\),...} represent the nodes of the service graph where \(s_1\),\(s_2\),\(s_3\),... are services and E = {(\(s_1\),\(s_2\)), (\(s_1\),\(s_3\)), (\(s_2\),\(s_4\)),....} represent the edges between the nodes which indicates the dependency between the services. As stated in Eq. (1), a service is a collection of coordinating and interacting processes.

$$\begin{aligned} S_i= \langle {P_1}^i, {P_2}^i, {P_3}^i, \ldots , {P_n}^i, \Lambda \rangle \end{aligned}$$
(1)

where \({S_i}\) is the logical service instance, \({P_k}^i\) indicates kth process implementing logical service functionality \({f_i}\) through the programmatic interface \({I_i}\) and \(\Lambda \) represents network communication function between individual processes.

Change Propagation (CP)

The change in one component of the software architecture impacts the other components in the system. Therefore, the other components should also be updated and redeployed. However, to evaluate the impact of changing one component on other components of the architecture is given by change propagation probability. Let S be the application designed using architecture A which is to be migrated to form a new application \( S^\prime \) of architecture B. We use this metric to find the probability, whether a change in one service \( s_1 \) of S requires a change in service \( s_2 \) while migrating the application from S to \( S^\prime \).

Definition 2

The conditional probability for the change propagation from service \( s_1 \) to \( s_2 \) in S is defined as [1]:

$$\begin{aligned} CP(s_1:s_2) = P((s_2 \ne s_2^\prime ) \mid (s_1 \ne s_1^\prime ) \wedge (S=S^\prime )) \end{aligned}$$
(2)

where \( S^\prime \) is the application obtained from S by migrating \( s_1 \) to \( s_1^\prime \) and \( s_2 \) to \( s_2^\prime \). Here, \( s_1 \) and \( s_2 \) are the services of application S of architecture A and \( s_1^\prime \) and \( s_2^\prime \) are the services of the migrated application \( S^\prime \) designed with architecture B.

The service based architectures can be seen as a collection of services \( s_i \), \( i=1,2,\ldots ,N \). Every service \( s_i \) has a set of processes \( V_i \) which provide the functionality for service \( s_i \). Using Bernoulli random variable, we find the usage coefficient value \(\pi ^{ij}_{v}\) for every process p \(\in \) \( V_i \) and every other service \( s_j \).

$$\begin{aligned} \pi _v^{ij} = {\left\{ \begin{array}{ll} 1 &{} \text {the process} \,\,p \,\,\text {of} \,\,s_i \,\, \text {is required by} \,\, s_j \\ 0 &{} \text {otherwise} \end{array}\right. } \end{aligned}$$
(3)

To estimate the change propagation probability CP(\( s_1:s_2 \)), for every pair of services \( s_i \) and \( s_j \), \( i \ne j \), we use the values of random variable \(\pi ^{ij}_{v}\).

$$\begin{aligned} \mathrm{{CP}}( s_1:s_2 )= \dfrac{1}{\mid V_i \mid } \sum _{p \in V_i }^{} \pi ^{ij}_{v} \end{aligned}$$
(4)

The CP is a matrix that contains the relation between all the services of the application. As matrices cannot be compared, we represent the values of the matrix as a scalar component which represents the architecture’s potential to wrap its services from other’s changes. We denote the scalar component as change propagation coefficient (CPC), and it is given as:

$$\begin{aligned} \mathrm{{CPC}}= \dfrac{\sum _{j}^{} \sum _{j\ne i}^{} \mathrm{{CP}}(s_i:s_j)}{N^{2}-N} \end{aligned}$$
(5)

Here N is the number of services in the architecture, and the CPC indicates whether changes in one service of the architecture propagates to other services or not. A low CPC value of the architecture indicates a good sign in the design of the application.

Architecture Stability

Stable software architecture has been a challenge for software architects due to the changes in environmental factors [31]. The major concern is the factors that influence architecture decisions, and stability of the architecture [10]. Stability is the capability of the application components to stay unchanged and remain intact while adding new changes or requirements [2]. Here, we consider the scenario of migrating service oriented architecture based applications to microservices, and as both the styles are service-based, we measure the stability of the application using the metrics. To measure the stability of the architectures, two metrics are defined based on the metrics proposed in [3].

Core Design Instability (CDI)

It is used to evaluate the change performed on the services of the architectural core when it is migrated. IT is defined as follows:

$$\begin{aligned} \mathrm{{CDI}} = \dfrac{n+d}{m}, \end{aligned}$$
(6)

where

  • n is the number of new services added after the migration of an application S from architecture A to \(S^\prime \) in architecture B.

  • d is the number of services deleted from the application S of A after migrating it to \(S^\prime \) of B.

  • m is the number of services of the application S of A before migrating it to the B.

Core Calls Instability (CCI)

It is used to evaluate the changes in the interactions between services and it is computed as:

$$\begin{aligned} \mathrm{{CCI}}=\dfrac{c+p}{t}, \end{aligned}$$
(7)

where

  • c is the total number of new calls between services belonging to the application \( S^\prime \) of B and not present in the application S of A.

  • p is the total number of calls between services of the application S and not present in the application \( S^\prime \) after migration to B.

  • t is the total number of calls between the services of the application S of architecture A.

Experimental Study

We use the vehicle management system (VMS) [4], a standard web-based tool for selecting, customizing, and purchasing automobiles and parts via a front-end web page. The application is used to assist clients in selecting, customizing, comparing vehicles, finding dealers, and requesting a quote. The database stores all of the information about the automobiles, their parts, and their costs, and the user interface assists clients with the details. Customers can use the inventory data to find the vehicle they want and the dealer that sells it. Customers may also select the part and product type for their car from the interface.

SOA Based Application

The SOA implementation of the VMS application has 8 services. Table 1 lists the details of the SOA services, and Fig. 3 shows the service graph representation, which is indicated as SG_SOA. We used TIBCO business works to develop the SOA-based application and TIBCO administrator to deploy it. An Oracle database is selected for data storage, and TIBCO BW database palettes assist in connecting to the database. The Representational State Transfer (REST) protocol is used to communicate between the services over HTTP. Each service is deployed on a single server as a stand-alone archive.

Table 1 Services of both the applications
Full size table
Fig. 3
figure 3

SG_SOA: Service graph representation of SOA based application

Full size image

Microservices Based Application

Microservices-based application is designed using the extraction approach [21] proposed for extraction of microservices application from a SOA-based application to construct a service graph that helps in the identification of candidate microservices. The VMS application is built with the spring boot framework and REST/JSON formats for communication between services in the network, taking into consideration the microservices. In a service register, the Eureka service is used to store all of the services. MYSQL database is used to store the data, while spring boot connector uses JPA connector to retrieve it. Each microservice is deployed in the cloud using Docker containers. The application’s docker image is created, deployed to Docker Hub, and containers are built from docker images. Table 1 contains the information of the produced microservices, whereas Fig. 4 depicts the service graph (SG_MSA).

Fig. 4
figure 4

SG_MSA: Service graph representation of microservices based web application

Full size image

Results and Discussion

Let SOA be represented as A and microservices architecture as B. For the evaluation purpose, consider S and \( S^\prime \) as the applications designed with both SOA and microservices styles respectively. We define \( \mathrm{{CP}}_\mathrm{{SOA}} \) and \( \mathrm{{CP}}_\mathrm{{MSA}} \) as the change propagation matrices of both SOA and microservices architectures. Similarly, we define \( \mathrm{{CPC}}_\mathrm{{SOA}} \) and \( \mathrm{{CPC}}_\mathrm{{MSA}} \) as change propagation coefficients for both SOA and microservices architectures.

Change Propagation Probability

From the service graph of the SOA application, the values of CP for each pair of services is calculated using the Equations (3) and (4). The values are presented in form of a matrix as given below.

figure a

The generated CP matrix is converted to a scalar component using the change propagation coefficient (CPC). The CPC value indicates the impact of change in one particular service has on other services. As we have eight services in the SOA application, the N value is eight.

$$\begin{aligned} \mathrm{{CPC}}_\mathrm{{SOA}}= \dfrac{35.33}{8^2 - 8} = 0.63. \end{aligned}$$

Similarly, from the service graph of microservices application given in Fig. 4, the CP values are calculated and presented as matrix given below.

figure b

The change propagation coefficient of the microservices application is also calculated using the CP matrix.

$$\begin{aligned} \mathrm{{CPC}}_\mathrm{{MSA}}= \dfrac{72}{12^2 - 12} = 0.54. \end{aligned}$$

From the above CPC values of both the styles, microservices based application exhibits low CPC value compared to applications built using SOA concepts. As the CPC value of microservices is low, it indicates a good sign of design, and it is best suitable for large enterprise applications compared to SOA based applications. This result of the chosen case study helps the software architects to assess the impact of migration. Though the other parameters such as effort required for migration and complexity of the applications are high for microservices [20], these metrics show that the use of microservices in design makes the application stable and maintainable.

Stability Evaluation

By considering the details of the services and service calls from the service graphs of the chosen application, the values of CDI and CCI are evaluated. From the services information in Table 1, the value of CDI is calculated as:

$$\begin{aligned} \mathrm{{CDI}}= \dfrac{4+0}{8} = 0.5 \end{aligned}$$

Similarly, we calculate the value of CCI,

$$\begin{aligned} \mathrm{{CCI}}=\dfrac{32+0}{38}= 0.84 \end{aligned}$$

The metric values CDI and CCI indicate a measure of how much the services of the application S of architecture A have changed after migrating to application \( S^\prime \) of architecture B. The threshold value chosen for both CDI and CCI is 0.15. If the metric values are less than 0.15, then the architecture is said to be stable and otherwise unstable. By observing the calculated values, the metric values are greater than 0.15, and hence, it indicates that the services in SOA application have undergone a major change to form the services in microservices application. Also, the impact of migration is very high.

Conclusion

With the evolution of microservices architecture, there is a paradigm shift in designing software applications. With the advancement of new technologies and tools, every day the IT world is witnessing many improvements and benefits of using new things. Similarly, many IT giants are migrating their SOA applications to microservices architecture. However, the impact of migration is not assessed, and some architects are uncertain whether or not to migrate, as both SOA and microservices have their own set of benefits and drawbacks. Hence, in this work, we presented an assessment of the impact of migrating SOA based applications to microservices architecture. We observe that, to migrate an SOA application, the system needs to change and be updated drastically as the design and deployment environments are quite different for both styles. The effort required for complete migration and comparing both the architectures with QoS attributes such as performance, maintenance, scalability, etc., can be considered as future work.