Academic literature on the topic 'Mikrotjänst'

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.

Under VT 2019 ägde projektet rum varav denna rapport är ett av resultaten. Projektets mål var att skapa en CI/CD pipeline vars syfte var tänkt att frekvent kunna leverera färdigtestad kod till olika molntjänster som Google Cloud Platform, Amazon Web Services och Azure. Projektspecifikationerna gavs av företaget Skira för att skapa en snabbare integrationsprocess för nya utvecklare. Detta så en ny utvecklare skulle kunna lägga mer tid på att koda istället för att gräva ner sig i leverans-/testningsprocessen. Slutprodukten ger företag möjligheten att koda direkt på sitt utvecklingskluster.

Microservices is perhaps the latest addition to the list of buzzwords in software engineering. And since 2014 the research on the subject been constantly growing. In this paper I conduct a comparative literature overview over microservices. Based on the findings and analysis of the overview, I propose a model called the microservices-triad for a better understanding what microservices are, and how it relates to other techniques in software engineering. The three legs of the triad are the following, 1) A style of designing one small service, 2) The system administrative approach, where DevOps, CI/CD and distributed computer system dictates what kind of application one build, and lastly, 3) Microservices as a new form of architectural design. Furthermore, I’ve migrated – a part of – one monolithic IoT-application into using a microservice. This migration is also benchmarked to see if the performance is better with the new, re-designed IoT-application.

The aim of this study has been to determine whether Microsoft Azure Service Bus has been able to match the needs and demands of Sogeti and its clients during a transition to a distributed and service-oriented system, as well as investi- gate possible gains that can be attained from such a transition. The study has also critically examined the potential problems and difficulties that may arise in such a scenario. The study has been accomplished using a literature study as well as the development of a Proof-of-Concept model to simulate such a system and to make calculations and surveys of and within one. The survey has shown that the Azure Service Bus does match the pre-defined requirements and requisites, as well as demonstrated how safe communication can be guaranteed using this particular service bus. The study concludes with an analysis of the study as a whole and the results thereof in particular, as well as proposes measures for further research on the subject. Finally, recommendations are made on how the client should proceed based on what is found in the study.
Målet med denna studie har varit att utröna huruvida Microsoft Azure Service Bus har kunnat matcha de behov och krav som Sogeti och dess klienter har på en sådan vid en övergång till ett distribuerat tjänsteorienterat system, samt undersöka vilka eventuella vinster som finns att göra vid en sådan övergång. Studien har också kritiskt granskat de problem och svårigheter som kan komma att uppstå. Undersökningen har gjorts med hjälp av en litteraturstudie samt en utveckling av en Proof-of-Concept-modell för att simulera ett sådant system och för att kunna göra beräkningar och undersökningar av och inom ett sådant. Undersökningen har visat att Azure Service Bus matchar de krav och önskemål som på förhand ställts, samt visat på hur säker kommunikation kan garanteras med hjälp av denna servicebuss. Undersökningen avslutas med en analys av studien som helhet och resultatet i synnerhet, samt föreslår åtgärder vid vidare forskning inom ämnet. Avslutningsvis lämnas rekommendationer på hur uppdragsgivaren ska gå tillväga baserat på vad som i studien framkommer.

