In this thesis project, a company’s continuously evolved service-oriented software architecture was studied for signs of architectural erosion. The architecture has been continuously developed over some time and the company have experienced a reduction in architectural quality and felt that it no longer fulfilled its design goals and therefore decided to start working on a replacement architecture based on the microservice archi-tectural style. This thesis project therefore aimed to study how the current architectures quality have changed during its evolution, find the causes of these changes in quality, andestimate how the planned microservice migration will effect these changes in quality. This study was performed in three steps. First, a suite of suitable quality metrics where gathered based on the stated architectural design goals and what information can be ex-tracted from the history of the implemented architecture. A tool was developed to model the architecture and to gather the quality metrics from the current architecture and how ithas changed over one year’s worth of development and evolution. Secondly, the causes ofthese changes in architectural quality was investigated through developer interviews with a wide range of developers that had worked on the architecture and the web application that it provides the structure for. The interviews focused on the topics of architectural knowledge, what consideration is taken to its design during component development, maintenance of existing components and architecture, as well as questions regardingspecific components and anomalies. Thirdly and finally, the migration to a microserviceand its effects on the quality of the current architecture is estimated through performing microservice reengineering on the model used to evaluate the current architecture. The tools developed during this thesis allowed for an analysis of the architecture didshow an increase in consistency violations, structural problems and level the of coupling have substantially increased over the version history that the model tracked. It was discov-ered by the developer interviews that some of the causes of this erosion was due to among other reasons an abandonment of some architectural deign decisions, lack of architectural knowledge on certain topics, and none-optimal development conditions and priorities. The microservice reengineering showed how the migration could be used to improve themeasured quality metrics and that a migration alongside some other architectural erosionprevention and repair methods could create an architecture that are more modular and erosion tolerant.

Function as a Service is a new addition to cloud services that allow a user to execute code in form of a function, in the cloud. All underlying complexity is handled by the cloud provider and the user only pay per use. Cloud services have been growing significantly over the past years and many companies want to take advantages of the benefits of the cloud. The cloud services deliver computing resources as a service over a network connection, often by the Internet. To use the benefit of the cloud, one can not just move an application to the cloud and think that it will solve itself. First of all, an application needs to be optimized to be able to take advantages of the cloud. Therefore, together with Tieto, a microservice architecture have been the main architectural pattern when Function as a Service has been evaluated. A major problem with applications, both application built with a monolithic and microservice architecture, is to handle great amounts of information flows. An application may have scaling issues when an information flow becomes too large. A person using Function as a Service does not have to buy, rent or maintain their own servers. However, Function as a Service has a certain memory and runtime restrictions, so an entire application cannot be applied to a Function as a Service. This thesis examines the possibility of using Function as a Service in different architectural environments and estimating the cost of it. Function as a Service is a new addition to cloud services, so cloud providers are also compared and evaluated in terms of the Function as a Service functionality. Function as a Service has been tested directly on various cloud platforms and even developed and executed locally, encapsulated in containers. The results show that Function as a Service is a good complement to an application architecture. The results also show that Function as a Service is highly flexible and cost-effective, and it is advantageous compared to physical servers and Virtual Machines. Depending on how a function is built, the developer can lower the cost even more by choosing the cloud supplier that fits best for their use. With the flexibility of Function as a Service, applications can handle greater information flow without bottlenecks in the infrastructure and therefore, becomes more efficient and cost-effective.

No description available.

Microservice-Architekturen haben sich mittlerweile etabliert und werden von immer mehr Firmen übernommen. Die erhöhte Komplexität der Microservice-Architektur aufgrund der Verteilung des Systems hat jedoch zur Folge, dass die effiziente und erfolgreiche Administration des Systems erschwert wird. Ziel der Arbeit ist es, alle notwendigen Metriken für ein effizientes und erfolgreiches Microservice-Monitoring zu identifizieren und auf Basis dieser Erkenntnisse das Linkerd-Dashboard prototypisch weiterzuentwickeln. Hierfür wurde eine Literaturrecherche durchgeführt. Darüber hinaus wurden Praktiker mittels eines Online-Fragebogens befragt. Abschließend wurde die prototypische Weiterentwicklung mithilfe eines halbstrukturierten Interviews evaluiert. Die Literaturrecherche ergab, dass Central-Processing-Unit (CPU)- und Random-Access-Memory (RAM)-Nutzung, Antwortzeit, Workload, Fehlerrate und Service-Interaktion eine Metrik-Menge sind, mit der Microservice-Architekturen effektiv überwacht werden können. Außerdem konnte konstatiert werden, dass die Darstellung der Metriken hauptsächlich mit Visualisierungen realisiert wird. CPU- und RAM-Auslastung sind eine sinnvolle Erweiterung des Linkerd-Dashboards, da diese in der Literatur sowie im Fragebogen als wichtige Kennzahlen deklariert und alle anderen als essenziell eingestuften Metriken bereits vom Linkerd-Dashboard abgedeckt werden. Der Prototyp wurde als gelungen eingestuft, benötigt aber einige kleinere Verbesserungen der Visualisierung, bevor er in der Produktion eingesetzt werden kann.

