En växande trend inom informationssystem är användningen av mikrotjänster som arkitekturstil för att bygga och underhålla system. Tidigare forskning har visat på fördelar som modularitet, skalbarhet samt möjlighet till snabb driftsättning av kodförändringar. Men tillsammans med välkända fördelar kommer även utmaningar. I den akademiska världen råder en begränsad tillgång till mikrotjänstapplikationer i stor skala, och det är därför intressant att undersöka systemutvecklares perspektiv. Denna studie kompletterar existerande litteratur med erfarenheter och insikter från systemutvecklare som jobbar med utveckling av mikrotjänster. Syftet med denna studie var att undersöka och analysera hur systemutvecklare tillämpar mikrotjänstarkitektur för att utnyttja dess teoretiska fördelar och hantera eventuella utmaningar, samt att identifiera vilka förutsättningar som är nödvändiga för en framgångsrik implementering av mikrotjänstarkitektur. Genom att utföra en kvalitativ intervjustudie med åtta systemutvecklare från sex olika organisationer kartlade vi de mest betydelsefulla fördelarna med mikrotjänster, inklusive tydliga avgränsningar, smidigare versionshantering samt möjlighet till kontinuerlig integration och leverans. Samtidigt identifierade vi även centrala utmaningar såsom tekniskt och operativt arv, organisatorisk tröghet samt komplexitet i hur mikrotjänster sammankopplas. Studiens resultat ledde fram till att en uppsättning framgångsfaktorer för att lyckas med mikrotjänstarkitektur kunde urskiljas. Dessa inkluderade bland andra tydligt ägandeskap, DevOps och centraliserad loggning. / A growing trend in information systems is the use of microservices as an architectural style for building and maintaining systems. Previous research has highlighted benefits such as modularity, scalability, and the ability for rapid deployment of code changes. However, along with these well-known advantages comes also challenges. In academia there is limited access to large-scale microservice applications, making it interesting to explore the perspectives of system developers. This study complements existing literature with experiences and insights from system developers involved in the development of microservices. The purpose of this study was to investigate and analyze how system developers apply microservice architecture to utilize its theoretical advantages and manage potential challenges, as well as to identify the prerequisites necessary for successful implementation of microservice architecture. By conducting a qualitative interview study with eight system developers from six different organizations we mapped the most significant benefits of microservices, including clear boundaries, easier version management, and the possibility of continuous integration and delivery. We also identified central challenges such as technical and operational legacy, organizational slowness and complexity in how microservices are interconnected. The results of the study led to the identification of a set of success factors for successful implementation of microservice architecture. These included clear ownership, DevOps and centralized logging.

The aim of this study has been to determine whether Microsoft Azure Service Bus has been able to match the needs and demands of Sogeti and its clients during a transition to a distributed and service-oriented system, as well as investi- gate possible gains that can be attained from such a transition. The study has also critically examined the potential problems and difficulties that may arise in such a scenario. The study has been accomplished using a literature study as well as the development of a Proof-of-Concept model to simulate such a system and to make calculations and surveys of and within one. The survey has shown that the Azure Service Bus does match the pre-defined requirements and requisites, as well as demonstrated how safe communication can be guaranteed using this particular service bus. The study concludes with an analysis of the study as a whole and the results thereof in particular, as well as proposes measures for further research on the subject. Finally, recommendations are made on how the client should proceed based on what is found in the study. / Målet med denna studie har varit att utröna huruvida Microsoft Azure Service Bus har kunnat matcha de behov och krav som Sogeti och dess klienter har på en sådan vid en övergång till ett distribuerat tjänsteorienterat system, samt undersöka vilka eventuella vinster som finns att göra vid en sådan övergång. Studien har också kritiskt granskat de problem och svårigheter som kan komma att uppstå. Undersökningen har gjorts med hjälp av en litteraturstudie samt en utveckling av en Proof-of-Concept-modell för att simulera ett sådant system och för att kunna göra beräkningar och undersökningar av och inom ett sådant. Undersökningen har visat att Azure Service Bus matchar de krav och önskemål som på förhand ställts, samt visat på hur säker kommunikation kan garanteras med hjälp av denna servicebuss. Undersökningen avslutas med en analys av studien som helhet och resultatet i synnerhet, samt föreslår åtgärder vid vidare forskning inom ämnet. Avslutningsvis lämnas rekommendationer på hur uppdragsgivaren ska gå tillväga baserat på vad som i studien framkommer.

