Containerization is widely recognized as a form of lightweight virtualization in the cloud. Due to its reliability, maturity, and rich capabilities, kubernetes has established itself as the de-facto standard for deployments and maintenance of containers. The availability of a kubernetes cluster for a cloud-native application would depend on the availability of the zone or region where the nodes are running. In general, the kubernetes cluster is deployed in a single shared network, but for higher availability, the nodes of the kubernetes cluster can be deployed in multiple regions. Deploying a multi-region kubernetes cluster aids in providing high availability for the service, allowing the data to be located closer to users, even when they are dispersed globally. However, with greater benefits come greater challenges, and networking in multi-region kubernetes clusters has proven to be a complex issue. Usually, kubernetes in a multi-region environment can be achieved by using tunneling across the worker nodes that are located in multiple regions and by using the VPN protocols as an overlay network. In this thesis, I investigated the performance of different VPN solutions in a multi-region kubernetes cluster and examine how these VPN solutions support kubernetes deployment. A literature review is conducted to identify the most common factors influencing VPN performance and to gather information on the differences between VPN solutions. I compared the response times of the multi-region Kubernetes cluster deployed with VPN solutions to the response times of the single shared region Kubernetes cluster also deployed with VPN solutions. This comparison allowed me to evaluate the performance of the VPN solution in a multi-region Kubernetes cluster. The aim of this thesis is to present the most influential factors, an overview of proposed VPN solutions, and performance comparisons of different VPN solutions in a multi-region kubernetes cluster.

With the growing use of cloud computing and need for resource effectiveness, the use of container technology has increased compared to virtual machines. This is since containers require fewer resources and are significantly faster to start up. A popular containerplatform is Docker which lets users manage and run containers. The containers are run from images that can be downloaded from different sources, Docker Hub being a popular choice. Because of container technology sharing the OS-kernel with the host, there is a great need to increase and monitor the security of containers and the images they are run from. To find vulnerabilities in images, there are image scanning tools available. In this dissertation, we study 5 different image scanning tools and their performance. Twentyfive random images were selected from popular images on Docker Hub and were then scanned for vulnerabilities with the tools in the study. We aimed to answer the following questions: (1) Are there any clear differences between the number of vulnerabilities found by different image vulnerability scanning tools? (2) Are there any differences between the types of vulnerabilities found by different image vulnerability scanning tools? (3) What is the relative effectiveness of different image vulnerability scanning tools? The results show that there are considerable differences between different container image scanning tools regarding the number of found vulnerabilities. We also found that there were differences regarding the severity-grading of found vulnerabilities between the tested tools. When using our proposed metric for calculation of relative effectiveness, we discovered that the tool with the highest relative effectiveness could still miss approximately 39 percent of the vulnerabilities in images. The tool with the lowest relative effectiveness could miss approximately 77 percent of the vulnerabilities in images.