Microservice architecture is an emerging approach to application development. While the decentralized nature of microservices comes with advantages it also introduces new challenges to monitoring as the graph of interactions between services can be complex. We explore how a dashboard for microservice monitoring can support first-line operators with limited experience in software development and microservice architecture. We apply a participatory design approach and create a prototype in an iterative fashion together with developers, operators and stakeholders. The final prototype is evaluated through a think-aloud protocol and a system usability scale survey. A thematic analysis of the think-aloud renders three prevalent design lessons: (1) automation and context-switches; (2) consistency across views and states; and (3) language differences between developers and operators. / Mikrotjänstarkitektur används alltmer inom applikationsutveckling. Även om dess decentraliserade natur kommer med vissa fördelar, introducerar den också nya utmaningar inom övervakning, då den samtidigt kan medföra komplexa beroenden mellan tjänster. Vi utforskar hur en dashboard för mikrotjänstövervakning kan stödja first-line operatörer med begränsad erfarenhet av mjukvaruutveckling och mikrotjänstarkitektur. Vi närmar oss problemet med hjälp av participatory design och skapar en prototyp på ett iterativt sätt tillsammans med utvecklare, operatörer och intressenter. Den slutliga prototypen utvärderas genom ett think-aloud-protokoll och en System Usability Scale-enkät. En tematisk analys av think-aloud sessionerna resulterade i tre teman: (1) automatisering och kontextväxling; (2) att vara konsekvent mellan vyer och tillstånd; och (3) språkskillnader mellan utvecklare och operatörer.

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 microservice architecture is a popular architectural pattern in the industry to implement large systems as they can reduce the code bases of each service and increase the maintainability for each of the individual services by dividing the application into smaller components based on business logic. The services can be implemented in different programming languages and communicates over a network. As a consequence, it might lead to a greater attack surface for an adversary of the system. In order to ease the implementation of microservice architectures, a set of design patterns exists. Two patterns addressing the security of the architecture are the API Gateway pattern and the sidecar pattern. More research is needed in order to identify the security threats microservice architecture encounters and how the design pattern handles those. This master thesis uses threat modeling with attack graphs along with attack simulations in order to investigate the threats in microservice architectures and how they compare between the design patterns. To construct the attack graphs and perform the attack simulations SecuriCAD along with CoreLang was used on a microservice architecture with each of the design patterns. The report concludes that the sidecar pattern is faced with less risk than the API Gateway pattern overall and presents a set of suggestions regarding how the security can be improved in microservice architectures. / Mikrotjänstarkitekturer har blivit ett populärt arkitekturmönster inom industrin för att implementera större system eftersom det kan reducera kodbaserna och underlätta underhållningen av varje enskild tjänst genom av att dela upp applikationen i mindre komponenter baserat på varje tjänsts domänlogik. Dessa tjänster kan vara implementerade i olika programmeringsspråk och kommunicerar med varandra över ett nätverk. Som följd skulle dock detta kunna leda till en större attackyta för en angripare av systemet. För att underlätta implementationen av mikrotjänster finns en mängd designmönster, två designmönster som hanterar säkerheten av mikrotjänstarkiterurer är API Gateway mönstret och sidecar mönstret. Mer forskning skulle dock behövas för att ta reda på vilka hot som mikrotjänstarkitekturer ställs inför samt hur väl de två design mönstren bemöter dessa. Den här masteruppsatsen använder hotmodellering med attack grafer samt attack simuleringar för att undersöka vilka hot som finns i mikrotjänstarkitekturer och hur dessa skiljer sig åt mellan de två design mönstren. För att framställa attack graferna och genomföra attack simuleringarna användes programmet SecuriCAD tillsammans med CoreLang på en mikrotjänstarkitektur med vardera design mönster. Rapporten kommer fram till att sidecarmönstrer har lägre risk i jämförelse med API Gateway mönstret överlag och presenterar en mängd förslag angående hur säkerheten kan förbättras i mikrotjänstarkitekturer.