Denna studie ämnar att bidra till kunskap till skapandet av en regelmotor för hanteringen av verksamhetsregler ur ett systemutvecklarperspektiv. Studien har utförts hos företaget Mobilaris som själva har identiferat ett potentiellt behov av verktyg för att på bättre sätt hantera verksamhetsregler. Innan studien påbörjades, så utfördes en förstudie då regelmotor som skulle nyttjas valdes ut. Studien har genom en designstudie där en regelmotor iterativt har utvecklats för att passa systemet Planning & Scheduling™. Datainsamlingen är gjort genom enkäter och semistrukturerade intervjuer som föregåtts av en presentation av artefakten. Enkäterna har följt en kvantitativ modell som kallas System Usability Scale. De semistrukturerade intervjuerna har sedan analyserats med hjälp av en innehållsanalys för att kunna identifera behoven och göra artefakten bättre. Resultatet av studien är riktlinjer som med fördel kan användas när man implementerar en regelmotor för ett resursplanneringssystem. Studien har identiferat nio teoretiska koncept varav åtta har kunnat bekräftas utifrån empirin. Det har också identiferats fyra nya designprinciper som anses göra regelmotorn bättre. / This study aims to contribute knowledge to the creation of a rule engine for the management of business rules from a system developer perspective. The study was conducted at a company called Mobilaris, which has identifed a potential need for tool to better manage business rules in one of their systems. Before the study began, a pilot study was carried out to select the rule engine that where going to be used in the study. The study has through a design science study where a rule engine has iteratively developed to fit the system Planning & Scheduling™. The data collection is done through surveys and semi-structured interviews that are preceded by a presentation of the artifact. The surveys follow a model called the System Usability Scale. The semi-structured interviews was then analyzed using a content analysis to be able to identify needs to make the artifact better. The results of the studies are guidelines that can be benefcial when implementing a rule engine for a resource planning system. The study has identifed nine theoretical concepts, of which eight have been confrmed based on empirical evidence. Four new design principles have also been identifed that are considered to make the rule engine better.

In recent years, microservice architecture has surpassed monolithic architecture in popularity among developers by providing a flexible way of developing complex distributed applications. Whereas a monolithic application functions as a single indivisible unit, a microservices-based application comprises a collection of loosely coupled services that communicate with each other to fulfill the requirements of the application. Consequently, different services in a microservices-based application can be developed and deployed independently. However, this flexibility is achieved at the expense of reduced observability of microservices-based applications complicating the debugging of such applications. The reduction of observability can be compensated by performing distributed tracing in microservices-based applications. Distributed tracing refers to observing requests propagating through a distributed system to collect observability data that can aid in understanding the interactions among the services and pinpoint failures and performance issues in the system. Open- Telemetry, an open-source observability framework supported by Cloud Native Computing Foundation (CNCF), defines a standardized specification for generating observability data. Nevertheless, instrumenting an application with an observability framework incurs performance overhead. To tackle this deterioration of performance and to reduce the cost of persisting observability data, only a subset of the requests are typically traced by performing head-based or tail-based sampling. In this work, we present a tail-based sampling framework using stream processing techniques. The developed framework demonstrated promising performance in our experiments by saving approximately a third of memory-based storage compared to an OpenTelemetry tail-based sampling module. Moreover, being compliant with the OpenTelemetry specifications, our framework aligns well with the OpenTelemetry ecosystem. / Under de senaste åren har mikrotjänstarkitektur överträffat monolitisk arkitektur i popularitet bland utvecklare genom att erbjuda ett flexibelt sätt att utveckla komplexa distribuerade tillämpningar. Medan en monolitisk tillämpning fungerar som en enda odelbar enhet, består en mikrotjänstbaserad tillämpning av en samling löst kopplade tjänster som kommunicerar med varandra för att uppfylla tillämpningens krav. Därför kan olika tjänster i en mikrotjänstbaserad tillämpning utvecklas och driftsättas oberoende av varandra. Denna flexibilitet uppnås dock på bekostnad av minskad observerbarhet för mikrotjänstbaserade tillämpningar, vilket försvårar felsökningen av sådana tillämpningar. Den minskade observerbarheten kan kompenseras genom att utföra distribuerad spårning i mikrotjänstbaserade tillämpningar. Distribuerad spårning innebär att man observerar förfrågningar som sprids genom ett distribuerat system för att samla in data om observerbarhet som kan hjälpa till att förstå interaktionerna mellan tjänsterna och lokalisera fel och prestandaproblem i systemet. OpenTelemetry, ett ramverk för observerbarhet med öppen källkod som stöds av Cloud Native Computing Foundation (CNCF), definierar en standardiserad specifikation för att generera observerbarhetsdata. Att instrumentera en tillämpning med ett ramverk för observerbarhet medför dock en överbelastning av prestanda. För att hantera denna försämring av prestanda och för att minska kostnaden för att bevara observerbarhetsdata spåras vanligtvis endast en delmängd av förfrågningarna genom att utföra s.k. “head-based sampling” eller “tail-based sampling”. I det här arbetet presenterar vi ett ramverk för tail-based sampling med hjälp av strömbehandlingsteknik. Den utvecklade ramen visade lovande prestanda i våra experiment genom att spara ungefär en tredjedel av den minnesbaserade lagringen jämfört med en OpenTelemetry-modul för tail-based sampling. Eftersom vårt ramverk är förenligt med OpenTelemetry-specifikationerna är det dessutom väl anpassat till OpenTelemetry-ekosystemet.