The concept of breaking down a bigger application into smaller components is not a new idea, but it has been more commonly adopted in recent years due to the rise of the microservice application architecture. What has not been elaborated on enough however, is the security of the microservice architecture and how it differs from a monolithic application architecture. This leads to question what the most relevant security vulnerabilities of integrating and using a microservice architecture are, and what the correlating metrics that can be used to detect intrusions based on the vulnerabilities can be. In this report, the security of the microservice architecture is elaborated on in a case study of the system at Skatteverket, the Swedish tax agency, which is a microservice based architecture running on Kubernetes. Interviews are conducted with people that have experience in Kubernetes and microservices separately, both employed at Skatteverket and elsewhere. In the interviews, vulnerabilities and intrusion detection metrics are identified, which are then analyzed with respect to a use case in the Skatteverket system. A survey is also done on the existing technologies that can mitigate the identified vulnerabilities that are related to a microservice architecture. The vulnerabilities present in the use case are then concluded to be most relevant, the identified intrusion detection metrics are elaborated on and the service mesh technology Istio is found to mitigate largest number of the identified vulnerabilities.
Konceptet att bryta ner en större applikation i mindre komponenter är inte en ny idé, men den har blivit vanligare under de senaste åren på grund av växten i användning av mikrotjänstsarkitekturer. Vad som dock inte har utforskats tillräckligt är säkerheten för mikrotjänstarkitekturen och hur den skiljer sig från en monolitisk applikationsarkitektur. Detta leder till att fråga vilka de mest relevanta säkerhetsriskerna med att integrera och använda en mikrotjänstarkitektur är, och vilka mätvärden som kan användas för att upptäcka intrång baserat på riskerna kan vara. I denna rapport utforskas säkerheten för mikrotjänstarkitekturer genom en fallstudie av systemet hos Skatteverket, som är en mikrotjänstbaserad arkitektur som körs på Kubernetes. Intervjuer genomförs med personer som har erfarenhet av Kubernetes och mikrotjänster separat, både med anställda på Skatteverket och på annat håll. I intervjuerna identifieras risker och mätvärden för att märka av intrång som sedan analyseras med avseende på ett användningsfall i Skatteverketssystemet. En undersökning görs också om befintlig teknik som kan mildra de identifierade riskerna som är relaterade till en mikrotjänstarkitektur. De risker som förekommer i användningsfallet anses sedan till att vara mest relevanta i slutsatserna, de identifierade mätvärdena för att märka av intrång diskuteras och service mesh teknologin Istio anses mitigera störst antal av de identifierade riskerna.

The microservice architectural pattern refers to a system consisting of independently deployable services that communicate across networks. RabbitMQ is a popular message broker that can be used to make this communication possible. An alternative to this is Amazon Simple Queuing Service (SQS), which is a fully managed queuing service. By performing a literature- and case study, two systems with a microservice architecture are developed. One using RabbitMQ to communicate between the services, and the other using Amazon SQS. The systems are compared, with regards to message latency, ease of use and maintainability. The results show that RabbitMQ provides much lower message latency than Amazon SQS. Amazon SQS is however both easier to maintain and to use than RabbitMQ.
En mikrotjänstarkitektur syftar till ett system bestående av tjänster som kan driftsättas oberoende av varandra och som kommunicerar över nätverk. RabbitMQ är en populär meddelandemäklare som nyttjas för att möjliggöra ovan nämnd kommunikation. Ett alternativ till detta är Amazon Simple Queueing Service (SQS), vilket är en meddelandetjänst som helt och hållet förvaltas av Amazon. Genom att utföra en litteratur- och fallstudie utvecklas två system med en mikrotjänstarkitektur. Det ena nyttjar RabbitMQ för kommunikation mellan tjänster, medan det andra använder Amazon SQS. Båda systemen jämförs därefter med hänsyn till meddelandens fördröjning, användarvänlighet samt enkelhet att underhålla. Resultaten visar att meddelanden skickade genom RabbitMQ har mycket lägre fördröjning än de skickade genom Amazon SQS. Ur perspektiven användarvänlighet och enkelhet att underhålla är Amazon SQS ett mer fördelaktigt akternativ än RabbitMQ.