Graphs are a powerful way to represent data. They can be seen as a collection of objects (nodes) and the relationships between them (edges or links). The power of this structure has its intrinsic value in the relationship between data points that can even provide more information than the data properties. An important type of graph is Knowledge Graphs in which each node and edge has a type associated. Often graph data is incomplete and in this case, it is not possible to retrieve useful information. Link prediction, also known as knowledge graph completion, is the task of inferring if there are missing edges or nodes in a graph. Models of different types, including Machine Learning-based, Rule-based, and Neural Network-based models have been developed to address this problem. The goal of this research is to understand how link prediction methods perform in a real use-case scenario. Therefore, multiple models have been compared on different accuracy metrics and production case requirements on a microservice tracing dataset. Models have been trained and tested on two different knowledge graphs obtained from the data, one that takes into account the temporal information, and the other that does not. Moreover, the prediction of the models has been evaluated with what is usually done in the literature, and also mimicking a real use-case scenario. The comparison showed that too complex models cannot be used when the time, at training, and/or inference phase, is critical. The best model for traditional prediction has been RotatE which usually doubled the score of the second- best model. Considering the use-case scenario, RotatE was tied with QuatE, which required a lot more time for training and predicting. They scored 20% to 40% better than the third-best performing model, depending on the case. Moreover, most of the models required less than a millisecond for predicting a triplet, with NodePiece that was the fastest, beating ConvE by a 4% margin. For the training time, NodePiece beats AnyBURL by 40%. Considering the memory usage, again NodePiece is the best, by an order of magnitude of at least 10 when compared to most of the other models. RotatE has been considered the best model overall because it had the best accuracy and an above-average performance on the other requirements. Additionally, a simulation of the integration of RotatE with a dynamic sampling tracing tool has been carried out, showing similar results to the ones previously obtained. Lastly, a thorough analysis of the results and suggestions for future work are presented. / Grafer är ett kraftfullt sätt att representera data. De kan ses som en samling objekt (noder) och förhållandet mellan dem (kanter eller länkar). Kraften i denna struktur har sitt inneboende värde i förhållandet mellan datapunkter som till och med kan ge mer information än dataegenskaperna. En viktig typ av graf är Knowledge Graphs där varje nod och kant har en typ associerad. Ofta är grafdata ofullständiga och i det här fallet är det inte möjligt att hämta användbar information. Länkprediktion, även känd som färdigställande av kunskapsdiagram, är uppgiften att förutsäga om det saknas kanter eller noder i en graf. Modeller av olika typer, inklusive Machine Learning-baserade, Regelbaserade och Neural Network-baserade modeller har utvecklats för att lösa detta problem. Målet med denna forskning är att förstå hur länkprediktionsmetoder fungerar i ett verkligt use-case scenario. Därför har flera modeller jämförts med olika noggrannhetsmått och produktionsfallskrav på en mikrotjänstspårningsdatauppsättning. Modeller har tränats och testats på två olika kunskapsgrafer som erhållits från data, en som tar hänsyn till tidsinformationen och den andra som inte gör det. Dessutom har förutsägelsen av modellerna utvärderats med vad som vanligtvis görs i litteraturen, och även efterlikna ett verkligt use-case scenario. Jämförelsen visade att alltför komplexa modeller inte kan användas när tiden, vid träning och/eller slutledningsfasen, är kritisk. Den bästa modellen för traditionell förutsägelse har varit RotatE som vanligtvis fördubblade poängen för den näst bästa modellen. Med tanke på användningsfallet var RotatE knuten till QuatE, vilket krävde mycket mer tid för träning och förutsägelse. De fick 20% till 40% bättre än den tredje bäst presterande modellen, beroende på fallet. Dessutom krävde de flesta av modellerna mindre än en millisekund för att förutsäga en triplett, med NodePiece som var snabbast och slog ConvE med 4% marginal. För träningstiden slår NodePiece AnyBURL med 40%. Med tanke på minnesanvändningen är återigen NodePiece bäst, med en storleksordning på minst 10 jämfört med de flesta andra modeller. RotatE har ansetts vara den bästa modellen överlag eftersom den hade den bästa noggrannheten och en prestanda över genomsnittet för övriga krav. Dessutom har en simulering av integrationen av RotatE med ett dynamiskt samplingsspårningsverktyg utförts, som visar liknande resultat som de tidigare erhållna. Slutligen presenteras en grundlig analys av resultaten och förslag till framtida arbete.

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.

Java is one of the more recent programming languages that in runtime free applications from manual memory management by using automatic Garbage collector (GC) threads. Although, at the cost of stop-the-world pauses that pauses the whole application. Since the initial GC algorithms new collectors has been developed to improve the performance of Java applications. Still, memory related errors occurs and developers struggle to pick the correct GC for each specific case. Since the concept of microservices were established the benefits of using it over a monolith system has been brought to attention but there are still problems to solve, some associated to garbage collectors. In this study the performance of garbage collectors are evaluated and compared in a microservice environment. The measurements were conducted in a Java SpringBoot application using Docker and a docker compose file to simulate a microservice environment. The application outputted log files that were parsed into reports which were used as a basis for the analysis. The tests were conducted both with and without a database connection. Final evaluations show that one GC does not fit all application environments. ZGC and Shenandoah GC was proven to perform very good regarding lowering latency, although not being able to handle the a microservice environment as good as CMS. ZGC were not able to handle the database connection tests at all while CMS performed unexpectedly well. Finally, the study enlightens the importance of balancing between memory and hardware usage when choosing what GC to use for each specific case.