Enquire Now
Machine Learning · Python · Data Science · Devops Automation Of Software Deployment Pipelin · 2026

Devops Rate Limiting Api Gateway

Data Preparation · Feature Engineering · Model Training · Evaluation — A practical machine-learning project concept for building, comparing and validating models using reproducible data-science workflows. Suitable for final-year, BE/BTech, ME/MTech and research-oriented project implementation.

7
Abstract Sections
7+
Tools & Platforms
3
Pipeline Stages

Devops Rate Limiting Api Gateway

Devops Automation Of Software Deployment Pipelin · ML Project

Python · Data Preprocessing · Model Development · Evaluation

Project focus: anomaly detection / classification using IoT sensor streams and timestamped device measurements.

Containerization of a polyglot microservice application

Vamsi Krishna Yepuri, Venkata Kalyan Polamarasetty, Shivani Donthi, Ajay Kumar Reddy Gondi

Department of Computer Science, Kent State University

Abstract—This project investigates the benefits of containerization be packaged as a container image, which abstracts it from the

technology in modern software development and deployment. The underlying infrastructure and makes it simpler to deploy and run study emphasizes the advantages of using Kubernetes and Docker in the services across various environments without compatibility the development process, including the easy packaging and deploy- ment of microservices, efficient resource utilization, faster startup issues. For example, consider an e-commerce application based

times, and greater scalability and flexibility. The project concludes on microservices, with various services such as product catalogs, by proposing a study that involves creating a polyglot microservice shopping carts, payment processing, and order management. Each application using Java, Python, and JavaScript, containerizing it with of these services can be containerized, making it easy to deploy Docker, and deploying it in Kubernetes. The study aims to evaluate and update them independently. This enables developers to add

service discovery and auto-scaling in distributed mode and compare the performance metrics with virtual machines and containers. The new features or modify existing ones without impacting other

results of this study can inform software development teams about services.

the benefits of containerization in modern software development and Additionally, containers provide a high degree of isolation deployment. between microservices, minimizing conflicts and dependencies Index Terms—Docker, Kubernetes, Containers, Microservices, between them. By packaging each service as a container, they

Polyglot can each run their own instance of the required database, without

impacting the other services in the system. As a result, con-

I. I NTRODUCTION tainers provide greater agility, scalability, and consistency in a

Containerization has transformed software development and microservices project, allowing developers to focus on developing

deployment with Docker being one of the most widely adopted and updating microservices rather than the infrastructure and open-source platforms for building, shipping, and running dis- deployment processes. tributed applications. However, as containerized applications be- The use of virtual machines (VMs) can present challenges come more complex, managing them at scale can be a chal- when it comes to running applications, as VMs require their

lenge. Kubernetes, an open-source container orchestration system, own operating system and consume significant amounts of CPU, provides a platform for managing and deploying containerized memory, and storage resources, which can result in slower appli- applications at scale. Its popularity is attributed to its ability to cation performance and increased complexity. This can be solved automate deployment, scaling, and management of containerized through the use of container technology, which allows multiple

applications, with features like automatic load balancing, scaling, containers to share the same operating system kernel, leading to and self-healing. Trends in Kubernetes technology include the better resource utilization and faster startup times for applications, adoption of serverless computing, which enables developers to and ultimately greater scalability, flexibility, and cost efficiency. run their code in lightweight containers without managing in- For instance, consider a data analytics application that needs

frastructure or container orchestration. Kubernetes also finds use to process a large amount of data quickly and efficiently. If in hybrid and edge computing, where computing resources are the application runs on a virtual machine, it may suffer from distributed across multiple devices and locations, demonstrating slower performance due to the overhead and complexity of its versatility and adaptability to modern software development running a full operating system. By using container technology,

and deployment needs. however, developers can run multiple lightweight containers on Public cloud providers have played a significant role in the the same host operating system, resulting in faster performance, adoption and advancement of container technology. They offer lower resource usage, and greater scalability for the application, container services that allow developers to deploy, manage, and allowing for faster data processing and analysis.

scale containerized applications, which have reduced the barrier of Achieving container capabilities with virtual machines is chal- entry to container adoption, making them available to businesses lenging due to the fundamental differences between the two of all sizes. These providers have also been instrumental in technologies. Containers are lightweight and efficient, sharing the promoting container standards and enabling interoperability, con- same operating system kernel as the host machine, while virtual

tributing to the adoption of Kubernetes as the de facto standard for machines emulate an entire hardware environment, including a container orchestration. Standardization of container orchestra- separate operating system, which can lead to higher resource tion simplifies the deployment and management of containerized usage and greater complexity. Additionally, virtual machines lack applications across different cloud providers and on-premises portability and flexibility as each one requires a specific configura-

environments. tion of hardware and operating system, making it difficult to move Containers provide a variety of benefits in microservices ar- or replicate them across different environments. Containers, on chitecture, with one of the most significant being the ease of the other hand, can be easily packaged and deployed on any host packaging and deploying microservices. Each microservice can system that supports the same container runtime. Although virtual

machines have their own strengths and use cases, containers addressed the challenges in distributed transactions in a polyglot are preferred for most modern applications due to their greater environment. proposes a performance model to analyze efficiency, flexibility, and portability, and because they can start resource management in Kubernetes clusters. The model uses up much more quickly, making them better suited for modern queuing theory and stochastic processes to represent the resource

application deployment and scaling. utilization of nodes and pods. The proposed model is validated The traditional monolithic application approach involves build- through experiments that compare its accuracy against the real ing a single, comprehensive app, which can be time-consuming system performance. The paper highlights the importance of to develop and maintain, making it challenging to achieve agility. having an accurate performance model to optimize resource allo-

To address these issues and achieve greater flexibility and ease of cation and improve the overall efficiency of Kubernetes clusters. maintenance, the world is moving towards microservices. In the Also in the evaluation of the performance of microservices era of microservices, numerous independent modules are set up in architectures using containers, specifically Docker. The authors traditional virtual machines, which can lead to conflicting libraries conduct experiments to compare the performance of a monolithic

and make the process of provisioning, scaling, service discovery, application with a microservices-based application, both deployed load balancing, and deployment manual and time-consuming. To on Docker. The experiments involve measuring the response time solve these problems, microservices can be packed in containers and throughput of the applications under various workloads. The instead of virtual machines, which will help to address conflicts results of the experiments demonstrate that the microservices

and create independence between each microservice. Workloads architecture outperforms the monolithic architecture in terms of can be run in a scalable and distributed manner using Kubernetes, response time and scalability. Overall, the use of microservices, which can solve auto-scaling and service discovery issues. This Docker, Kubernetes, and polyglots in software development has project involves building a polyglot microservice application become increasingly popular in recent years due to their benefits

from the ground up using Java, Python, and JavaScript, container- in terms of portability, scalability, and flexibility. However, there izing it with Docker, and deploying it in Kubernetes to examine are also challenges involved in using these technologies, such service discovery and auto-scaling in distributed mode, while as managing stateful microservices in Kubernetes and achieving comparing the performance differences between the containerized consistent distributed transactions across polyglot microservices.

technique and the traditional virtual machine strategy. To address these challenges, researchers have proposed various In this project, we aim to compare the performance of virtual solutions and approaches, such as using a State Controller to im- machines and containers using several metrics. Firstly, we will prove the availability of stateful microservices in Kubernetes and examine the resource utilization of the microservice application developing a performance model to optimize resource allocation

between the two technologies, analyzing the CPU, memory, and in Kubernetes clusters. In addition, studies have been conducted storage usage to determine which technology is more efficient. to evaluate the performance of microservices architectures using Secondly, we will compare the startup time and scaling capabil- containers like Docker, and the results have shown that mi- ities of virtual machines and containers to see which is faster croservices architectures can outperform monolithic architectures

and more scalable. Thirdly, we will examine the storage space in terms of response time and scalability. Overall, the adoption utilized by both virtual machines and containers to see which of microservices, Docker, Kubernetes, and polyglots in software technology uses storage more effectively. Finally, we will evaluate development is likely to continue to grow as more organizations the portability of both virtual machines and containers and their seek to achieve the benefits these technologies provide while also

ability to be moved across different environments. By comparing addressing the challenges involved in their use. these performance metrics, we aim to determine which technology From TABLE I: Related Work, we can see the different features is more suitable for our microservice application and gain insights implemented by the referenced papers and the features that are into the strengths and weaknesses of each technology. implemented in this project. Our proposed solution will be dealing

with a stateless polyglot micro service, containerized used docker,

II. R ELATED W ORK and Kubernetes. We deploy our application and analyze the

Microservices, Docker, Kubernetes, and polyglots are some of improved performance using Kubernetes. the major collectively used technologies in the field of software

Reference Microservices Stateless Container Kubernetes Polyglot

development. There are many works that can be found on these X X topics which demonstrate the purpose of a shift towards the X X X docker and Kubernetes along with the challenges involved in X X X X the approaches. The importance of adopting a microservice-based X

architecture to achieve high availability for stateful applications X X in Kubernetes is explained in . The challenges of managing Our Project stateful microservices in Kubernetes and also proposed a solu- TABLE I: Related Work tion to improve their availability using a State Controller but did not mention the performance of Stateless polyglot micro service. In , presented a case study of a web application