The microservice architectural pattern refers to a system consisting of independently deployable services that communicate across networks. RabbitMQ is a popular message broker that can be used to make this communication possible. An alternative to this is Amazon Simple Queuing Service (SQS), which is a fully managed queuing service. By performing a literature- and case study, two systems with a microservice architecture are developed. One using RabbitMQ to communicate between the services, and the other using Amazon SQS. The systems are compared, with regards to message latency, ease of use and maintainability. The results show that RabbitMQ provides much lower message latency than Amazon SQS. Amazon SQS is however both easier to maintain and to use than RabbitMQ. / En mikrotjänstarkitektur syftar till ett system bestående av tjänster som kan driftsättas oberoende av varandra och som kommunicerar över nätverk. RabbitMQ är en populär meddelandemäklare som nyttjas för att möjliggöra ovan nämnd kommunikation. Ett alternativ till detta är Amazon Simple Queueing Service (SQS), vilket är en meddelandetjänst som helt och hållet förvaltas av Amazon. Genom att utföra en litteratur- och fallstudie utvecklas två system med en mikrotjänstarkitektur. Det ena nyttjar RabbitMQ för kommunikation mellan tjänster, medan det andra använder Amazon SQS. Båda systemen jämförs därefter med hänsyn till meddelandens fördröjning, användarvänlighet samt enkelhet att underhålla. Resultaten visar att meddelanden skickade genom RabbitMQ har mycket lägre fördröjning än de skickade genom Amazon SQS. Ur perspektiven användarvänlighet och enkelhet att underhålla är Amazon SQS ett mer fördelaktigt akternativ än RabbitMQ.

Att utveckla applikationer med mikrotjänstarkitektur har idag blivit ett trendande tillvägagångssätt för att skapa tjänster som är anpassade för att köras i molnet med fördelar som mindre underhållsarbete och lättare skalbarhet. Mikrotjänster kännetecknas som löstkopplade och oberoende tjänster som kommunicerar genom att exponera ett API. För många populära programmeringsspråk, som till exempel Java, finns det flera ramverk att använda för att underlätta utvecklandet av mikrotjänster. Företaget Redpill Linpro i Karlstad, som är uppdragsgivare för den här studien, använder sig idag av Javaramverket Quarkus vid utvecklandet av mikrotjänster. De är dock intresserade av att veta hur mikrotjänster som utvecklats i Quarkus jämför sig prestandamässigt mot mikrotjänster som utvecklats i ett annat programmeringsspråk. Redpill Linpro har märkt att intresset för programmeringsspråket Go har ökat på sistone. I Gos officiella dokumentation rekommenderas ramverket Gin för att få bättre prestanda när det kommer till att utveckla tjänster som exponerar ett API. Redpill Linpro har tilldelat författaren av denna uppsats ett uppdrag att utveckla mikrotjänster med hjälp av ramverken Quarkus och Gin för att studera skillnader i prestanda samt beskriva tillvägagångssättet för hur utvecklingen av mikrotjänsterna gått till. Studien syfte är att identifiera vilken av mikrotjänsterna utvecklade i Gin eller Quarkus som presterar snabbast beträffande kompileringstid och uppstartstid, skillnader i filstorlek och skillnader i responstid vid HTTP-anropen GET och POST med och utan koppling till databas. Även vilken mikrotjänst som använder minst CPU-kraft och RAM-minne. Studiens resultat visar för- och nackdelar med båda ramverken men att mikrotjänsterna skapade med Gin presterade bäst i flest antalet parametrar som mättes i den här studien.

