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 <kasperli@kth.se>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 blue­green 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 Decision­Making . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Pre­Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1 Continuous Integration and Continuous Delivery . . . . . . . . . 234.3 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.1 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Post­Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 on­premise 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 user­specific 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 general­purpose 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 open­source 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 on­demand that

provides all the continually­updated 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 HTTP­based 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 on­demand in amanaged, serverless

Azure environment. Azure Container Instances is a solution for any scenario

that can operate in isolated containers, without orchestration. Run event­driven

applications, quickly deploy from your container development pipelines, and run

data processing and build jobs.

• Batch. Azure Batch runs large­scale applications efficiently in the cloud.

Schedule compute­intensive 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 cloud­native due to its independent module structure and

through the properties gained by a microservice architecture, independent services

are self­contained. 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 retro­compatible [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 lower­level support, which combined all result in a

financial gain [17].

15

CHAPTER 2. BACKGROUND

2.6.1 Decision­Making

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 decision­makingprocesses 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 decision­making 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/what­container2https://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 non­experimental 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 non­experimental 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 third­party 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 Pre­Migration

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 counter­clockwise.

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 up­to­date 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

built­in infrastructuremaintenance, security, patching, loadbalancing, and scaling [4].

Additionally, Indicio could utilize the built­in DevOps support with the zero­downtime

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 HA­proxy 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 blue­green deployment, reducing the downtime

to zero [31]. Blue­green 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 re­routed 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 Post­Migration

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 counter­clockwise

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

re­routed 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 blue­green 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:

• Pre­study 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 blue­green deployment easily. Azure’s App service provided the possibility

to utilize deployment slots in Azure. Now with the implementation of blue­green

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 blue­green deployment method could be

implemented with ease by utilizing deployment slots in the Azure App service. The

blue­green 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 blue­green 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 blue­green 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 Infrastructure­as­Code”. In: 2017 IEEE/ACM 39th

International Conference on Software Engineering Companion (ICSE­C).

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 Decision­Making in Microservices Migrations.

2021. arXiv: 2104.00390 [cs.SE].

[7] Balalaie, A., Heydarnoori, A., and Jamshidi, P. “Microservices Architecture

Enables DevOps:Migration to a Cloud­Native 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: 0164­1212. 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ópez­Fernández, Daniel, Pérez, Jorge, and González­Prieto,

Á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: 978­3­319­67425­

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, 22­25 July. CSREA Press USA. 2013, pp. 67–73.

[19] Jaspan, C., Jorde, M., Knight, A., Sadowski, C., Smith, E., Winter, C., and

Murphy­Hill, 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 (ICSE­SEIP).

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, Willem­Jan.

“The pains and gains of microservices: A Systematic grey literature review”. In:

Journal of Systems and Software 146 (2018), pp. 215–232. ISSN: 0164­1212.

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, Tomala­Reyes, Angel E., Singh, Manu,

and Ramnath, Anirudh. “Service Discovery Based Blue­Green 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