Microservice architecture has emerged as a new way to create large complex applications by removing some problems that exist for a monolithic counterpart. While this will asset agility, resilience, maintainability and scalability within the application, other problems will be predominant such as performance. This case study aims to provide more clarity on this matter by comparing a microservice architecture with a monolithic architecture. By conducting several experiment on two self-developed systems it could be found that microservice architecture will must likely show a lower performance in terms of throughput and latency on HTTP requests which use internal communication requests. On small intensive HTTP requests with minimum internal communication the difference between the architectures is so low it could almost be neglected. With microservice architecture comes other challenges that a company must keep into account such loadbalancing, caching and orchestration which are beneficial for the performance.

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.

Dagens applikationer är alltmer byggda enligt en mikrotjänstarkitektur istället för den klassiska monolitiska formen. I en mikrotjänstarkitektur har tjänster beroenden av varandra. Detta betyder att systemet måste kunna hantera situationer där dessa beroenden inte kan mötas. För att lösa de problemen som kan uppstå krävs ett felhanteringssystem som försäkrar att viktiga delar inte korrumperas eller går förlorad. Denna studie tar fram en modell på ett felhanteringssystem, och föreslår ett flertal teknologier som kan användas för en praktisk implementation av felhanteringssystemet. En fallstudie genomförs för att visa att teknologierna kan användas för att realisera modellen i en simulerad produktionsmiljö. Undersökningen föreslår en plattformsoberoende modell av Saga-mönstret som förhindrar korrumperad data, och ett återhämtningssystem som med hjälp av en meddelandekö kan återskapa förlorad data. Det framtagna felhanteringssystemet utvärderas utifrån de krav och begränsningar som ställs av beställaren, Asteria AB. Studien ger en generell lösning för de problem, som uppstår i en mikrotjänstarkitektur vid störningar och avbrott. Detta gör det möjligt att återanvända lösningen i olika kontext med minimala ändringar. / Today's applications are increasingly built according to a microservice architecture instead of the classic monolithic pattern. In a microservice architecture, services are interdependent. This means that the system must be able to handle situations where these dependencies cannot be met. To solve the problems that may arise, an error handling system is required that ensures that important parts are not corrupted or lost. This study develops a model of a fault management system, and proposes several technologies that can be used for a practical implementation of the fault management system. A case study is conducted to show that the technologies can be used to realize the model in a simulated production environment. The study proposes a platform-independent model of the Saga pattern that prevents corrupted data, and a recovery system that can recover lost data using a message queue. The developed error handling system is evaluated on the basis of the requirements and limitations set by the customer, Asteria AB. The study provides a general solution to the problems that arise in a microservice architecture in the event of disruptions and interruptions. This makes it possible to reuse the solution in different contexts with minimal changes.

The adoption of microservices facilitates extending computer systems in size, complexity, and distribution. Alongside their benefits, they introduce the possibility of partial failures. Besides focusing on the business logic, developers have to tackle cross-cutting concerns of service-to-service communication which now defines the applications' reliability and performance. Currently, developers use libraries embedded into the application code to address these concerns. However, this increases the complexity of the code and requires the maintenance and management of various libraries. The service mesh is a relatively new technology that possibly enables developers staying focused on their business logic. This thesis investigates one of the available service meshes called Istio, to identify its benefits and limitations. The main benefits found are that Istio adds resilience and security, allows features currently difficult to implement, and enables a cleaner structure and a standard implementation of features within and across teams. Drawbacks are that it decreases performance by adding CPU usage, memory usage, and latency. Furthermore, the main disadvantage of Istio is its limited testing tools. Based on the findings, the Webcore Infra team of the company can make a more informed decision whether or not Istio is to be introduced. / Tillämpningen av microservices underlättar utvidgningen av datorsystem i storlek, komplexitet och distribution. Utöver fördelarna introducerar de möjligheten till partiella misslyckanden. Förutom att fokusera på affärslogiken måste utvecklare hantera övergripande problem med kommunikation mellan olika tjänster som nu definierar applikationernas pålitlighet och prestanda. För närvarande använder utvecklare bibliotek inbäddade i programkoden för att hantera dessa problem. Detta ökar dock kodens komplexitet och kräver underhåll och hantering av olika bibliotek. Service mesh är en relativt ny teknik som kan möjliggöra för utvecklare att hålla fokus på sin affärslogik. Denna avhandling undersöker ett av de tillgängliga service mesh som kallas Istio för att identifiera dess fördelar och begränsningar. De viktigaste fördelarna som hittas är att Istio lägger till resistens och säkerhet, tillåter funktioner som för närvarande är svåra att implementera och möjliggör en renare struktur och en standardimplementering av funktioner inom och över olika team. Nackdelarna är att det minskar prestandan genom att öka CPU-användning, minnesanvändning och latens. Dessutom är Istios största nackdel dess begränsade testverktyg. Baserat på resultaten kan Webcore Infra-teamet i företaget fatta ett mer informerat beslut om Istio ska införas eller inte.

