Microservice is an architectural design that promises a more elastic system where a microservice can be allocated compute power according to demand. Through the separation of components, each microservice can have its own hardware or cloud setup. As a result, the code becomes more maintainable through smaller repositories. Development and Operations (DevOps) is a set of best practices to improve software development and operations. Two important components of DevOps are Continuous Integration (CI) and Continuous Delivery (CD). CI is a set of practices that aims to automate testing and increase development velocity through continuously integrate code changes. While CD aims to streamline the deployment process of the code, enabling a shorter time to market. When migrating a monolithic codebase towards a microservice architecture, one faces a lot of decisions that can have a deep impact on the whole organization. From a CI/CD perspective, some decisions can impact the efficiency of the CI/CD pipeline. This thesis investigated how Indicio’s CI/CD pipeline changed when going from a monolith towards a microservice architecture. It documents the decisions Indicio made along the way and investigates how the CI buildtime and CD deploy time were affected. The result showed that Indicio’s decision to keep the new microservice in the same repository added 44% to the median buildtime. The time increase was acceptable since it only resulted in an average of 20 seconds increase in median buildtime. Although, the decision to separate the CD into two independent CD pipelines, one for the old monolith and one for the new microservice didn’t affect the deploy time by any considerate margin. The new microservice was deployed to Microsoft Azure to be able to take advantage of the elastic compute power. The big advantage from a CD perspective by utilizing Azure was the blue-green deployment method resulting in zero downtime. / Mikrotjänster är en arkitektdesign som lovar ett mer flexibelt system där en mikrotjänst kan tilldelas den nödvändiga datakraften. Genom att dela upp komponenter kan varje mikrotjänst ha sin egen hårdvara eller molninställning. Det resulterar i mindre stycken kod som är lättare att underhålla. Development and Operations (DevOps) är en samling av bästa praxis för att förbättra mjukvaruutveckling och operationer. Två viktiga komponenter av DevOps är Continuous Integration (CI) och Continuous Delivery (CD). CI är en samling av verktyg som försöker automatisera tester och öka utvecklingshastigheten genom att kontinuerligt integrera kodändringar. Medan syftet med CD är att effektivisera distribution av kod, vilket möjliggör en kortare tid till marknaden. När man migrerar en monolitiskt kodbas mot en mikrotjänst arkitektur står man inför flera val som kan påverka hela organisationen. Utifrån ett CI/CD perspektiv så kan dessa val påverka effektiviteten av CI/CD processen. Denna uppsats undersöker hur Indicios CI/CD process förändras när dem går mot en mikrotjänstarkitektur från en monolit. Uppsatsen dokumenterar de val Indicio har gjort under migrationen och hur det påverkar CI byggnadstid och CD distribution tid. Resultaten visar att Indicios beslut att behålla den nya mikrotjänsten i samma förvar resulterade i 44% ökad medianbyggtid. Tidsökningen var acceptabel då det endast innebar en snittökning på 20 sekunder. Fastän Indicio beslutade att separera på CD processen till två nya, en för den nya mikrotjänsten och en för den nya monoliten så påverkades inte distribueringstiden särskilt mycket. Den nya mikrotjänsten distribuerades på Microsoft Azure för att kunna utnyttja den elastiska datakraften. Den stora fördelen från ett CD perspektiv med Azure var att man kunde utnyttja blågrön distributionsmetod, vilket gjorde att driftstopp tiden försvann.

Många stora organisationer som myndigheter och banker arbetar med en monolitisk applikationsarkitektur som är ett gammalt sätt att strukturera applikationer. Flera faktorer som att attrahera och behålla talang, vara skalbar och flexibel, samt en bra tjänsteleverans driver dessa organisationer att byta till en mikrotjänstorienterad arkitektur. Att migrera stora applikationer och samtidigt leverera tjänster till kunder eller användare är en stor och svår uppgift. Problemet är att det inte finns tillräckligt med forskning om hur man arbetar under denna typ av modernisering av applikationsarkitekturen samtidigt som organisatorisk stabilitet upprätthålls. Denna studie syftar till att bättre förstå hur organisatorisk stabilitet kan upprätthållas under tider av stora tekniska förändringar i arbetssätt under övergångsperioden för arkitekturer. Studien utgick från följande forskningsfråga: Hur upprätthålls organisatorisk stabilitet under övergångsperioden för modernisering av arkitekturer under flytten mot mikrotjänster? Studien har baserats på en kvalitativ ansats, där en fallstudie har använts för att samla in empiriskt material. Studiens empiriska material har samlats in genom åtta semistrukturerade intervjuer med anställda med olika roller på myndigheten som utför ett storskaligt applikationsarkitektur projekt; containerprojektet. Datan analyserades med hjälp av tematisk analys. Studiens resultat visar hur både förberedande och löpande hantering är viktiga för framgång. I de förberedande stadierna är faktorer relaterade till risktagande och hantering av projektets arbetsstyrka viktiga att besluta om. När projektet väl har startat är det viktigt att aktivt arbeta med förändringsarbete och att vara flexibel, kommunicera med riktad information och hantera varje specifikt hinder noggrant. Studien visade också hur valet av teknik inte är avgörande för projektets framgång utan en metod för att nå dit. Resultaten har visat hur uppdelningen av en stor plan i mindre projekt, som vidare delas upp i faser, är en framgångsfaktor. Studien har bidragit med nya insikter till forskningen inom IT-hantering och applikationsarkitektur. / Many large organizations, such as government entities and banks, operate with a monolithic application architecture, an old way of structuring applications. Several factors including attracting and maintaining talent, being scalable and flexible, as well as a good service delivery, are driving these organizations to change toward a microservice-oriented architecture. To migrate large applications while simultaneously delivering the services to clients or users is a large and challenging task. The problem is that there is insufficient research on how to work during this type of application architecture modernization while maintaining organizational stability. This thesis aims to better understand how organizational stability can be maintained during times of disruptive technological change in the workspace during the transition period of architecture. The study utilized the following research question: How to maintain organizational stability in the transition period of architectural modernization moving towards microservices? The study has been based on a qualitative approach, where one case has been used in gathering empirical material. The study's empirical material has been collected through eight semi-structured interviews with employees of various roles at the Swedish agency performing a large-scale application architecture project; the containerization-project. The data were analyzed using thematic analysis. The thesis findings show how both preparatory and ongoing management contributions are essential for success. In the preparatory stages, factors related to risk-taking and managing the project workforce are essential to decide. Once the project has started, it is crucial to work on change management efforts actively and to be flexible, communicate with targeted information, and handle each specific obstacle carefully. The study also showed how the choice of technologies is not central to the project's success but a method to get there. The findings have shown how dividing a large plan into smaller projects, further divided into phases, is a success factor. The study contributed new insights to IT management and application architecture research.

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.