The evolution from monolithic to cloud-native microservices architectures represents a fundamental shift in software engineering practices, driven by the increasing demands for scalability, reliability, and rapid deployment in modern digital environments. The fundamental distinction between monolithic and microservices architectures lies in their codebase configuration and component organization. Microservices employ multiple, independent codebases distributed across separate services within a distributed system, while monolithic architectures operate as singular, cohesive units with unified codebases that create interdependencies among all components. This structural difference has cascading effects on various system design, deployment, and maintenance aspects. Due to these advantages, migrating existing monolithic systems to a microservice architecture might be beneficial because of a potential high. This decision must be evaluated thoroughly since the migration effort can be very high. To gain practical insights into migrating a typical monolithic application, selected components of a webshop were migrated as a representative example. This approach aims to highlight the essential steps involved in the migration process and identify potential challenges. Subsequently, the newly developed system is evaluated against the original monolithic version, focusing on performance. The findings from this prototype migration are intended to serve as a foundation for guiding future migration decisions _____________________________________________________ SQAMIA 2025: Workshop on Software Quality, Analysis, Monitoring, Improvement, and Applications, September 20--12, 2025, Maribor, Slovenia ∗ Corresponding author. † These authors contributed equally.
Application
The evolution from monolithic microservices architectures represents a fundamental shift in
software engineering practices, driven by the increasing demands for scalability, reliability, and
rapid deployment in modern digital environments [
While monolithic systems may remain viable for specific use cases, the transition to cloud-native
microservices architecture delivers substantial operational efficiency, system resilience, and
organizational adaptability, particularly for enterprises experiencing rapid growth or requiring
highavailability services [
While the benefits of microservices architecture are substantial, organizations must carefully
evaluate their specific circumstances and requirements before initiating migration efforts [
This leads to the research question for this project: What impact does the migration of a monolithic application to a microservice-based application have on performance (response time and CPU usage)?
Developing and validating a prototype can be justified as a scientific method to answer the
research question. Prototypes allow to test whether proposed ideas, theories, or designs are practical
and feasible before committing to full development [
This section presents the central theoretical concepts relevant to the migration project.
Monolithic architecture represents the traditional approach to software development, where
applications are constructed as unified, self-contained units with a single codebase that couples all
business concerns together. This architectural model treats the entire application as a singular,
extensive computing network, requiring comprehensive updates to the whole stack when any
modifications are necessary. The monolithic approach has historically provided simplicity in
development and deployment, as it involves managing a single executable file that encompasses all
application functionality [
However, monolithic systems present significant scalability challenges as applications grow in
complexity and user base. The integrated structure of monoliths creates bottlenecks when
attempting to scale specific components independently, often requiring scaling the entire application
even when only particular features experience increased demand [
The coupling of components in monolithic systems also creates reliability concerns, where
failures in one component can potentially compromise the entire application's functionality. This
lack of fault isolation means that a single point of failure can result in complete system downtime,
making monolithic architectures less resilient compared to distributed alternatives. Additionally,
monolithic systems often constrain development team organization and technology choices, as all
teams must work within the same technological framework and coordinate changes across the entire
codebase [
This kind of software architecture represents a paradigm shift toward microservices-oriented,
containerized, and dynamically orchestrated systems designed to optimize resource utilization in
cloud computing environments. These applications are fundamentally structured as collections of
small, independent services that can be developed, deployed, and scaled autonomously while
maintaining loose coupling between components. The microservices architecture adheres to several
key principles that distinguish it from traditional monolithic approaches [
To meet the flexible requirements of microservices, containers are used to encapsulate each
module, which replaces the traditional virtual machine (VM) operating mode. Container can be
started and stoped quickly to optimize resource consumption [
The single responsibility principle ensures that each microservice focuses on a specific business
function or capability, promoting maintainability and enabling easy replacement of individual
services without affecting the broader system [
Independent deployment capabilities represent another crucial advantage of microservices architecture, enabling faster release cycles and reducing the risk of deployment failures. Each service can be updated, scaled, or modified without requiring changes to other system components, significantly improving development velocity and reducing coordination overhead [18]. Fault isolation mechanisms ensure that failures in one microservice do not cascade throughout the system, enhancing overall resilience and maintaining service availability even when individual components experience issues [19].
Containerization serves as the foundation for cloud-native microservices deployment, providing lightweight, standardized units that package application code with all necessary dependencies. Containers enable rapid scaling capabilities and portability across different environments, while orchestration platforms like Kubernetes manage the complexity of deploying and scaling containerized applications. The stateless nature of many microservices further enhances scalability by eliminating persistent memory requirements and enabling dynamic resource allocation based on demand [20].
Performance testing is part of software testing and is an essential phase in the software development process for evaluating a software product. New problems can arise with web applications due to high user numbers and the associated higher load. The performance of a web application is typically determined under normal load using a load test and under very high load using a stress test. Different metrics can be specified with the tests.
This section gives an overview of the architecture of the monolithic and microservices application. Furhtermore, the use technologies and toos for both systems are presented.
ShoppingCart is an e-commerce website developed with Java. Users can look closely at products and add them to their virtual shopping cart. The user must be logged in and registered to use the shopping cart function. To successfully place the order, there is a typical order flow where the user's data is entered again, and a final order button. There is also an About Us page with information about the store and a contact page to contact the operator. Admins can also add products and edit existing products.
The application of the monolithic application is based on a model-view-controller architecture. The front end is realized by JSP pages, which are coupled with the Spring controllers. An H2 database is used as the database. The data models are created with Hibernate in Java. The build tool Maven is used for compilation and deployment. Maven creates a war (Web Application Resource) file, which is executed using Apache Tomcat Server.
The individual components of the sample application are ported into independent microservices. The new microservice architecture creates a distributed system for which new interfaces must be made. To determine how large a microservice should be, the various data models are considered and analyzed to determine which data is closely related and which is independent. Similar data is grouped, and the individual services are derived from this. This results in the microservices product service, user service, cart service, and order service for the ShoppingCart application. In case of doubt, services should be roughly granulated, as these can always be broken down further if necessary or advantageous. REST interfaces are created to communicate with the microservices.
An API gateway is also required, containing the front end and the interface between users and all microservices [21]. The API gateway uses the newly implemented REST interfaces to communicate with the various microservices. A discovery service is also built to provide better name resolution during communication and an overview of all running microservices. With the help of a load balancer, it is possible to have a balanced load even with multiple instances of a microservice. This enables the scalability of a microservice-based system.
ShoppingCart uses Spring MVC as the basis. Dynamic HTML pages are rendered with the help of JSP, and Spring Security is also used for authentication, as well as Spring Webflow for the check-out process. An H2 database is used, and Hibernate is the interface. Maven is also used to manage dependencies and as a build tool. The migration to microservices means that Spring MVC can be dispensed completely. Spring Boot is used instead. In addition, JSP is replaced with AngularJS and the H2 database is replaced with a MariaDB. Finally, Spring Webflow must be removed, as Spring Webflow is not compatible with AngularJS. The technologies are summarized once again in table 1:
Spring Boot Spring MVC is a Model-View-Controller framework for web applications. Spring Boot is used for REST APIs and requires less configuration. It is, therefore, well suited as a foundation for microservices.
AngularJS Java Server Pages are compatible with Spring Web MVC.
A different frontend technology is required since REST APIs are used for microservices. AngularJS was chosen here because it is compatible, and there is much online information for the migration.
MariaDB MariaDB has a large community and will make cloud deployment easier in the future.
Hibernate Not Changed Spring Webflux Spring Webflux includes WebClient, an interface that enables web requests for reactive websites. Spring Security will also be migrated to Spring Webflux Security.
Spring Security Despite Spring Webflux Security, Spring Security is still used to configure web filters.
Spring Webflow is not compatible with AngularJS. The order flow must, therefore, be rebuilt.
To reduce possible differences in performance caused by the runtime environment, a branch of the original version is used. This branch has already been converted to Spring Boot and MariaDB. The application is started in the Google Compute Engine. This is based on the same "e2-medium" computer type and the same image as the Kubernetes instances. This is to avoid performance differences due to different computing power.
The microservices are started in the Google Kubernetes Engine, as described in the Deployment section. An external IP address is assigned for the API gateway, and port 8080 is forwarded. The cluster is set up so that 6 nodes are used. The "e2-medium" machine is selected as the computer type for the nodes. This offers 4GB RAM and 2 virtual CPUs. For the performance comparison, automatic scaling is deactivated for the time being, and instead, a fixed scaling factor of 2 instances is set for each service. This represents approximately how the system would run in standard operation.
In this chapter, comparisons are made between the original monolithic application and the migrated microservice application. The performance for various use cases is recorded and compared for both application versions.
The microservices are packaged into containers using Docker and deployed in a Kubernetes cluster at any cloud provider. When Kubernetes operates on virtualized infrastructure, VM clusters can be provisioned, managed, and scaled up or down with relative ease. Most cloud providers offer virtual machines as their fundamental compute units, along with services specifically designed to support Kubernetes deployments.
All measurements are carried out using the Apache JMeter tool. The following dimensions are used to measure performance [22,23]:
Response time: comparison of the monolith with microservices; response time is the time between sending a request and receiving the complete response CPU usage for the following services: · API-gateway: API gateway required, which contains the front end and serves as an interface between users and all microservices · The discovery service can recognize unreachable services, remove them, or redirect requests to available instances. · Cart-Service: This service represents the shopping cart. For each customer, a new cart is created · Order-Service: This service handles customer orders · User-Service: The User-Service is responsible for registration and login
To measure performance, a fixed sequence of queries is defined, which should cover the functions and workflow of the application (Table 2). This is to ensure that a real workload is simulated. JSP pages are called in the monolithic architecture, whereas, in the microservice architecture, the newly implemented REST interfaces can be accessed. There are four test cases (Table 3) whereby the HTTP query process is always the same. However, the number of threads that simulate the number of users and the number of repetitions changes for each test. Each test triggers a different load, and it is possible to compare how the two applications behave. Ramp-up is the time it takes for all users to be added to the test. Even in a productive environment, the number of users does not typically increase to 100 percent from one second to the next. The ramp-up time should, therefore, simulate a natural increase in the number of users.
During the test period, it can be seen that the CPU utilization of the microservices hardly increases (Figure 1, left). In this case the microservices are spread across 5 VMs. For the microservice solution, the metrics show that the CPU usage is always below 50 percent (Figure 1, right), compared to over 100 percent for the monolithic solution (Figure 2). This is possible because the e2-medium computer type of the instance has CPU bursting, which allows the instance to temporarily access additional CPU capacity.
With five simulated users, where all requests are repeated 100 times, no microservice uses more than 20 percent (Figure 3, left) of the CPU. This picture is also reflected in the utilization of the VM instances (Figure 3, right). The VM of the monolithic software activates burst mode again, as the CPU has already reached its limits, as depicted in Figure 4.
The microservices (services and VMs) have not yet reached their limits. The left part of Figure 5 represents the CPU utilization of the services, the VMs CPU utilization can be seen on the right side of Figure 5. The VM of the monolith cannot cope with the load even in bursting mode, as shown in Figure 6. These additional resources are limited to around two minutes. From this point onwards, there are substantial deviations in the server response times.
In Google Cloud Monitoring, it can be seen that microservices also reach their limits with 50 users (Figure 7, left). The advantage, however, is that five VM instances are available for this workload. The bottleneck in this case are the two VM instances, each with an API gateway, which also enter burst mode during the test (Figure 7, right). To increase performance, the two API gateways' fixed scaling would have to be removed or increased. The VM with the monolithic architecture is running at full capacity throughout this test. It can be seen how the load initially rises to up to 200 percent (Figure 8)with the help of burst mode and then levels off at around 100 percent.
Regarding performance, particularly response time and CPU usage, it has been shown that microservices deliver significantly better results than the monolithic system. With Kubernetes, the services and the number of nodes in a cluster can be scaled automatically. This is a particular advantage when the system is used very dynamically. If the load is higher, the services can be split across several VM instances; if the load is lower, the number of nodes can be reduced again, saving costs.
An architecture based on microservices has further advantages compared to a monolithic architecture. Defective services can be detected with health check metrics and restarted automatically. With several replicas of a service, functionality is still guaranteed even if one of these replicas fails. Such a system's maintenance and further development are also more efficient than a monolithic system, especially if the system's complexity is high or increasing.
On the other hand, there is the migration effort. Therefore, It is essential to conduct a thorough analysis to clarify how the new system will be structured, which new interfaces need to be created, and which technologies and tools will be used.
During the preparation of this work, the authors used Grammarly in order to: Grammar and spelling check. After using these tools, the authors reviewed and edited the content as needed and take full responsibility for the publication's content.