Microservice architectures are the base of modern cloud applications. With the adoption of microservices, application teams manage to reduce codebase complexity and write more modular services that can run inter-dependently. Despite all the advantages offered by microservices over monolithic architectures, they introduce additional complexities, such as handling inter-service communication, ensuring security, introducing traceability, and achieving acceptable performance. To manage all these microservices, the orchestrator tool Kubernetes has shown promising results, but it is not sufficient to tackle all the cross-cutting concerns of the applications. With more complex architectures, it becomes difficult to troubleshoot and trace inter-service application programming interface calls. For this purpose, the service mesh technology emerged and is being introduced in many companies. There are different implementations available for service mesh, with some being more compatible with specific cloud providers than others. The selection of an adequate service mesh shapes the entire application deployment process. If chosen wrongly, it might introduce further complexities or performance losses. This thesis investigates ways to make this decision more efficiently. It takes into account the company’s needs of service mesh and compares implementations to meet performance expectations with minimal deployment efforts. Specially, we perform different testing scenarios to compare AWS cloud specific, AWS App Mesh with most widely used, Istio service mesh. The outcome suggests that AWS App Mesh performs consistently for all cases with acceptable latency ranges, but, Istio outperforms AWS App Mesh under standard conditions, such as high but manageable request load on the application. In addition, Istio can achieve the same deployment with less lines of code as compared to that of AWS App Mesh. On the other hand, resource utilization by these service meshes is found to be a non-conclusive factor for selecting the service mesh implementation. With these outcomes, application teams can make more well-informed decisions to run the production-grade workloads with an efficient service mesh implementation. / Mikroservicearkitekturer är basen för moderna containerapplikationer. Med antagandet av mikrotjänster lyckas applikationsteam minska kodbaskomplexiteten och skriva fler modulära tjänster som kan köras beroende av varandra. Trots alla fördelar som mikrotjänster erbjuder framför monolitiska arkitekturer, introducerar de ytterligare komplexitet, såsom kommunikation mellan tjänster, säkerhet, spårbarhet och prestanda. För att hantera alla dessa mikrotjänster har orkestreringsverktyget Kubernetes visat lovande resultat, men det är inte tillräckligt för att ta itu med alla övergripande problem med applikationerna. Med mer komplexa arkitekturer blir det svårt att felsöka och få synlighet i mikrotjänster. För detta ändamål växte servicemesh-tekniken fram och introduceras i många företag. Det finns olika implementeringar tillgängliga för servicemesh, där vissa är mer kompatibla med specifika molnleverantörer än andra. Valet av ett adekvat servicenät formar hela applikationsdistributionsprocessen. Om det väljs fel kan det leda till ytterligare komplexitet eller prestandaförluster. Denna avhandling undersöker sätt att göra detta beslut mer effektivt. Den tar hänsyn till företagets behov av servicenät och jämför implementeringar för att möta prestandaförväntningar med minimala implementeringsinsatser. Speciellt genomför vi olika scenarier för prestandatestning för att jämföra AWS App Mesh med Istio servicemesh. Resultatet tyder på att AWS App Mesh presterar konsekvent för alla fall med acceptabla latensintervall, men Istio överträffar AWS App Mesh under standardförhållanden, såsom hög men hanterbar förfrågningsbelastning på applikationen. Istio kan uppnå samma distribution med färre rader kod jämfört med AWS App Mesh. Resursutnyttjande av dessa tjänstenät har visat sig vara en icke avgörande faktor för val av tjänstenätimplementering. Med dessa utfall kan företaget där detta examensarbete genomförs, Infor (Sweden) AB, fatta mer välinformerade beslut för att driva de produktionsmässiga arbetsbelastningarna med en effektiv implementering av servicenät.

In line with the growth of software, code bases are getting bigger and more complex. As a result of this, the architectural patterns, which systems rely upon, are becoming increasingly important. Recently, decomposed architectural styles have become a popular choice. This thesis explores system behavior with respect to decomposing system granularity and external communication between the resulting decomposed services. An e-commerce scenario was modeled and implemented at different granularity levels to measure the response time. In establishing the communication, both REST with HTTP and JSON and the gRPC framework were utilized. The results showed that decomposition has impact on run-time behaviour and external communication. The highest granularity level implemented with gRPC for communication establishment adds 10ms. In the context of how the web behaves today, it can be interpreted as feasible but there is no discussion yet on whether it is theoretically desirable. / I linje med de växande mjukvarusystemen blir kodbaserna större och mer komplexa. Arkitekturerna som systemen bygger på får allt större betydelse. Detta examensarbete utforskar hur upplösning av system som tillämpar mikroservicearkitektur beter sig, och hur de påverkas av kommunikationsupprättande bland de upplösta och resulterande tjänsterna. Ett e-handelsscenario modelleras i olika granularitetsnivåer där REST med HTTP och JSON samt gRPC används för att upprätta kommunikationen. Resultaten visar att upplösningen påverkar runtimebeteendet och den externa kommunikationen blir långsammare. En möjlig slutsats är att påverkan från den externa kommunikationen i förhållande till hur webben beter sig idag är acceptabel. Men om man ska ligga inom teoretiskt optimala gränser kan påverkan ses som för stor.

