Den tekniska utvecklingen driver fram allt mer avancerade datorsystem. Samtidigt ställs allt större krav på stabilitet och flexibilitet i de operativsystem som ska användas på dessa system. De senaste årtiondena har micro kernel arkitekturen varit föremål för intensiv forskning och det finns idag ett flertal operativsystem på marknaden som använder denna arkitektur. Traditionella monolitiska operativsystem är relativt resurskrävande system som ofta anklagats för att sakna struktur. Micro kernel baserade system är en lösning på detta problem där man bantat ner kernel till så lite som ett tiotal kilobyte och flyttar ut tjänster som normalt ligger i kernel till user space. Solaris och Linux bygger på en utveckling av monolitisk kernel där man byggt operativsystemet i ett antal sinsemellan beroende lager vilket bidrar till ökad struktur i systemet. Flexibilitet uppnås i dessa system genom att man lägger till funktionalitet för att under exekvering länka in ny kod i kernel. Windows NT och Mac OS X är baserade på micro kernel arkitektur. De använder en relativt liten kernel och flyttar övriga tjänster till user space. På grund av prestandaproblem med t.ex. grafik och nätverk har dock vissa tjänster flyttats tillbaka till kernel space, vilket har lett till att kritiker hävdar att de inte är rena micro kernel system.

Microservices is a new software design concept for developing scalable, loosely coupled services with a smaller codebase than the traditional monolithic approach. The designed microservices can communicate using several protocols, such as Advanced Message Queuing Protocol (AMQP) or HTTP/REST. Software developed using microservices design offers the developers great flexibility to choose a preferred technology stack and make independent data storage decisions. On the other hand, containerization is a mechanism that packages together the application code and dependencies to run on any platform uniformly and consistently. Our work utilizes Docker and Kubernetes to manage a containerized application. The Docker platform bundles the application dependencies and runs them in the containers. Moreover, Kubernetes is used for deploying, scaling, and managing containerized applications. On the other hand, microservices-based architecture brings many challenges as multiple services are being built and deployed simultaneously in this design. Similarly, a software developer faces many questions such as where to physically deploy the newly developed service? For example, place the service on a machine with more computing resources or near another service which it often needs to communicate with? Furthermore, it is observed in previous studies that the microservices may bring performance degradation due to increased network calls between the services. To answer these questions, we develop a unique microservices-based containerized application that classifies images using deep learning tools. The application is deployed into the Docker containers, while Kubernetes manages and executes the application on the on-premise machines. In addition, we design experiments to study the impact of container placement on the application performance in terms of latency and throughput. Our experiments reveal that Communication Aware Worst Fit Decreasing (CAWFD) obtained 49%, 55%, and 54% better average latency in microservice placement scenario two. This average latency is lower than CAWFD in scenario one in the 100, 300, 500 images group. Simultaneously, the Spread strategy displayed minimal performance because the Kubernetes scheduler determines the container placements on the nodes. Finally, we discover that CAWFD is the best placement strategy to reduce the average latency and enhance throughput. / Microservices är ett nytt mjukvarudesignkoncept för att utveckla skalbara, löst kopplade tjänster med en mindre kodbas än den traditionella monolitiska metoden. Tjänsterna kan kommunicera med flera protokoll, till exempel AMPQ eller HTTP/REST. Programvaran som utvecklats med hjälp av mikroservicedesign erbjuder en utvecklare stor flexibilitet att välja en föredragen teknikbunt och fatta oberoende datalagringsbeslut. Dessutom är containerisering en mekanism som grupperar applikationskoden och beroenden för att köra på vilken plattform som helst enhetligt och konsekvent. Vårt arbete använde Docker och Kubernetes för att hantera de containeriserade applikationerna. Docker plattformen buntar programberoenden och kör dem i behållarna. Samtidigt används Kubernetes för distribution, skalning och hantering av containeriserade applikationer. Å andra sidan ger mikrotjänstbaserad arkitektur många utmaningar. Många tjänster byggs och distribueras samtidigt i denna design. På samma sätt står en mjukvaruutvecklare inför många frågor. Som, var ska de placera den nyutvecklade tjänsten? Till exempel, placera tjänsten på en maskin med fler datorer och nära en annan tjänst där de ofta behöver kommunicera med varandra. Vidare har det observerats i tidigare studier att mikrotjänsterna försämrar prestandan på grund av ökade nätverkssamtal mellan tjänsterna. För att besvara dessa frågor har vi utvecklat en unik mikrotjänstbaserad containeriserad applikation. Den klassificerar en bild med hjälp av djupa inlärningsverktyg. Programmet distribueras till Docker-behållarna, medan Kubernetes hanterar och kör programmet på lokala datorer. Dessutom utformade vi ett par experiment för att studera behållarnas inverkan på applikationsprestanda när det gäller latens och genomströmning. Våra experiment avslöjar att Communication Aware Worst Fit Decreasing (CAWFD) fick 49%, 55% och 54% bättre genomsnittlig latens i scenario två med mikrotjänstplacering. Denna genomsnittliga latens är lägre än CAWFD i scenario ett i gruppen 100, 300, 500 bilder. Samtidigt visade Spreadstrategin minimal prestanda eftersom Kubernetes-schemaläggaren bestämmer behållarplaceringarna på noderna. Slutligen upptäcker vi att CAWFD är den bästa placeringsstrategin för att minska den genomsnittliga latensen och förbättra genomströmningen.