Ziel dieser Arbeit ist es, die Entwicklung von RDF-Wissensbasen in verteilten kollaborativen Szenarien zu unterstützen. In dieser Arbeit wird eine neue Methodik für verteiltes kollaboratives Knowledge Engineering – „Quit“ – vorgestellt. Sie geht davon aus, dass es notwendig ist, während des gesamten Kooperationsprozesses Dissens auszudrücken und individuelle Arbeitsbereiche für jeden Mitarbeiter bereitzustellen. Der Ansatz ist von der Git-Methodik zum kooperativen Software Engineering inspiriert und basiert auf dieser. Die Analyse des Standes der Technik zeigt, dass kein System die Git-Methodik konsequent auf das Knowledge Engineering überträgt. Die Hauptmerkmale der Quit-Methodik sind unabhängige Arbeitsbereiche für jeden Benutzer und ein gemeinsamer verteilter Arbeitsbereich für die Zusammenarbeit. Während des gesamten Kollaborationsprozesses spielt die Data-Provenance eine wichtige Rolle. Zur Unterstützung der Methodik ist der Quit-Stack als eine Sammlung von Microservices implementiert, die es ermöglichen, die Semantic-Web-Datenstruktur und Standardschnittstellen in den verteilten Kollaborationsprozess zu integrieren. Zur Ergänzung der verteilten Datenerstellung werden geeignete Methoden zur Unterstützung des Datenverwaltungsprozesses erforscht. Diese Managementprozesse sind insbesondere die Erstellung und das Bearbeiten von Daten sowie die Publikation und Exploration von Daten. Die Anwendung der Methodik wird in verschiedenen Anwendungsfällen für die verteilte Zusammenarbeit an Organisationsdaten und an Forschungsdaten gezeigt. Weiterhin wird die Implementierung quantitativ mit ähnlichen Arbeiten verglichen. Abschließend lässt sich feststellen, dass der konsequente Ansatz der Quit-Methodik ein breites Spektrum von Szenarien zum verteilten Knowledge Engineering im Semantic Web ermöglicht.:Preface by Thomas Riechert Preface by Cesare Pautasso 1 Introduction 2 Preliminaries 3 State of the Art 4 The Quit Methodology 5 The Quit Stack 6 Data Creation and Authoring 7 Publication and Exploration 8 Application and Evaluation 9 Conclusion and Future Work Bibliography Web References List of Figures List of Tables List of Listings List of Definitions and Acronyms List of Namespace Prefixes / The aim of this thesis is to support the development of RDF knowledge bases in a distributed collaborative setup. In this thesis, a new methodology for distributed collaborative knowledge engineering – called Quit – is presented. It follows the premise that it is necessary to express dissent throughout a collaboration process and to provide individual workspaces for each collaborator. The approach is inspired by and based on the Git methodology for collaboration in software engineering. The state-of-the-art analysis shows that no system is consequently transferring the Git methodology to knowledge engineering. The key features of the Quit methodology are independent workspaces for each user and a shared distributed workspace for the collaboration. Throughout the whole collaboration process data provenance plays an important role. To support the methodology the Quit Stack is implemented as a collection of microservices, that allow to integrate the Semantic Web data structure and standard interfaces with the distributed collaborative process. To complement the distributed data authoring, appropriate methods to support the data management process are researched. These management processes are in particular the creation and authoring of data as well as the publication and exploration of data. The application of the methodology is shown in various use cases for the distributed collaboration on organizational data and on research data. Further, the implementation is quantitatively compared to the related work. Finally, it can be concluded that the consequent approach followed by the Quit methodology enables a wide range of distributed Semantic Web knowledge engineering scenarios.:Preface by Thomas Riechert Preface by Cesare Pautasso 1 Introduction 2 Preliminaries 3 State of the Art 4 The Quit Methodology 5 The Quit Stack 6 Data Creation and Authoring 7 Publication and Exploration 8 Application and Evaluation 9 Conclusion and Future Work Bibliography Web References List of Figures List of Tables List of Listings List of Definitions and Acronyms List of Namespace Prefixes

As IT platforms grow larger and more complex, so does the underlying infrastructure. Virtualization is an essential factor for more efficient resource allocation, improving both the management and environmental impact. It allows more robust solutions and facilitates the use of IaC (infrastructure ascode). Many systems developed today consist of containerized microservices. Considered the standard of container orchestration, Kubernetes is the natural next step for many companies. But how do we move on from previous solutions to a Kubernetes cluster? We found that there are not a lot of detailed enough guidelines available, and set out to gain more knowledge by diving into the subject - implementing prototypes that would act as a foundation for a resulting guideline of how it can be done.

Serverless edge computing is a distributed network and computing system in which the data is processed at the edge of the network based on serverless architecture. It can provide large-scale computing and storage resources with low latency, which are very useful in AI applications such as object detection. However, when analyzing serverless computing architectures, we model them using simple models, such as single server or multi-server queues, and it is important to make sure these models can explain the behaviors of real systems. Therefore, we focus on the performance evaluation of serverless edge computing for AI applications in this project. With that, we aim at proposing more realistic and accurate models for real serverless architectures. In this project, our objective is to evaluate the performance and model mathematically an object-detection application running on a serverless architecture implemented with Kubernetes. This project provides a detailed description of the implementation of the serverless platform and YOLOv5-based object detection application. After implementation, we design experiments and make performance evaluations of the time of object detection results and quality of object detection results. Finally, we conclude that the number of users in the system significantly affects the service time. We observe that there is no queue in the system, so we cannot just use mathematical models with a queue to model the system. Therefore, we consider that the processor sharing model is more appropriate for modeling this serverless architecture. This is very helpful for giving insights on how to make more realistic and accurate mathematical queueing models for serverless architectures. For future work, other researchers can also implement our serverless platform and do further development, such as deploying other serverless applications on it and making performance evaluations. They can also design other use-cases for the experiments and make further analyses on queue modeling of serverless architecture based on this project. / Serverless edge computing är ett distribuerat nätverk och datorsystem där data bearbetas i kanten av nätverket baserat på serverlös arkitektur. Det kan tillhandahålla storskaliga dator- och lagringsresurser med låg latens, vilket är mycket användbart i AI-applikationer som objektdetektering. Men när vi analyserar serverlösa datorarkitekturer modellerar vi dem med hjälp av enkla modeller, till exempel enstaka servrar eller köer med flera servrar, och det är viktigt att se till att dessa modeller kan förklara beteendet hos verkliga system. Därför fokuserar vi på prestandautvärdering av serverlös edge computing för AI-applikationer i detta projekt. Med det siktar vi på att föreslå mer realistiska och exakta modeller för riktiga serverlösa arkitekturer. I detta projekt är vårt mål att utvärdera prestandan och matematiskt modellera en objektdetekteringsapplikation som körs på en serverlös arkitektur implementerad med Kubernetes. Detta projekt ger en detaljerad beskrivning av implementeringen av den serverlösa plattformen och den YOLOv5-baserade objektdetekteringsapplikationen. Efter implementering designar vi experiment och gör prestandautvärderingar av tidpunkten för objektdetekteringsresultat och kvaliteten på objektdetekteringsresultaten. Slutligen drar vi slutsatsen att antalet användare i systemet avsevärt påverkar servicetiden. Vi observerar att det inte finns någon kö i systemet, så vi kan inte bara använda matematiska modeller med en kö för att modellera systemet. Därför anser vi att processordelningsmodellen är mer lämplig för att modellera denna serverlösa arkitektur. Detta är mycket användbart för att ge insikter om hur man gör mer realistiska och exakta matematiska kömodeller för serverlösa arkitekturer. För framtida arbete kan andra forskare också implementera vår serverlösa plattform och göra vidareutveckling, såsom att distribuera andra serverlösa applikationer på den och göra prestandautvärderingar. De kan även designa andra användningsfall för experimenten och göra ytterligare analyser av kömodellering av serverlös arkitektur utifrån detta projekt.