90% of the data that exists today has been created over the last two years only. Part of the data space is created and collected by machines, sending logs of internal measurements to be analyzed and used to evaluate service incidents. However, efficiently comprehending datasets requires more than just access to data, as Richard Hamming puts it; "The purpose of computing is insight, not numbers." A tool to simplify apprehension of complex datasets is information visualization, which works by transforming layers of information into a visual medium, enabling the human perception to quickly extract valuable information and recognise patterns. This was an experimental design-oriented research study, set out to explore if an information visualization of microservice architecture relations combined with system health data could help developers at a Swedish digital rights management company (DRMC) to find root cause incidents, increase observability and decision support, i.e. simplifying the incident handling process. To explore this, a prototype was developed and user tests consisting of a set of tasks as well as a semi-structured interview was executed by ten developers at DRMC. The results concluded that the proposed solution provided a welcomed overview of service health and dependencies but that it lacked the ability to effectively focus on certain services, essentially making it difficult to find root causes. Visualizations like this seems to be best suited for overview-, rather than focused, comprehension. Further research could be conducted on how to efficiently render large complex datasets while maintaining focus and how to account for external factors. / 90% av alla data som finns idag har skapats under de senaste två åren. En del av datautrymmet skapas och samlas in av maskiner som genererar loggar innehållandes interna systemmätningar för att utvärdera felaktiga tjänster. För att effektivt förstå ett dataset krävs mer än bara tillgång till data, som Rickard Hamming har sagt; “Syftet med datoranvändning är insikt, inte siffror.” Ett verktyg för att förenkla ens uppfattning av komplexa dataset är informationsvisualisering. Det fungerar genom att transformera lager av information till ett visuellt medium, och på så sätt tillåta mänsklig perception att snabbt extrahera värdefull information och utläsa mönster. Det här var en experimentell, design-orienterad, forskningsstudie med syftet att utforska ifall en informationsvisualisering av mikrotjänsters relationer kombinerat med system-hälso-data kunde hjälpa utvecklare på ett svenskt förvaltningsföretag av digitala rättigheter (DRMC) att hitta grundorsaken till felaktiga mikrotjänster samt utöka observerbarhet och beslutstöd, d.v.s. förenkla felhanteringsprocessen. För att utforska detta problem så utvecklades en prototyp som testades genom att låta tio utvecklare på DRMC utföra ett antal olika uppgifter samt svara på en semi-strukturerad intervju. Resultatet visade på att den föreslagna lösningen möjliggjorde en välkommen överblick över systemets hälsa och relationer, men också att den saknade möjligheten att effektivt fokusera på specifika tjänster, vilket ledde till att grundorsaksproblem var svåra att hitta. Visualiseringar som denna verkar fungera bäst för att presentera en överblick av ett system, snarare än ett fokus på specifika tjänster. Framtida forskning skulle kunna utföras för att utreda hur visualiseringar effektivt kan återge komplexa dataset utan att förlora fokus på specifika delar, samt hur externa faktorer kan integreras.