Microservices is one of the most commonly used buzzword of the systems architecture industry and is being adopted by several of the world’s largest technology companies such as Netflix, Uber and Amazon. The architecture which embraces splitting up your system in smaller independent units is an extension of the service-oriented architecture and an opponent of the monolithic architecture. Being a top buzzword and promises of extreme scalability has spiked the interest for microservices, but unlike the relatively simple monolithic architecture the complexity of microservices creates a new set of obstacles. This work sheds a light on these issues and implements solutions for some of the most frequent problems using a case study. The study shows that while microservices can help reduce the inner complexity of a system, it greatly increases the outer complexity and creates the need for a variety of tools aimed at distributed systems. It also concludes that communication and data storage are two of the most frequently occurring issues when developing microservices with the most difficult one being how you reason with and structure your data, especially for efficient queries across microservices.
Microservices eller så kallade mikrotjänster är ett ofta förekommande buzzword inom systemarkitektur och nyttjas av flera teknikjättar som exempelvis Netflix, Uber och Amazon. Arkitekturen som bygger på att dela upp sina system i mindre oberoende delar är en utbyggnad av den tjänstorienterade arkitekturen och numera motståndare till den klassiska monolitiska arkitekturen. En plats högt upp på trendlistan och lovord om extrem skalbarhet har gjort att intresset för mikrotjänster är enormt, men till skillnad från den relativt simpla monolitiska arkitekturen skapar komplexiteten hos mikrostjänster en rad nya hinder. Det här arbetet belyser dessa hinder och implementerar även lösningar för de vanligaste förekommande problemen med hjälp av en fallstudie. Resultatet visar att även fast en mikrotjänstarkitektur kan minska systemets interna komplexitet så leder det till en markant ökning av systemets yttre komplexitet och det skapas ytterligare behov av en mängd olika verktyg och tjänster designade för distribuerade system. Studien visar också att de två mest förekommande problemen vid utveckling av en mikrotjänstarkitektur är kommunikation och datalagring där hantering och struktur av data är den mest komplicerade och kräver mycket kunskap, speciellt för att skapa effektiva datasökningar som sträcker sig över flera mikrotjänster.

Microservices have emerged as an attractive alternative to more classical monolithic software application architectures. Microservices provides many benefits that help with code base comprehension, deployability, testability, and scalability. As the Information technology (IT) industry has grown ever larger, it makes sense for the technology giants to adopt the microservice architecture to make use of these benefits. However, with new software solutions come new security vulnerabilities, especially when the technology is new and vulnerabilities are yet to be fully mapped out. Authentication and authorization are the cornerstone of any application that has a multitude of users. However, due to the lack of studies of microservices, stemming from their relatively young age, there are no standardized design patterns for how authentication and authorization are best implemented in a microservice. This thesis investigates an existing microservice in order to secure it by applying what is known as a security design pattern for authentication and authorization. Different security patterns were tested and compared on performance. The differing levels of security provided by these approaches assisted in identifying an acceptable security versus performance trade-off. Ultimately, the goal was to give the patterns greater validity as accepted security patterns within the area of microservice security. Another goal was to find such a security pattern suitable for the given microservice used in this project. The results showed a correlation between increased security and longer response times. For the general case a security pattern which provided internal authentication and authorization but with some trust between services was suggested. If horizontal scaling was used the results showed that normal services proved to be the best target. Further, it was also revealed that for lower user counts the performance penalties were close to equal between the tested patterns. This meant that for the specific case where microservices sees lower amounts of traffic the recommended pattern was the one that implemented the maximum amount access control checks. In the case for the environment where the research were performed low amounts of traffic was seen and the recommended security pattern was therefore one that secured all services of the microservices.
Mikrotjänster har framträtt som ett mer attraktivt alternativ än mer konventionella mjukvaruapplikationsarkitekturer såsom den monolitiska. Mikrotjänster erbjuder flera fördelar som underlättar med en helhetsförståelse för kodbasen, driftsättning, testbarhet, och skalbarhet. Då IT industrin har växt sig allt större, så är det rimligt att tech jättar inför mikrotjänstarkitekturen för att kunna utnyttja dessa fördelar. Nya mjukvarulösningar medför säkerhetsproblem, speciellt då tekniken är helt ny och inte har kartlagts ordentligt. Autentisering och auktorisering utgör grunden för applikationer som har ett flertal användare. Då mikrotjänster ej hunnit blivit utförligt täckt av undersökning, på grund av sin relativt unga ålder, så finns det ej några standardiserade designmönster för hur autentisering och auktorisering är implementerade till bästa effekt i en mikrotjänst. Detta examensarbete undersöker en existerande mikrotjänst för att säkra den genom att applicera vad som är känt som ett säkerhetsdesignmönster för autentisering och auktorisering. Olika sådana mönster testades och jämfördes baserat på prestanda i olika bakgrunder. De varierade nivåerna av säkerhet från de olika angreppssätten som säkerhetsmönstrena erbjöd användes för att identifiera en acceptabel kompromiss mellan säkerhet mot prestanda. Målet är att i slutändan så kommer detta att ge mönstren en högre giltighet när det kommer till att bli accepterade som säkerhetsdesignmönster inom området av mikrotjänstsäkerhet. Ett annat mål var att hitta den bästa kandidaten bland dessa säkerhetsmönster för den givna mikrotjänsten som användes i projektet. Resultaten visade på en korrelation mellan ökad säkerhet och längre responstider. För generella fall rekommenderas det säkerhetsmönster som implementerade intern autentisering och auktorisering men med en viss del tillit mellan tjänster. Om horisontell skalning användes visade resultaten att de normala tjänsterna var de bästa valet att lägga dessa resurser på. Fortsättningsvis visade resultaten även att för ett lägre antal användare så var den negativa effekten på prestandan nästan likvärdig mellan de olika mönstren. Detta innebar att det specifika fallet då mikrotjänster ser en lägre mängd trafik så är det rekommenderade säkerhetsmönstret det som implementerad flest åtkomstkontroller. I fallet för den miljö där undersökningen tog plats förekom det en lägre mängd trafik och därför rekommenderades det säkerhetsmönster som säkrade alla tjänster närvarande i mikrotjänsten.