that consists of several microservices, each running in a separate III. P ROJECT BACKGROUND container, and highlighted the improved portability, scalability, The trend towards microservices architecture has become more and flexibility. There are some situations that demand the use of and more popular in recent years, as it allows organizations to polyglots in order to achieve the desired solutions. discussed develop, deploy, and manage large, complex applications in a

the approaches for achieving consistent distributed transactions more agile and efficient manner. However, one of the challenges across polyglot microservices that use multiple databases and of implementing a microservices architecture is managing the

Fig. 1: Monolithic vs Microservices

Fig. 2: Polyglot Microservices

deployment and scaling of individual services in a way that is both effective and efficient. This is where containerization and tools, these can be overcome with the right approach and tools. container orchestration tools like Docker and Kubernetes come As a result, many organizations are adopting this approach to into play. In this project, we are going to show the analysis of build more resilient and adaptable software systems. performance improvement with the use of container orchestration A polyglot microservices architecture can provide significant

tools. advantages for monitoring , load balancing , security and QoS by allowing you to choose the best technology

A. Microservice vs Monolithic architecture for each microservice, improve resilience, make monitoring and

Monolithic and microservice architectures are two different troubleshooting easier, distribute the workload, and optimize

approaches to designing and building software systems. A mono- each microservice for specific tasks or functions. A polyglot lithic architecture is a traditional approach where an application microservices architecture can also take advantage of traffic is built as a single unit, while a microservice architecture is engineering! capabilities in data center networks to opti- an approach where an application is broken down into smaller mize the performance of microservices and improve over-

independent services. Fig. 1: Monolithic vs Microservices shows all application performance. By leveraging intelligent routing, the difference between monolithic and microservice-based ar- traffic shaping, load balancing, network performance monitoring, chitecture. The monolithic approach is easier to develop and and scalability, a polyglot microservices architecture can ensure deploy but can become difficult to maintain and scale as the that traffic is routed to the most optimal endpoint, manage the

application grows. On the other hand, the microservice approach flow of traffic between microservices, distribute traffic evenly offers greater flexibility, scalability, and resilience but requires across multiple endpoints, monitor network performance, and coordination between different teams. The choice of architecture accommodate changes in traffic volume and application usage. depends on the specific needs and requirements of the application, All of these capabilities can help to reduce latency, prevent

with monolithic being better suited for smaller applications and congestion, allocate resources efficiently, identify and resolve microservices for larger, complex applications. issues quickly, and ultimately, improve application performance explains the process of transforming monolithic applications and user experience. into microservices and provides a framework for understanding the migration process. It discusses the benefits and challenges of C. Container

adopting a microservices architecture.

A container is a lightweight, standalone, and executable pack-

age of software that includes everything needed to run an ap-

B. Polyglot microservices plication, such as code, libraries, and system tools. Containers

Polyglot microservices refer to a software architecture that provide a consistent run time environment, ensuring that the involves using multiple programming languages and technologies application can run reliably regardless of the underlying system’s to build independent, small-sized services that work together to configuration. Fig. 3: Virtual Machine vs Container shows the accomplish a larger goal. Fig.2 : Polyglot microservices repre- difference between a virtual machine and a container.

sents polyglot microservices. This approach allows developers to is a comprehensive report on the use of container technology choose the best language and tools for each service, rather than in modern software development. It covers various aspects of being limited to a single technology stack. Polyglot microservices container technology, including its history, benefits, challenges, are becoming increasingly popular because they offer several ben- and future trends. The goal of containerization is to package each

efits, such as increased flexibility, improved scalability, and better service and its dependencies into a lightweight, portable container fault tolerance. They can be designed to communicate with each that can run on any machine or cloud environment. other through APIs, message queues, or other protocols, which Docker is widely used as a containerization platform because it enables them to work together as a cohesive system. While there offers a reliable and reproducible setting for running applications.

are challenges to building and managing polyglot microservices, Docker makes it simple to create, deploy, and manage images, such as the need to manage multiple programming languages and which makes it easier to develop and test applications across

enable organizations to easily package and deploy services written in different languages or frameworks while ensuring that each service runs in a consistent and isolated environment. This makes it easier to manage dependencies, test and deploy services, and scale applications as needed.

Overall, the containerization of a polyglot microservices ap-

plication using Docker and Kubernetes can help organizations achieve greater agility, scalability, and reliability in their software development and deployment processes. It can also help reduce the complexity of managing and scaling multiple services, which can be particularly challenging in a polyglot environment.

Fig. 3: Virtual Machine vs Container IV. I NFRASTRUCTURE

The infrastructure required for containerization using Docker

and Kubernetes typically includes : a. physical or virtual machines, b. storage systems, and c. networking components.

Physical or virtual machines are needed to host containerized

applications. These machines should have sufficient CPU, mem- ory, and storage to run the application and the containers. Storage systems are necessary to store the container images, as well as any data or files that the application needs to access. The storage should be accessible to all the machines in the infrastructure. Net- working components such as load balancers and firewalls are Fig. 4: Docker vs Kubernetes also required to ensure that traffic can be routed to the appropriate

containers and that the network is secure. We also need a cloud engine, for that we are using GCP. Google Cloud Platform (GCP) different environments. A Docker container is a self-contained is a cloud provider that offers a range of services for hosting and software package that operates independently of other containers managing applications, data, and infrastructure in the cloud. GCP and the host system. It has its own network, file system, and provides tools and services such as Google Kubernetes Engine

resources, making it perfect for deploying applications with (GKE), Google Container Registry (GCR), and Cloud Storage that specific requirements. Docker images serve as snapshots of are well-suited for containerization using Docker and Kubernetes. an application’s file system, and they can be created using a Additionally, GCP provides tools for monitoring and managing Dockerfile script. Images can be utilized to start one or more containerized applications, such as Stackdriver Monitoring and

containers. Docker containers have advantages such as portability, Logging, and Cloud Trace for application tracing. consistency, isolation, resource efficiency, and scalability, while There are examples provided in describe the steps to their disadvantages include complexity, a learning curve, security deploy a web application using Google Cloud Platform, which in- concerns, dependency management challenges, and limited access volves creating a new project, enabling necessary APIs, choosing

to hardware resources. a deployment method, creating an instance or app, configuring it, and deploying the application. Once deployed, the application can D. Kubernetes and Docker be managed and monitored through the Google Cloud Platform.

Also, the GCP services used were VPC networks (Virtual Pri-

Kubernetes is an open-source platform for container orchestra-

vate Cloud Networks) and Compute Engine. VPC networks allow tion, which automates the deployment, scaling, and management for the creation of private virtual networks within GCP, while of containerized applications.Fig. 4: Docker vs Kubernetes shows

Compute Engine provides virtual machines with configurable

the difference between docker and Kubernetes and how Kuber- amounts of CPU, memory, and storage for running Kubernetes netes is used in a distributed environment and orchestrating the and deploying applications and services. docker containers. It provides a framework for deploying, scaling, and managing multiple containers across a cluster of servers, allowing organizations to run and manage their microservices V. S YSTEM A RCHITECTURE at scale. explains how Docker and Kubernetes can be To carry out a test of Docker and Kubernetes with an applica-

used to automate the scaling of a defense application in a tion in our scenario, it is necessary to have a polyglot microservice cloud environment. It highlights the benefits of these tools, such application that is designed with various programming languages. as improved security and reliability, and provides a detailed The bookstore application comes into picture here. The bookstore deployment process. application has been designed to offer its customers a conve-

In the case of a polyglot microservices application, where nient way to browse and purchase books online as a polyglot multiple programming languages and frameworks are used to microservice. Four microservices are being used to fulfill the develop individual services, containerization, and container or- result of the application as seen in Fig.5 which are developed in chestration can be particularly valuable. Docker and Kubernetes multiple programming languages and using scripts. They are the

run with the image name saved in the Docker hub command is given. The main reason of moving from the single-node Docker system to Kubernetes is that it can provide several benefits such as scalability, high availability, resource efficiency, service discovery for more complex applications with higher demands from the user.

By distributing the workload across multiple nodes, Kubernetes

can handle much larger workloads than a single-node Docker system, making it an ideal choice for applications with rapidly increasing traffic. The automatic detection and recovery features of Kubernetes can help maintain application availability, reduce downtime, and minimize the need for manual intervention.

The bookstore application can be deployed on Kubernetes. For

the multiple nodes, we are using the Google Cloud platform -

GCP as shown in Fig.7. The system starts with the creation of

Fig. 5: Bookstore application Architecture a VPC network, which is a virtual private network for Google

Cloud resources. This network provides a private network space

for the deployment of Kubernetes clusters. A Kubernetes cluster is then deployed on the VPC network with 1 master node and 2 slave nodes. This cluster consists of one or more nodes, where each node is a virtual machines (VMs). Each virtual machine runs a Kubernetes node, which is responsible for running pods and managing the resources of the virtual machine. Utilizing compute engine in GCP, a kubernetes master node is deployed, which manages the Kubernetes API server, controller, scheduler, and the

