Potreba dodania hodnoty uživatelom každodočne rastie na kompetitívnom trhu IT. Agilita a DevOps sa stávajú kritickými aspektami pre vývoj software, vyhľadávajúci nástroje ktoré podporujú agilnú kultúru. Softwarové projekty v agilnej kultúre majú častú tendenciu zaoberať sa stratégiami nasadenia ktoré redukujú risk nasadenia nových zmien do existujúceho systému. A však, prostredia určené pre vývoj a testovanie sa takmer vždy odlišujú od produkčných. Využitie primeranej stratégie nasadenie ako canary zlepšuje celkovú stabilitu systému testovaním nových zmien na malej vzorke produkčnej prevádzky. Bolo vykonaných niekoľko experimentov pre dôkaz, že stratégia canary môže pozitívne ovplyvniť stabilitu nasadení a redukovať risk ktorý prinášajú nové zmeny.

The development of applications that use microservice architecture patterns is increasingrapidly, and this architecture is proven to be successful in many different areas, especiallyin cloud computing. The reason microservices and cloud computing are a great matchis the possibility of scaling and deploying individual services, which positively affects thecost and utilization. This architecture pattern includes some challenges for the devel-opers, such as placement optimisation and knowledge about how the applications aredeployed.This study intends to clarify how the applications in a multi-cluster environment are de-ployed. A service model was created, describing how applications built with microservicearchitecture patterns communicate to each other and which microservices the applicationcontains. More specifically, this can be seen as the first step of placement optimisationthat will be developed in the future. The test cases used to produce the service modelshave various characteristics, such as control planes, where applications were deployed,and numbers of replicas. These kinds of characteristics were varied so that the servicemodels could be relied on and such that the model created works independent of howthe deployment model is created. The created service models show that the applicationtopology is not restricted for the reverse engineering method to work. Independent ofthe number of control planes or replicas, this method worked. Furthermore, the servicemodels created for each test case gave the correct outcome for each application regardingmicroservices and the connections between each microservice.

Microservice architecture is an emerging paradigm that has been unceasingly adopted by large organizations to develop flexible, agile, and distributed applications. This architecture involves breaking a large monolithic application into multiple services that can be deployed and scaled autonomously. Moreover, it helps to improve the resiliency and fault tolerance of a large-scale distributed application. However, this architecture is not without challenges. It increases the number of services communicating with each other, leading to an increased surface of attack. To overcome the security vulnerabilities, it is important that the communication between the services must be secured. Service Mesh is increasingly embraced to resolve the security challenges of microservices and facilitate secure and reliable communication. It is a dedicated infrastructure layer on top of microservices responsible for their networking logic. It uses sidecar proxies to ensure secure and encrypted communication between the services. This thesis studies different deployment models of service meshes, identifies the reasons for federating heterogeneous service meshes, investigates the existing problems faced during the federation process, and proposes a solution to achieve a secure federation between heterogeneous service meshes, i.e., Istio and Consul. The security of the proposed solution was evaluated against the basic security requirements, such as Authenticity, Confidentiality, and Integrity. The evaluation results proved the solution to be secure and feasible for implementation. / Microservice är ett framväxande paradigm som oavbrutet har anammats av stora organisationer för att utveckla flexibla, agila och distribuerade applikationer. denna arkitektur innebär att dela upp en stor monolitisk applikation i flera tjänster som kan distribueras och skalas autonomt. Dessutom hjälper det till att förbättra motståndskraften och feltolerans för en storskalig distribuerad applikation. Men denna arkitektur är inte utan utmaningar. Det ökar antalet tjänster som kommunicerar med varandra, vilket leder till en ökad attackyta. För att övervinna säkerhetsproblemet nerabiliteter är det viktigt att kommunikationen mellan tjänsterna måste säkra. Service Mesh anammas alltmer för att lösa säkerhetsutmaningarna med microservice och underlätta säker och pålitlig kommunikation. Det är en dedikerad infrastruktur lager ovanpå mikrotjänster som ansvarar för deras nätverkslogik. Den använder sidovagn fullmakter för att säkerställa säker och krypterad kommunikation mellan tjänsterna. Detta avhandlingen studerar olika utbyggnadsmodeller av servicenät, identifierar orsakerna för att förena heterogena servicenät, undersöker de befintliga problemen som står inför under förbundsprocessen, och föreslår en lösning för att uppnå en säker federation mellan heterogena tjänstemaskor, d. v. s. Istio och Consul. Säkerheten för prolösningen utvärderades mot de grundläggande säkerhetskraven, såsom Autentticitet, konfidentialitet och integritet. Utvärderingsresultaten visade att lösningen var säker och genomförbar för implementering.

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.