With the growth of cloud computing, various delivery models have emerged to attract developers looking for scalable and cost-effective infrastructures for their software. Traditionally, applications are developed as a monolith with one single codebase repository, and they are easily deployed; for example as Platform as a Service (PaaS). However, monolithic applications have received criticism for inefficient resource handling when deployed on the cloud; therefore, new delivery models have been introduced as alternatives. Recent research points towards Function as a Service (FaaS) to potentially solve the issue of inefficient resource handling and, therefore, reduce costs. Furthermore, since multiple distinct development strategies and delivery models exist, it becomes increasingly important to choose the right strategy from the beginning since migrating to another development strategy or deployment model in the future is rather expensive. This thesis load tests monolithic and serverless applications to determine which development approach best suits performance, scalability, and cost requirements. The findings obtained showed that an application implemented with a serverless architecture can be a better strategy if the application needs to be able to handle a sudden large up-scaling. Otherwise, both architectures showed similar results to stable workloads. Regarding costs, the serverless architecture optimized costs on a smaller scale but further analysis showed that it can surpass the costs of a monolithic architecture if it surpasses a threshold of requests per month. / Nya molntjänster har lanserats för att locka utvecklare som letar efter skalbara och kostnadseffektiva infrastrukturer för sin programvara. Traditionellt utvecklas applikationer som en monolit med en enda kodbas, och de är lätta att lansera; till exempel med Platform as a Service (PaaS). Monolitiska applikationer har dock fått kritik för ineffektiv resurshantering när de distribueras i molnet; därför har nya servicemodeller introducerats som alternativ. Ny forskning pekar mot Function as a Service (FaaS) för att potentiellt lösa problemet med ineffektiv resurshantering och därför minska kostnaderna. Dessutom, eftersom det finns flera olika utvecklingsstrategier och servicemodeller, blir det allt viktigare att välja rätt strategi från början eftersom att det kan bli dyrt att migrera till en annan strategi i framtiden. Detta examensarbete testar en monolitisk applikation och en serverlös applikation för att avgöra vilken utvecklingsmetod som passar bäst gällande prestanda, skalbarhet och kostnadskrav. Resultaten som erhölls visade att en applikation implementerad med en serverlös arkitektur kan vara en bättre strategi om applikationen ska kunna hantera en snabb uppskalning. Annars visade båda arkitekturerna liknande resultat när det var stabilare arbetsbelastningar. Serverlösa arkitekturen optimerade kostanderna i en mindre skala, men vidare analyser visade att kostnaden kan överskrida en monolitisk arkitektur om applikationens efterfrågan skulle passera ett visst antal användare per månad.

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.