Microfrontend applications are composed of multiple smaller frontend applications, which are integrated at run-time. As with microservices, microfrontends can be updated in production at any time. There are no technological restrictions for releasing API-breaking updates. Therefore it is difficult to trust microfrontend applications to perform reliably in run-time and to introduce API-breaking updates without the risk of breaking consumers. This thesis presents Plutt, a tool that provides automatic guarantees for safely consuming microfrontends, by ensuring that updates in run-time are compatible. By using Plutt, consumers can be confident that a provided microfrontend will per- form the same during production as in development. Likewise, microfrontend providers can release updates without being concerned about how it will affect consumers. Moreover, a comprehensive survey about microfrontends is presented, where five industry experts are interviewed. Aspects that are not found in existing literature are discovered, which contributes to a broader knowledge base that helps future microfrontend research.
Mikrofrontend-applikationer är sammansatta av flera mindre frontend-applikationer som integreras under exekvering. Precis som med mikrotjänster, kan mikrofrontends bytas ut i produktion när som helst. Det saknas teknologiska restriktioner för att publicera API-brytande uppdateringar. Därför är det svårt att lita på att en mikrofrontend-applikation beter sig tillförlitligt under exekvering samt att introducera API-brytande uppdateringar utan att riskera att förstöra konsumenter. Det här examensarbetet presenterar Plutt, ett verktyg som erbjuder automatiska garantier för att säkert konsumera mikrofrontends genom att säkerställa att uppdateringar som introduceras i körtid är kompatibla. Genom att använda Plutt, kan konsumenter vara trygga i vetskapen att en försedd mikrofrontend presterar likadant under produktion som i utveckling. Samtidigt kan utvecklare som förser mikrofrontends släppa uppdateringar utan att bekymra sig över hur det påverkar konsumenter. Utöver Plutt, presenteras en grundlig kartläggning över mikrofrontends, där fem experter från industrin är intervjuade. Aspekter som inte hittas i existerande litteratur är upptäckta, vilket kunskapsbas och framtida forskning om mikrofrontends.