Цель работы – разработка серверной части приложения и инфраструктурных компонентов для проекта «Мониторинг IT-конференций». Методы исследования: анализ, сравнение, систематизацию и обобщение данных о существующих и разработанных инфраструктурных компонентах, апробация современных подходов при построении архитектуры инфраструктуры. В результате работы сконфигурированы две виртуальные машины для работы Kubernetes и Gitlab Runner, настроены компоненты хранения постоянных данных для PostgreSQL, RabbitMQ и S3-хранилища на базе Rook Ceph, создано приложение на базе Django для предоставления API клиентскому приложению, написана конфигурация для Gitlab CI, обеспечивающая сборку образа приложения и его развертывание в Kubernetes. Созданное приложение предоставляет функционал управления контентом для администраторов сервиса (загрузка видео в S3-хранилище, разметка с помощью системы тегов, привязывание конференций к спикерам) и HTTP API для клиентского приложения с возможностью регистрации, аутентификации через JWT-токены, иерархическому поиску по системе тегов и отдаче подписанных ссылок на S3-хранилище для просмотра видео. / The purpose of the work is to develop the server part of the application and infrastructure components for the project "Monitoring IT conferences". Research methods: analysis, comparison, systematization and generalization of data on existing and developed infrastructure components, approbation of modern approaches in building infrastructure architecture. As a result of the work, two virtual machines were configured for Kubernetes and Gitlab Runner, persistent data storage components for PostgreSQL, RabbitMQ and S3 storage based on Rook Ceph were configured, an application based on Django was created to provide an API to a client application, a configuration for Gitlab CI was written, providing building an application image and deploying it to Kubernetes. The created application provides content management functionality for service administrators (uploading videos to S3 storage, marking using a tag system, binding conferences to speakers) and an HTTP API for a client application with the ability to register, authenticate through JWT tokens, hierarchical search using the tag system, and giving back signed links to S3 storage for watching videos.