The way the structure of systems and programs are designed is very important. When working with smaller groups of systems, the chosen architecture does not affect the performance and efficiency greatly, but as these systems increase in size and complexity, the choice of architecture becomes a very important one. Problems that can arise when the complexity of software scales up are waiting for data accesses, long sequential executions and potential loss of data. There is no single, optimal software architecture, as there are countless different ways to design programs, but it is interesting to look at which architectures perform the best in terms of execution time when handling multiple bigger systems and large amounts of data. In this thesis, a case called "The Income Deduction" will be implemented in a monolithic and an event-driven architectural style and then be put through three different scenarios. The monolithic architecture was chosen due to its simplicity and popularity when constructing simpler programs and systems, while the event-driven architecture was chosen due to its theoretical benefits of removing sequential communicating between systems and thus reduce the time systems spend waiting for each other to respond. The main research question to answer is what the main benefits and drawbacks are when building larger systems with an event-driven architectural style. Additional research questions include how the architecture affects the organisation’s efficiency and cooperation between different teams, as well as how the security of data is handled. The two implementations where put through three different scenarios within the case, measuring execution time, number of HTTP requests sent, database accesses and events emitted. The results show that the event-driven architecture performed 9.4% slower in the first scenario and 0.5% slower in the second scenario. In the third scenario the event-driven architecture performed 49.0% faster than the monolithic implementation, finishing the scenario in less than half the amount of time. The monolithic implementation generally performed well in the simpler scenarios 1 and 2, where the systems had fewer integrations to each other. In these cases it is the preferred solution since it is easier to design and implement. The event-driven solution did perform much better in the more complex scenario 3, where a lot of systems and integrations were involved, since it could remove certain connections between systems. Lastly, this thesis also discusses the sustainability and ethics of the study, as well as the limitations of the research and potential future work. / Strukturen som system och program designas efter är väldigt viktigt. När en arbetar med mindre grupper av system så kommer den valda arkitekturen inte att påverka prestandan mycket. Men när dessa system växter i storlek och komplexitet så kommer valet av arkitektur vara väldigt viktigt. Problem som kan uppstå när mjukvarukomplexiteten ökar är väntandet på dataaccesser, långa sekventiella exekveringar och potentiell förlust av data. Det finns ingen optimal mjukvaruarkitektur, det finns oräkneligt många sätt att designa program. Det är intressant att kolla på vilka arkitekturer som preseterar bäst sätt till exekveringstid när en hanterar ett flertal större system och stora mängder data. I den här avhandlingen kommer ett fall, kallat "Ingångsavdraget", att implementeras i en monolitisk och en event-driven arkitekturell stil och sedan köras igenom tre olika scenarion. Den monolitiska arkitekturen var vald på grund av dess enkelhet och populäritet vid utveckling av enklar program och system. Den event-drivna arkitekturen valdes på grund av vissa teoretiska fördelar, så som att kunna undvika sekventiell kommunikation mellan systemen och därmed reducera tiden som systemen väntar på svar från varandra. Den huvudsakliga forskningsfrågan som ska besvaras är vad de största fördelarna och nackdelarna är när man bygger större system med en event-driven arkitekturell stil. Andra forskningsfrågor inkludera hur arkitekturen påverkar effektiviteten hos en organisation och samarbetet mellan olika team, samt hur datasäkerheten hanteras. De två implementationerna sattes igång tre olika scenarion inom fallet, där exekveringstid, antal HTTP-anrop skickade, databasaccesser och event skickad mättes. Resultaten visar att den event-drivna arkitekturen presterade 9.4% långsamare i det första scenariot och 0.5% långsamare i det andra scenariot. I det tredje scenariot presterade den event-drivna lösningen 49.0% snabbare än den monolitiska lösningen och avslutade därmed scenariot under hälften av tiden. Den monolitiska implementationen presterade generellt väl under de simplare scenarion 1 och 2, där systemen hade färre integrationer till varandra. I dessa fallen så är den den föredragna lösningen eftersom det är lättare att designa och implementera. Den event-drivna lösningen presterade mycket bättre i det mer komplexa scenario 3, där många system och integrationer var inblandade, eftersom den kunde ta bort vissa kopplingar mellan system. Slutligen så diskuteras även hållbarhet och etik i studien, samt begränsningarna av forskningen och potentiellt framtida arbete.