microservice migration patterns and how continuous
TRANSCRIPT
IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS
, STOCKHOLM SWEDEN 2021
Microservice Migration Patterns and how Continuous Integration and Continuous Delivery are affected
A Case study of Indicio’s journey towards microservice
KASPER LIU
KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
AuthorsKasper Liu <[email protected]>Information and Communication TechnologyKTH Royal Institute of Technology
Place for ProjectStockholm, SwedenIndicio Technology AB
ExaminerBenoit BaudryStockholm, SwedenKTH Royal Institute of Technology
Supervisor
Somayeh Aghanavesi
Stockholm, Sweden
KTH Royal Institute of Technology
ii
Abstract
Microservice is an architectural design that promises a more elastic system where
a microservice can be allocated compute power according to demand. Through
the separation of components, each microservice can have its own hardware or
cloud setup. As a result, the code becomes more maintainable through smaller
repositories.
Development and Operations (DevOps) is a set of best practices to improve software
development and operations. Two important components of DevOps are Continuous
Integration (CI) and Continuous Delivery (CD). CI is a set of practices that aims to
automate testing and increase development velocity through continuously integrate
code changes. While CD aims to streamline the deployment process of the code,
enabling a shorter time to market.
When migrating a monolithic codebase towards a microservice architecture, one faces
a lot of decisions that can have a deep impact on the whole organization. From a CI/CD
perspective, some decisions can impact the efficiency of the CI/CD pipeline.
This thesis investigated how Indicio’s CI/CD pipeline changed when going from a
monolith towards a microservice architecture. It documents the decisions Indicio
made along the way and investigates how the CI buildtime and CD deploy time were
affected.
The result showed that Indicio’s decision to keep the new microservice in the same
repository added 44% to the median buildtime. The time increase was acceptable
since it only resulted in an average of 20 seconds increase in median buildtime.
Although, the decision to separate the CD into two independent CD pipelines, one for
the old monolith and one for the new microservice didn’t affect the deploy time by
any considerate margin. The new microservice was deployed to Microsoft Azure to
be able to take advantage of the elastic compute power. The big advantage from a CD
iii
perspective by utilizing Azure was the bluegreen deploymentmethod resulting in zero
downtime.
Keywords
Microservice architecture, Monolithic Architecture, DevOps, Continuous Integration,
Continuous Delivery, Cloud, Migration
iv
Abstract
Mikrotjänster är en arkitektdesign som lovar ett mer flexibelt system där en
mikrotjänst kan tilldelas den nödvändiga datakraften. Genom att dela upp
komponenter kan varje mikrotjänst ha sin egen hårdvara eller molninställning. Det
resulterar i mindre stycken kod som är lättare att underhålla.
Development and Operations (DevOps) är en samling av bästa praxis för att
förbättra mjukvaruutveckling och operationer. Två viktiga komponenter av DevOps
är Continuous Integration (CI) och Continuous Delivery (CD). CI är en samling
av verktyg som försöker automatisera tester och öka utvecklingshastigheten genom
att kontinuerligt integrera kodändringar. Medan syftet med CD är att effektivisera
distribution av kod, vilket möjliggör en kortare tid till marknaden.
När manmigrerar enmonolitiskt kodbas mot enmikrotjänst arkitektur står man inför
flera val som kan påverka hela organisationen. Utifrån ett CI/CD perspektiv så kan
dessa val påverka effektiviteten av CI/CD processen.
Denna uppsats undersöker hur Indicios CI/CD process förändras när dem går mot
en mikrotjänstarkitektur från en monolit. Uppsatsen dokumenterar de val Indicio
har gjort under migrationen och hur det påverkar CI byggnadstid och CD distribution
tid.
Resultaten visar att Indicios beslut att behålla den nya mikrotjänsten i samma förvar
resulterade i 44% ökad medianbyggtid. Tidsökningen var acceptabel då det endast
innebar en snittökning på 20 sekunder. Fastän Indicio beslutade att separera på CD
processen till två nya, en för den nya mikrotjänsten och en för den nya monoliten
så påverkades inte distribueringstiden särskilt mycket. Den nya mikrotjänsten
distribuerades påMicrosoft Azure för att kunnautnyttja den elastiska datakraften. Den
stora fördelen från ett CD perspektiv med Azure var att man kunde utnyttja blågrön
distributionsmetod, vilket gjorde att driftstopp tiden försvann.
v
Nyckelord
Microservice architecture, Monolithic Architecture, DevOps, Continuous Integration,
Continuous Delivery, Cloud, Migration
vi
Acknowledgements
I would like to thank my Examiner Benoit Baudry and advisor Somayeh Aghanavesi at
KTH. They both have provided invaluable advice, feedback and guidance throughout
thework. Furthermore, Iwould like to thank Indicio TechnologyABandDaniel Schiess
for providing the opportunity for the research and the support. This thesis would not
have been possible without theses people.
vii
Contents
1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Benefits, Ethics and Sustainability . . . . . . . . . . . . . . . . . . . . . 3
1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Background 62.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 TeamCity and Octopus Deploy . . . . . . . . . . . . . . . . . . . 9
2.3 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Monolithic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Microservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
viii
CONTENTS
2.6.1 DecisionMaking . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6.2 Microservices Migration patterns . . . . . . . . . . . . . . . . . . 17
3 Methodology 183.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Research method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Research approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5 Data Analysis method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Migration 224.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 PreMigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Continuous Integration and Continuous Delivery . . . . . . . . . 234.3 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 PostMigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Continuous Integration and Continuous Delivery . . . . . . . . . 26
5 Result 285.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 Evaluation and Reliability Analysis . . . . . . . . . . . . . . . . . . . . . 305.5 Validity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1 Research question 1 . . . . . . . . . . . . . . . . . . . . . . . . 325.6.2 Research question 2 . . . . . . . . . . . . . . . . . . . . . . . . 325.6.3 Research question 3 . . . . . . . . . . . . . . . . . . . . . . . . 33
6 Conclusion 356.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
References 37
ix
Chapter 1
Introduction
Two big trends within software development that have gained a lot of traction in
recent years are development and operations (DevOps) andmicroservices [7, 23]. Both
of the concepts supposedly can improve code quality and the development process
of projects. A large part of DevOps is Continuous Integration (CI) and Continuous
Delivery and Deployment (CD) which are a set of practices to ease the development
and deployment process. The difference between continuous delivery and continuous
deployment is in how the practices deploy the changes. Continuous delivery requires
a manual operation to deploy while in continuous deployment the whole process is
automated [25]. Due to how the two practices are intertwined, they will be referred to
CD in this thesis.
1.1 Background
With software projects only growing in scale and complexity, it can be frustrating and
hard to work with a single large monolithic system that has thousands if not millions
of lines of code. Teams grow bigger and it becomes harder to organize the workflow
and collaborate within the same project [1, 13]. CI/CD and microservices both tackle
this issue by two different approaches.
a software development practicewheremembers of a team integrate their
work frequently, usually each person integrates at least daily—leading to
multiple integration’s per day, where each integration is verified by an
1
CHAPTER 1. INTRODUCTION
automated build (including test) to detect integration errors as quickly as
possible. [27]
Although the practices of CI/CDare proven to increase productivity in the formofmore
handled pull requests without a compromise of the code quality [30]. Some parts of
the development are hard to make more efficient in a monolithic system, where it is
common to keep all the code of a company on the same repository with a common
build system and/or libraries. Build time increase as the codebase grows and results
in more downtime [16]. This is where microservices complement CI/CD practices.
By splitting up a large monolithic system into a bunch of microservices where each
microservice handles a part of the system independently, and is handled by a separate
team has the potential to speed up the development process by streamlining the work
process [9]. Although, amicroservice architecture is usually more complex as a system
compared to a monolithic system, the improvement on how a team can work with the
code outweighs it [11]. However it is important to set up the microservice architecture
correctly otherwise, it might add overhead complexity and not be worth while[25].
1.2 Objective
To observe, investigate and compare the behavior of the CI/CD of Indicio Technology
AB’s monolithic codebase vs migrating part of their codebase towards a microservice
architecture. By going towards a microservice architecture, Indicio hope to be able to
meet future demand better through a more elastic system.
1.2.1 Research Questions
RQ1: What are the architectural changes in the CI/CD pipeline when going towards a
microservice architecture?
With the fundamental changes in the architecture that are happening when migrating
from a monolithic codebase to a microservice, the CI/CD pipeline is bound to change.
How does it change and are there alternatives? The answers might provide more
insight into whether it is worth migrating or not.
RQ2: How is the buildtime impacted in the CI pipeline when going towards a
microservice architecture?
2
CHAPTER 1. INTRODUCTION
Buildtime being amajor time consumer in Indicio’s current CI pipeline. What happens
with the buildtime when going towards a microservice and what options are available?
The answers might show alternative options depending on the needs.
RQ3: How is the deploy time impacted in the CD pipeline when going towards a
microservice architecture?
Currently, deploy time equals the time the system is down, therefore keeping the deploy
time low is essential for a good user experience. When going towards a microservice
architecture, an opportunity to adapt the CD pipeline presents itself. What options
exist and how is the deploy time affected by the decisions? The answers can help other
organizations to consider the different options.
1.3 Purpose
CI/CD has become an essential tool for developers and in combination with the
rise of microservices developers will have to adapt to a new architecture. Thus,
the purpose of this thesis is to investigate Indicio’s migration process towards a
microservice architecture from a monolith, if there are lessons to be learned from a
CI/CD perspective. The research will be conducted on their code however, there might
be lessons for organizations and developers to learn from it.
1.4 Benefits, Ethics and Sustainability
The company stands to benefit from the result in the form of more insight into where
the possible gains and pains of migrating to a microservice comes from a CI/CD
perspective. The company plans to migrate more of their code into microservices, and
through this study, they will learn how buildtime and deploy time might be affected.
Upon the result, they might decide to use a different strategy moving forward. As for
ethics and sustainability, although there is no direct connection to issues regarding
ethics or sustainability. There might be some indirectly. The power usage might
change by having everything on separate servers compared to one monolithic system
on a single server. So it might be a question of carbon footprint.
3
CHAPTER 1. INTRODUCTION
1.5 Methodology
The project will be a case study of Indicio’s journey towards microservice architecture,
consisting of a qualitative comparison of the eventual change in the CI/CD pipeline
to determine the differences of the structure and what implication that might have on
the system itself. Due to it not having any tangible data for comparison, a qualitative
assessment is suitable for the comparison. By looking at how the CI/CD pipeline
change when migrating towards a microservice architecture, it provides an idea of
possible differences in the quantitative research. This will give an overview of the
characteristics of the pipeline and provide insight into why the data in the quantitative
research part might differ. This will be more of a case study as architecture styles are
usually adopted to fit a certain purpose.
As for a more quantitative research, data from different aspects of their CI/CD
pipeline will be collected and compared. This part is crucial to determine the
possible advantages or disadvantages of the two different architectures from a CI/CD
perspective,more specifically TeamCity andOctopusDeploy. Once the data is collected
they will be compared and a conclusion drawn from them.
1.6 Stakeholders
The project is conducted at Indicio Technology AB. Indicio offers a software as a service
that gives access to advanced statistical models to their clients. Due to the rapid
growth of their product and to keep up with future demand, Indicio is investigating the
advantages of microservices and possible migration to it for part or all of their current
systems. The goal is to easier be able to handle demand as the company grows.
1.7 Delimitations
The project will make a comparison of the architectural differences in the CI/CD
pipeline and point out the key differences. As for the more quantitative research part,
the projectwill only compare the result of the chosenparameters anddrawa conclusion
from it.
4
CHAPTER 1. INTRODUCTION
1.8 Outline
Section 2 the theoretical background that is necessary to understand the study is
presented. Section 3 describes the methodology and how it was applied to the study.
Section 4 is the documentation of the system and how the changes were implemented.
Section 5 presents the result together with an analysis of the result. Section 6 present
the conclusion and discusses possible future work.
5
Chapter 2
Background
This chapter presents the theory and backgrounds of the different architectures
and practices for this research. Each section will describe the theory behind the
architectures or practices and give enough information to understand the research
itself.
2.1 Overview
Many companies have instilled DevOps in the recent decade, hoping to gain a more
efficient and productive development cycle [12]. CI/CDbeing a core part of theDevOps
process, any changesmade to theCI/CDpipelinewill change theway a teamworkswith
a particular code.
Continuous Integration (CI) – which automates software build tasks
such as the system. The increased compilation and testing–is rapidly
increasing in popularity. When combined with Continuous Delivery
(CD) – which can automate the deployment of software –the overall
time between when code is completed, and made available to end
users/customers, is greatly reduced. Reports show that CI/CD can help
companies, for example: Flickr to deploy software more than 10 times
per day [11].
How the CI/CD pipeline behaves when adapting it to a microservice architecture is
quite different compared to a monolithic codebase. Just like DevOps, microservices
have gained traction in recent years, see figure 1. The microservice architecture
6
CHAPTER 2. BACKGROUND
Figure 1: Google Trends showing amount of searches for the past 10 years
enables projects and companies to reduce their technical debt and enables easier
scaling for future demands on the hardware [20] In comparison to CI/CD, which is
more of a toolset for developers to automate the work and have an efficient pipeline
for the system. Although microservices and CI/CD differs in how the help software
development, both of the concepts have been introduced as it seeks to help developers
with development. But they tackle the problem from different directions, CI/CD helps
to improve the development and deploy cycle while microservices can reduce the
overhead complexity.
2.2 DevOps
Development and operations have historically been separated and through separation,
they have developed their own set of practices that make it difficult to collaborate.
DevOps aims to combine these sets of practices through common practices, tools, and
social techniques to remove the friction between these practices [5]. One set of tools
that are a big part of this effort to reduce the frictions are CI/CD practices.
2.2.1 Continuous Integration
CI is a software development practice where developer continuously merge their
working branch to the main branch frequently (at least once a day) to ensure
development compatibility. Today many tools provide this service, just to name a few,
Jenkins, Travis, TeamCity. The CI is triggered when someone pushes a commit to a
Distributed version control system (DVCS) e.g., Github, which in turn triggers the CI
7
CHAPTER 2. BACKGROUND
Figure 2: FlowChart of CI
tool. The CI will then build the application from the source code and run tests. If there
are any issues, the code will not be deployed and the errors have to be taken care of.
If the code passes all build configurations and tests, it will be deployed to the DVCS.
According to K. Gallaba and S. McIntosh [15] CI is usually split into three steps see
figure 2. First, create the job to make sure that the program will compile, as to not
waste reviewers’ time. Next, run the automated test to make sure the code will be
integrated and not create any unforeseen hazards. Lastly, Notify the team that it is
ready to be deployed, in Indicio’s case the CI will send to it Octopus deploy for it to be
deployed.
The ability to automate the process of testing and integrating code has been shown
to improve development speed and decrease the chances of releasing unfinished code
[15]. However, the efficiency of the CI is at the mercy of the developer who uses it as
well. It is important to set up relevant tests, otherwise one might miss the advantages
CI tools provide.
2.2.2 Continuous Delivery
CD is the complementary software engineering approach to CI, where teams aim to
automate the delivery of software releases. The ability to release software often and
continuously ensures that small changes can be deployed frequently to reduce the cost
and risk of delivering changes while increasing productivity and efficiency [10]. While
CI is focused on the integration of code changes into the main branch, CD is focused
8
CHAPTER 2. BACKGROUND
on the delivery and deployment of the changes. The CD pipeline usually consists of
three main steps see figure 3. Acceptance tests check that the build meets user needs,
business requirements, and other defined requirements defined by the developer. If it
passes all the acceptance tests it will prepare the build for staging by deploying it to an
environment where it can be easily deployed to production. Finally, the build will be
deployed to the production slot, either automatically if it is continuous deployment or
by a person, if it is continuous delivery.
Figure 3: FlowChart of CD
Through the streamlining of the deployment, the time to market for updates is
shortened. One example is Paddy Power, the largest public betting and gaming
company in the world with approximately 5000 employees [10]. They saw their time
to market drop from between one to six months down to once a week. Furthermore,
they saw Improved productivity, efficiency, quality and, customer satisfaction.
2.2.3 TeamCity and Octopus Deploy
TeamCity is a CI tool and is the choice of Indicio. TeamCity’s pipeline follows the
structure according to figure 4 and can be integrated with GitHub and Octopus Deploy
as is the case for Indicio. TeamCity is triggered by when a commit is pushed to a DVCS,
Github in Indicio’s case, which initiates the whole CI/CD pipeline. The reason for
Indicio to use TeamCity mainly comes down to cost. TeamCity offers a free version
of up to 100 build configurations and is an option for organizations that just started
and are a bit more price sensitive.
Octopus Deploy is a CD tool that offers both continuous delivery and deployment all on
9
CHAPTER 2. BACKGROUND
Figure 4: FlowChart of TeamCity and Octopus
one platform for easy management. It works together with TeamCity and can deploy
to both onpremise and the cloud. It follows the structure of figure 4 but also allows
multiple deployment slots such as development, testing, and production. Just like
TeamCity, Octopus Deploy also offers a free version and together with its ability to
integrate with TeamCity made it the choice for Indicio.
2.3 Cloud
Cloud computing is a service that offers the possibility to develop systems and
applications on a remote system through cloud providers such as Microsoft Azure,
Amazon Web Service (AWS), Google Cloud Platform (GCP). It offers many benefits in
the formof highly available and elastic computer power, unlimited backup and storage,
fully managed services and overall cost saving [29].
The National Institute of Standards and Technology defines cloud computing by five
composed essential characteristics, three service models, and four deployment models
[22]. The three service models are:
Service Models:
• Software as a Service (SaaS). The provided application is running on a cloud
infrastructure while the consumer access it through various devices. The
10
CHAPTER 2. BACKGROUND
consumer does not have any control of the underlying cloud infrastructure except
for userspecific application configuration settings.
• Platform as a Service (PaaS). The functions provided to consumers are to deploy
applications created or acquired by consumers using programming languages,
libraries, services, and tools supported by providers to the cloud infrastructure.
Users do not manage or control the underlying cloud infrastructure, but can
control the configuration settings of deployed applications and application
hosting environments.
• Infrastructure as a Service (IaaS). The capability provided to the consumer is
fundamental computing resources such as processing, storage, network, and
more for the consumer to deploy and run arbitrary software. Including, operating
systems and applications. The consumer has control over operating systems,
storage, and deployed applications. However, they can not manga or control the
underlying cloud infrastructure.
2.3.1 Microsoft Azure
Azure is Microsoft’s cloud computing service for building, testing, deploying, and
managing applications and services through their data centers. Azure offers SaaS,
PaaS, and IaaS through a wide range of products and services [2]. The one service
group that’s most relevant in this project is the compute service. A numver of these
services can be used to achieve a microservice architecture. However the one Idicio
decided to use is the App Service plan. Azure compute provides infrastructure for apps
and offers compute capacity in the cloud with scalable compute power. It consist of 10
different products [3]:
• Virtual Machine (VM). Provision Linux andWindows VMs, VMs are categorized
as IaaS and are a type of generalpurpose service with highly configurable
settings.
• Virtual Machine Scale Sets. Similar to the VM product but with automated
virtual machine scaling based on demand or a schedule.
• Azure Kubernetes Service (AKS). Kubernetes is a opensource platform for
managing containerized workloads and service [24]. Through the use of
virtualization, a set of physical resources can be presented as a cluster of VMs.
11
CHAPTER 2. BACKGROUND
AKS integrate Kubernetes into Azure for the deployment of a ready Kubernetes
cluster.
• Azure Functions. Azure Functions is a cloud service available ondemand that
provides all the continuallyupdated infrastructure and resources needed to run
your applications. Functions provides serverless compute for Azure. Functions
can be used to buildwebAPIs, respond to database changes, process IoT streams,
manage message queues, and more.
• Service Fabric. Azure Service Fabric is a distributed systems platform thatmakes
it easy to package, deploy, and manage scalable and reliable microservices and
containers.
• App Service. Azure App Service is a PaaS HTTPbased service for hosting
web applications, REST APIs, and mobile back ends. It also offers DevOps
capabilities such as package management, staging environments, custom
domain, integration with GitHub, Azure DevOps, and other sources.
• Container Instance. RunDocker containers ondemand in amanaged, serverless
Azure environment. Azure Container Instances is a solution for any scenario
that can operate in isolated containers, without orchestration. Run eventdriven
applications, quickly deploy from your container development pipelines, and run
data processing and build jobs.
• Batch. Azure Batch runs largescale applications efficiently in the cloud.
Schedule computeintensive tasks and dynamically adjust resources for your
solution without managing infrastructure.
• Cloud Services. Create highly available, scalable cloud applications andAPIs that
help you focus on apps instead of hardware.
• Azure Dedicated Host. Deploy Azure virtual machines on a physical server only
used by the organization.
Indicio decided to use App Service due the control it offers being suitable to the
microservice Indicio wanted to extract. An added bonus was the DevOps capabilities
it offered. According to NetApp [32], Azure is slightly cheaper than AWS, making it
more appealing to a price sensitive organization.
12
CHAPTER 2. BACKGROUND
2.4 Monolithic
A monolithic codebase usually refers to a collection of source code used to build a
system, where the whole system is usually deployed on one repository. By only having
one repository, engineers have access to a set of shared tools and one set of common
dependencies. Many large companies such as Facebook, Google, and Microsoft use
this type of organizational model [19]. When having multiple products sharing one
monolithic codebase, with a common set of tools and dependencies it is essential to
organizing these aspects of the code for efficient development.
2.4.1 Advantages
One of the big advantages of amonolithic codebase according to these companies is the
viability, which makes it is easy to search code across the system and the possibility to
use local calls [19]. The increased visibility has a large positive impact on the code
quality and velocity of the codebase. By sharing the same codebase, there is a tendency
to develop in a consistent style which benefits code quality and ease of cooperation.
Furthermore, the shared codebase creates a standardization where developers do not
have to worry about versioning problems. Collaboration between teams is easier as a
result of the standardization of the codebase, making it easier to build a community at
the company [19].
2.4.2 Disadvantages
On the other end, one of the drawbacks of a monolithic codebase is the limit when
it comes to tools and dependencies. In a monolithic repository, engineers reported
that they were frustrated if their dependencies failed [19]. Were as in a multi
repository codebase, the dependencies do not change until the owner of the repository
decides so. This lack of power to influence a large codebase can be frustrating and
counterproductive is a concern in a monolithic codebase.
Running a monolithic codebase comes with the risk of one point of failure. If there is
a bug or attack on the system, the system runs the risk of going down as a whole. A
company whose business is a software as a service might have serious consequences if
a product went down for some time.
Although CI/CD are used as tools to make the development and deployment easier,
13
CHAPTER 2. BACKGROUND
the sheer size of a monolithic codebase might be a challenge due to architectural
properties [25]. As the codebase and team grow, it can be challenging to have a CI/CD
pipeline. Even small changes can necessitate rebuilding, retesting, and redeploying
the entire application. The whole process can take quite some time, and will probably
only increase in time as the codebase grows which may result in downtime for further
development for the whole team.
2.5 Microservice
Microservice is an attempt to tackle some of the problems with large monolithic
codebases. Ever since it was introduced back in 2014 [26]. The architectural style
was described as a collection of small independent services. Each service is built
around a certain capability with its process and communicates with other services
independently through some type of mechanisms e.g. HTTP API. Each service can
be deployed separately, and as a result of these properties, scalability comes naturally
through the design. By being able to increase the hardware capabilities of only the
services where it is necessary, compared to a monolithic system where one would have
to scale up the whole system.
2.5.1 Advantages
Microservices are by nature cloudnative due to its independent module structure and
through the properties gained by a microservice architecture, independent services
are selfcontained. Each microservice can use the tools best fitted for the service,
independently worked and analyzed without knowledge of the wider system it is a
part of. Through these characteristics, each team working on a microservice can work
independently without the fear of influence the system at large. These attributes
make the architecture as a whole flexible without constraints from other services.
Furthermore, the learning curve for new team members is reported to be lower due
to the architecture [8].
The ability to scale the services that are needed is often mentioned as the most
important advantage during the operation stage [26]. Independence of Deployment,
being the second most important advantage during the operation stage, due to the
microservice architecture naturally support the separation of services. As a result of
14
CHAPTER 2. BACKGROUND
the independent deployment, each microservice can be reactive and scaled to suit its
needs. FromaCI/CDperspective, eachmicroservice can have its separate independent
pipeline where the microservice is developed and deployed in smaller increments.
the implication of an independent CI/CD pipeline is gains in build, test, and deploy
time.
2.5.2 Disadvantages
The advantages the come with microservice through the decoupling of services can
also become disadvantages. Through many independent microservices, the overall
complexity of a system can increase when it comes to design, development, and
operation.
When each microservice is independent, a possibility is that each team working on
a microservice develop their strategies when it comes to design, development, and
operation. This can cause issues when it comes to collaboration, evaluation, and
debugging a system as a whole. With many independent logs and services, it can be
a task just to identify the correct service to evaluate.
The necessity of communication between the microservices through APIs requires
correct versioning of the API. The risk of violating the contracts between the
microservices, the new API version needs to be retrocompatible [26]. Furthermore,
the need for more access controls and endpoints for communication is a security risk.
As a result, the attack surface is considerably larger than a monolithic application
[26].
2.6 Related Work
There is no single method or strategy for migrating a monolith to a microservice and
each company or project has to take different decision’s that can impact the whole
organization [6]. Although some migration patterns are more frequent due to their
value of industrial practices [8]. Onemight even consider rewriting thewhole codebase
from the beginning using microservice architecture [14]. But depending on the nature
of the product, there can be improvements in code reuse, performance increases in the
favor of lower response time, and lowerlevel support, which combined all result in a
financial gain [17].
15
CHAPTER 2. BACKGROUND
2.6.1 DecisionMaking
Although the migration is a technical process, equally important are the business or
organizational issues. These aspects and their relationship with the technical aspect
are often forgotten [6]. A recent study [6] looks into the human aspect of themigration
process. The study investigates 16 migration cases by conducting a grounded theory
interviewwith its participantswhere they identify three decisionmakingprocesses and
their decision points.
• Decisions on Creating Engagement
Migrating an existing service is a tedious task and the first decision is to evaluate if
there even is a will in the organization to migrate. Therefore it is important to evaluate
the technical feasibility as well as creating engagement.
• Decisions on the Technical Dimension
The next step in the decisionmaking is the engagement of the technical migration.
Here the organization decides upon the migration strategy depending on their
situation. The study [6] identifies three approaches to the migration process. The first
method is to start from scratch, meaning leaving the existing monolith and that the
new system is developed from the ground up. Once the new microservice is ready for
deployment the old monolith is decommissioned. The second method is by gradually
decomposing the monolith while developing new features as a microservice. The final
method is to extract a microservice from the existing monolith but keep parts of the
monolith that are hard or even impossible to extract as a microservice.
• Decisions on the Organizational dimension
The final step is tomake decisions on how to continue as an organization. The objective
is to lead operations to maximize the benefits of the new system and align business
with the new capabilities and requirements of the new technology. A migration can
take years to complete and have a huge impact on the organization, it is important
to decide on how the migration should be conducted. To be certain to keep track of
the new architecture, the study [6] has observed to strategies. The first option is to
distribute responsibilities to the developers, by including all the developers across the
organization, the risk of having isolated knowledge is minimized. However, there is a
lack of competence within the field and delegating the job across an organization can
make the project neglectable [14]. The second option is to put together a dedicated
16
CHAPTER 2. BACKGROUND
team. This can accelerate the learning curve on microservice architecture and making
sure that the migration is a focus of the organization.
2.6.2 Microservices Migration patterns
Although each organization’s method differs from each other, one study [8] tries to
identify some common pattern across the industry and found that there are some
common aspects. Of the three migration methods, the most common one seems to
be the decomposition of the old monolith, where subdomains are identified in the
monolith and separated. Although, another study [14] found that in their cases the
method of rewriting the monolith from scratch was most common.
To handle the communication between the microservices a common method was
to introduce a service registry that stores service instance addresses. The service
registry allows an edge server or load balancer to locate the needed service [8].
To ensure consistency between the development and the production environment,
containerization 1 was used by a majority of participants of the same study. There is
a strong link between containerization and microservice architecture, where through
the collection of all dependencies in a container it is possible to treat any given service
as a black box2 [8, 17, 28]. This is especially important for a microservice architecture
where each microservice differs in the needs of the environment for its deployment.
Furthermore, to be able to orchestrate the deployment of manymicroservice, the most
commonmethod was to deploy into a cluster by using cluster management tools.
1https://www.docker.com/resources/whatcontainer2https://en.wikipedia.org/wiki/Blackbox
17
Chapter 3
Methodology
Themethodology decides on how the study is conducted and ensures the quality of the
research and validation of the result. It is important to choose suitable methodologies
for the study to ensure a correct conclusion that can provide value for other people.
This chapter will go through the chosen methodologies used for conducting this
research together with an explanation of why it was suitable and what was done to
maintain the standard.
3.1 Overview
The case study is split into two types of research, a quantitative and qualitative
research. The nature of the CI/CD pipeline in combination with the architectural
changes makes it hard to isolate and quantify the data. The data provided from such
a research would not provide enough information when taken out of the context of
the architect. Therefore qualitative methods were more suitable to draw a conclusion
through an inductive approach regarding the architectural changes. While quantitative
research is more suitable for quantifying the changes that happened in the CI/CD
pipeline. The data was collected from existing sources in Teamcity and Octopus deploy
before the start of the migration and compared to data collected after some part of the
migration.
18
CHAPTER 3. METHODOLOGY
3.2 Background
Indicios CI/CD pipeline consists of TeamCity and Octopus deploy. Both these services
save the history of previous builds and deployment to a certain degree. By collecting
the data of the pipeline before the start of the migration of how long the buildtime
in Teamcity was and how long time the deployment was, a data set of the old
architect could be made. Once the changes to the CI/CD pipeline were implemented,
development continued as normal but with the new CI/CD pipeline. The new data
was collected roughly after four months of running with the new CI/CD pipeline and
put together as a new data set. Once the data was collected from before and after the
changes, a statistical comparison of the two data set is made. Next, the data were
analyzed with the change of the CI/CD pipeline taken into consideration to then be
able to draw a conclusion.
3.3 Research method
The research method provides the course of action to fulfill the research task. These
actions define the way the research is conducted, from initiating, carrying out, and
completing the research task [18]. Hence, the process of the research is supported by
the research method applied to the project.
The research was about documenting the changes and observe what happened, a non
experimental research method was used. The nonexperimental research method
focuses on existing scenarios and concludes the situation [18]. This research is focused
on documenting the migration process, and how the buildtime and deploy time is
impacted due to the architectural changes in the CI/CD pipeline. The focus is not
on experiments, but rather migration pattern decision and how it impacts the CI/CD
pipeline. Hence the nonexperimental research method worked well for this study
regarding how the research was conducted.
At the beginning of the study, data was collected from prior commits and deployment
to be used as a benchmark for the new data after the migration. During the study,
all the work and decisions were documented while simultaneously collecting more
information from research papers regarding similar subjects.
19
CHAPTER 3. METHODOLOGY
3.4 Research approaches
The research approach is how to draw conclusions and determine what is true or false.
After the data were collected, an inductive approach was used to draw conclusions
from the results. The inductive approach formulates theories and propositions with
alternative explanations from observations and patterns [18]. Data collection through
the qualitative method is applied and analyzed to gain an understanding of the result
and establish different views of it. There must be enough data to determine why
something is happening based on behaviors, opinions, and experiences [18].
As the process of migration is a big part of this study, one has to take that into account
when looking at the gathered data. To ensure the conclusion was correct, continuous
research into other papers and articles were made in parallel to the migration project.
Knowledge of alternative patterns Indicio could have taken and how the decisions
Indicio made differed from other patterns. A combination of the migration decisions
made along the way, the gathered data, and knowledge of alternative solutions was
necessary to draw a correct conclusion. It is important to see the impact of the
migration patterns on the CI/CD pipelines. For those reasons, an inductive approach
can answer RQ1 which in turn can explain the result of RQ2 and RQ3.
3.5 Data Analysis method
The data analysis method is the process of inspecting, cleaning, transforming, and
modeling the collected data. The data that was extracted for this study were analyzed
with descriptive statistics to gain an understanding of what was changed. The data
before the migration started were collected from prior commits in TeamCity and prior
deployments from Octopus Deploy. Together with the new data after decoupling a
module from the monolith an overview of the result was gained. Some of the data had
to be ignored due to artificial reasons that affected the data. Some data points were
shown incorrectly due to Octopus and how it handles deployment, therefore those data
points has been ignored. The result in combination with the answers to RQ1 will then
be evaluated and discussed to try and explain the meaning of the answers to RQ2 and
RQ3.
20
CHAPTER 3. METHODOLOGY
3.6 Quality Assurance
Quality Assurance is the validation and verification of the research material. The
qualitative research with its inductive approach considered validity, transferability,
dependability, confirmability, and ethics [18]. All these steps were taken to ensure
the validity of the research was done according to the specified rules. Transferability
ensures the quality of the documentation of the research. Dependability confirms
the correctness of the conclusion through auditing. Confirmability assures objectivity
throughout the research. Ethics is the moral guideline for the research where
participant’s safety, confidentiality, and consent are guaranteed.
21
Chapter 4
Migration
This chapter will go through the work that was done at Indicio. Section 4.2 explains
the old architecture and CI/CD pipeline. Section 4.3 describes the decisions and work
that had to be done tomake thismigration possible. Section 4.4 describes the resulting
architecture of the system including the new CI/CD pipeline.
4.1 Overview
Indicios through their platform provides their clients with advanced statistical models
to predict price changes, everything frommetal prices to housing prices. The data that
enables these predictions are collected from a wide range of industry providers such as
Valueguard1, Statistics Sweden2. This is done through the thirdparty provider’s API
services.
This case study is split into two parts, first an analysis of the monolithic architecture
before the migration in combination with the CI/CD pipeline. Secondly, an analysis
of the architecture after a small part of the code has been migrated to microservice
architecture and the changes in the CI/CD pipeline as a result of that. An API service
that handled the communication between the backend, remote data service, and the
database was broken lose to its own microservice.
1https://valueguard.se/2https://www.scb.se/
22
CHAPTER 4. MIGRATION
4.2 PreMigration
The old system consisted of a frontend that communicates with the backend which
handles all user requests and communication with the database see figure 5.
Figure 5: Old monolith architecture, the flow goes counterclockwise.
An API service exists in the backend to facilitate requests regarding variables from
remote sources. The user requests the import or update of remote variables, and
through the API the backend receives the information of the requested variable from
the remote data provider. The API then checks if the variable data has changed in the
database, if it has changed the API will update the database with the new value. Once
the most current data has been established the API returns the data to the user to be
used in the prediction models.
4.2.1 Continuous Integration and Continuous Delivery
The CI/CD pipeline before the start of migration consists of TeamCity and Octopus
deploy see figure 6.
TeamCity will check for changes in source control (Github), once changes are detected
(through a commit with git) TeamCity will compile and build the code from Github. If
it is successful in compiling and building the code TeamCity will then create packages
for deployment. Octopus will take those packages and deploy them to the chosen
environment for acceptance tests before being deployed to the production server once
the developer deems it fit.
23
CHAPTER 4. MIGRATION
Figure 6: Old CI/CD pipeline.
4.3 Migration
The API service which handles the requests to remote data services was deemed to
be a good first module of the monolith to break into a microservice. The API service
is currently used heavily to constantly keep the variables uptodate through a daily
update of all variables, which takes roughly 8 hours. In addition to the daily update,
the API service can also be triggered manually by the user. To make sure the company
can keep up with future growth and demand, the API service has to be able to handle
more requests. In addition to the strain on the API service, the API service is quite
small (roughly 200 lines of code) making it ideal for a first module to migrate.
In combination with the migration towards microservices, Indicio decided to deploy
the microservice on Microsoft Azure by utilizing Azures App service plan. Indicio
decided to use Microsoft Azure due to it being the most compatible and cost
competitive for their need. The App service offers a fully managed platform with
builtin infrastructuremaintenance, security, patching, loadbalancing, and scaling [4].
Additionally, Indicio could utilize the builtin DevOps support with the zerodowntime
deployment feature through deployment slots.
The API service is deployed to Azure, becoming a remote service handler. Indicio
24
CHAPTER 4. MIGRATION
wanted to take advantage of the elastic compute power and have the option to deploy
multiple instances of the remote service handler. The communication with Azure
was handled through a proxy which was set up in Azure. The proxy handles the
communication with the remote service handler within Azure. The company decided
to use HAproxy 3 mainly due to the simplicity of setup of the proxy service.
4.3.1 Strategy
The method of migration for this project is to extract the API service from the existing
monolith. Once the API service was chosen for the migration, an analysis of how
the API service was ingrained in the monolith was conducted. What dependencies
it used and how the communication between the module and the rest of the system
were built up. Due to the API service being a part of a larger monolith at this stage, it
shared code with other parts of the monolith. A deep understanding of the API service
was necessary to be able to migrate it. In total, roughly 400 lines of codes had to be
refactored. In addition, a new build file had to be configured for the newmodule.
It was decided to keep the microservice in the same repository but with its separate
build file to be able to utilize the existing dependencies in the current monolith. This
drastically reduced the amount of code that needs to be refactored and migrated.
However, this method does not take full advantage of the CI capabilities that
microservices bring, as a result of its inability to separate the CI to separate pipelines.
The size of the module made it acceptable, and the time spent on the migration was
significantly lowered. The downside is that TeamCity has to compile an extra build
file, which increased the buildtime of the repository.
There are no tests in the current CI pipeline, whichmeant that therewas a lot ofmanual
testing to ensure the work was done correctly. The risk of relying on manual tests
for this migration meant a higher chance of undetected error and possibly a slower
migration process.
As for Octopus deploy, a new pipeline for the new API service was needed since it
was split into a new service that was deployed on Azure. As a result, Octopus had
to handle two deployments. Through Azure App service it was possible to use the
deployment slots and implement the bluegreen deployment, reducing the downtime
to zero [31]. Bluegreen deployment is a method of deploying to a staging server, once
3https://www.haproxy.com/
25
CHAPTER 4. MIGRATION
the deployment to the staging server is done, the staging server swaps with the live
server. Resulting in traffic being rerouted to the newly updated environment. As an
added bonus the old deployment can be easily swapped back into the production slot
in case the new update have some issue.
4.4 PostMigration
The new architecture according to Figure 7 with the remote service handler now being
a microservice.
Figure 7: Post migration microservice architecture, the flow goes counterclockwise
While backend still handles all the usual functionality such as login and browsing on
the site. The request of remote variables through import or update requests are sent to
the remote service handler through the proxy. The remote service handler fetches data
from the remote data services and checks it against the database through the remote
service handler. If the new data is newer than the data already in the database, the
database is updated. The latest data is fetched from the database and returned to the
user through the proxy.
4.4.1 Continuous Integration and Continuous Delivery
The decision to keep TeamCity the samemeant onlyminor changes happened, it had to
build another execution file and deploy to two Octopus deploy slots see figure 8.
Once Octopus receives the packages it deploys them to the respective slots. The new
monolith gets deployed to the same slot as it did before while the new remote service
26
CHAPTER 4. MIGRATION
Figure 8: Post migration CI/CD pipeline
handler gets deployed to a staging server. Once the deployment to the staging server
is done, Azure swaps the staging slot with the production slot. Meaning, traffic is
rerouted to the staging slot and becomes the production slot while the production
slot becomes the new staging slot. For the deployment to Azure, a procedure had to
be added into Octopus Deploy pipeline where Octopus executes a script on behalf of
Azure.
The decisions made along the way had a big impact on this thesis and how the study
was conducted. Had different decisions been made, the outcome would have been
different. The decision to keep everything in the same repository had an impact on
the buildtime of the code, which correlates to RQ 2. While the decision to deploy to
Azure and being able to take advantage of bluegreen deployment made a big impact
on how the result for the deploy time was interpreted.
27
Chapter 5
Result
This chapter presents the results of the study starting with 5.1 which describes the
result of the architectural changes. 5.2 and 5.3 present the data gathered from
TeamCity and Octopus Deploy. 5.4 and 5.5 are an evaluation and validity analysis of
the study followed up by section 5.6 which discusses and analyses the results.
5.1 Architecture
The changes in TeamCity were not substantial in Indicios’s case when going towards
microservice architecture, mainly due to the decisions made along the way. However,
OctopusDeploy changed considerably, by having two separate CDpipelines for the new
monolith and the microservice meant that the CD could be adjusted to their specific
needs. The deployment for the microservice to Azure could take full advantage of the
tools offered by Azure. While the newmonolith could still be deployed to Indicio’s own
servers.
It should be noted that the design choices were only viable due to the size of Indicios
codebase. In a larger codebase where the separated modules were to contain all the
dependencies, the CI/CD pipeline procedure might take days. As would be the case for
a larger system such asMGDIS [17]. They had 40microservices decomposed from their
monolith. Had they not split the deployment of their microservices, the deployment
process would last a week or so.
28
CHAPTER 5. RESULT
5.2 CI
The result of the collected data is presented in figure 9. There are 14 commits for
TeamCity before the migration started and 45 commits for after the migration. The
commits prior to the microservice decoupling are earlier versions of the code. The
reason for the limited amount of commits before the migration is due to TeamCity not
saving more history.
Figure 9: TeamCity buildtime comparison
The median time for the buildtime for the old architecture was 45 seconds and 65
seconds after the migration, an increase of roughly 44% in the mean time. The added
time comes from the extra build file that TeamCity has to compile to fit the new
architecture.
5.3 CD
The result of Octopus Deploys deploy time is presented in figure 10. For Octopus
Deploy there were 32 deploys for the old monolith architecture and 47 for the
new architecture. The new architecture also adds in another deployment for the
microservice which is deployed to Azure.
The median deploy time for the monolith was 59 seconds, and after the migration, the
time for the new monolith was 70 seconds. For the new remote service handler, the
29
CHAPTER 5. RESULT
Figure 10: Octopus Deploy deploy comparison
mediandeploy time is 43 seconds. Although the combined time ismore than the deploy
time for the old monolith, the new deployments are handled independently. Meaning
the deployment of the new monolith and the microservice can be run in parallel. It
should be noted, like the CI commits, the deployments are different versions. The
deployments to the old monolith are for earlier system versions.
5.4 Evaluation and Reliability Analysis
The data from Octopus deploy have been gathered from the history of deployments.
Octopus Deploy offers different pricing models depending on the needs of the
customer. The pricing option Indicio currently has limited the amount of work one
deployment pipeline can do at the same time. Meaning if one decided to deploy to a
development slot and a test slot for the monolith, only one deployment can happen
at a time. The process forces one of the deployments to wait until the other one is
done and therefore adds time to the deployment time. Therefore the data from those
deployments have been removed. If those results were to be included the mean time
for both the old and new monolith would increase, but due to artificial reasons rather
than reasons related to the code or architecture. If Indicio were to change the price
plan, this issue would go away and that would give a more accurate representation of
30
CHAPTER 5. RESULT
the median deploy time.
5.5 Validity Analysis
To ensure the validity of the study it was important to decide on a suitable research
method to guarantee the correctness of the data gathered to answer the research
questions. To assure the validity of the study, the process was the following:
• Prestudy to determine the feasibility of the study. What and how to conduct the
research were determined.
• Suitable research method was chosen and applied, as can be read in chapter 3.
• Continuous assessment of the data gathered to ensure correctness. As the data
was gathered from the CI/CD tools history where some data predates the starting
date, and some during the time spent at Indicio. It was important to continually
review data as to remove data that were deviating due to factors unrelated to the
study.
• Being transparent to minimize bias. Through presenting what data is collected
and what data that is being ignored.
5.6 Discussion
A monolithic codebase with an existing CI/CD pipeline will have to be adapted when
going towards a microservice architecture. The results show the implications of the
decisions of the migration pattern Indicio decided to use.
The new architecture for Indicio consists of one smallmicroservice and a newmonolith
where the API service has been extracted. Although the work needed to be put into a
migration is no small amount, Indicio’s approach of keeping it in the same repository
hastened the initial work. However, from a CI perspective this resulted in an increased
buildtime due to a larger repository, extra build file, shared dependencies, and tools.
Additionally, the repository cannot be configured with relevant dependencies and
tools, creating a larger than necessary repository. As the system grows, the buildtime
is expected to grow and it might reach a point where the time penalty impacts the
development. More specifically, the development team might not be able to make any
31
CHAPTER 5. RESULT
meaningful changes to the system while the code is in the CI pipeline.
5.6.1 Research question 1
The decision to keep the code for the new microservice in the same repository meant
not having to break out all the dependencies and create a new repository. As a result,
less portion of the system had to be analyzed and migrated, this made the project
possible in a short time frame. The downside was the increased buildtime for the CI
pipeline, and not being able to customize the CI pipeline to suit the microservice needs
through targeted testing. The increased meantime are all linked to the extra build file
TeamCity had to build. However, this was not an issue for Indicio since they do not
have any tests for this phase.
As for the CD pipeline, Indicio set up two independent pipelines consisting of the new
monolith and the newmicroservice. To accommodate the changes in the CDpipeline, a
new pipeline wasmade for the microservice. The new CD pipeline for the microservice
is also deployed to Microsoft Azure see figure 7. This meant there was one extra step
to the CD pipeline for the microservice, the deployment to Azure. As a result, Indicio
is now also dependent on Microsoft Azure service, and that Microsoft continues to
maintain Azure.
5.6.2 Research question 2
Due to the decision Indicio chose, TeamCity could not be utilized to its potential
through the customization of the CI pipeline. The consequences were deemed
acceptable since the 44%meantime increase only resulted in an additional 20 seconds
for the buildtime. Where the additional builtime came from the extra build file
TeamCity had to compile. However, should Indicio decide to migrate the remote
service handler into its own repository in the future, the amount of work is acceptable
due to the size of the remote service handler. The spikes in buildtime are due to
TeamCity and are related to building issues where TeamCity simply has to wait a few
seconds. Future microservices might be migrated into their own repository with their
own set of dependencies and CI pipelines.
If the remote service handler were to have its own repository the buildtime in the
CI pipeline for both the remaining monolith and the microservice would decrease.
32
CHAPTER 5. RESULT
Additionally, the CI/CD pipeline would be more customizable with better test cases
relevant to the repository [10].
Furthermore, the mean time spent in TeamCity is low, this comes down to the absence
of tests in the CI pipeline. It is not uncommon to spend hours or even days in the
CI/CD pipeline when pushing changes, and themajor time consumer are the tests [21].
Indicio does not run any unit tests in their current CI pipeline for this repository. The
fact that there are no test cases together with the decision to keep TeamCity the same
meant only minor changes happened. There was no need to extract tests and fit them
to the new microservice meant that the only added time came from building another
execution file and deploy to two Octopus deploy slots.
By running no tests, the risk for human errors being deployed is increased
considerably. Errors which can have major implications for the system and users.
Especially for a migration where changes are happening to both the old monolith and
the new microservice. Additionally, it will affect the development process negatively
in the future through a longer development process and fewer integrations due to
unexpected errors [21]. As a Consequence, manual testing had to be conducted during
themigration and that itself can increase themigration process. The issue with relying
onmanual testing are the humans, it is hard to conduct a thorough testing process and
the chances for undetected error are higher.
5.6.3 Research question 3
One could expect the deploy time for the newmonolith after the microservice has been
extracted to decrease, that was not the case due to two reasons. First, the microservice
is small, and the amount of code extracted was not enough to affect the time to deploy
by any noticeable margin. Secondly, shown by the time to deploy the microservice.
The majority of the deploy time for this system is not linked to the size of the code in
Indicios’s case. Rather a big chunk of the time is spent on the migration to the server,
setting up console app, and apply retention policies. These steps are all quite similar
in time, due to the small size of the codebase. The cause of the high volatility amongst
the data points of the microservice is the retention policies. Due to the development
changes in the microservice, the retention policies had to be updated quite often and
resulted in volatility in deployment time, especially the new microservice.
Although the deploy time did not change by any noticeable margin and the aggregated
33
CHAPTER 5. RESULT
time increased. The fact that the deployments are independent means that they can
run independently of each other. As a result, it is possible to update andmake changes
to the microservice and then deploy those changes without having to touch the up
and running monolith. Furthermore, as the monolith continues to be decoupled, the
overall deploy time for each deployment should decrease. The volatility of the curve
should smooth out for the microservice as well.
Before the migration, the deploy time of the code meant the time the service was
down for the user. Although the downtime is low, it meant that Indicio tried to
push their update during the night as to not disturb any potential user. This limited
them somewhat as to not update the service during peak hours as that could disturb
users.
One big advantage that comes with Azure in Indicios’s case was the possibility to
implement bluegreen deployment easily. Azure’s App service provided the possibility
to utilize deployment slots in Azure. Now with the implementation of bluegreen
deployment, the downtime has been reduced to zero for the microservice. Resulting
in a better user experience and the possibility to update at any time without the user
noticing.
For now, Indicio only has one microservice deployed to Azure. However, the option
to make a clone of the microservice or scale up the compute resources for the
microservice, ensures that the remote service handlerwill be able to keepupwith future
demand.
34
Chapter 6
Conclusion
Whenmigrating towards a microservice architecture from a monolithic one, decisions
made in the beginning can be hard to reverse. Therefore it is important to properly
investigate what one wants to accomplish with the migration. How one wants to adopt
the CI/CD pipeline can be highly influential on the development and operations side of
a system. Depending on the decisions, time spent in the CI/CD pipeline can drastically
change. Indicios decision to keep everything in the same repository for this project was
deemed the optimal solution. Indicio’s relatively smallmonolithmade it acceptable for
the decomposed microservice to remain in the same repository. The 44% increase in
buildtime only resulted in a 20 seconds increase in mean buildtime.
There are no types of tests for this CI pipeline and as a result, the time spent in
TeamCity is low. Consequently, the chances for undetected errors are higher than they
would have been with tests. This is especially important when migrating, as the code
goes through big changes. All the testing was done manually and there may be missed
cases.
The deployment process was changed through the separation of the new microservice
from the old monolith. The new microservice now has its own deployment pipeline
which deploys to Microsoft Azure while the new monolith is deployed to Indicio’s own
servers. Through the App service solution, a bluegreen deployment method could be
implemented with ease by utilizing deployment slots in the Azure App service. The
bluegreen deployment meant downtime for the microservice was reduced to zero.
Resulting in a big improvement in downtime for the microservice compared to the
old monolith, where the mean deployment time of 65 seconds equals the downtime.
35
CHAPTER 6. CONCLUSION
The biggest change did not come from a massive improvement in deploy time for
Indicio, but rather from being able to utilize cloud computing. However, the prospect
of separating the CD pipeline is promising. The ability to have an independent CD
pipeline that can deploy independently of each other means that the microservice can
be developed and deployed without affecting the monolith.
6.1 Benefits
The company have gained knowledge about how their decisions have affected the
CI/CD pipeline. The results show that their decisions does affect the time penalty in
their CI/CD pipeline. However the time penalty is acceptable for Indicio but Indicio
might considering changing strategy in the future.
The benefits for the users through the bluegreen deployment means a better user
experience with zero down time. As the system continues to be decoupled and if the
whole system can utilize the advantages presented by bluegreen deployment. Users
will not have toworry about a potential update during usagewhich leader to better user
confidence.
6.2 Future Work
As the migration towards a microservice architecture continues, one can continue to
study how the future decoupledmodule will affect the buildtime and deploy time of the
CI/CD pipeline. Especially when tests are added to the CI pipeline and the implication
the test has on the CI/CD pipeline. Considering the route Indicio has taken regarding
the repository, the evolution of the CI will be interesting. Especially since the current
microservice module increased the mean buildtime by an average of 44%. At one
point the penalty might not be acceptable anymore and a shift towards independent
repositories might be necessary. Additionally, when unit testing is applied, a study on
how thatwould affect the time spent in the CI pipelinewould be interesting to see.
36
Bibliography
[1] Ahmadvand, M. and Ibrahim, A. “Requirements Reconciliation for Scalable
and Secure Microservice (De)composition”. In: 2016 IEEE 24th International
Requirements Engineering Conference Workshops (REW). 2016, pp. 68–73.
DOI: 10.1109/REW.2016.026.
[2] App Service. URL: https://azure.microsoft.com/en-us/services/.
[3] App Service. URL: https : / / azure . microsoft . com / en - us / product -
categories/compute/.
[4] App Service. URL: https://docs.microsoft.com/en-us/azure/app-service/
overview.
[5] Artac, M., Borovssak, T., Di Nitto, E., Guerriero, M., and Tamburri, D. A.
“DevOps: Introducing InfrastructureasCode”. In: 2017 IEEE/ACM 39th
International Conference on Software Engineering Companion (ICSEC).
2017, pp. 497–498. DOI: 10.1109/ICSE-C.2017.162.
[6] Ayas, Hamdy Michael, Leitner, Philipp, and Hebig, Regina. Facing the Giant:
a Grounded Theory Study of DecisionMaking in Microservices Migrations.
2021. arXiv: 2104.00390 [cs.SE].
[7] Balalaie, A., Heydarnoori, A., and Jamshidi, P. “Microservices Architecture
Enables DevOps:Migration to a CloudNative Architecture”. In: IEEE Software
33.3 (2016), pp. 42–52. DOI: 10.1109/MS.2016.64.
[8] Balalaie, Armin, Heydarnoori, Abbas, Jamshidi, Pooyan, Tamburri, Damian A,
and Lynn, Theo. “Microservicesmigration patterns”. In: Software: Practice and
Experience 48.11 (2018), pp. 2019–2042.
[9] Chen, L. “Microservices: Architecting for Continuous Delivery and DevOps”. In:
2018 IEEE International Conference on Software Architecture (ICSA). 2018,
pp. 39–397. DOI: 10.1109/ICSA.2018.00013.
37
BIBLIOGRAPHY
[10] Chen, Lianping. “Continuous Delivery: Overcoming adoption challenges”. In:
Journal of Systems and Software 128 (2017), pp. 72–86. ISSN: 01641212. DOI:
https : / / doi . org / 10 . 1016 / j . jss . 2017 . 02 . 013. URL: https : / / www .
sciencedirect.com/science/article/pii/S0164121217300353.
[11] Debroy, Vidroha, Miller, Senecca, and Brimble, Lance. “Building Lean
Continuous Integration and Delivery Pipelines by Applying DevOps Principles:
A Case Study at Varidesk”. In: Proceedings of the 2018 26th ACM Joint
Meeting on European Software Engineering Conference and Symposium on
the Foundations of Software Engineering. ESEC/FSE 2018. Lake Buena Vista,
FL, USA: Association for Computing Machinery, 2018, pp. 851–856. ISBN:
9781450355735. DOI: 10.1145/3236024.3275528. URL: https://doi.org/
10.1145/3236024.3275528.
[12] Dıaz, Jessica, LópezFernández, Daniel, Pérez, Jorge, and GonzálezPrieto,
Ángel. “Why are many businesses instilling a DevOps culture into their
organization?” In: Empir. Softw. Eng. 26.2 (2021), p. 25. DOI: 10 . 1007 /
s10664-020-09919-3. URL: https://doi.org/10.1007/s10664-020-09919-3.
[13] Dragoni, Nicola, Giallorenzo, Saverio, Lafuente, Alberto Lluch,
Mazzara, Manuel, Montesi, Fabrizio, Mustafin, Ruslan, and Safina, Larisa.
“Microservices: Yesterday, Today, and Tomorrow”. In: Present and Ulterior
Software Engineering. Ed. by Manuel Mazzara and Bertrand Meyer. Cham:
Springer International Publishing, 2017, pp. 195–216. ISBN: 978331967425
4. DOI: 10.1007/978-3-319-67425-4_12. URL: https://doi.org/10.1007/
978-3-319-67425-4_12.
[14] Fritzsch, J., Bogner, J., Wagner, S., and Zimmermann, A. “Microservices
Migration in Industry: Intentions, Strategies, and Challenges”. In: 2019 IEEE
International Conference on Software Maintenance and Evolution (ICSME).
2019, pp. 481–490. DOI: 10.1109/ICSME.2019.00081.
[15] Gallaba, K. and McIntosh, S. “Use and Misuse of Continuous Integration
Features: An Empirical Study of Projects That (Mis)Use Travis CI”. In: IEEE
Transactions on Software Engineering 46.1 (2020), pp. 33–50. DOI: 10.1109/
TSE.2018.2838131.
38
BIBLIOGRAPHY
[16] Ghaleb, Taher Ahmed, Da Costa, Daniel Alencar, and Zou, Ying. “An empirical
study of the long duration of continuous integration builds”. In: Empirical
Software Engineering 24.4 (2019), pp. 2102–2139.
[17] Gouigoux, J. and Tamzalit, D. “From Monolith to Microservices: Lessons
Learned on an Industrial Migration to a Web Oriented Architecture”. In: 2017
IEEE International Conference on SoftwareArchitectureWorkshops (ICSAW).
2017, pp. 62–65. DOI: 10.1109/ICSAW.2017.35.
[18] Håkansson, Anne. “Portal of research methods and methodologies for research
projects and degree projects”. In: The 2013 World Congress in Computer
Science, Computer Engineering, and Applied ComputingWORLDCOMP 2013;
Las Vegas, Nevada, USA, 2225 July. CSREA Press USA. 2013, pp. 67–73.
[19] Jaspan, C., Jorde, M., Knight, A., Sadowski, C., Smith, E., Winter, C., and
MurphyHill, E. “Advantages and Disadvantages of a Monolithic Repository: A
Case Study at Google”. In: 2018 IEEE/ACM 40th International Conference on
Software Engineering: Software Engineering in Practice Track (ICSESEIP).
2018, pp. 225–234.
[20] Lenarduzzi, Valentina, Lomio, Francesco, Saarimäki, Nyyti, and Taibi, Davide.
“Does migrating a monolithic system to microservices decrease the technical
debt?” In: Journal of Systems and Software 169 (2020), p. 110710. ISSN: 0164
1212. DOI: https://doi.org/10.1016/j.jss.2020.110710. URL: https:
//www.sciencedirect.com/science/article/pii/S0164121220301539.
[21] Lima, Jackson A Prado and Vergilio, Silvia R. “Test Case Prioritization
in Continuous Integration environments: A systematic mapping study”. In:
Information and Software Technology 121 (2020), p. 106268.
[22] Mell, Peter, Grance, Tim, et al. “The NIST definition of cloud computing”. In:
(2011).
[23] O’Connor, Rory V, Elger, Peter, and Clarke, Paul M.
“Continuous software engineering—A microservices architecture perspective”.
In: Journal of Software: Evolution and Process 29.11 (2017), e1866.
[24] Overview. URL: https://kubernetes.io/docs/concepts/overview/what-
is-kubernetes/.
39
BIBLIOGRAPHY
[25] Shahin, Mojtaba, Zahedi, Mansooreh, Babar, Muhammad Ali, and Zhu, Liming.
“An empirical study of architecting for continuous delivery and deployment”.
In: Empirical Software Engineering 24.3 (2019), pp. 1061–1108.
[26] Soldani, Jacopo, Tamburri, Damian Andrew, and Van DenHeuvel, WillemJan.
“The pains and gains of microservices: A Systematic grey literature review”. In:
Journal of Systems and Software 146 (2018), pp. 215–232. ISSN: 01641212.
DOI: https://doi.org/10.1016/j.jss.2018.09.082. URL: https://www.
sciencedirect.com/science/article/pii/S0164121218302139.
[27] Stolberg, S. “Enabling Agile Testing through Continuous Integration”. In: 2009
Agile Conference. 2009, pp. 369–374. DOI: 10.1109/AGILE.2009.16.
[28] Taibi, Davide, Auer, Florian, Lenarduzzi, Valentina, and Felderer, Michael.
“From monolithic systems to microservices: an assessment framework”. In:
arXiv preprint arXiv:1909.08933 (2019).
[29] Tubre, Brock and Rodeghero, Paige.
“Exploring the Challenges of Cloud Migrations During a Global Pandemic”. In:
2020 IEEE International Conference on Software Maintenance and Evolution
(ICSME). 2020, pp. 784–785. DOI: 10.1109/ICSME46990.2020.00090.
[30] Vasilescu, Bogdan, Yu, Yue,Wang, Huaimin, Devanbu, Premkumar, and Filkov,
Vladimir. “Quality and Productivity
OutcomesRelating toContinuous Integration inGitHub”. In:Proceedings of the
2015 10th Joint Meeting on Foundations of Software Engineering. ESEC/FSE
2015. Bergamo, Italy: Association for Computing Machinery, 2015, pp. 805–
816. ISBN: 9781450336758. DOI: 10.1145/2786805.2786850. URL: https:
//doi.org/10.1145/2786805.2786850.
[31] Yang, Bo, Sailer, Anca, Jain, Siddharth, TomalaReyes, Angel E., Singh, Manu,
and Ramnath, Anirudh. “Service Discovery Based BlueGreen Deployment
Technique in Cloud Native Environments”. In: 2018 IEEE International
Conference on Services Computing (SCC). 2018, pp. 185–192. DOI: 10.1109/
SCC.2018.00031.
[32] Yifat Perry, ProductMarketing Lead. Sept. 2020.URL: https://cloud.netapp.
com/blog/azure-vs-aws-pricing-comparing-apples-to-apples-azure-
aws-cvo-blg.
40
TRITA -EECS-EX-2021:698
www.kth.se