etcd database. The API server is responsible for receiving and pro- cessing requests from its clients, while etcd stores configuration data and metadata for the Kubernetes cluster. The controller sends the commands to the slave nodes. For example, if the image is to be deployed in the slave node, the controller sends a command to the kubelet in the slave node to implement the process. The scheduler is used while the initial creation of the pods in the Fig. 6: Architecture of Bookstore application on single-node slave nodes to configure the placement of the pods in case of any

Docker system downtime. The container run time is used to run the container

when it is started. We will use Network File System (NFS) server to store the data stored in the databases as a central repository . user service, orders service, books service, and the bookstore UI Kubernetes clients can then interact with the API server to deploy service. The data is stored in the central repository of a database. and manage applications on the cluster. When an application is The microservices are all connected to one another to commu- deployed, Kubernetes schedules the necessary containers onto the

nicate between them using REST APIs. Let us suppose that available nodes based on resource requirements and availability the bookstore application is deployed on a single-node Docker and also manages their life cycle, scaling them up or down as system as shown in Fig.6. Docker containers are lightweight needed. To access the application, users connect to a load balancer and standalone virtual machines that can run on any computer. that is deployed on the Kubernetes as a service. The service

The Docker engine effectively manages these containers and distributes traffic across the containers running in the Kubernetes ensures that they have access to the necessary resources, such as cluster. memory and CPU, while keeping them isolated from each other.

By running multiple containers on the same machine, each with VI. I MPLEMENTATION

its own set of dependencies and configurations, applications can This project is implemented as the following four steps. To im- be easily deployed and managed without having to worry about plement the containerization of polyglot microservice application conflicts between different software components. All the services , firstly we need to develop the microservices required for the with the source code and Dockerfile are built using the Docker application and then deploy the images of the microservices to

container platform. Once the build is completed, the data is the cloud system where kubernetes is configured. After deploying pushed to the central repository of the Docker hub. This eliminates the microservices, we will compare the performance of the the need to download and configure software dependencies for application on a virtual machine and a container. each microservice individually, making deployment more efficient and less time-consuming. With the required software already pre-

packaged into the images, it’s simply a matter of pulling the A. Development of polyglot microservices and containerizing necessary images and running them in the Docker container. then with Docker To run the bookstore application, all the microservices required A bookstore application is developed to order books online. The images that are saved on Docker Hub are set to run by using the customer is able to view the books, add books to the cart, order

docker run command. The containers are created once the docker them, and view the order history and the status of the order. The

We have created one more node with the configuration of 4vCPU, 8GB of RAM, and 50GB SSD with Ubuntu 20.0 LTS amd focal image built on 2023-03-0 as an operating system. This machine is used as the Network File System - NFS server for centralized storage. In a Kubernetes environment, an NFS server can be used as a persistent storage solution that allows containers to access and manipulate data stored on a networked file system.

The Kubernetes cluster is configured to automatically provision

and manage persistent volumes (PVs) that are backed by the NFS server, which can be used by applications running in pods. When a pod requests access to the storage, it would create a Persis- tentVolumeClaim (PVC) that specifies the storage requirements, which Kubernetes would use to dynamically provision a PV that is backed by the NFS server. Once the PV is provisioned, it can be mounted as a volume in the pod’s container, allowing the Fig. 7: Architecture of Bookstore application on Kubernetes application to read and write data to the shared storage. This

provides a scalable and reliable way to store data that can be accessed from multiple pods or nodes in a Kubernetes cluster. administrator can also easily add new books to the application, including important details such as author information, price, C. Deployment, scaling and load balancing of microservices on and quantity available. To achieve its functionality, the bookstore K8s application is comprised of four key microservices, which are the We have created the manifest files required for the deployment

User Service, Orders Service, front-end Bookstore UI, and the of the bookstore application in this milestone. In Kubernetes, Books Service. All of these microservices work together seam- deployment and service files are two types of manifest files used lessly to ensure optimal performance of the application. The data to define and manage applications running in a cluster. For each is stored in a centralized database, specifically MySQL, which one of the microservices, a deployment file is created as a de-

has been carefully chosen for its reliability and performance. The ployment object in Kubernetes which in turn runs the application Bookstore UI is developed using HTML, CSS, and JavaScript, container inside a pod. The deployment file typically includes providing a user-friendly and intuitive interface for customers specifications for the container image, the number of replicas to and administrators. Depending on the user’s role, the User Service create, and any necessary environment variables, volumes, and

ensures that the appropriate functionality is available to them. This networking configuration. When the deployment file is applied to service has been developed using Java programming language. the cluster, Kubernetes will create the specified number of replicas The Orders Service is responsible for managing the user’s cart and manage their life cycle, ensuring that the desired number of details, order history, and the delivery status of each order which replicas is always running and up-to-date. This is responsible for

has been developed using Python programming language and scaling each microservice and auto-healing the pods. Service files has been seamlessly integrated with the other microservices. for all the microservices are created as they are used to define The Books Service, developed in Java programming language, is a Kubernetes Service object, which provides a stable IP address responsible for managing information about the books available and DNS name for accessing a set of pods running in the cluster.

in the application. The application has been developed with great The service file typically includes specifications for the type of attention to detail, ensuring that every aspect of the process, from service, the selector used to target the pods, and any necessary browsing books to order fulfillment, is seamless and intuitively networking configuration. When the service file is applied to the developed as polyglot microservices. Once the application was cluster, Kubernetes will create the Service object and ensure that

developed, we converted it into Docker images using Dockerfile it is available for other objects in the cluster to use for accessing and then pushed those images to Docker Hub. Next, we set up a the pods. By default, the Round robin scheduling algorithm is single node Docker machine and pulled all the Docker images used for diverting the traffic to the pods. The MySQL database from Docker Hub onto this machine. Finally, we ran all the is configured as the persistent volume as the data stored in the

containers on this single node Docker machine, allowing us to MySQL database is persisted across pod restarts or node failures, test our application using Docker. ensuring that the data is always available. It also makes sure to use a centralized storage solution, such as an NFS server or cloud- B. Setting up Kubernetes on cloud based storage service, for storing the data. This can help ensure

For the deployment of the bookstore application in a large that the data is stored securely and centrally, and can be easily scale, the Kubernetes setup is done on the Google Cloud Platform accessed by other pods or services in the Kubernetes cluster. We (GCP). A Virtual Private Cloud (VPC) network is auto-configured ensured that all four microservices of the book application were in the Google Cloud Platform for the intercommunication of the running as pods in the Kubernetes cluster and that they were able

applications and network discovery. As part of the project, a to communicate with each other and the database pods. Next, we Kubernetes cluster of three nodes is created with the configuration exposed the application to the internet by creating a service. This of 4vCPU and 8GB of RAM. We are implementing the cluster has allowed users to access the application using any IP of the node one master and two slave nodes. The operating system deployed in the cluster.After completing these steps, the book application

on the machines is Ubuntu 20.0 LTS amd focal image built was successfully up and running, and users could access it over on 2023-03-02. We are using containerd as the container runtime. the internet using any of the IP of the node in the cluster.

D. Performance comparison of application on VM and containers

Performance evaluation for containers versus VMs is an im-

portant step in determining the most appropriate virtualization technology for a given application or workload.In this evaluation, the key metrics considered are

1. Boot Time

2. Server Footprint

3. Performance metrics

For the evaluation of performance of containerized services and

services running on VM , both the systems are tested in the same environment and allocated equal resources of 2 core CPU with 2GB RAM to achieve the best possible results.

Fig. 9: VM vs Container - Server foot Print Comparison

1) Boot Time: Boot Time refers to the amount of time it takes for a server or system to start up and become fully operational. It’s an important parameter to consider, especially in situations that the system is meeting the needs of its users and is performing where high availability and recover time are critical, as longer optimally. Factors that can impact performance metrics include boot times can result in longer down times and potentially impact the hardware configuration, software stack, network connectivity,

user experience. Factors that can impact boot time include the and workload characteristics. We have tested performance metrics hardware configuration, software stack, and network connectivity. for both VM and containers. We observed the performance In our scenario, applications are created as services inside VM metrics under two states. One is idle state, when servers are and container, which means the application will be started after not handling any traffic. Another state is load state, where we

the system boots. Here we considering the boot times of both simulate the load on the application. In this two different states,

VM and a container. we observed the performance metrics for both the containers and

a. Boot time of application running on a VM : To calculate the VMs. boot time of the server and application to come up, the timestamp In load state, i.e to simulate the load on the application, we used difference between the VM powered-on and the application JMeter tool where we simulate a load of 10 requests in 1 second serving timestamp is calculated. ramp up period with 1 iterations. So totally 100 requests will

b. Boot time of application running on a container : To calculate be imposed on the application. The observation of the VMs and the boot time of the application running on a container,the containers during idle state and load state is carried out using timestamp difference between the time at which existing pod is Prometheus monitoring tool. To visualize these metrics, Grafana killed and the next pod serving is calculated. is used on top of prometheus to create dashboards for observing