The rapid growth of the tech industry has led to a deficiency of qualified developers. Employing developers with adequate skills requires accurate assessments of the candidates. Today, an abundance of tools exists that companies can use in their recruitment processes. These tools are commonly prebuilt and often unadaptable, as well as being unrealistic in terms of real working life. In a normal work process, tasks have a duration of weeks instead of hours and developers can cooperate to solve assignments. Most companies today use recruitment tools created by external companies to facilitate their recruitment process. These tools are often rigid and cannot be adapted to the specific needs of the company. The consequences of these prebuilt tools have led to companies' rising desire to use an adaptable recruitment platform. The problem is that no such platform exists that provides a tool where companies can create their own assessments and adapt them according to their needs, with respect to the choice of tasks. The purpose of this thesis is to create an adaptable platform providing a tool for companies to use in their recruitment process, where tasks can be modified according to the requirements for the Recruit platform. The goal is to facilitate the recruitment process by creating an adaptable and expandable tool. The project strategy used for the development of the platform was an agile method inspired by Scrum. The development process resulted in a platform called Recruit that was built with a microservice architecture that fulfilled all the requirements for the functionality. This thesis was conducted on behalf of Knightec. The focus lies in building the platform with microservices using the cloud computing infrastructure of Amazon Web Services. The platform was built around social events where candidates can play a game proving their coding and problem-solving abilities. The implemented game supports different levels of difficulty and is accessed through API (Application Programming Interface) requests. Instead of candidates focusing on how to use the platform, the difficulty in the challenge lies in the focus of the candidates’ ability to create a solution to play the game. The development method used in this thesis is an agile method inspired by Scrum that is a part of a project method. The project method consists of five phases where the platform was designed and implemented, and lastly evaluated. The evaluation of this thesis concerned the project evaluation, prototype evaluation, and requirements evaluation. To prove that the requirements of the platform were fulfilled, semi-open interviews were conducted as well as acceptance tests. The discussion concerning the type of game resulted in implementing a turn-based single-player game, because of the increased complexity of implementing real-time or multiplayer games. / Den hastiga tillväxten av teknikindustrin har lett till en brist på kvalificerade utvecklare. För att anställa utvecklare med lämplig kompetens behövs noga utvalda tester. Idag existerar många verktyg som företag kan använda i deras rekryteringsprocess. Dessa verktyg är vanligtvis förbyggda och därmed inte anpassningsbara, samt speglar inte verkligheten korrekt. En arbetsuppgift, enligt verkligheten, har ofta en varaktighet på flera veckor snarare än timmar och utvecklarna kan samarbeta för att lösa uppgiften. Idag använder de flesta företag rekryteringsverktyg skapade av externa företag för att underlätta deras rekryteringsprocess. Dessa verktyg är ofta fasta och kan därför inte anpassas utefter företagets behov. Konsekvensen av dessa förbyggda verktyg har lett till ett begär hos företagen att använda anpassningsbara rekryteringsplattformar. Problemet är att ingen sådan plattform, som tillhandahåller ett verktyg där företag kan konstruera och skapa sina tester utefter behov, med hänsyn till val av test, existerar. Syftet med det här projektet är att skapa en anpassningsbar plattform som tillhandahåller ett verktyg, där företag kan modifiera sina tester utefter krav och använda dem i deras rekryteringsprocess. Målet är att underlätta rekryteringsprocessen genom att skapa en anpassningsbar plattform och ett expanderbart verktyg. Projekt-strategin som använts för att utveckla plattformen var en agil metod inspirerad av Scrum. Utvecklingsprocessen resulterade i plattformen Recruit som byggdes med en mikrotjänstarkitektur där alla krav uppfylldes. Det här examensarbetet har utförts på uppdrag av Knightec. Fokuset var att bygga plattformen med mikrotjänster genom att använda Amazon Web Services molnbaserade infrastruktur. Plattformen byggdes runt sociala evenemang där kandidater kan spela ett spel för att bevisa deras kodnings- och problemlösningsförmåga. Det implementerade spelet stödjer olika nivåer av svårighetsgrad och nås via API (Application Programming Interface) anrop. I stället för att kandidaterna ska fokusera på hur plattformen används, gör svårighetsgraden i utmaningen att kandidaternas förmåga till att konstruera en lösning för att spela spelet, hamnar i fokus. Utvecklingsmetoden som användes i detta examensarbete är en agil metod som är inspirerad av Scrum och är en del av en projektmetod. Projektmetoden bestod av fem faser där plattformen designades och implementerades, och till sist evaluerades. Evalueringen av det här examensarbetet omfattade projektevaluering, prototypevaluering, och kravevaluering. För att visa på att kraven för plattformen var uppfyllda genomfördes semi-öppna intervjuer, samt acceptanstester. Diskussionen kring typen av spel resulterade i en implementation av ett turbaserat enmansspel eftersom komplexiteten ökade med realtid- eller flermansspel.

