Linköping University | Department of Computer and Information Science
Master thesis, 30 ECTS | Datateknik
2021 | LIU-IDA/LITH-EX-A--21/015--SE
Framework to set up a generic
environment for applications
Ramverk för uppsättning av generisk miljö för applikationer
Ruben Das
Supervisor : Anders Fröberg Examiner : Erik Berglund
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Abstract
Infrastructure is a common word used to express the basic equipment and structures that are needed e.g. for a country or organisation to function properly. The same concept applies in the field of computer science, without infrastructure one would have problems operating software at scale. Provisioning and maintaining infrastructure through manual labour is a common occurrence in the "iron age" of IT. As the world is progressing towards the "cloud age" of IT, systems are decoupled from physical hardware enabling anyone who is software savvy to automate
provisioning and maintenance of infrastructure. This study aims to determine how a generic environment can be created for applications that can run on Unix platforms and how that underlying infrastructure can be provisioned effectively. The results show that by utilising OS-level virtualisation, also known as "containers", one can deploy and serve any application that can use the Linux kernel in the sense that is needed. To further support realising the generic environment, hardware virtualisation was applied to provide the infrastructure needed to be able to use containers. This was done by provisioning a set of virtual machines on different cloud providers with a lightweight operating system that could support the container runtime needed. To manage these containers at scale a container orchestration tool was installed onto the cluster of virtual machines. To provision the said environment in an effective manner, the principles of infrastructure as code (IaC) were used to create a "blueprint" of the infrastructure that was desired. By using the metric mean time to environment (MTTE) it was noted that a cluster of virtual machines with a container orchestration tool installed onto it could be provisioned under 10 minutes for four different cloud providers.
Acknowledgments
I would like to thank Erik Berglund and Anders Fröberg for helping me finish this thesis work. I especially want to thank Johan Burell who introduced me to the world of infrastructure within the field of computer science.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables viii
List of Code ix Glossary x 1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 2 1.3 Research questions . . . 2 1.4 Delimitations . . . 2 2 Theory 3 2.1 Continuous Practices and DevOps . . . 3
2.2 Cloud computing . . . 5
2.3 Software architecture patterns . . . 6
2.4 Virtualisation . . . 8 2.5 Orchestration . . . 11 2.6 Deployment environments . . . 14 2.7 Server provisioning . . . 15 2.8 Infrastructure . . . 15 3 Method 18 3.1 Pre-study . . . 18 3.2 Implementation . . . 18 3.3 Evaluation . . . 19 4 Results 21 4.1 Pre-study . . . 21 4.2 Implementation . . . 23 4.3 Evaluation . . . 26 5 Discussion 27 5.1 Results . . . 27
6 Conclusion 31
List of Figures
2.1 The core of DevOps . . . 4
2.2 Monolith . . . 6
2.3 Microservices . . . 7
2.4 Virtual Machines . . . 8
2.5 Containers . . . 9
2.6 Kubernetes market dominance . . . 12
2.7 Kubernetes node overview . . . 13
2.8 Deployment environments . . . 14
4.1 Current process . . . 22
4.2 Desired process . . . 23
4.3 Structure of the entity (node) . . . 24
List of Tables
List of Code
2.1 Kubernetes deployment example . . . 14 2.2 Terraform example . . . 17
Glossary
API application programming interface. 7, 10, 11, 19, 30
AWS Amazon web services. 10
CD continuous delivery. 4, 7, 15, 16
CI continuous integration. 3, 4, 14, 16, 28
CNCF Cloud Native Computing Foundation. 12
CPU central processing unit. xi, 8, 9
FOSS free open-source software. 2
GCP Google cloud platform. 10
gRPC gRPC remote procedure call. 7
HCL HashiCorp configuration language. 16, 29
horizontal scaling means that you scale by adding more machines into your pool of re-sources. 9
HTTP hypertext transfer protocol. 7
I/O input/output. 8, 9
IaaS Infrastructure as a Service. 5, 19, 20, 23, 24, 26
IaC infrastructure as code. iii, 1, 16, 19, 26, 28–32
IDE integrated development environment. 6, 14
IIS internet information services. 16
IP internet protocol. 10
IT information technology. 1, 16, 18, 27, 28, 30
k8s Kubernetes. 11
LXC Linux containers. 10
MTBF mean time between failures. 17
MTTE mean time to environment. iii, viii, 2, 17–20, 26, 28, 30–32
NIST National Institute of Standards and Technology. 5
OS operating system. iii, 8–11, 15, 18, 19, 23, 28–31
PaaS Platform as a Service. 5
provisioning is the process of making an element, such as a server. 1, 2, 9, 10, 15, 16, 18
public cloud is a term for cloud computing services offered over the public internet and available to everyone who wants to purchase them. 10
RAM random access memory. xi
REST representational state transfer. 7
SaaS Software as a Service. 5
SOA service-oriented architecture. 7
SRE site reliability engineer. 1, 30
sysadmin system administrator. 1, 30
TLS transport layer security. 24
UI user interface. 6
VCS version control systems. 16
vertical scaling means that you scale by adding more power such as CPU, RAM to an exist-ing machine. 9
VM virtual machine. iii, 8–11, 18, 19, 21–23, 26, 28–31
1
Introduction
Infrastructure is a common word used to express the basic equipment and structures that are needed for e.g. a country or organisation to function properly. The same concept applies in the field of computer science, without infrastructure one would have problems operating software at scale.
System administrators (sysadmins) or site reliability engineers (SREs) all over the world are responsible for infrastructure which requires certain up-time, performance, resources and security. Having to ensure all of the mentioned attributes exist in a hosting environment for a certain application is a common task for a sysadmin or SRE. A tedious task that is often done through manual labour. [21]
Provisioning and maintaining infrastructure through manual labour is a common occur-rence in the "iron age" of IT. An age requiring humans to allocate their time to pointing and clicking to create necessary environments. As the world is progressing towards the "cloud age" of IT, systems are decoupled from physical hardware, enabling sysadmins or anyone software savvy to automate provisioning and maintenance of infrastructure. [21]
In this paper, it is shown that by entering the "cloud age" of IT, using modern virtual-ization techniques and infrastructure as code (IaC), among other factors, one can simplify provisioning and maintaining infrastructure.
The remainder of this paper is structured as follows. In section 2 theory is presented to get acquainted with terms and technologies used when entering the "cloud age" of IT. This is then followed by section 3 where the method of this paper is conducted. In later stages results in section 4 are presented with regards to the research questions declared in section 1.3. The paper is then concluded by discussing these results and a conclusion presented.
1.1
Motivation
This project was done in collaboration with an IT-consulting firm based in Stockholm, where web development is the main area of expertise. The project does not focus on creating web applications, but rather on the hosting part of applications to make it easier for the firm to provision and maintain infrastructure. During the rest of this report, the IT-consulting firm will be referred to as the company.
1.2. Aim
1.2
Aim
The main goal of this project is to investigate and evaluate solutions to simplify the process of provisioning and maintaining servers. The expected output of this project is a framework that allows provisioning and maintaining infrastructure.
1.3
Research questions
The main research question for this thesis is;
• How does the implementation of a generic environment affect the mean time to envi-ronment (MTTE)?
In order to answer that, we also need to answer;
˝ How can an environment be realised in order for it to be generic?
˝ How can a generic environment be realised so that an effective provisioning pro-cess of infrastructure is achieved?
1.4
Delimitations
This thesis is limited to only focus on providing infrastructure for applications that can be run in a Unix environment. Therefore, serving Windows services such as .NET Framework is not intended to be supported, however, a Windows service such as .NET Core that can run in a Unix environment due to its runtime enabling cross-platform development and deployment will be considered to be supported.
Software used when constructing the infrastructure is only allowed to use free open-source software (FOSS). Meaning the software being used should classify as both free soft-ware and open-source softsoft-ware. This enables anyone to use, copy, study and change the software in any way they want.
Due to limited local hardware resources, providing infrastructure onto bare metal will not be prioritised over cloud solutions.
Worth noting is that this thesis was conducted in the beginning of 2018. Techniques and tools used might have been deprecated, replaced or better alternatives have emerged. There is a lot of progress within this field and that should be taken into consideration when reading this thesis.
2
Theory
2.1
Continuous Practices and DevOps
DevOps is a phrase that during recent years has risen to become a trend among IT practi-tioners all over the world and attracted significant attention from researchers since 2014. The product of merging the words "development" and "operations" brought the world a phrase that is notorious for its ambiguity, lack of established definitions and a large overlap with continuous practices exists according to Ståhl et al. [29]
In "Continuous Practices and DevOps: Beyond the Buzz, What Does It All Mean?" written by Ståhl et al. a set of definitions is proposed to disentangle DevOps and continuous practices from one another. By doing this we can agree on the meaning of buzzwords that often are tossed around in the software engineering community and ultimately making sure the words do not lose their meaning. These definitions are presented in this section. [29]
Continuous integration
Continuous integration (CI) is a software developer practice where developers of a team in-tegrate their work frequently, usually, each developer in a team inin-tegrates their work at least daily, resulting in multiple integrations per day. The integration is preferably verified by an automated build to detect integration errors as soon as possible. By doing this teams have reported that this leads to significantly reduced integration problems, which in return allows a team to develop software more rapidly. [13]
The mentioned practice is a developer practice and not a development practice, meaning that it is ultimately about developer behaviour. Even if a fancy automated software pipeline is provided, it does not guarantee that developers actually integrate their work according to the principles of continuous integration, it is up to the developers to do so. However, a provided automated software pipeline could encourage developers to follow the practice. [29]
Some of the most popular software used in CI pipelines are Jenkins1(open-source written in Java), TeamCity2(commercial software from JetBrains) and TravisCI3 (free for all open-source projects hosted on GitHub).
1https://jenkins.io/
2https://www.jetbrains.com/teamcity/ 3https://travis-ci.org/
2.1. Continuous Practices and DevOps
Continuous delivery
Unlike CI, continuous delivery (CD) is a development practice [29]. A practice that treats every change as a potential release candidate to be frequently and rapidly evaluated through one’s pipeline as expressed by Humble and Farley. Also, that one is always able to deploy and/or release the latest working version if desired. [14]
Continuous deployment
Continuous deployment is the next step after CD and is a so-called operations practice, it is not the same thing as continuous delivery even though many use the terms interchange-ably. This practice encourages that release candidates evaluated in continuous delivery are frequently and rapidly placed into a production environment. [29]
DevOps
DevOps is a harder concept to define unlike the other practices mentioned in this section. It is a concept that often is referred to as a culture or mindset, but also about tooling, processes and concrete practices. Basically, DevOps is a combination of values, principles, methods, practices and tools as shown in figure 2.1. [29]
Figure 2.1: The core of DevOps [29]
One does not adopt DevOps just by adopting continuous integration, continuous deliv-ery, continuous deployment or using some modern automation tool. It requires teams to embrace all the elements seen in figure 2.1, but using continuous practices and automation tools is at least a healthy foundation, to begin with.
2.2. Cloud computing
2.2
Cloud computing
Another buzzword that is commonly used in the distributed computing community is "cloud computing". The NIST’s definition of cloud computing defines it as such [20]:
"Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, stor-age, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three
ser-vice models, and four deployment models."
Where the three service models Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) often are mentioned in the software engineering commu-nity. These models are defined as such according to the National Institute of Standards and Technology (NIST) [20]:
"Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings."
In general SaaS’s are applications shared between end users. A common example of SaaS is Microsoft Office 3654. [8, 21]
"Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The con-sumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations."
A more brief explanation of PaaS is that it is a shared platform for application developers to build, test and host their software. Popular PaaS providers are Heroku5and Salesforce6. [8, 21]
"Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing re-sources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not man-age or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select net-working components (e.g., host firewalls)."
Simplified, IaaS is shared hardware infrastructure that system administrators can use to build virtual infrastructure for services. Amazon EC27, Google Compute Engine8and Digi-talOcean9are examples of a such service. [8, 21]
4https://www.office.com/ 5https://www.heroku.com/ 6https://www.salesforce.com/ 7https://aws.amazon.com/ec2/ 8https://cloud.google.com/compute/ 9https://www.digitalocean.com/
2.3. Software architecture patterns
2.3
Software architecture patterns
Architecture patterns help developers to define the basic characteristics and behaviours of an application by using a general, reusable solution that has been applied to common problems regarding software architecture in the past. [24]
Two of the most commonly used architecture patterns used today are the monolith and microservices architecture pattern.
Monolithic architecture pattern
The traditional approach of building an application is usually done by developers coding on a single code base, resulting in the application being built as a single unit. By building an application as a single unit one follows the monolithic architecture pattern. Monolithic in this sense means composed all in one piece. [12, 21]
Applications are often built into three primary parts; a client-side user interface (UI), a server-side application and a database interface as seen in figure 2.2. The server-side appli-cation usually handles business logic and is a monolith, where every change to the system involves rebuilding and deploying a new version of it. When developers want to add or change a service into this monolith they must guarantee that all other services continue func-tioning as intended. [11, 32]
Figure 2.2: Monolith
Following the monolithic architecture pattern is a natural approach due to current devel-opment tools and IDEs are mainly built for monolithic applications. They are also easy to deploy, one does only need to deploy a single unit and they are also simple to scale as you can instantiate multiple copies of this single unit behind a load balancer. [26]
With that said, monolithic applications can be successful, but eventually they can get very complex. As more services are added to the monolith the complexity grows, making it hard to keep a good modular structure which eventually leads to a tightly coupled system. A system that is so large that it might intimidate developers new to the project. Scaling is possible as mentioned earlier, but scaling a monolith requires scaling the entire application rather than parts of it which ultimately allocates more resources than what might be needed. [11, 26]
2.3. Software architecture patterns
A lot of notable companies such as Netflix10, Amazon11 and eBay12 have founded their platforms using the monolith pattern. [11, 21]
Microservice architecture pattern
An architecture pattern that has been mentioned quite a lot during the last few years in the software engineering community is the microservice architecture pattern. Some people would call this pattern a specialisation of service-oriented architecture (SOA), which is a pat-tern that uses services as building blocks for building distributed applications, which is a debate for another time. [11, 24, 25]
This architectural style guides developers to build applications as suites of services. Ser-vices are independently deployable, scalable and each of them provides a firm module boundary. This module boundary enables developers to use different programming lan-guages for different services and the possibility to assign a team to one or more service. It also enables the use of decentralised data management, meaning every service has a different data storage endpoint, as illustrated in figure 2.3. By doing this, every service is responsible for its own data and its own persistence. [11, 25]
Figure 2.3: Microservices
By building applications as suites of services one implies to develop a single application as a suite of small services, where each service is running its own process and communicates with other services through some transport layer, usually through a HTTP resource API such as REST that depends on HTTP/1.1. Faster transport layers are however becoming more popular such as gRPC13that uses HTTP/2 for transport.
A service typically implements a set of distinct features or functionality, such as customer management. Determining how big a microservice is meant to be is hard. Amazon has a notation that the team maintaining the service should be able to be fed by two pizzas, that is the optimal size for a microservice. However, two pizzas in Sweden would feed 2 to 3 people at most, so the metric is probably best used for teams in America. [21]
There are several benefits of adopting the microservice architecture pattern, it enables continuous delivery and continuous deployment for large complex applications. The smaller the service, the easier and faster it is to test. Also, it enables developers to quickly understand
10https://www.netflix.com/ 11https://www.amazon.com/ 12https://www.ebay.com/ 13https://grpc.io/
2.4. Virtualisation
what a service does if it is small. However, there are some downsides as well; deploying microservices is not the most trivial thing to do and the complexity of creating or working with a distributed system can be hard to grasp for a developer. [25]
To benefit from the microservice pattern, one should be able to rapidly provision machines and deploy application whilst monitoring the microservices in a basic way to see if everything is running as intended. [11]
2.4
Virtualisation
Virtualisation is a technology used to allow one to create multiple simulated environments or dedicated resources from a single, physical hardware system [34]. The technology is widely used in data centers and cloud environments to decouple applications from the hardware they are running on. Common types of virtualisation consist of hardware and operating system level (OS-level) virtualisation. [28]
Hardware-level virtualisation involves running a hypervisor that virtualises a machines resources across multiple virtual machines, where each hardware virtual machine (VM) runs its own operating system and applications. OS-level virtualisation on the other hand virtu-alises resources at the OS-level, by encapsulating standard OS processes and their dependen-cies to create "containers" that are managed by the underlying OS kernel. [28]
Hardware virtualisation
Hardware virtualisation concerns virtualising the hardware on a server and creating virtual machines that provide the abstraction of a physical machine. To be able to utilise hardware virtualisation one needs a hypervisor, also known as a virtual machine monitor (VMM). The hypervisors purpose is to emulate virtual hardware such as the CPU, memory, I/O and net-work devices for each virtual machine. Each VM then runs an independent operating system and applications on top of that OS. An illustration of how hardware virtualisation is realised is shown in figure 2.4. [28]
2.4. Virtualisation
Since VMs allocate their virtual hardware before boot-up, their resource limits are gener-ally hard. This means that the VM cannot utilise resources beyond its allocation, even if those resources are unused on the host. Vertical scaling is possible, but not a common practice due to the lack of support. However, horizontal scaling is a common practice when using VMs, due to the ease of provisioning new VMs in a matter of tens of seconds. [28]
Commonly used virtualisation platforms include VMWare ESXi14, Linux KVM15 and Xen16. One should note that some virtualisation packages can be installed and run on top of another operating system, such as VirtualBox17which is intended to run on desktops. [21]
OS-level virtualisation
Instead of virtualising the physical hardware as shown in figure 2.4, operating system level virtualisation virtualises the OS kernel as presented in figure 2.5. These types of virtual ma-chines are referred to as containers and each container encapsulates a group of processes that are isolated from other containers or processes in the system. The container abstraction is made by the OS kernel which allocates CPU shares, memory and network I/O to each con-tainer and also provides a file system isolation. Concon-tainers provide lightweight virtualisation since they do not run their own OS kernels, instead, they rely on the underlying kernel for OS services. By sharing the underlying kernel one lacks complete isolation from neighbouring containers. [28]
Unlike VMs, containers allocate resources according to soft limits, which implies that ap-plications inside containers can use resources beyond their allocated limit if those resources are under-utilised. Due to the nature of containers resource allocation strategy, they are more efficient when it comes to resource utilisation. [28]
By combining lightweight hardware virtualisation and direct host file system access en-ables new ways of combining hardware and operating system virtualisation.
A similar aspect between containers and VMs is that they are both easily scaled horizon-tally, containers are in fact faster to create multiple instances of as starting one barely requires a second. Worth noting is that scaling containers horizontally is easier to do if the container is isolated to a single function. [1]
Figure 2.5: Containers [28] 14https://www.vmware.com/products/esxi-and-esx.html 15https://www.linux-kvm.org/
16https://www.xenproject.org/ 17https://www.virtualbox.org/
2.4. Virtualisation
Popular OS virtualisation techniques exists, such as Solaris Zones18, BSD-jails19and Linux containers (LXC)20. During recent years new OS virtualisation techniques have emerged such as Docker21and rkt22. [28]
Linux containers in particular utilise two key features [28]:
• Cgroups, abbreviated for control groups are kernel mechanisms for controlling the re-source allocation to process groups.
• Namespaces is a feature of the Linux kernel that provides an abstraction for a kernel re-source that makes it appear to the container that it has its own private, isolated instance of the resource.
LXC was the first widely used container technique, it uses kernel namespaces to pro-vide resource isolation. Docker is an extension of that container technique which propro-vides a kernel- and application-level API that together run processes in isolation. In 2014 Docker dropped LXC as its default execution environment and replaced it with their own Go writ-ten library called libcontainer23. Docker also uses namespaces to completely isolate an ap-plication’s view of the underlying operating system, including process trees, network, user identifiers and file systems. [2, 16]
Docker is mainly composed of three different components; the Docker daemon, the Docker client and the Docker registry. Whereas the Docker daemon listens for Docker API requests and manages Docker objects such as images, container, networks and volumes. To communicate with the Docker daemon users write commands towards the Docker client, which is the primary interface of the system. A Docker registry is an archive of container images, i.e. a place to store images. [9, 30]
A majority of developers embrace the technology Docker has to offer due to it enabling them to easily pack, ship and run applications as lightweight portable containers that can run virtually anywhere. Docker containers are created using base images, an image can include just the OS fundamentals or consist of a prebuilt application stack. [2]
The process of creating a container starts with the Docker client telling the Docker daemon to run a container, which will check the presence of the required image, if the image is not found locally it will download it from a specific registry if available. When the image is acquired, Docker will create a container, allocate a file system and mount a read-write layer. Finally, a network interface is created to interact with the local host and assigns an available IP address. When the environment is ready Docker can run the application alongside logging inputs, output and errors. [30]
Containers inside VMs
Containers inside VMs means that each container is encapsulated in a VM and applications run inside the container. Multiple containers can be encapsulated inside a VM if necessary. By doing this one can benefit from applications relying on the security and performance isolation provided by the VM, but still, be able to take advantage of the provisioning and deployment aspects of containers. [28]
The concept of containers inside VMs is a popular approach used when running contain-ers in public clouds such as Amazon web services24, Google cloud platform25 and Azure26 where isolation along with security are important concerns. [28]
18https://docs.oracle.com/cd/E18440_01/doc.111/e18415/chapter_zones.htm 19https://www.freebsd.org/doc/handbook/jails.html 20https://linuxcontainers.org/ 21https://www.docker.com/ 22https://coreos.com/rkt/ 23https://github.com/opencontainers/runc/tree/master/libcontainer
2.5. Orchestration
Sharma et al. has conducted a comparative case study about containers and virtual ma-chines, where they found surprising benefits of using nested containers in VMs. Since only containers from a single user may be allowed to run in a VM, neighbouring containers within a VM can now be trusted. Besides improving security with the use of nested containers inside VMs one does also improve performance compared to solely running applications inside a VM due to the benefits of using soft resource limits that containers provide. [28]
Combining virtual machines and containers thus seems to be a good fit, the VM pro-vides the isolation and deployment benefits, which means that a full-blown OS is not needed when combining these two virtualising techniques, as only the isolation and the deployment aspects are essential. In other words combining a lightweight VM with containers would be optimal, since lightweight VMs reduces virtual machine overhead and footprint. [28] CoreOS Container Linux is an example of such a lightweight OS, advertised as an open-source lightweight Linux operating system designed for cluster deployments, providing au-tomation, security and scalability with support for container engines Docker and rkt out of the box that is automatically updated alongside the operating system. [7]
2.5
Orchestration
As containers are recommended to be isolated to a single function, an application can consist of multiple containers to be realised. Managing all these containers can be troublesome and therefore some kind of orchestration is needed. Orchestration means to arrange or manipu-late, especially by means of clever or thorough planning or manoeuvring [22].
Container orchestration allows us to define how to select, to deploy, to monitor and dy-namically control the configuration of multi-container packaged applications. Common con-tainer orchestration tools are Cloudify27, Kubernetes28and Docker Swarm29. [5]
Typical container orchestration tools have the following components as described by Claus Paul [23]:
• The deployment of distributed applications through containers is supported using a virtual scalable service node (cluster) with high internal complexity (supporting scaling, load balancing, failover) and reduced external complexity.
• An API allows operating clusters from the creation of services and container sets to other life-cycle functions.
• A platform service manager looks after the software packaging and management. • An agent manages the containers life cycles (at each host).
• A cluster head node service is the controller that receives commands from the outside and relays them to containers hosts.
Kubernetes
As mentioned Kubernetes, also called k8s for short (due to the eight characters between the k and the s), is a common container orchestration tool that embraces the components just described and has during recent time risen to become the de-facto standard for container orchestration as one can see in figure 2.6, just as Docker is considered the standard for con-tainers.
27https://cloudify.co/ 28https://kubernetes.io/
2.5. Orchestration
Figure 2.6: Kubernetes market dominance [19]
Kubernetes was open-sourced by Google in 2014, later donated to the Cloud Native Com-puting Foundation (CNCF) and builds upon a decade and a half of experience that Google has with managing Linux containers at scale. This is the third container-management sys-tem built by Google followed by Borg and Omega, it was conceived of and developed in a world where developers not affiliated with Google was starting to get interested in Linux containers. Therefore Kubernetes was developed with a strong focus on the experience of de-velopers writing applications that run in a cluster as its main goal to make it easy to deploy and manage complex distributed systems, while still benefiting from the improved utilisation that containers enable. [4]
Kubernetes advertises itself as a container platform, a microservices platform, a portable cloud platform and a lot more. It orchestrates computing, networking and storage infrastruc-ture on behalf of users workloads. [33] At its most basic level, Kubernetes is a system for running and coordinating containerised applications across a cluster of machines. It is a plat-form designed to completely manage the life cycle of containerised applications and services. [10]
The main components that Kubernetes consists of is a set of worker machines called nodes. A node typically looks as illustrated in figure 2.7, containing a containerised applica-tion that is meant to run encapsulated inside a pod. A pod is as quoted "the smallest deployable units of computing that you can create and manage in Kubernetes". To make sure that containers are running in a pod a kubelet is needed, it basically is an agent that runs on each node in the cluster. Alongside the kubelet, another node process is needed to actually be able to run containerised applications which is a container runtime. In figure 2.7 Docker is used as the container runtime for this node. Besides the nodes, another core component of Kubernetes is the control plane. The control plane manages the worker nodes and the pods in the cluster. [17]
2.5. Orchestration
Figure 2.7: Kubernetes node overview [31]
In listing 2.1 a Kubernetes deployment is shown, "a deployment provides declarative updates for pods". In its essence, a Kubernetes deployment declares the desired state one wants for their deployment. When the following listing is applied towards a Kubernetes cluster it will start up two pods (as noted by the replicas) with the containerised application "mywebapp" that is fetched from any given container registry. [18]
2.6. Deployment environments a p i V e r s i o n : apps/v1 kind : Deployment metadata : name : mywebapp l a b e l s : app : mywebapp spec : r e p l i c a s : 2 s e l e c t o r : matchLabels : app : mywebapp t e m p l a t e : metadata : l a b e l s : app : mywebapp spec : c o n t a i n e r s : ´ name : mywebapp image : g c r . i o / m y c o n t a i n e r r e g i s t r y /mywebapp : l a t e s t p o r t s : ´ c o n t a i n e r P o r t : 80
Listing 2.1: Kubernetes deployment example
2.6
Deployment environments
An environment is a computer system in which an application is deployed and executed on, an example of an environment is a server. Industrial practices often adopt the usage of four different environments; development, testing, staging and production as seen in figure 2.8. This type of release management process allows phased deployment, testing and rollback in case of problems. [6]
Figure 2.8: Deployment environments
The most common environment used is the development environment or local environ-ment, where changes to the software are developed with the help of IDEs and compilers. A development environment usually consists of individual developers’ workstation, such as a laptop. It should be noted that the application being developed might not be meant for usage on a computer, it could be targeted for a smartphone or an embedded system. [6]
Next in line is the testing environment, allowing testers to exercise new and changed code, usually through exploratory testing or as automated unit tests are commonly done before deployment to the environment through CI tools. [6]
The staging environment, also sometimes called preprod, is the last stage before making the code available in production and is where all release candidates are handled. This envi-ronment should mirror the actual production envienvi-ronment as closely as possible and the final testing should be done here. A common convention is to discard the testing environment and
2.7. Server provisioning
Finally, the code is released to the production environment, which is the most sensitive step. The currently released version of the application resides here. [6] Depending on the operations practice the developers follow, one does either release the latest version to the production environment manually or it does automatically by using a continuous delivery flow as mentioned in section 2.1.
2.7
Server provisioning
Provisioning is the process of making an element, such as a server. There is however more to infrastructure than making an element such as a server, it needs to be created, configured and changed. These tasks allocate the time and energy when provisioning machines. [21]
According to Kieff Morris, an effective provisioning process based on infrastructure as code has the following characteristics [21]:
• Any existing infrastructure element can be effortlessly rebuilt on demand.
• A new element can be defined once and then rolled out and replicated to multiple in-stances and environments.
• The definition of any element and the process to provision it, is transparent and easily modified.
Typical provisioning tasks for a server include allocating hardware, creating the server instance, partitioning disks, installing an operating system, installing software, configuring the server and setting up networking. [21]
Randy Bias is a so-called outspoken cloud expert that coined the phrase "Pets vs Cattle", where he illustrated servers in form of pets and cattle as such [3]:
”In the old way of doing things, we treat our server like pets, for example, Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot and replaced on the line.”
Pets in this case are servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed and "hand-fed" as Randy Bias would express it. He expresses the cattle as arrays of more than two servers that are built using automated tools and designed for failure, where every server is replaceable. [3]
The gist of what he is trying to say is, do not treat servers as pets. For every "hand-fed" server we create a server that is different from any other server. It is special in ways that can not be replicated. These type of servers are also commonly known as "snowflakes" as every snowflake is unique. Instead one should treat their servers as cattle, disposable and easy to replicate or scale with automated tools. Worth mentioning are phoenix servers that are similar to cattle, they are servers that always are built from scratch. [21]
2.8
Infrastructure
Infrastructure within the field of software engineering usually follows two states; mutable and immutable. Whereas the first state is mostly used in traditional infrastructure where servers are continually updated and modified in place. These servers are treated as pets, causing snowflake servers that can not be replicated. With that said, common issues mutable infrastructure suffers from are [21]:
2.8. Infrastructure
• Server sprawl, when servers are growing faster than the ability of the team to manage them in an optimal way.
• Configuration drift, when servers that should be the same become different over time. E.g. people configuring IIS differently on different web servers.
• Erosion, when problems creep into a running system over time, e.g. a server’s disk filling up with log files.
Immutable infrastructures, on the other hand, lends ideas from the phoenix concept cov-ered in section 2.7, servers are never modified after they are provisioned. If something needs to be updated, fixed or modified in any way, new servers are provisioned. By having an im-mutable infrastructure one can eliminate most of the problems one would have when using a mutable infrastructure as one would benefit from reliability and consistency. [21]
Infrastructure as code
Infrastructure as code (IaC), or programmable infrastructure is an approach to manage con-figurations and automate the provisioning of infrastructure by writing code in a high-level language. The idea is to use practices from software development to treat systems and de-vices that are used to run software can themselves be treated as software. The key benefits of using IaC is that one obtains consistent, repeatable routines for provisioning and changing systems and their configuration. As one applies provisioning code a system is produced into the same desired state irrespective of previous configurations on the same components, by doing this we can achieve idempotence, meaning we can apply something multiple times and always get the same result. [15, 21, 27]
By using a tool e.g. Terraform30to treat infrastructure as software and data, developers can use techniques they have used for other software. Techniques such as version control systems (VCS), automated testing libraries and deployment tools. It also enables the usage of development practices such as continuous integration and continuous delivery. [21]
Kieff Morris describes the main goals of using infrastructure as code that many teams and organisations looking to achieve are [21]:
• IT infrastructure supports and enables change, rather than being an obstacle or a con-straint.
• Changes to the system are routine, without drama or stress for users or IT staff. • IT staff spends their time on valuable things that engage their abilities, not on routine,
repetitive tasks.
• Users are able to define, provision and manage the resources they need, without need-ing IT staff to do it for them.
• Teams are able to easily and quickly recover from failures, rather than assuming failure can be completely prevented.
An example of using Terraform with the HashiCorp configuration language (HCL) syntax can be seen in listing 2.2. In this example Terraform is used to provision a VM running CoreOS as its operating system in a specific region alongside a configuration. DigitalOcean is used as the cloud provider of choice in this example.
2.8. Infrastructure s o u r c e " d i g i t a l o c e a n _ s s h _ k e y " " d e f a u l t " { name = " t f ´key " p u b l i c _ k e y = " $ { f i l e ( " $ { var . p u b l i c _ k e y } " ) } " } p r o v i d e r " d i g i t a l o c e a n " { token = " $ { var . do_token } " }
r e s o u r c e " d i g i t a l o c e a n _ d r o p l e t " " c o r e o s " { count = " $ { var . c l u s t e r _ s i z e } "
name = " $ { var . name}´ coreos ´$ { count . index } " image = " coreos ´s t a b l e " r e g i o n = " $ { var . r e g i o n } " s i z e = " $ { var . s i z e } " ssh_keys = [ " $ { d i g i t a l o c e a n _ s s h _ k e y . d e f a u l t . f i n g e r p r i n t } " ] u s e r _ d a t a = " $ { f i l e ( " c o n t a i n e r _ l i n u x . conf " ) } " }
Listing 2.2: Terraform example
Infrastructure metrics
Kieff Morris expresses that teams should choose measurements that are useful to them, based on their goals and situation. Some common metrics used when measuring infrastructure are [21]:
• Cycle time, the time taken from a need being identified to fulfilling it.
• Mean time to recover (MTTR), the time taken from an availability problem being iden-tified to a resolution, even where it’s a workaround.
• Mean time between failures (MTBF), the time between critical availability issues. • Availability, the percentage of time that the system is available, excluding the time of
the system is offline for planned maintenance.
• True availability, the percentage of time the system is available, not excluding planned maintenance.
As one can notice, time is of significance in the metrics mentioned by Morris. Mean time
to environment (MTTE)is a common metric organisations use when measuring infrastruc-ture, this metric expresses the time taken to provision an environment suitable for the appli-cation it is supposed to host.
3
Method
This chapter is divided into three sections; pre-study, implementation and evaluation. In section 3.1 the method to understand the perceived problems with provisioning and main-taining servers at the company is presented. The second section 3.2, presents how the generic environment was constructed. Finally, the third section, 3.3 covers the evaluation of the pro-visioning process and the use of mean time to environment.
3.1
Pre-study
During a set of meetings in the beginning of 2018 initial discussions were made with a se-nior developer and the IT staff at the company regarding the process of provisioning and maintaining servers for different projects that the company are responsible for. The main ob-jective of this set of meetings was to understand how the company provisions and maintains servers today and determine how the company as an organisation could improve their way of provisioning and maintaining servers. The desired outcome of this set of meetings was to pin down a desired a workflow that mitigated a majority of the issues raised by the different stakeholders.
3.2
Implementation
To provide an environment where any application can live, hence an generic environment, usage of OS-level virtualisation is needed, also known as "containers" as seen in section 2.4. By using containers one can run any application that can manipulate the Linux kernel and in this thesis, the scope is defined to only pay regard to such software. Thus, a container runtime is needed to realise the environment. Docker was the chosen container runtime due to the fact it is the most widely supported container technology and is heavily adopted by the software engineering community. To be able to run and orchestrate these containers at scale a container orchestration tool was required and Kubernetes was chosen due to its market dominance and high adoption rate as covered in section 2.5. Running these core components (Docker and Kubernetes) requires support from the underlying infrastructure. By using the
3.3. Evaluation
not coupling the environment to one IaaS. The operating system (OS) used on these VMs was CoreOS Container Linux to reap the benefits of utilising a lightweight VM to minimise overhead and footprint as covered in section 2.4, also it supports Docker out of the box. As all of the needed components were in place, Bootkube was used to render all of the assets necessary for bootstrapping the Kubernetes cluster, establishing a set of Kubernetes nodes as shown in figure 2.7. The total number of nodes provisioned during the implementation consisted of 3 virtual machines, where one node acted as the controller node and the rest as worker nodes.
In order to provision the above mentioned environment so that an effective provision-ing process of infrastructure is achieved, the principles of infrastructure as code (IaC) as de-scribed in section 2.8 was used. To provision the said environment, Terraform was used to create a "blueprint" of the infrastructure wanted. The "blueprint" in this case essentially con-tains the amount of virtual machines we want to instantiate with a certain operating system (OS) and configuration, the operating system in this "blueprint" is CoreOS Container Linux as mentioned previously. Next the "blueprint" is applied and the virtual machines are pro-visioned, when successfully provisioned the "blueprint" created with Terraform continues to make these virtual machines to proper Kubernetes nodes by utilising Bootkube, essentially issuing a kubelet to each one of them. In this implementation, each cloud provider that was tested had its own set of Terraform configuration files, as each cloud provider has different naming conventions for their resources as well as certain quirks, they also expose different APIs. All Terraform configuration files were versioned controlled via Git1and GitHub2was used as the hosting service to manage the Git repository.
The cloud providers where this infrastructure was provisioned on was AWS, Azure, Dig-italOcean and Google Cloud as they are the most frequently used ones within the company. As per section 1.4, due to limited local hardware resources, providing infrastructure onto bare metal was not prioritised.
3.3
Evaluation
This section presents how the evaluation of the provisioning process and the use of the metric mean time to environment will be conducted.
Effective provisioning process
To determine if a provisioning process of infrastructure is effective it was noted in section 2.7 that an effective provisioning process has the following characteristics:
• Any existing infrastructure element can be effortlessly rebuilt on demand.
• A new element can be defined once and then rolled out and replicated to multiple in-stances and environments.
• The definition of any element and the process to provision it, is transparent and easily modified.
Mean time to environment
In order to measure the mean time to environment (MTTE) as mentioned in section 2.8, the following formula will be used. Where n represents the number of times an environment for a specific IaaS has been provisioned and t represents the total time accumulated to provision the said environment measured in minutes.
1https://git-scm.com/ 2https://github.com/
3.3. Evaluation
Mean time to environmentiaas =
t1+...+tn n ; n ě 1
To measure the mean time to environment for the environment constructed, as described in section 3.2, the environment was provisioned five times for each IaaS of interest. To mea-sure the time taken to Terraform the environment, time3was used, a simple command that runs the specified program command and returns timing statics about the command it just ran.
When terraforming an environment, the following command was thus executed time terraform apply -auto-approve, which in return provided the elapsed real time between invocation and termination expressed in seconds. The times were converted into rounded minutes and used in the formula as follows.
Mean time to environmentiaas= t1
+t2+t3+t4+t5 5
4
Results
This chapter presents the results of the pre-study, implementation and the evaluation sections with regards to the method chapter 3.
4.1
Pre-study
In the set of meetings as described in section 3.1 the process of how the company provisions and maintains servers today were described and illustrated. After going through the cur-rent process the diffecur-rent stakeholders described what the ideal solution would be according them.
Currently the process of provisioning server(s) - in most cases - starts with an email re-quest from a developer to the IT staff, stating that they need to host their application on some-thing. The IT staff will provide the developer with everything needed when time is available, usually, that consists of the latest Windows Server, a database, a domain and credentials to access that server. Normally a set of servers are provided, such as a test, staging and pro-duction server as mentioned in section 2.6. When the IT staff has provisioned the server(s) for the requesting developer(s), the developer(s) manually install all the necessary software required to run their application on the server by using remote desktop, a typical example would be to install a service such as Redis as a cache solution. Installing this service needs to be completed on all the machines, preferably in the same way to avoid configuration drift as mentioned in section 2.8. The provisioning time for the IT staff as advertised on the company intranet is set to two working days due to their heavy workload. However, it takes roughly five minutes to provision a single server for the IT staff when the request is dealt with. The process of provisioning a server consists of the IT staff manually processing through a set of steps in a program called vSphere (a virtualisation platform utilising VMWare ESXi) and ul-timately a set of VMs are provisioned on their own self-hosted or remote bare metal servers. The process is illustrated in a flow chart in figure 4.1.
4.1. Pre-study
Figure 4.1: Current process
Parts such as relying on the IT staff to provision and manage resources for developer(s) and doing it through manual labour was identified as a flaw. Besides burdening the IT staff, problems such as configuration drift are easily introduced due to installing software man-ually on servers and treating the servers as pets which are prone to erosion as covered in section 2.8. Applications also suffer from poor redundancy and scaling due to it being hosted locally and in a VM as a monolith. The overall process from needing server(s) to deploy the application onto them is tedious, there are too many steps to be dealt with.
As there are many steps involved when setting up an environment, a suggestion was made to explore the possibilities to shorten the number of steps that need to be taken to create an environment suitable for the application it is going to host. A roughly desired workflow is illustrated in figure 4.2, essentially consisting of executing a script that provisions servers
4.2. Implementation
Figure 4.2: Desired process
The intent of the desired workflow as discussed during the meetings is to minimise the efforts that need to be taken to provision a server. By minimising the efforts, the assumption is that developers will be more encouraged to provision their infrastructure on their own. Besides minimising the efforts that need to be taken, the desired workflow could mitigate configuration drift, erosion, redundancy and scaling problems if constructed properly.
4.2
Implementation
The infrastructure constructed is meant to be generic, in the sense that applications should not need to change their internal structure to fit into the environment. To adhere to that, a Kubernetes cluster was provisioned where each node of that cluster was built accordingly to figure 4.3. The first layer consists of the hardware, the hardware specifically used for this implementation was provided by an IaaS. On top of this hardware, the second layer resides and that is the operating system, it runs on the VM with the help of a hypervisor as covered in section 2.4. In this implementation, CoreOS Container Linux was chosen as the operating system. The next layer consists of the node processes, by using CoreOS a container runtime is given out of the box, in this case it is Docker, alongside this container runtime a kubelet is instantiated. The kubelet in return maintains a set of Kubernetes pod(s), which wraps around the Docker container(s). In the final layer and in the core the entity the application lives.
4.2. Implementation
Figure 4.3: Structure of the entity (node)
To provision the said infrastructure, a set of Terraform configuration files were written for each cloud provider that was of interest. In this case four different sets where created, each one for AWS, Azure, DigitalOcean and Google Cloud. When applying the Terraform configuration for a specific IaaS two concurrent actions occurs as illustrated in figure 4.4. One of these actions starts creating the necessary files for the infrastructure, files such as the Container Linux config, the TLS assets, Kubernetes object manifests and a kubeconfig. In parallel with the mentioned action, Terraform provisions a specified number of virtual machines on the chosen IaaS with CoreOS Container Linux running on them. When the creation of the files and machines have been completed, Terraform connects to each machine and copies over all the files, except the Cloud-Config that was created in the initial step. Next Terraform connects to the controller and starts the Bootkube service. Ultimately an infrastructure is provisioned and in our case, it is a fully operational Kubernetes cluster.
4.2. Implementation
4.3. Evaluation
4.3
Evaluation
This section presents the evaluation of the provisioning process and the measurements of the mean time to environment.
Effective provisioning process
From the implementation in section 4.2 it can be noted that to provision the wanted infrastruc-ture, a "blueprint" was constructed accordingly. This "blueprint" is more technically known as the Terraform configuration files with regards to this implementation. By using Terraform the principles of infrastructure as code (IaC) are utilised, as everything with regards to the infrastructure is documented as code and not via manual user interactions.
Any existing infrastructure element within this "blueprint" could be rebuilt on demand effortlessly by applying the Terraform configuration files again. To restart from scratch one could use Terraform to destroy all provisioned elements of the "blueprint" and in later stages apply the configuration files again to rebuild what was destroyed.
Adding additional elements to an already existing infrastructure could be done once and replicated against multiple instances and environments by writing the required specification needed for the element to be provisioned into the Terraform configuration files. When those files are applied, Terraform will compare the current state of the infrastructure with what is desired to be applied. Any diff regarding the state and the "blueprint" will be acknowledged by Terraform. If one element is removed from the specification, Terraform will destroy it and if one element is added to the specification, Terraform will provision it accordingly to what has been specified.
Having the infrastructure documented as code allows for transparent and easily modified infrastructure. In order to change the infrastructure, one would have to edit the "blueprint", in other words, change the code. As Git was used to version control all Terraform configuration files each change was transparent with regards to when it happened and by whom the edit was made by.
Mean time to environment
Looking at table 4.1 one can observe the mean time to environment (MTTE) for the infras-tructure implemented in section 4.2 to be provisioned on four different cloud providers. The four IaaS’s where the infrastructure was provisioned on were; AWS, Azure, DigitalOcean and Google Cloud. The results present how long it takes to provision the said infrastructure as described in section 3.3.
As stated in section 3.2, the cluster consisted of 3 nodes in total, resulting in 3 virtual machines being provisioned each time a cluster was Terraformed. Something to note is that provisioning a cluster with more than 3 nodes would not impact the mean time to environ-ment as all of the machines are provisioned concurrently. With that said, provisioning 3 or 300 virtual machines would not impact the mean time to environment. As compared to manually provisioning a set of servers, where one single machine took about 5 minutes to provision, scaling this to 300 would ultimately take 300 * 5 minutes, which is 25 hours of manual labour for one person.
Table 4.1: Mean time to environment (MTTE)
Cloud provider MTTE
AWS 7 min
Azure 8 min
5
Discussion
In this chapter, the result and method chapters are discussed along with the ethical and soci-etal aspects of this work.
5.1
Results
From the results it can be noted that tooling was built accordingly to what was established during the initial meetings covered in section 4.1. The desired process seen in figure 4.2 was achieved by letting developers provision infrastructure on their own by using Terraform and deploying their applications to the provisioned Kubernetes cluster as they pleased without the involvement of the IT-staff of the company. This was a big milestone for the developers in the sense of owning the whole development flow for their project(s).
However, what was built might not fit everyone’s actual use-case. To utilise the "generic" environment constructed in this implementation developers would have to get acquainted with tools such as Terraform, Docker and Kubernetes to a certain degree. Terraform could be seen as a small hurdle to overcome in the sense of adding another tool to the developer’s knowledge base as a lot of emphases was put into not having to understand the internal workings of it and simply just apply it with given input parameters to provision the infras-tructure wanted. In this case, the infrasinfras-tructure of interest for the developer would be Ku-bernetes itself. To use KuKu-bernetes to its full extent, developers would have to master how to containerise their application(s) with Docker and write Kubernetes objects such as the one in listing 2.1 to deploy and run them. For some developers, this might be an easy ask, whilst for some others, it’s a bigger one.
Besides learning the just mentioned techniques one would have to adapt their way of building their software with regards to architectural patterns such as the ones mentioned in section 2.3, the monolithic and microservice architecture patterns. Theoretically, nothing is stopping a developer to deploy and run their monolith inside Kubernetes as long as it’s containerised. Kubernetes was however mainly built for managing Linux containers with regards to distributed systems as covered in section 2.5. Thus, using microservices instead of monoliths is a more ideal choice when constructing the architecture with regards to the software to reek the benefits of Kubernetes, in other words, the environment provisioned in this implementation. Transitioning from monoliths to microservices is therefore another hurdle some developers will have to face when designing their applications. Migrating an
5.2. Method
existing monolith to a set of microservices might also be a struggle, but as seen in section 2.3 a handful of companies have done the same journey in the past successfully.
Kubernetes is a great microservices platform that simplifies orchestrating containers sig-nificantly. The containers and Kubernetes objects however have to end up in the cluster somehow, preferably in an automated manner. In section 2.1 continuous practices and the term "DevOps" are introduced. For developers to deploy and maintain their applications in an effective manner, they would have to embrace the principles of DevOps as stated in the referenced section. This means that certain tooling and developer behaviour needs to be in place, e.g. a CI pipeline that can build Docker images and apply Kubernetes configurations whenever new work is integrated, also establishing a developer behaviour to integrate their work frequently. Worth mentioning is that tooling is only part of the change that is needed to fully embrace DevOps, mindset and culture has to do so as well according to Ståhl et al.
Ultimately there are a lot of new techniques and mindsets a developer would need to embrace to be able to utilise the environment established in this thesis and one could ask themselves, is it worth all the trouble? In this thesis, the developer experience is not evaluated which in hindsight was a poor decision taken, but also a needed one due to limitations with regards to time. A proper evaluation of the developer experience would require following a team of developers utilising the environment over an extended period of time to see if the issues that were mentioned during the pre-study were mitigated or not and if the developers could learn to use the environment to its full extent.
The results show that by utilising an effective way to provision infrastructure by using the principles of IaC and a tool that supports it the mean time to environment (MTTE) can be lowered significantly compared to what was in place before. From the results, we can see that provisioning the infrastructure wanted took less than 10 minutes and those 10 minutes are purely allocated to waiting. Actual active time in creating the infrastructure would be less than a minute, where that minute would be allocated to run the command and parse through what is going to be provisioned when the command has been executed.
5.2
Method
The method as presented in chapter 5 consists of three parts, a pre-study, an implementation and evaluation. The following paragraphs will discuss these different parts in depth.
The pre-study consisted of a set of meetings where the overall goal was to establish how the company could provision and maintain servers in an efficient manner without burdening the IT-staff with routine repeatable tasks. From a scientific perspective, no specific guidelines on how to conduct a pre-study were followed, the information was simply gathered ad hoc due to limitations of time that could be allocated from each participant. One could state that the meetings did not conduct any specific study to understand in depth what the problem was and how it could be solved, it was simply more of a requirements gathering from certain stakeholders to build a product that could potentially benefit their own and others’ needs.
With regards to the implementation, how one could realise an environment for it to be generic, it was noted that three major components where needed; Docker, Kubernetes and CoreOS. In its essence, those specific components are not required, but the techniques that they adopt are. The techniques in this case are;
• OS-level virtualisation (Docker was used in this implementation). • Container orchestration (Kubernetes was used in this implementation).
