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.