The concept of breaking down a bigger application into smaller components is not a new idea, but it has been more commonly adopted in recent years due to the rise of the microservice application architecture. What has not been elaborated on enough however, is the security of the microservice architecture and how it differs from a monolithic application architecture. This leads to question what the most relevant security vulnerabilities of integrating and using a microservice architecture are, and what the correlating metrics that can be used to detect intrusions based on the vulnerabilities can be. In this report, the security of the microservice architecture is elaborated on in a case study of the system at Skatteverket, the Swedish tax agency, which is a microservice based architecture running on Kubernetes. Interviews are conducted with people that have experience in Kubernetes and microservices separately, both employed at Skatteverket and elsewhere. In the interviews, vulnerabilities and intrusion detection metrics are identified, which are then analyzed with respect to a use case in the Skatteverket system. A survey is also done on the existing technologies that can mitigate the identified vulnerabilities that are related to a microservice architecture. The vulnerabilities present in the use case are then concluded to be most relevant, the identified intrusion detection metrics are elaborated on and the service mesh technology Istio is found to mitigate largest number of the identified vulnerabilities. / Konceptet att bryta ner en större applikation i mindre komponenter är inte en ny idé, men den har blivit vanligare under de senaste åren på grund av växten i användning av mikrotjänstsarkitekturer. Vad som dock inte har utforskats tillräckligt är säkerheten för mikrotjänstarkitekturen och hur den skiljer sig från en monolitisk applikationsarkitektur. Detta leder till att fråga vilka de mest relevanta säkerhetsriskerna med att integrera och använda en mikrotjänstarkitektur är, och vilka mätvärden som kan användas för att upptäcka intrång baserat på riskerna kan vara. I denna rapport utforskas säkerheten för mikrotjänstarkitekturer genom en fallstudie av systemet hos Skatteverket, som är en mikrotjänstbaserad arkitektur som körs på Kubernetes. Intervjuer genomförs med personer som har erfarenhet av Kubernetes och mikrotjänster separat, både med anställda på Skatteverket och på annat håll. I intervjuerna identifieras risker och mätvärden för att märka av intrång som sedan analyseras med avseende på ett användningsfall i Skatteverketssystemet. En undersökning görs också om befintlig teknik som kan mildra de identifierade riskerna som är relaterade till en mikrotjänstarkitektur. De risker som förekommer i användningsfallet anses sedan till att vara mest relevanta i slutsatserna, de identifierade mätvärdena för att märka av intrång diskuteras och service mesh teknologin Istio anses mitigera störst antal av de identifierade riskerna.

As monolithic software grows in complexity, they tend to reach a point where further improvements and maintenance become a significant burden. Therefore, Many organizations consider moving components of their systems into separate microservices. Distributed systems with loosely coupled microservices tend to become more manageable involving development, deployment, and maintenance.  Transitioning from a monolithic architecture to an architecture based on microservices is not straightforward. The purpose of this thesis is to study and develop a strategy for extracting microservices from a pre-existing monolithic system. It also intends to provide concepts for how to investigate and carry out migrations.  The results showed that serverless computing would serve the system in question well while simultaneously leveraging DevOps principles across an entire domain. In conclusion, the strategy was summed up in several steps that represent the initiation towards full migration. Further research needs to be conducted on avoiding abrupt interruptions of services during migration and how to share data effectively across services and domains. / När monolitisk programvara växer i komplexitet finns det en tendens att den når ett tillstånd där ytterligare förbättringar och underhåll orsakar avsevärd börda. Många organisationer överväger därför att flytta komponenter från sina system till separata mikrotjänster. Distribuerade system med löst kopplade mikrotjänster syftar till att vara mer hanterbara med avseende till utveckling, driftsättning och underhåll.  Övergången från en monolitisk arkitektur till en arkitektur baserad på mikrotjänster är ibland inte helt självklar. Därför är syftet med detta examensarbete att studera och utveckla en strategi för att extrahera mikrotjänster från ett redan existerande monolitiskt system. Rapporten avser även att ge koncept för hur man utreder och genomför en migration.  Resultaten visar att serverlös databehandling skulle vara till nytta för systemet i fråga och samtidigt främja nyttjandet DevOps-principerna över en tjänst som utgör en hel domän. Strategin sammanfattades i flertalet steg, vilka representerar migrationsövergången. Ytterligare forskning behöver utföras för att undvika plötsliga avbrott i tjänster under migration och hur man effektivt kan dela data mellan tjänster och domäner.