the performance. Each vm and container were allocated with the limits of 2 core CPU and 2 GB memory. In the following, we compare the performance metrics for our polyglot microservices in different states (idle and load) in both VM and containers. a) Orders - Python Service: The orders microservice was written in python for the management of orders in our application.

Fig. 8: VM vs Container - Boot Time Comparison

Fig. 8: VM vs Container - Boot Time Comparison shows the

comparison of boot time on VM and container and it is clearly evident that the boot time has been greatly improved using the containerized services. 2) Server Footprint: Server footprint refers the amount of Fig. 10: Orders Python Service - Idle state Comparison physical space a server takes up. A smaller server footprint can be desirable in situations where space is limited. Fig: 1 Orders Python Service - Idle state Comparison shows Fig: 9 VM vs Container - Server foot Print Comparison depicts the comparison of the CPU utilization and memory consumption

the tremendous decrease in the server footprint with the containers by the application on VM and container in the idle state. When in compared to that of VM’s. the idle state the CPU usage by the VM fluctuated between 1.4% 3) Performance Metrics: Performance Metrics refers to vari- and 2.1%. Whereas in the container, it fluctuated between 0.004% ous metrics that are used to measure the performance of a server and around 0.006%. The Memory usage by the order service in

or system, such as cpu utilization, memory usage and response VM started around 41.36% and increased to around 41.3725% time. These metrics are important to consider in order to ensure and stayed constant. Whereas in the container, it started around

Fig. 11: Orders Python Service - Load state Comparison Fig. 13: UI JavaScript Service - Idle state Comparison

Fig. 12: Orders Python Service - Response Time Comparison

8.5% and increased up to 11% and stayed constant for a while. Fig: 1 Orders Python Service - Load state Comparison shows Fig. 14: UI JavaScript Service - Load state Comparison the comparison of the CPU utilization and memory consumption by the application on VM and container in the load state. When the load was applied on the orders service running on the VM, we can see a significant spike in the CPU usage that ranged around 60% for a while, whereas in the container we can also see a

significant spike ranging around 20%. The Memory usage by the order service in VM started around 41.4% and increased to around 41.6%, whereas in the container, it started around 14% and increased up to 18% and stayed there for a while. By the above comparisons of CPU usage and memory usage by the Fig. 15: UI JavaScript Service - Response Time Comparison orders service running in VM and container, both in idle and load state, we can clearly state that the orders service consumes less

resources in container. Fig: 1 Orders Python Service - Response VM and container in the load state. When in the load state the Time Comparisons hows the comparison of the response times of CPU usage by the VM fluctuated at around 25%, whereas in the the orders service when running on VM and a container. While container, it fluctuated at around 5%. The Memory usage by the running the application in both VM and container, 100 requests UI service in VM started around 22.53% and increased to around

were sent to check the response times the average time was 22.67% during the load, whereas in the container, it is around about 780ms on VM, whereas while running on the container 1.8% during the load. By the above two comparisons, we can the average response time was 625ms. By the above comparison, say that the UI JS service consumes less resources in container we can clearly see that the service performs well in a container. than VM, both in idle and load states. Fig: 1 UI JS Service -

b) UI - JavaScript Service: The UI is handled by a Response Time Comparison shows the comparison of the response microservice was written in HTML and JavaScript to carryout the times of the UI JS Service when running on VM and Container. user interaction with application. Fig: 1 UI JS Service - Idle While running the application in both VM and containers, 100 state Comparison shows the comparison of the CPU utilization requests were sent to check the response times and the average

and memory consumption by the application on VM and container time was about 376ms when running in the VM, whereas while in the idle state. When in the idle state the CPU usage by the VM running in the container the average response time was 140ms. By fluctuated between 2% and around 4%, whereas in the container, the above comparison, we can clearly see that the UI JS Service it fluctuated between 0.001% and around 0.002%. The Memory performs better when running on a container.

usage by the UI service in VM started around 18% and increased c) Books - Java Service: The Books Micro service was to around 20.5% and stayed constant. Whereas in the container, written in Java for the purpose of management of books in the it started around 1% and stayed constant there. Fig: 1 UI JS application. Fig: 1 Books Java Service - Idle state Compari- Service - Load state Comparison shows the comparison of the son shows the comparison of the CPU utilization and memory

CPU utilization and memory consumption by the application on consumption by the application on VM and container in the idle

was 417ms. By the above comparison, we can’t actually say that the Java service runs efficiently when ran in a container. Because the response time is more in case of containers.

VII. C ONCLUSION

With this evaluation , services running on containers offer

several advantages, including faster boot time, lower disk usage, and lower CPU and memory usage. They provide a lightweight and efficient solution for software development and deployment, particularly in resource-constrained environments. However, Vir- tual machines take precedence in the situations where the response time is crucial and strict isolation is expected. Container runs as Fig. 16: Books Java Service - Idle state Comparison a process on the host machine and provides only isolation at the

application level. If security is the major concern, VM offers great level of isolation when compared to containers.

R EFERENCES

Pwint Phyu Khine and Zhaoshun Wang. A review of polyglot persistence

in the big data world. Information, 10(4):141, 2019.

Leila Abdollahi Vayghan, Mohamed Aymen Saied, Maria Toeroe, and Ferhat

Khendek. Microservice based architecture: Towards high-availability for

stateful applications with kubernetes. In 20 IEEE 19th international conference on software quality, reliability and security (QRS), pages 176–

185. IEEE, 2019.

Vivek Sharma, Harsh Kumar Saxena, and Akhilesh Kumar Singh. Docker

for multi-containers web application. In 20 2nd International Conference on Innovative Mechanisms for Industry Applications (ICIMIA), pages 589–

592. IEEE, 2020.

Guogen Zhang, Kun Ren, Jung-Sang Ahn, and Sami Ben-Romdhane.

Grit: consistent distributed transactions across polyglot microservices with

Fig. 17: Books Java Service - Load state Comparison multiple databases. In 20 IEEE 35th International Conference on Data Engineering (ICDE), pages 2024–2027. IEEE, 2019.

Vı́ctor Medel, Omer Rana, José Ángel Bañares, and Unai Arronategui. Mod-

elling performance & resource management in kubernetes. In Proceedings of the 9th International Conference on Utility and Cloud Computing, pages 257–262, 2016.

Marcelo Amaral, Jorda Polo, David Carrera, Iqbal Mohomed, Merve Un-

uvar, and Malgorzata Steinder. Performance evaluation of microservices architectures using containers. In 20 ieee 14th international symposium on network computing and applications, pages 27–34. IEEE, 2015.

Daniel Escobar, Diana Cárdenas, Rolando Amarillo, Eddie Castro, Kelly

Garcés, Carlos Parra, and Rubby Casallas. Towards the understanding and

evolution of monolithic applications as microservices. In 20 XLII Latin Fig. 18: Books Java Service - Response Time Comparison American Computing Conference (CLEI), pages 1–11, 2016. Massimiliano Rak, Salvatore Venticinque, Gorka Echevarria, Gorka Esnal, et al. Cloud application monitoring: The mosaic approach. In 20

IEEE Third International Conference on Cloud Computing Technology and

state. CPU Usage: When in idle state the CPU usage by the VM Science, pages 758–763. IEEE, 2011.

Debobroto Das Robin and Javed I. Khan. Clb: Coarse-grained precision

fluctuated between 2.2% and 2.8%,whereas in the container, it traffic-aware weighted cost multipath load balancing on pisa. IEEE Trans- fluctuated between 0.03% and around 0.07%. The memory usage actions on Network and Service Management, 19(2):784–803, 2022. by the order service in VM is around 33% in the VM whereas Uwe Zdun, Pierre-Jean Quèval, Georg Simhandl, Riccardo Scandariato,

Somik Chakravarty, Marjan Jelic, and Aleksandar Jovanovic. Microservice

in the container, it started around 12.77%.Fig: 1 Books Java security metrics for secure communication, identity management, and ob- Service - Load state Comparison shows the comparison of the servability. ACM Transactions on Software Engineering and Methodology, CPU utilization and memory consumption by the application on 32(1):1–34, 2023.

Debobroto Das Robin and Javed I. Khan. P4kp: Qos-aware top-k best path

VM and container in the load state. When in load state the CPU using programmable switch. IEEE Access, 9:109115–109129, 2021. usage of the VM is around 50%, we can see a spike that ranges Debobroto Das Robin and Javed I Khan. P4te: Pisa switch based traffic en- between 0 and around 50%. Whereas in the container, it is around gineering in fat-tree data center networks. Computer Networks, 215:109210, 2022. 17.5%. The memory usage by the UI service in VM started Vittorio Cortellessa, Daniele Di Pompeo, Romina Eramo, and Michele

is around 32% and increased to around 40% during the load, Tucci. A model-driven approach for continuous performance engineering in whereas in the container, it started around 13% and increased to microservice-based systems. Journal of Systems and Software, 183:111084, 2022. 17% during the load. By the above two comparisons, we can say Tamanna Siddiqui, Shadab Alam Siddiqui, and Najeeb Ahmad Khan. that the Java service runs better in container than VM, both in Comprehensive analysis of container technology. In 20 4th International

idle and load states.Fig: 1 Books Java Service - Response Time Conference on Infor