The last decade has seen an emergence of various types of cloud services and development frameworks offered by leading companies in the software industry. While each of these services has been used to solve specific tasks, their specifications have changed over time as they have matured. Therefore, integrating these components to solve a whole new task tends to get tricky due to their incompatible and experimental nature. While some technology components might continue to be developed, others might deprecate. In this thesis, using a user-centered design and agile development approach, we have attempted to develop a cloud solution using microservice software architecture by integrating state-of-the-art technology components to solve a totally new task of providing a non-intrusive technology experience during walking meetings. We present our results based on interaction with the research group, user studies as a part of the research study “Movement of the mind”, and expectations of the working prototype within the context of walking meetings. We also present the features of the prototype and our motivation for choosing the tools to develop them. Finally, we discuss the development challenges faced during our attempt and conclude whether it is plausible to integrate various components of bleeding-edge technology to solve complex real-life problems or rather wait for these technologies to mature. / Under det senaste decenniet har marknaden erbjudits en mängd olika typer av molntjänster och utvecklings-ramverk framtagna av ledande företag inom mjukvaruindustrin. Dessa tjänster har ofta använts för att lösa specifika uppgifter. Olika komponenterna som ingår i dessa specifika lösningar har med tiden utvecklats ändrats allteftersom de har mognat. Att integrera dessa komponenter för att lösa en helt ny uppgift tenderar därför att bli svårt på grund av deras instabila, inkompatibla och experimentella karaktär. Medan vissa teknikkomponenter kan fortsätta att utvecklas kan andra avstanna och utgå. Vi har närmat oss detta problemområde genom agil och iterativ utveckling samt användar-centrerad design-metod. En moln-baserad lösning som bland annat integrerat bleeding-edge teknikkomponenter har utvecklats och utvärderats med syfte att ge en icke-påträngande tekniskt support för gå-möten. De resultat som här presenteras och diskuteras baseras på interaktion med forskargruppen inom projektet "Med rörelse i tankarna", användarstudier och användartesteter i fält på olika arbetsplatser där den prototyp som utvecklats sökt motsvara användarnas utryckta förväntningar på tekniskt support för gångmöten. Vi diskuterar också prototypens egenskaper och vår motivation för val av metoder för att utveckla den. Slutligen diskuterar vi de utvecklingsutmaningar vi ställdes inför under vårt försök och om det är rimligt att integrera olika bleeding-edge komponenter för att lösa komplexa verkliga problem eller huruvida man hellre bör vänta på att dessa teknologier nått en stabilare mognadsgrad.

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.

A popular architecture for developing large-scale systems is the microservice architecture, which is currently in use by companies such as Amazon, LinkedIn, and Uber. The are many benefits of the microservice architecture with respect to maintainability, resilience, and scalability. However, despite these benefits, the microservice architecture presents its own unique set of challenges, particularly related to software testing. Software testing is exacerbated in the microservice architecture due to its complexity and distributed nature. To mitigate this problem, this project work investigated the use of a graph-based visualization system to simplify the software testing process of microservice systems. More specifically, the role of the visualization system was to provide an analysis platform for identifying the root cause of failing test cases. The developed visualization system was evaluated in a usability test with 22 participants. Each participant was asked to use the visualization system to solve five tasks. The average participant could on average solve 70.9% of the five tasks correctly with an average effort rating of 3.5, on a scale from one to ten. The perceived average satisfaction of the visualization system was 8.0, also on a scale from one to ten. The project work concludes that graph-based visualization systems can simplify the process of identifying the root cause of failing test cases for at least five different error types. The visualization system is an effective analysis tool that enables users to follow communication flows and pinpoint problematic areas. However, the results also show that the visualization system cannot automatically identify the root cause of failing test cases. Manual analysis and an adequate understanding of the microservice system are still necessary. / En populär arkitektur för att utveckla storskaliga system är mikrotjänstarkitekturen, som för närvarande används av företag som Amazon, LinkedIn och Uber. Det finns många fördelar med mikrotjänstarkitekturen med avseende på underhållbarhet, motståndskraft och skalbarhet. Men trots dessa fördelar presenterar mikrotjänstarkitekturen sin egen unika uppsättning utmaningar, särskilt med hänsyn till mjukvarutestningen. Mjukvarutestningen försvåras i mikrotjänstarkitekturen på grund av dess komplexitet och distribuerade natur. För att mildra detta problem undersökte detta projektarbete användningen av ett grafbaserat visualiseringssystem för att förenkla mjukvarutestprocessen för mikrotjänstsystem. Mer specifikt var visualiseringssystemets roll att tillhandahålla en analysplattform för att identifiera grundorsaken till misslyckade testfall. Det utvecklade visualiseringssystemet utvärderades i ett användbarhetstest med 22 deltagare. Varje deltagare ombads att använda visualiseringssystemet för att lösa fem uppgifter. Den genomsnittliga deltagaren kunde i genomsnitt lösa 70.9% av de fem uppgifterna korrekt med ett genomsnittligt ansträngningsbetyg på 3.5, på en skala från ett till tio. Den upplevda genomsnittliga nöjdheten med visualiseringssystemet var 8.0, också på en skala från ett till tio. Projektarbetet drar slutsatsen att grafbaserade visualiseringssystem kan förenkla processen att identifiera grundorsaken till misslyckade testfall för minst fem olika feltyper. Visualiseringssystemet är ett effektivt analysverktyg som gör det möjligt för användare att följa kommunikationsflöden och peka ut problemområden. Men resultaten visar också att visualiseringssystemet inte automatiskt kan identifiera grundorsaken till misslyckade testfall. Manuell analys och en grundlig förståelse av mikrotjänstsystemet är fortfarande nödvändigt.