Edge computing, as an approach to leveraging computation capabilities located in different places, is widely deployed in the industry nowadays. With the development of edge computing, many big companies move from the traditional monolithic software architecture to the microservice design. To provide better performance of the applications which contain numerous loosely coupled modules that are deployed among multiple clusters, service routing among multiple clusters needs to be effective. However, most existing solutions are dedicated to static service routing and load balancing strategy, and thus the performance of the application cannot be effectively optimized when network condition changes.To address the problem mentioned above, we proposed a dynamic weighted round robin algorithm and implemented it on top of the cutting edge service mesh Istio. The solution is implemented as a Docker image called RoutingAgent, which is simple to deployed and managed. With the RoutingAgent running in the system, the weights of the target routing clusters will be dynamically changed based on the detected inter-cluster network latency. Consequently, the client-side request turnaround time will be decreased.The solution is evaluated in an emulated environment. Compared to the Istio without RoutingAgent, the experiment results show that the client-side latency can be effectively minimized by the proposed solution in the multicluster environment with dynamic network conditions. In addition to minimizing response time, emulation results demonstrate that loads of each cluster are well balanced. / Edge computing, som ett tillvägagångssätt för att utnyttja beräkningsfunktioner som finns på olika ställen, används i stor utsträckning i branschen nuförtiden. Med utvecklingen av kantdatabasen flyttar många stora företag från den traditionella monolitiska mjukvaruarkitekturen till mikroserviceteknik. För att ge bättre prestanda för de applikationer som innehåller många löst kopplade moduler som distribueras bland flera kluster, måste service routing bland flera kluster vara effektiva. De flesta befintliga lösningarna är dock dedikerade till statisk service-routing och belastningsbalanseringsstrategi, vilket gör att programmets prestanda inte effektivt kan optimeras när nätverksförhållandena ändras.För att ta itu med problemet som nämnts ovan föreslog vi en dynamisk viktad round robin-algoritm och implementerade den ovanpå den avancerade servicenätverket Istio. Lösningen implementeras som en Docker-bild som heter RoutingAgent, som är enkel att distribuera och hantera. Med agenten som körs i systemet ändras vikten av målruteringsklustret dynamiskt baserat på den upptäckta interklusternätets latens. Följaktligen kommer klientsidans begäran om omställningstid att minskas.Lösningen utvärderas i en emulerad miljö. Jämfört med Istio utan agent visar experimentresultaten att klientens latentitet effektivt kan minimeras av den föreslagna lösningen i multicluster-miljö med dynamiska nätverksförhållanden. Förutom att minimera responstid visar emuleringsresultat att belastningar i varje kluster är välbalanserade.

Mobilné zariadenia sú v rámci technologickej histórie novinka a pri technológii, ktorá sa vyvíja tak rapídnym tempom a rastom používania je nutné dbať na zabezpečenie. Táto diplomová práca sa zaoberá rozborom bezpečnostných mechanizmov používaných v Android OS a komunikáciou medzi OS Android a vzdialeným serverom. Cieľom je preskúmať tieto mechanizmy a otestovať aké kryptografické metódy a postupy je najvýhodnejšie používať z hľadiska bezpečnosti s ohľadom na efektivitu. Tieto znalosti boli použité pre vytvorenie demonštračného systému, ktorý využíva vybrané zabezpečovacie mechanizmy a kryptografické postupy.