Continued Discussion and Extended Analysis (Part 2)

Containerization of a polyglot microservice application

Vamsi Krishna Yepuri, Venkata Kalyan Polamarasetty, Shivani Donthi, Ajay Kumar Reddy Gondi

Department of Computer Science, Kent State University

Abstract—This project investigates the benefits of containerization be packaged as a container image, which abstracts it from the

technology in modern software development and deployment. The underlying infrastructure and makes it simpler to deploy and run study emphasizes the advantages of using Kubernetes and Docker in the services across various environments without compatibility the development process, including the easy packaging and deploy- ment of microservices, efficient resource utilization, faster startup issues. For example, consider an e-commerce application based

times, and greater scalability and flexibility. The project concludes on microservices, with various services such as product catalogs, by proposing a study that involves creating a polyglot microservice shopping carts, payment processing, and order management. Each application using Java, Python, and JavaScript, containerizing it with of these services can be containerized, making it easy to deploy Docker, and deploying it in Kubernetes. The study aims to evaluate and update them independently. This enables developers to add

service discovery and auto-scaling in distributed mode and compare the performance metrics with virtual machines and containers. The new features or modify existing ones without impacting other

results of this study can inform software development teams about services.

the benefits of containerization in modern software development and Additionally, containers provide a high degree of isolation deployment. between microservices, minimizing conflicts and dependencies Index Terms—Docker, Kubernetes, Containers, Microservices, between them. By packaging each service as a container, they

Polyglot can each run their own instance of the required database, without

impacting the other services in the system. As a result, con-

I. I NTRODUCTION tainers provide greater agility, scalability, and consistency in a

Containerization has transformed software development and microservices project, allowing developers to focus on developing

deployment with Docker being one of the most widely adopted and updating microservices rather than the infrastructure and open-source platforms for building, shipping, and running dis- deployment processes. tributed applications. However, as containerized applications be- The use of virtual machines (VMs) can present challenges come more complex, managing them at scale can be a chal- when it comes to running applications, as VMs require their

lenge. Kubernetes, an open-source container orchestration system, own operating system and consume significant amounts of CPU, provides a platform for managing and deploying containerized memory, and storage resources, which can result in slower appli- applications at scale. Its popularity is attributed to its ability to cation performance and increased complexity. This can be solved automate deployment, scaling, and management of containerized through the use of container technology, which allows multiple

applications, with features like automatic load balancing, scaling, containers to share the same operating system kernel, leading to and self-healing. Trends in Kubernetes technology include the better resource utilization and faster startup times for applications, adoption of serverless computing, which enables developers to and ultimately greater scalability, flexibility, and cost efficiency. run their code in lightweight containers without managing in- For instance, consider a data analytics application that needs

frastructure or container orchestration. Kubernetes also finds use to process a large amount of data quickly and efficiently. If in hybrid and edge computing, where computing resources are the application runs on a virtual machine, it may suffer from distributed across multiple devices and locations, demonstrating slower performance due to the overhead and complexity of its versatility and adaptability to modern software development running a full operating system. By using container technology,

and deployment needs. however, developers can run multiple lightweight containers on Public cloud providers have played a significant role in the the same host operating system, resulting in faster performance, adoption and advancement of container technology. They offer lower resource usage, and greater scalability for the application, container services that allow developers to deploy, manage, and allowing for faster data processing and analysis.

scale containerized applications, which have reduced the barrier of Achieving container capabilities with virtual machines is chal- entry to container adoption, making them available to businesses lenging due to the fundamental differences between the two of all sizes. These providers have also been instrumental in technologies. Containers are lightweight and efficient, sharing the promoting container standards and enabling interoperability, con- same operating system kernel as the host machine, while virtual

tributing to the adoption of Kubernetes as the de facto standard for machines emulate an entire hardware environment, including a container orchestration. Standardization of container orchestra- separate operating system, which can lead to higher resource tion simplifies the deployment and management of containerized usage and greater complexity. Additionally, virtual machines lack applications across different cloud providers and on-premises portability and flexibility as each one requires a specific configura-

environments. tion of hardware and operating system, making it difficult to move Containers provide a variety of benefits in microservices ar- or replicate them across different environments. Containers, on chitecture, with one of the most significant being the ease of the other hand, can be easily packaged and deployed on any host packaging and deploying microservices. Each microservice can system that supports the same container runtime. Although virtual

machines have their own strengths and use cases, containers addressed the challenges in distributed transactions in a polyglot are preferred for most modern applications due to their greater environment. proposes a performance model to analyze efficiency, flexibility, and portability, and because they can start resource management in Kubernetes clusters. The model uses up much more quickly, making them better suited for modern queuing theory and stochastic processes to represent the resource

application deployment and scaling. utilization of nodes and pods. The proposed model is validated The traditional monolithic application approach involves build- through experiments that compare its accuracy against the real ing a single, comprehensive app, which can be time-consuming system performance. The paper highlights the importance of to develop and maintain, making it challenging to achieve agility. having an accurate performance model to optimize resource allo-

To address these issues and achieve greater flexibility and ease of cation and improve the overall efficiency of Kubernetes clusters. maintenance, the world is moving towards microservices. In the Also in the evaluation of the performance of microservices era of microservices, numerous independent modules are set up in architectures using containers, specifically Docker. The authors traditional virtual machines, which can lead to conflicting libraries conduct experiments to compare the performance of a monolithic

and make the process of provisioning, scaling, service discovery, application with a microservices-based application, both deployed load balancing, and deployment manual and time-consuming. To on Docker. The experiments involve measuring the response time solve these problems, microservices can be packed in containers and throughput of the applications under various workloads. The instead of virtual machines, which will help to address conflicts results of the experiments demonstrate that the microservices

and create independence between each microservice. Workloads architecture outperforms the monolithic architecture in terms of can be run in a scalable and distributed manner using Kubernetes, response time and scalability. Overall, the use of microservices, which can solve auto-scaling and service discovery issues. This Docker, Kubernetes, and polyglots in software development has project involves building a polyglot microservice application become increasingly popular in recent years due to their benefits

from the ground up using Java, Python, and JavaScript, container- in terms of portability, scalability, and flexibility. However, there izing it with Docker, and deploying it in Kubernetes to examine are also challenges involved in using these technologies, such service discovery and auto-scaling in distributed mode, while as managing stateful microservices in Kubernetes and achieving comparing the performance differences between the containerized consistent distributed transactions across polyglot microservices.

technique and the traditional virtual machine strategy. To address these challenges, researchers have proposed various In this project, we aim to compare the performance of virtual solutions and approaches, such as using a State Controller to im- machines and containers using several metrics. Firstly, we will prove the availability of stateful microservices in Kubernetes and examine the resource utilization of the microservice application developing a performance model to optimize resource allocation

between the two technologies, analyzing the CPU, memory, and in Kubernetes clusters. In addition, studies have been conducted storage usage to determine which technology is more efficient. to evaluate the performance of microservices architectures using Secondly, we will compare the startup time and scaling capabil- containers like Docker, and the results have shown that mi- ities of virtual machines and containers to see which is faster croservices architectures can outperform monolithic architectures

and more scalable. Thirdly, we will examine the storage space in terms of response time and scalability. Overall, the adoption utilized by both virtual machines and containers to see which of microservices, Docker, Kubernetes, and polyglots in software technology uses storage more effectively. Finally, we will evaluate development is likely to continue to grow as more organizations the portability of both virtual machines and containers and their seek to achieve the benefits these technologies provide while also

ability to be moved across different environments. By comparing addressing the challenges involved in their use. these performance metrics, we aim to determine which technology From TABLE I: Related Work, we can see the different features is more suitable for our microservice application and gain insights implemented by the referenced papers and the features that are into the strengths and weaknesses of each technology. implemented in this project. Our proposed solution will be dealing

with a stateless polyglot micro service, containerized used docker,

II. R ELATED W ORK and Kubernetes. We deploy our application and analyze the

Microservices, Docker, Kubernetes, and polyglots are some of improved performance using Kubernetes. the major collectively used technologies in the field of software

Reference Microservices Stateless Container Kubernetes Polyglot

development. There are many works that can be found on these X X topics which demonstrate the purpose of a shift towards the X X X docker and Kubernetes along with the challenges involved in X X X X the approaches. The importance of adopting a microservice-based X

architecture to achieve high availability for stateful applications X X in Kubernetes is explained in . The challenges of managing Our Project stateful microservices in Kubernetes and also proposed a solu- TABLE I: Related Work tion to improve their availability using a State Controller but did not mention the performance of Stateless polyglot micro service. In , presented a case study of a web application

that consists of several microservices, each running in a separate III. P ROJECT BACKGROUND container, and highlighted the improved portability, scalability, The trend towards microservices architecture has become more and flexibility. There are some situations that demand the use of and more popular in recent years, as it allows organizations to polyglots in order to achieve the desired solutions. discussed develop, deploy, and manage large, complex applications in a

the approaches for achieving consistent distributed transactions more agile and efficient manner. However, one of the challenges across polyglot microservices that use multiple databases and of implementing a microservices architecture is managing the

Fig. 1: Monolithic vs Microservices