With the current developments in modern web browsers, WebAssembly has been a rising trend over the last four years. Aimed at replacing bits of JavaScript functionality, it attempts to bring extra features to achieve portability and sandboxing through virtualisation. After the release of the WebAssembly System Interface, more and more projects have been working on using it outside web pages and browsers, in scenarios such as embedded, serverless, or distributed computing. This is thus not only relevant to the web and its clients, but also to applications in distributed systems. Considering the novelty of the topic, there is currently very little related scientific literature. With constant changes in development, proposals and goals, there is a large gap in relevant research. We aim to help bridge this gap by focusing on Rust and Arc-Lang, a domain-specific language for data analytics, in order to provide an overview of how far the technology has progressed, in addition to what runtimes there are and how they work. We investigate what kind of use case WebAssembly could have in the context of distributed systems, as well as how it can benefit data processing pipelines. Even though the technology is still immature at first glance, it is worth checking whether its proposals have been implemented, and how its performance compared to that of native Rust can affect data processing in a pipeline. We show this by benchmarking a filter program as part of a distributed container environment, while looking at different WebAssembly compilers such as Cranelift and LLVM. Then, we compare the resulting statistics to native Rust and present a synopsis of the state of WebAssembly in a distributed context. / I takt med den nuvarande utvecklingen av moderna webbläsare har WebAssembly stigit i trend under de senaste fyra åren. WebAssembly har som syfte att ersätta och utöka JavaScript med funktionalitet som är portabel och isolerad från omvärlden genom virtualisering. Efter lanseringen av WebAssembly System Interface har fler och fler projekt börjat applicera WebAssembly utanför webbsidor och webbläsare, i scenarier som inbäddade, serverlösa eller distribuerade beräkningar. Detta har gjort WebAssembly till ett språk som inte bara är relevant för webben och dess användare, utan även för applikationer i distribuerade system. Med tanke på ämnets framkant finns det för närvarande väldigt lite relaterad vetenskaplig litteratur. Ständiga förändringar i utveckling, förslag och mål har resulterat i stort gap i relevant forskning. Vi strävar efter att hjälpa till att överbrygga denna klyfta genom att studera WebAssembly i perspektivet av Rust och Arc-Lang, ett domänspecifikt språk för dataanalys, för att ge en översikt över hur långt tekniken har kommit, och samt utreda vilka exekveringssystem som finns och hur de fungerar. Vi undersöker vilken typ av användning WebAssembly kan ha i samband med distribuerade system, samt hur det kan gynna databehandlingspipelines. Även om tekniken fortfarande är ny vid första anblicken, är det värt att kontrollera om dess förslag har implementerats och hur dess prestanda gentemot Rust kan påverka databehandling i en pipeline. Vi visar detta genom att benchmarka ett filtreringsprogram som en del av en distribuerad containermiljö, samtidigt som vi tittar på olika WebAssembly-kompilatorer som exempelvis Cranelift och LLVM. Vi jämför resultaten med Rust och presenterar en sammanfattning av WebAssemblys tillstånd i sammanhanget av distribuerade system.

This thesis explores the creation of a scaling, containerized, advertisement server that will be used by Gold Town Games AB to better integrate ads into their application(s). The server is built as a Docker image that will be used to create server instances on AWS Elastic Container Service for automatic scaling and server resource configuration. The server was created with the intention that GTG will have full control over what advertisements are shown in their application(s) and to seamlessly integrate sponsored logos onto jerseys or sports fields. This will not only serve as a source of income with advertisers paying for ad space, but it will also make the game elements more realistic as we have come to expect teams and stadiums to be sponsored and plastered with company logos. Another important part when displaying advertisement is to track statistics for the ads, since without a way to show advertisers that their ads are shown and that they are generating engagement it is very hard to sell the ad space. / Detta examensarbete utforskar skapandet av en skalbar, containerbaserad, reklamserver som kommer användas av Gold Town Games AB för att integrera reklam i deras applikation(er). Servern är byggd som en Docker-bild som används för att skapa instanser på AWS Elastic Container Service för automatisk skalning och serverresurshantering. Servern är utvecklad med tanken att GTG ska ha full kontroll över vilken reklam som visas i deras applikation(er) och för att kunna lägga till sponsrade loggor på matchtröjor och i arenor. Detta är inte bara en extra form av inkomst, då annonsörer betalar för reklamplatser, utan hjälper även till att få delar av spelen att kännas mer realistiska då vi är vana att lag och arenor är sponsrade och fulla av företagsloggor. En annan viktig del när man visar reklam är att kunna spara statistik för den, eftersom det skulle vara väldigt svårt att sälja reklamplatser utan att kunna visa att folk faktiskt ser reklamen.

Continuous Delivery is a software development discipline where the software is always kept in a release ready state. It has proven to be a challenge for companies to adopt the practices of Continuous Delivery, but the benefits it brings may well be worth overcoming the challenges the adoption process brings. But the problem with the challenges is that they appear to be unknown, different adoption cases report different problems, some even consider something a solution whilst another case considered the same subject to be a problem. Thus adopting Continuous Delivery is a tricky process. But the tech company IST is interested in adopting Continuous Delivery and are looking to take a soft start by adding new functionality to their service-oriented system, this functionality is to be able to run multiple versions of their services at the same time. This study has implemented this functionality in their system and then researched possible issues or benefits the functionality would have towards Continuous Delivery. Finally, a discussion was made on how the author thinks approaching Continuous Delivery should be done by any company or developer interested.

Master thesis deals with concept and realization of wireless measuring system, powered by battery. The system consists of two main parts. First part, the node, is designed for the lowest possible power consumption. This is achieved mainly by usage of microcontroller from the STM32 family. Gathered information is transfered via RFM69 module. Second part, the gateway, is powered by Linux operating system on Raspberry Pi. Data from the gateway proxy are propagated through MQTT into Home Assistant, which interprets the results.