Att designa mjukvaruapplikationer med en viss struktur kan ofta framhäva efterfrågade egenskaper. För att välja rätt arkitektur behövs ofta övervägningar, och ibland till och med kompromisser, göras om applikationens planerade karaktär. Det är ofta bra att i detta stadie ha en klar bild om vilka attribut en applikation önskas ha. Ett av de viktigare attributen på sikt är skalbarhet. Kunskapen om olika arkitekturers skalbarhet spelar en definitiv roll i designfasen, vilket avgör hur en applikation senare skalas. På senare år har mikrotjänst-arkitektur blivit ett populärt sätt att bygga mjukvara på där den höga skalbarheten sägs vara en bidragande faktor. Detta arbete har till syfte att undersöka skalbarheten hos mikrotjänst-arkitektur i förhållande till monolitisk arkitektur och visa hur detta kvalitetsattribut påverkas när en transformering från en monolit till en mikrotjänst-arkitektur görs. Arbetet har valt att utgå ifrån en existerande modul i en E-handelsplattform med öppen källkod. Modulen som transformerades till en mikrotjänst, skalades horisontellt för respektive arkitektur och applikations-version. Vid användandet av lämpliga verktyg, såsom Docker, visar resultatet att horisontell skalbarhet finns i högre grad hos mikrotjänst-arkitekturen och fortsätter därefter vara hög. Skalning av mikrotjänster kan göras med en högre precision av det som önskas förändras. Detta står i kontrast till den monolitiska strukturen, där skalning begränsas av prestandan av den miljö där mjukvaruapplikationen körs. Efter transformationen till en mikrotjänst-arkitektur ökade skalbarheten, då skalningsmetoden gjordes med mer finkornighet och isolering av den utvalda modulen. För att individuellt skala den monolitiska modulen horisontellt behövdes förändringen göras virtuellt med hjälp av bakgrundsprocesser. Denna lösning visar sig vara en indirekt skalning av hela den monolitiska strukturen. Utöver horisontell skalbarhet fokuserar utvärderingen av resultatet på kvalitativa attribut i form av simplicitet, autonomi och modularitet. / In designing software applications, a chosen structure can often accentuate desired properties. To choose the correct architecture, one must often do considerations and sometimes even compromises, about the intended characteristics of the application. In that stage it is often well motivated to have a clear picture about which attributes the application shall possess. Over time, one of the most important attributes is scalability. The knowledge about the scalability of different architectures could play a crucial part in the design phase, determining how an application is scaled in the future. In recent years Microservice Architecture has been a popular way of building software and its high scalability is said to be a contributing factor. This work has the purpose of examine the scalability of microservice architecture relative to the monolithic architecture and how this quality attribute is affected after a transformation is done from a monolith to a microservice system. This work is based on an existing module from an open source E-commerce platform. The module was first transformed into a working microservice, then both architectures was horizontally scaled. Using suitable tools such as Docker, the result of this work shows that horizontal scalability exists in a high degree within the microservice architecture and continues being high there after. Scaling of microservices can be done with higher precision of what are to be changed. This stands in relation to the monolithic approach where scaling is limited to the performance of the environment where the software application is running. The transformation to a microservice architecture resulted in an increase of scalability. The scaling method was more fined-grained and isolated to the selected module. In contrast, individual horizontal scaling of the monolithic module was required to be done virtually with background processes. This concluded in an indirect scaling of the whole structure of the monolith. Besides horizontal scalability, the evaluation is focused on the system quality attributes of simplicity, autonomy and modularity.