Fig. 2: Polyglot Microservices

deployment and scaling of individual services in a way that is both effective and efficient. This is where containerization and tools, these can be overcome with the right approach and tools. container orchestration tools like Docker and Kubernetes come As a result, many organizations are adopting this approach to into play. In this project, we are going to show the analysis of build more resilient and adaptable software systems. performance improvement with the use of container orchestration A polyglot microservices architecture can provide significant

tools. advantages for monitoring , load balancing , security and QoS by allowing you to choose the best technology

A. Microservice vs Monolithic architecture for each microservice, improve resilience, make monitoring and

Monolithic and microservice architectures are two different troubleshooting easier, distribute the workload, and optimize

approaches to designing and building software systems. A mono- each microservice for specific tasks or functions. A polyglot lithic architecture is a traditional approach where an application microservices architecture can also take advantage of traffic is built as a single unit, while a microservice architecture is engineering! capabilities in data center networks to opti- an approach where an application is broken down into smaller mize the performance of microservices and improve over-

independent services. Fig. 1: Monolithic vs Microservices shows all application performance. By leveraging intelligent routing, the difference between monolithic and microservice-based ar- traffic shaping, load balancing, network performance monitoring, chitecture. The monolithic approach is easier to develop and and scalability, a polyglot microservices architecture can ensure deploy but can become difficult to maintain and scale as the that traffic is routed to the most optimal endpoint, manage the

application grows. On the other hand, the microservice approach flow of traffic between microservices, distribute traffic evenly offers greater flexibility, scalability, and resilience but requires across multiple endpoints, monitor network performance, and coordination between different teams. The choice of architecture accommodate changes in traffic volume and application usage. depends on the specific needs and requirements of the application, All of these capabilities can help to reduce latency, prevent

with monolithic being better suited for smaller applications and congestion, allocate resources efficiently, identify and resolve microservices for larger, complex applications. issues quickly, and ultimately, improve application performance explains the process of transforming monolithic applications and user experience. into microservices and provides a framework for understanding the migration process. It discusses the benefits and challenges of C. Container

adopting a microservices architecture.

A container is a lightweight, standalone, and executable pack-

age of software that includes everything needed to run an ap-

B. Polyglot microservices plication, such as code, libraries, and system tools. Containers

Polyglot microservices refer to a software architecture that provide a consistent run time environment, ensuring that the involves using multiple programming languages and technologies application can run reliably regardless of the underlying system’s to build independent, small-sized services that work together to configuration. Fig. 3: Virtual Machine vs Container shows the accomplish a larger goal. Fig.2 : Polyglot microservices repre- difference between a virtual machine and a container.

sents polyglot microservices. This approach allows developers to is a comprehensive report on the use of container technology choose the best language and tools for each service, rather than in modern software development. It covers various aspects of being limited to a single technology stack. Polyglot microservices container technology, including its history, benefits, challenges, are becoming increasingly popular because they offer several ben- and future trends. The goal of containerization is to package each

efits, such as increased flexibility, improved scalability, and better service and its dependencies into a lightweight, portable container fault tolerance. They can be designed to communicate with each that can run on any machine or cloud environment. other through APIs, message queues, or other protocols, which Docker is widely used as a containerization platform because it enables them to work together as a cohesive system. While there offers a reliable and reproducible setting for running applications.

are challenges to building and managing polyglot microservices, Docker makes it simple to create, deploy, and manage images, such as the need to manage multiple programming languages and which makes it easier to develop and test applications across

enable organizations to easily package and deploy services written in different languages or frameworks while ensuring that each service runs in a consistent and isolated environment. This makes it easier to manage dependencies, test and deploy services, and scale applications as needed.

Overall, the containerization of a polyglot microservices ap-

plication using Docker and Kubernetes can help organizations achieve greater agility, scalability, and reliability in their software development and deployment processes. It can also help reduce the complexity of managing and scaling multiple services, which can be particularly challenging in a polyglot environment.

Fig. 3: Virtual Machine vs Container IV. I NFRASTRUCTURE

The infrastructure required for containerization using Docker

and Kubernetes typically includes : a. physical or virtual machines, b. storage systems, and c. networking components.

Physical or virtual machines are needed to host containerized

applications. These machines should have sufficient CPU, mem- ory, and storage to run the application and the containers. Storage systems are necessary to store the container images, as well as any data or files that the application needs to access. The storage should be accessible to all the machines in the infrastructure. Net- working components such as load balancers and firewalls are Fig. 4: Docker vs Kubernetes also required to ensure that traffic can be routed to the appropriate

containers and that the network is secure. We also need a cloud engine, for that we are using GCP. Google Cloud Platform (GCP) different environments. A Docker container is a self-contained is a cloud provider that offers a range of services for hosting and software package that operates independently of other containers managing applications, data, and infrastructure in the cloud. GCP and the host system. It has its own network, file system, and provides tools and services such as Google Kubernetes Engine

resources, making it perfect for deploying applications with (GKE), Google Container Registry (GCR), and Cloud Storage that specific requirements. Docker images serve as snapshots of are well-suited for containerization using Docker and Kubernetes. an application’s file system, and they can be created using a Additionally, GCP provides tools for monitoring and managing Dockerfile script. Images can be utilized to start one or more containerized applications, such as Stackdriver Monitoring and

containers. Docker containers have advantages such as portability, Logging, and Cloud Trace for application tracing. consistency, isolation, resource efficiency, and scalability, while There are examples provided in describe the steps to their disadvantages include complexity, a learning curve, security deploy a web application using Google Cloud Platform, which in- concerns, dependency management challenges, and limited access volves creating a new project, enabling necessary APIs, choosing

to hardware resources. a deployment method, creating an instance or app, configuring it, and deploying the application. Once deployed, the application can D. Kubernetes and Docker be managed and monitored through the Google Cloud Platform.

Also, the GCP services used were VPC networks (Virtual Pri-

Kubernetes is an open-source platform for container orchestra-

vate Cloud Networks) and Compute Engine. VPC networks allow tion, which automates the deployment, scaling, and management for the creation of private virtual networks within GCP, while of containerized applications.Fig. 4: Docker vs Kubernetes shows

Compute Engine provides virtual machines with configurable

the difference between docker and Kubernetes and how Kuber- amounts of CPU, memory, and storage for running Kubernetes netes is used in a distributed environment and orchestrating the and deploying applications and services. docker containers. It provides a framework for deploying, scaling, and managing multiple containers across a cluster of servers, allowing organizations to run and manage their microservices V. S YSTEM A RCHITECTURE at scale. explains how Docker and Kubernetes can be To carry out a test of Docker and Kubernetes with an applica-

used to automate the scaling of a defense application in a tion in our scenario, it is necessary to have a polyglot microservice cloud environment. It highlights the benefits of these tools, such application that is designed with various programming languages. as improved security and reliability, and provides a detailed The bookstore application comes into picture here. The bookstore deployment process. application has been designed to offer its customers a conve-

In the case of a polyglot microservices application, where nient way to browse and purchase books online as a polyglot multiple programming languages and frameworks are used to microservice. Four microservices are being used to fulfill the develop individual services, containerization, and container or- result of the application as seen in Fig.5 which are developed in chestration can be particularly valuable. Docker and Kubernetes multiple programming languages and using scripts. They are the

run with the image name saved in the Docker hub command is given. The main reason of moving from the single-node Docker system to Kubernetes is that it can provide several benefits such as scalability, high availability, resource efficiency, service discovery for more complex applications with higher demands from the user.

By distributing the workload across multiple nodes, Kubernetes

can handle much larger workloads than a single-node Docker system, making it an ideal choice for applications with rapidly increasing traffic. The automatic detection and recovery features of Kubernetes can help maintain application availability, reduce downtime, and minimize the need for manual intervention.

The bookstore application can be deployed on Kubernetes. For

the multiple nodes, we are using the Google Cloud platform -

GCP as shown in Fig.7. The system starts with the creation of

Fig. 5: Bookstore application Architecture a VPC network, which is a virtual private network for Google

Cloud resources. This network provides a private network space

for the deployment of Kubernetes clusters. A Kubernetes cluster is then deployed on the VPC network with 1 master node and 2 slave nodes. This cluster consists of one or more nodes, where each node is a virtual machines (VMs). Each virtual machine runs a Kubernetes node, which is responsible for running pods and managing the resources of the virtual machine. Utilizing compute engine in GCP, a kubernetes master node is deployed, which manages the Kubernetes API server, controller, scheduler, and the

etcd database. The API server is responsible for receiving and pro- cessing requests from its clients, while etcd stores configuration data and metadata for the Kubernetes cluster. The controller sends the commands to the slave nodes. For example, if the image is to be deployed in the slave node, the controller sends a command to the kubelet in the slave node to implement the process. The scheduler is used while the initial creation of the pods in the Fig. 6: Architecture of Bookstore application on single-node slave nodes to configure the placement of the pods in case of any

Docker system downtime. The container run time is used to run the container

when it is started. We will use Network File System (NFS) server to store the data stored in the databases as a central repository . user service, orders service, books service, and the bookstore UI Kubernetes clients can then interact with the API server to deploy service. The data is stored in the central repository of a database. and manage applications on the cluster. When an application is The microservices are all connected to one another to commu- deployed, Kubernetes schedules the necessary containers onto the

nicate between them using REST APIs. Let us suppose that available nodes based on resource requirements and availability the bookstore application is deployed on a single-node Docker and also manages their life cycle, scaling them up or down as system as shown in Fig.6. Docker containers are lightweight needed. To access the application, users connect to a load balancer and standalone virtual machines that can run on any computer. that is deployed on the Kubernetes as a service. The service

The Docker engine effectively manages these containers and distributes traffic across the containers running in the Kubernetes ensures that they have access to the necessary resources, such as cluster. memory and CPU, while keeping them isolated from each other.

By running multiple containers on the same machine, each with VI. I MPLEMENTATION

its own set of dependencies and configurations, applications can This project is implemented as the following four steps. To im- be easily deployed and managed without having to worry about plement the containerization of polyglot microservice application conflicts between different software components. All the services , firstly we need to develop the microservices required for the with the source code and Dockerfile are built using the Docker application and then deploy the images of the microservices to

container platform. Once the build is completed, the data is the cloud system where kubernetes is configured. After deploying pushed to the central repository of the Docker hub. This eliminates the microservices, we will compare the performance of the the need to download and configure software dependencies for application on a virtual machine and a container. each microservice individually, making deployment more efficient and less time-consuming. With the required software already pre-

packaged into the images, it’s simply a matter of pulling the A. Development of polyglot microservices and containerizing necessary images and running them in the Docker container. then with Docker To run the bookstore application, all the microservices required A bookstore application is developed to order books online. The images that are saved on Docker Hub are set to run by using the customer is able to view the books, add books to the cart, order

docker run command. The containers are created once the docker them, and view the order history and the status of the order. The

We have created one more node with the configuration of 4vCPU, 8GB of RAM, and 50GB SSD with Ubuntu 20.0 LTS amd focal image built on 2023-03-0 as an operating system. This machine is used as the Network File System - NFS server for centralized storage. In a Kubernetes environment, an NFS server can be used as a persistent storage solution that allows containers to access and manipulate data stored on a networked file system.

The Kubernetes cluster is configured to automatically provision

and manage persistent volumes (PVs) that are backed by the NFS server, which can be used by applications running in pods. When a pod requests access to the storage, it would create a Persis- tentVolumeClaim (PVC) that specifies the storage requirements, which Kubernetes would use to dynamically provision a PV that is backed by the NFS server. Once the PV is provisioned, it can be mounted as a volume in the pod’s container, allowing the Fig. 7: Architecture of Bookstore application on Kubernetes application to read and write data to the shared storage. This

provides a scalable and reliable way to store data that can be accessed from multiple pods or nodes in a Kubernetes cluster. administrator can also easily add new books to the application, including important details such as author information, price, C. Deployment, scaling and load balancing of microservices on and quantity available. To achieve its functionality, the bookstore K8s application is comprised of four key microservices, which are the We have created the manifest files required for the deployment

User Service, Orders Service, front-end Bookstore UI, and the of the bookstore application in this milestone. In Kubernetes, Books Service. All of these microservices work together seam- deployment and service files are two types of manifest files used lessly to ensure optimal performance of the application. The data to define and manage applications running in a cluster. For each is stored in a centralized database, specifically MySQL, which one of the microservices, a deployment file is created as a de-

has been carefully chosen for its reliability and performance. The ployment object in Kubernetes which in turn runs the application Bookstore UI is developed using HTML, CSS, and JavaScript, container inside a pod. The deployment file typically includes providing a user-friendly and intuitive interface for customers specifications for the container image, the number of replicas to and administrators. Depending on the user’s role, the User Service create, and any necessary environment variables, volumes, and

ensures that the appropriate functionality is available to them. This networking configuration. When the deployment file is applied to service has been developed using Java programming language. the cluster, Kubernetes will create the specified number of replicas The Orders Service is responsible for managing the user’s cart and manage their life cycle, ensuring that the desired number of details, order history, and the delivery status of each order which replicas is always running and up-to-date. This is responsible for

has been developed using Python programming language and scaling each microservice and auto-healing the pods. Service files has been seamlessly integrated with the other microservices. for all the microservices are created as they are used to define The Books Service, developed in Java programming language, is a Kubernetes Service object, which provides a stable IP address responsible for managing information about the books available and DNS name for accessing a set of pods running in the cluster.

in the application. The application has been developed with great The service file typically includes specifications for the type of attention to detail, ensuring that every aspect of the process, from service, the selector used to target the pods, and any necessary browsing books to order fulfillment, is seamless and intuitively networking configuration. When the service file is applied to the developed as polyglot microservices. Once the application was cluster, Kubernetes will create the Service object and ensure that

developed, we converted it into Docker images using Dockerfile it is available for other objects in the cluster to use for accessing and then pushed those images to Docker Hub. Next, we set up a the pods. By default, the Round robin scheduling algorithm is single node Docker machine and pulled all the Docker images used for diverting the traffic to the pods. The MySQL database from Docker Hub onto this machine. Finally, we ran all the is configured as the persistent volume as the data stored in the

containers on this single node Docker machine, allowing us to MySQL database is persisted across pod restarts or node failures, test our application using Docker. ensuring that the data is always available. It also makes sure to use a centralized storage solution, such as an NFS server or cloud- B. Setting up Kubernetes on cloud based storage service, for storing the data. This can help ensure

For the deployment of the bookstore application in a large that the data is stored securely and centrally, and can be easily scale, the Kubernetes setup is done on the Google Cloud Platform accessed by other pods or services in the Kubernetes cluster. We (GCP). A Virtual Private Cloud (VPC) network is auto-configured ensured that all four microservices of the book application were in the Google Cloud Platform for the intercommunication of the running as pods in the Kubernetes cluster and that they were able

applications and network discovery. As part of the project, a to communicate with each other and the database pods. Next, we Kubernetes cluster of three nodes is created with the configuration exposed the application to the internet by creating a service. This of 4vCPU and 8GB of RAM. We are implementing the cluster has allowed users to access the application using any IP of the node one master and two slave nodes. The operating system deployed in the cluster.After completing these steps, the book application

on the machines is Ubuntu 20.0 LTS amd focal image built was successfully up and running, and users could access it over on 2023-03-02. We are using containerd as the container runtime. the internet using any of the IP of the node in the cluster.

D. Performance comparison of application on VM and containers

Performance evaluation for containers versus VMs is an im-

portant step in determining the most appropriate virtualization technology for a given application or workload.In this evaluation, the key metrics considered are

1. Boot Time

2. Server Footprint

3. Performance metrics

For the evaluation of performance of containerized services and

services running on VM , both the systems are tested in the same environment and allocated equal resources of 2 core CPU with 2GB RAM to achieve the best possible results.

Fig. 9: VM vs Container - Server foot Print Comparison

1) Boot Time: Boot Time refers to the amount of time it takes for a server or system to start up and become fully operational. It’s an important parameter to consider, especially in situations that the system is meeting the needs of its users and is performing where high availability and recover time are critical, as longer optimally. Factors that can impact performance metrics include boot times can result in longer down times and potentially impact the hardware configuration, software stack, network connectivity,

user experience. Factors that can impact boot time include the and workload characteristics. We have tested performance metrics hardware configuration, software stack, and network connectivity. for both VM and containers. We observed the performance In our scenario, applications are created as services inside VM metrics under two states. One is idle state, when servers are and container, which means the application will be started after not handling any traffic. Another state is load state, where we

the system boots. Here we considering the boot times of both simulate the load on the application. In this two different states,

VM and a container. we observed the performance metrics for both the containers and

a. Boot time of application running on a VM : To calculate the VMs. boot time of the server and application to come up, the timestamp In load state, i.e to simulate the load on the application, we used difference between the VM powered-on and the application JMeter tool where we simulate a load of 10 requests in 1 second serving timestamp is calculated. ramp up period with 1 iterations. So totally 100 requests will

b. Boot time of application running on a container : To calculate be imposed on the application. The observation of the VMs and the boot time of the application running on a container,the containers during idle state and load state is carried out using timestamp difference between the time at which existing pod is Prometheus monitoring tool. To visualize these metrics, Grafana killed and the next pod serving is calculated. is used on top of prometheus to create dashboards for observing

the performance. Each vm and container were allocated with the limits of 2 core CPU and 2 GB memory. In the following, we compare the performance metrics for our polyglot microservices in different states (idle and load) in both VM and containers. a) Orders - Python Service: The orders microservice was written in python for the management of orders in our application.

Fig. 8: VM vs Container - Boot Time Comparison

Fig. 8: VM vs Container - Boot Time Comparison shows the

comparison of boot time on VM and container and it is clearly evident that the boot time has been greatly improved using the containerized services. 2) Server Footprint: Server footprint refers the amount of Fig. 10: Orders Python Service - Idle state Comparison physical space a server takes up. A smaller server footprint can be desirable in situations where space is limited. Fig: 1 Orders Python Service - Idle state Comparison shows Fig: 9 VM vs Container - Server foot Print Comparison depicts the comparison of the CPU utilization and memory consumption

the tremendous decrease in the server footprint with the containers by the application on VM and container in the idle state. When in compared to that of VM’s. the idle state the CPU usage by the VM fluctuated between 1.4% 3) Performance Metrics: Performance Metrics refers to vari- and 2.1%. Whereas in the container, it fluctuated between 0.004% ous metrics that are used to measure the performance of a server and around 0.006%. The Memory usage by the order service in

or system, such as cpu utilization, memory usage and response VM started around 41.36% and increased to around 41.3725% time. These metrics are important to consider in order to ensure and stayed constant. Whereas in the container, it started around

Fig. 11: Orders Python Service - Load state Comparison Fig. 13: UI JavaScript Service - Idle state Comparison

Fig. 12: Orders Python Service - Response Time Comparison

8.5% and increased up to 11% and stayed constant for a while. Fig: 1 Orders Python Service - Load state Comparison shows Fig. 14: UI JavaScript Service - Load state Comparison the comparison of the CPU utilization and memory consumption by the application on VM and container in the load state. When the load was applied on the orders service running on the VM, we can see a significant spike in the CPU usage that ranged around 60% for a while, whereas in the container we can also see a

significant spike ranging around 20%. The Memory usage by the order service in VM started around 41.4% and increased to around 41.6%, whereas in the container, it started around 14% and increased up to 18% and stayed there for a while. By the above comparisons of CPU usage and memory usage by the Fig. 15: UI JavaScript Service - Response Time Comparison orders service running in VM and container, both in idle and load state, we can clearly state that the orders service consumes less

resources in container. Fig: 1 Orders Python Service - Response VM and container in the load state. When in the load state the Time Comparisons hows the comparison of the response times of CPU usage by the VM fluctuated at around 25%, whereas in the the orders service when running on VM and a container. While container, it fluctuated at around 5%. The Memory usage by the running the application in both VM and container, 100 requests UI service in VM started around 22.53% and increased to around

were sent to check the response times the average time was 22.67% during the load, whereas in the container, it is around about 780ms on VM, whereas while running on the container 1.8% during the load. By the above two comparisons, we can the average response time was 625ms. By the above comparison, say that the UI JS service consumes less resources in container we can clearly see that the service performs well in a container. than VM, both in idle and load states. Fig: 1 UI JS Service -

b) UI - JavaScript Service: The UI is handled by a Response Time Comparison shows the comparison of the response microservice was written in HTML and JavaScript to carryout the times of the UI JS Service when running on VM and Container. user interaction with application. Fig: 1 UI JS Service - Idle While running the application in both VM and containers, 100 state Comparison shows the comparison of the CPU utilization requests were sent to check the response times and the average

and memory consumption by the application on VM and container time was about 376ms when running in the VM, whereas while in the idle state. When in the idle state the CPU usage by the VM running in the container the average response time was 140ms. By fluctuated between 2% and around 4%, whereas in the container, the above comparison, we can clearly see that the UI JS Service it fluctuated between 0.001% and around 0.002%. The Memory performs better when running on a container.

usage by the UI service in VM started around 18% and increased c) Books - Java Service: The Books Micro service was to around 20.5% and stayed constant. Whereas in the container, written in Java for the purpose of management of books in the it started around 1% and stayed constant there. Fig: 1 UI JS application. Fig: 1 Books Java Service - Idle state Compari- Service - Load state Comparison shows the comparison of the son shows the comparison of the CPU utilization and memory

CPU utilization and memory consumption by the application on consumption by the application on VM and container in the idle

was 417ms. By the above comparison, we can’t actually say that the Java service runs efficiently when ran in a container. Because the response time is more in case of containers.

VII. C ONCLUSION

With this evaluation , services running on containers offer

several advantages, including faster boot time, lower disk usage, and lower CPU and memory usage. They provide a lightweight and efficient solution for software development and deployment, particularly in resource-constrained environments. However, Vir- tual machines take precedence in the situations where the response time is crucial and strict isolation is expected. Container runs as Fig. 16: Books Java Service - Idle state Comparison a process on the host machine and provides only isolation at the

application level. If security is the major concern, VM offers great level of isolation when compared to containers.

R EFERENCES

Pwint Phyu Khine and Zhaoshun Wang. A review of polyglot persistence

in the big data world. Information, 10(4):141, 2019.

Leila Abdollahi Vayghan, Mohamed Aymen Saied, Maria Toeroe, and Ferhat

Khendek. Microservice based architecture: Towards high-availability for

stateful applications with kubernetes. In 20 IEEE 19th international conference on software quality, reliability and security (QRS), pages 176–

185. IEEE, 2019.

Vivek Sharma, Harsh Kumar Saxena, and Akhilesh Kumar Singh. Docker

for multi-containers web application. In 20 2nd International Conference on Innovative Mechanisms for Industry Applications (ICIMIA), pages 589–

592. IEEE, 2020.

Guogen Zhang, Kun Ren, Jung-Sang Ahn, and Sami Ben-Romdhane.

Grit: consistent distributed transactions across polyglot microservices with

Fig. 17: Books Java Service - Load state Comparison multiple databases. In 20 IEEE 35th International Conference on Data Engineering (ICDE), pages 2024–2027. IEEE, 2019.

Vı́ctor Medel, Omer Rana, José Ángel Bañares, and Unai Arronategui. Mod-

elling performance & resource management in kubernetes. In Proceedings of the 9th International Conference on Utility and Cloud Computing, pages 257–262, 2016.

Marcelo Amaral, Jorda Polo, David Carrera, Iqbal Mohomed, Merve Un-

uvar, and Malgorzata Steinder. Performance evaluation of microservices architectures using containers. In 20 ieee 14th international symposium on network computing and applications, pages 27–34. IEEE, 2015.

Daniel Escobar, Diana Cárdenas, Rolando Amarillo, Eddie Castro, Kelly

Garcés, Carlos Parra, and Rubby Casallas. Towards the understanding and

evolution of monolithic applications as microservices. In 20 XLII Latin Fig. 18: Books Java Service - Response Time Comparison American Computing Conference (CLEI), pages 1–11, 2016. Massimiliano Rak, Salvatore Venticinque, Gorka Echevarria, Gorka Esnal, et al. Cloud application monitoring: The mosaic approach. In 20

IEEE Third International Conference on Cloud Computing Technology and

state. CPU Usage: When in idle state the CPU usage by the VM Science, pages 758–763. IEEE, 2011.

Debobroto Das Robin and Javed I. Khan. Clb: Coarse-grained precision

fluctuated between 2.2% and 2.8%,whereas in the container, it traffic-aware weighted cost multipath load balancing on pisa. IEEE Trans- fluctuated between 0.03% and around 0.07%. The memory usage actions on Network and Service Management, 19(2):784–803, 2022. by the order service in VM is around 33% in the VM whereas Uwe Zdun, Pierre-Jean Quèval, Georg Simhandl, Riccardo Scandariato,

Somik Chakravarty, Marjan Jelic, and Aleksandar Jovanovic. Microservice

in the container, it started around 12.77%.Fig: 1 Books Java security metrics for secure communication, identity management, and ob- Service - Load state Comparison shows the comparison of the servability. ACM Transactions on Software Engineering and Methodology, CPU utilization and memory consumption by the application on 32(1):1–34, 2023.

Debobroto Das Robin and Javed I. Khan. P4kp: Qos-aware top-k best path

VM and container in the load state. When in load state the CPU using programmable switch. IEEE Access, 9:109115–109129, 2021. usage of the VM is around 50%, we can see a spike that ranges Debobroto Das Robin and Javed I Khan. P4te: Pisa switch based traffic en- between 0 and around 50%. Whereas in the container, it is around gineering in fat-tree data center networks. Computer Networks, 215:109210, 2022. 17.5%. The memory usage by the UI service in VM started Vittorio Cortellessa, Daniele Di Pompeo, Romina Eramo, and Michele

is around 32% and increased to around 40% during the load, Tucci. A model-driven approach for continuous performance engineering in whereas in the container, it started around 13% and increased to microservice-based systems. Journal of Systems and Software, 183:111084, 2022. 17% during the load. By the above two comparisons, we can say Tamanna Siddiqui, Shadab Alam Siddiqui, and Najeeb Ahmad Khan. that the Java service runs better in container than VM, both in Comprehensive analysis of container technology. In 20 4th International

idle and load states.Fig: 1 Books Java Service - Response Time Conference on Infor

FAQ

Typical stacks include Git, a CI engine (Jenkins/GitHub Actions/GitLab CI), Docker, Kubernetes or a cloud PaaS, infrastructure-as-code (Terraform/Ansible), and monitoring (Prometheus/Grafana). Exact tools for Devops Rate Limiting Api Gateway depend on the chosen cloud and delivery model.
It can be delivered as a fully documented simulation on local/kind clusters or as a guided deployment on a cloud free tier. Both approaches are acceptable for academic evaluation when metrics, logs and diagrams are captured.
Pipeline screenshots, successful/failed run history, deployment frequency charts, rollback demos, monitoring dashboards, IaC plans/applies, and a short viva demo script are commonly included.