In order to fully benefit from cloud computing, services are designed following the “multi-tenant” architectural model which is aimed at maximizing resource sharing among users. However, multi-tenancy introduces challenges of security, performance isolation, scaling and customization. RStudio server is an open source Integrated Development Environment (IDE) accessible over a web browser for R programming language. The purpose of this thesis is to develop an open source multi-user distributed system on Hopsworks, a data intensive and AI platform, following the multi-tenant model, that provides RStudio as Software as a Service (SaaS). Our goal is to promote collaboration among users when using RStudio and the learning and teaching of R by enabling users easily have access to same computational environments and resources while eliminating installation and maintenance tasks. Hopsworks introduces project-based multi-tenancy where users within a project share project resources (e.g datasets, programs and services) for collaboration which introduces one more challenge of sharing project resources in RStudio server instances. To achieve our purpose and goal we therefore needed to solve the following problems: performance isolation, security, project resources sharing, scaling and customization. Our proposed model is on demand single user RStudio server instances per project. Our system is built around Docker and Kubernetes to solve the problems of performance isolation, security and scaling. We introduce HopsFS-mount, that allows securely mounting HopsFS via FUSE to solve the project resources (datasets and programs) sharing problem. We integrate our system with Apache Spark which can scale and handle Big Data processing workloads. Also we provide a UI where users can provide custom configuration and have full control of their own RStudio server instances. Our system was tested on a GCP cluster with four worker nodes each with 30GB of RAM allocated to them. The tests on this cluster showed that 44 RStudio servers, each with 2GB of RAM, can be run concurrently. Our system can scale out to potentially support hundreds of concurrently running RStudio servers by adding more resources (CPUs and RAM) to the cluster or system. / För att dra full nytta av molntjänster är vissa applikationer designade för multitenans som syftar till att maximera resursdelning mellan användare. Dock introducerar multitenans utmaningar i hänsyn till resursdelning, säkerhet, prestandaisolering, anpassning och skalning. RStudio-server är en öppen källkod Integrerad utvecklingsmiljö (IDE) tillgänglig över en webbläsare för programmeringsspråket R. Syftet med denna avhandling är att utveckla ett distribuerat system med öppen källkod för flera användare på Hopsworks, en data krävande AI-plattform, efter multitenans-modellen, som tillhandahåller RStudio som Software as a Service (SaaS). Vårt mål är att främja samarbete mellan användare vid användning av RStudio, inlärning och undervisning av R genom att göra det enkelt för användare att ha tillgång till samma beräknings miljöer och resurser samtidigt som installation och underhållsarbete elimineras. Hopsworks introducerar projektbaserad multitenans där användare inom ett projekt delar projektresurser (t.ex. datamängder, program och tjänster) för samarbete som introducerar ytterligare en utmaning att dela projektresurser i RStudio server instanser. För att uppnå vårt syfte och mål behövde vi därför lösa följande problem: prestandaisolering, säkerhet, projekt resursdelning, skalning och anpassning. Vår föreslagna modell är på bergäran en-användares RStudio-serverinstanser per projekt. Vårt system är byggt kring Docker och Kubernetes för att lösa problemen med prestanda isolering, säkerhet och skalning. Vi introducerar HopsFS-mount, som gör det möjligt att säkert montera HopsFS via FUSE för att lösa resurs (datamängder och program) delning problemet. Vi integrerar vårt system med Apache Spark som kan skala och hantera Big Data bearbetning belastningar. Vi tillhandahåller också ett användargränssnitt där användare kan tillhandahålla anpassad konfiguration och ha full kontroll över sina egna RStudio-serverinstanser. Vårt system testades på ett GCP-kluster med fyra arbets noder, varje node hade 30 GB RAM. Testerna på detta kluster visade att 44 RStudio-servrar, var och en med 2 GB RAM, kan köras samtidigt. Vårt system kan även skala ut för att potentiellt stödja hundratals RStudio-servrar som samtidigt körs genom att lägga till fler resurser (CPU:er och RAM) i klustret eller systemet.

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.

Software projects can nowadays have complex infrastructures behind them, in the form of libraries and various other dependencies which need to be installed on the machines they are being developed on. Setting up this infrastructure on a new machine manually can be a tedious process prone to errors. This can be avoided by automating the process using a software provisioning tool, which can automatically transfer infrastructure between machines based on instructions which can be version controlled in similar ways as the source code. Docker and Vagrant are two tools which can achieve this. Docker encapsulates projects into containers, while Vagrant handles automatic setup of virtual machines. This study compares Docker and Vagrant regarding their performance for machine level provisioning, both when setting up an infrastructure for the first time on a new machine, as well as when implementing a change in the infrastructure configuration. This was done by provisioning a project using both tools, and performing experiments measuring the time taken for each tool to perform the tasks. The results of the experiments were analyzed, and showed that Docker performed significantly better than Vagrant in both tests. However, due to limitations of the study, this cannot be assumed to be true for all use cases and scenarios, and performance is not the only factor to consider when choosing a provisioning tool. According to the data collected in this study, Docker is thereby the recommended tool to choose, but more research is needed to determine whether other test cases yield different results. / Moderna mjukvaruprojekt kan ha en komplex infrastruktur bakom sig, i form av bibliotek och andra beroenden som måste installeras på utvecklarmaskiner. Att konfigurera denna infrastruktur på en ny maskin manuellt kan vara en tidskrävande process, som även kan leda till en ofullständigt eller felaktigt konfigurerad lösning. Detta kan undvikas genom att automatisera processen med hjälp av provisioneringsverktyg, som automatiskt kan överföra infrastrukturer mellan maskiner baserat på instruktioner som kan versionshanteras på liknande sätt som källkoden. Docker och Vagrant är två verktyg som kan användas till detta ändamål. Docker kapslar in projektet i containers, medan Vagrant hanterar automatisk konfiguration av virtuella maskiner. Denna studie jämför Docker och Vagrant avseende deras prestanda för mjukvaruprovisionering på maskinnivå, både när det kommer till en förstagångsinstallation av infrastrukturen på en ny maskin, och även implementering av en ändring i konfigurationen av infrastrukturen. Denna jämförelse gjordes genom att implementera båda lösningarna, och sedan utföra experiment för att mäta tidsåtgången för båda verktygen att lösa de två uppgifterna. Resultaten av experimenten analyserades, och visade att Docker presterade bättre än Vagrant i båda tester. På grund av begränsningar i studien kan detta inte antas vara sant för alla användningsområden och scenarier, och prestanda är inte den enda faktorn att ha i åtanke när ett provisioneringsverktyg ska väljas. Baserat på datan insamlad i denna studie är Docker därmed verktyget som rekommenderas, men mer forskning krävs för att avgöra om andra testområden ger andra resultat.

Smartphones and other Internet of Things devices have become a rapidly growing topic. Along with the growth comes new technologies, likeWeb Real- Time Communication (WebRTC), that enables richer services to be built for the devices. These kind of services are typically consumed on-demand, in shorter periods at a time. Likewise have cloud computing exploded in popularity during the last years. Cloud computing offers compelling advantages, such as rapid elasticity and on-demand usage, that allow servers' resource utilization to be more effcient. The flexibility of allocating and releasing resources swiftly as they are required, enables services that run in the cloud to adopt to ephemeral workloads. The research in this thesis targets a real-time video streaming service that is based on WebRTC. Incoming streams are handled by Multipoint Control Units (MCUs) that have the responsibility to redistribute the incoming streams to the consumers. Scaling horizontally aligns well with the idea of cloud computing. The work in this thesis is based on the extreme case where each of the incoming streams are handled by a separate MCU. The thesis presents the process of finding a exible Cloud Execution Environment (CEE) for the streaming service. The process includes an analysis of the streaming service's requirements, an evaluation of existing solutions, and an implementation. Moreover, the thesis includes a discussion about the capabilities of the implemented system. The result of the thesis is a CEE upon which the streaming service can be deployed and managed. The developed CEE allows any workload that is encapsulated within a Docker container to be orchestrated, not exclusively the streaming service, which makes the implementation viable to other cloud computing projects. / Användandet av smartphones och andra "Internet of Things"-enheter ökar snabbt. I takt med ökningen, så släpps nya tekniker som möjliggör utveckling av mer avancerade tjänster. Ett exampel är Web Real-Time Communication (WebRTC). Den här typen av tjänster konsumeras oftast sporadiskt under kortare tidsintervall. även cloud computing har drastiskt ökat i popularitet under de senaste åren. Hög elasticitet samt möjligheten att allokera datorresurser på begäran har medfört att utnyttjandegraden av datorers kapacitet kan höjas. Flexibiliteten att snabbt kunna allokera och frigöra resurser möjliggör att tjänster kan utvecklas för att utnyttja upp- och nerskalningsm öjligheterna bättre, även för kortvariga lastökningar. Forskningen i rapporten riktar in sig på ett system för videoströmning mellan användare i realtid baserat påa WebRTC. Inkommande strömmar hanteras av Multipoint Control Units (MCUs), som har som uppgift att vidaredistribuera strömmarna till andra användare som vill spela upp strömmen. Horisontell skalning och cloud computing har mycket gemensamt. Det underliggande arbetet till den här rapporten fokuserar på ett extremfall, där varje inkommande videoström hanteras av en enskild MCU. Den här uppsatsen presenterar den process som användes för att ta fram en lämplig molnlösning för strömningssystemet. Processen beståar av en kravanalys av strömningssystemet, en jämförelse av befintliga lösningar samt en implementation av en molnlösning. Slutligen så innehåller uppsatsen en utvärdering av implementationen. Resultatet av uppsatsen är en molnlösning som videoströmningssystemet kan driftsättas och köras på. Molnlösningen är inte begränsad till videoströmningssystemet utan klarar av att hantera alla applikationer som paketerats inuti Docker-kapslar. Molnlösningen är så pass generell att den kan användas till andra projekt inom cloud computing.

Setting up one's software environment and ensuring that all dependencies and settings are the same across the board when deploying an application, can nowadays be a time consuming and frustrating experience. To solve this, the industry has come up with an alternative deployment environment called software containers, or simply containers. These are supposed to help with eliminating the current troubles with virtual machines to create a more streamlined deployment experience.The aim of this study was to compare this deployment technique, containers, against the currently most popular method, virtual machines. This was done using a case study where an already developed application was migrated to a container and deployed online using a cloud provider’s services. Then the application could be deployed via the same cloud service but onto a virtual machine directly, enabling a comparison of the two techniques. During these processes, information was gathered concerning the usability of the two environments. To gain a broader perspective regarding the usability, an interview was conducted as well. Resulting in more well-founded conclusions. The conclusion is that containers are more efficient regarding the use of resources. This could improve the service provided to the customers by improving the quality of the service through more reliable uptimes and speed of service. However, containers also grant more freedom and transfers most of the responsibility over to the developers. This is not always a benefit in larger companies, where regulations must be followed, where a certain level of control over development processes is necessary and where quality control is very important. Further research could be done to see whether containers can be adapted to another company’s current environment. Moreover, how different cloud provider’s services differ. / Att sätta upp och konfigurera sin utvecklingsmiljö, samt att försäkra sig om att alla beroenden och inställningar är lika överallt när man distribuerar en applikation, kan numera vara en tidskrävande och frustrerande process. För att förbättra detta, har industrin utvecklat en alternativ distributionsmiljö som man kallar “software containers” eller helt enkelt “containers”. Dessa är ämnade att eliminera de nuvarande problemen med virtuella maskiner och skapa en mer strömlinjeformad distributionsupplevlese. Målet med denna studie var att jämföra denna nya distributionsteknik, containrar, med den mest använda tekniken i dagsläget, virtuella maskiner. Detta genomfördes med hjälp av en fallstudie, där en redan färdigutvecklad applikation migrerades till en container, och sedan distribuerades publikt genom en molnbaserad tjänst. Applikationen kunde sedan distribueras via samma molnbaserade tjänst men på en virtuell maskin istället, vilket möjliggjorde en jämförelse av de båda teknikerna. Under denna process, samlades även information in kring användbarheten av de båda teknikerna. För att få ett mer nyanserat perspektiv vad gäller användbarheten, så hölls även en intervju, vilket resulterade i något mer välgrundade slutsatser. Slutsatsen som nåddes var att containrar är mer effektiva resursmässigt. Detta kan förbättra den tjänst som erbjuds kunder genom att förbättra kvalitén på tjänsten genom pålitliga upp-tider och hastigheten av tjänsten. Däremot innebär en kontainerlösning att mer frihet, och därmed även mer ansvar, förflyttas till utvecklarna. Detta är inte alltid en fördel i större företag, där regler och begränsningar måste följas, en viss kontroll över utvecklingsprocesser är nödvändig och där det ofta är mycket viktigt med strikta kvalitetskontroller. Vidare forskning kan utföras för att undersöka huruvida containers kan anpassas till ett företags nuvarande utvecklingsmiljö. Olika molntjänster för distribuering av applikationer, samt skillnaderna mellan dessa, är också ett område där vidare undersökning kan bedrivas.

Modern stream processing engines usually use the Java virtual machine (JVM) as execution platform. The JVM increases portability and safety of applications at the cost of not fully utilising the performance of the physical machines. Being able to use hardware accelerators such as GPUs for computationally heavy analysis of data streams is also restricted when using the JVM. The project Continuous Deep Analytics (CDA) explores the possibility of a stream processor executing native code directly on the underlying hardware using Rust. Rust is a young programming language which can statically guarantee the absence of memory errors and data races in programs without incurring performance penalties during runtime. Rust is built on top of LLVM which gives Rust a theoretical possibility to compile to a large set of target platforms. Each specific target platform does however require a specific configured runtime environment for Rust’s compiler to work properly. The CDA compiler will run in a distributed setting where the compiler has to be able to reallocate to different nodes to handle node failures. Setting up a reassignable Rust compiler in such a setting can be error prone and Docker is explored as a solution to this problem. A concurrent thread based system is implemented in Scala for building Docker images and compiling Rust in containers. Docker shows a potential of enabling easy reallocation of the driver without manual configuration. Docker has no major effect on Rust’s compile time. The large Docker images required to compile Rust is a drawback of the solution. They will require substantial network traffic to reallocate the driver. Reducing the size of the images would therefore make the solution more responsive. / Moderna strömprocessorer använder vanligtvis Javas virtuella maskin (JVM) som plattform för exekvering. Det gör strömprocessorerna portabla och säkra men begränsar hur väl de kan använda kapaciteten i den underliggande fysiska maskinen. Att kunna använda sig av hårdvaruaccelerator som t.ex. grafikkort för tung beräkning och analys av dataströmmar är en anledning till varför projektet Continuous Deep Analytics (CDA) utforskar möjligheten att istället exekvera en strömprocessor direkt i den underliggande maskinen. Rust är ett ungt programmeringsspråk som statiskt kan garantera att program inte innehåller minnesfel eller race conditions", detta utan att negativt påverka prestanda vid exekvering. Rust är byggt på LLVM vilket ger Rust en teoretisk möjlighet att kompilera till en stor mängd olika maskinarkitekturer. Varje specifik maskinarkitektur kräver dock att kompileringsmiljön är konfigurerad på ett specifikt sätt. CDAs kompilator kommer befinna sig i ett distribuerat system där kompilatorn kan bli flyttad till olika maskiner för att kunna hantera maskinfel. Att dynamiskt konfigurera kompilatorn i en sådan miljö kan leda till problem och därför testas Docker som en lösning på problemet. Ett trådbaserat system för parallell exekvering är implementerat i Scala för att bygga Docker bilder och kompilera Rust i containrar. Docker visar sig att ha en potential för att möjliggöra lätt omallokering av drivern utan manuell konfiguration. Docker har ingen stor påverkan på Rusts kompileringstid. De stora storlekarna på de Docker bilder som krävs för att kompilera Rust är en nackdel med lösningen. De gör att om allokering av drivern kräver mycket nätverkstrafik och kan därför ta lång tid. För att göra lösningen kvickare kan storleken av bilderna reduceras.

The choice of development environment can be crucial when it comes to developing a software. Few researches exist on comparing development environments. Docker is a relatively new software for handling and setting up container-environments. In this research, the possibility of using Docker as a software development environment is being investigated and compared against virtual machines as a development environment. The purpose of this research is to examine how the choice of development environment affect the development process. The work was qualitative, with an inductive and a deductive approach. It included a case study with two phases. One in which virtual machines and one in which Docker were used to implement a development environment. Observations were made after each implementation. The data from each implementation were then compared and evaluated against each other. The results from the comparisons and the evaluation clearly shows that the choice of development environment can influence the process of developing software. Different development environments affect the development process differently, both good and bad. With Docker, it’s possible to run more environments at once than when using virtual machines. Also, Docker stores the environments in a clever way that results in the environments taking up less space on the secondary storage compared to virtual machine environments. This is due to that Docker uses a layer system when it comes to containers and their components. When using Docker, no Graphical User Interface (GUI) to install and manage applications inside a container is provided, this can be a drawback since some developers may need a GUI to work. The lack of a GUI makes it harder to get an Integrated Development Environment (IDE) to work properly with a container to for example debug code. / Valet av utvecklingsmiljö kan vara avgörande vid utveckling av mjukvara. Få undersökningar finns idag angående jämförelser mellan utvecklingsmiljöer. Docker är en relativt ny mjukvara för att sätta upp samt hantera container- miljöer. I denna undersökning, kommer möjligheten att använda Docker som utvecklingsmiljö att undersökas och jämföras mot virtuella maskiner som utvecklingsmiljö. Syftet med undersökningen är att se hur valet av utvecklingsmiljö påverkar utvecklingsprocessen av en mjukvara. Arbetet bedrevs på ett kvalitativt sätt, med både ett induktivt samt ett deduktivt tillvägagångssätt. Det inkluderade även en fältstudie med två faser. En där virtuella maskiner och en där Docker användes till att implementera en utvecklingsmiljö. Observationer utfördes efter varje implementation. Data från varje implementation jämfördes och evaluerades mot varandra. Resultaten från jämförelserna och evalueringen visar att valet av utvecklingsmiljö har inflytande på processen av utveckling av mjukvara. Olika utvecklingsmiljöer påverkar utvecklingsprocessen olika, både på bra och dåliga sätt. Med Docker är det möjligt att köra fler miljöer samtidigt än vad som är möjligt vid användande av virtuella maskiner. Docker lagrar även miljöerna på ett smart sätt, som gör att de tar upp mindre plats på den sekundära lagringen jämfört med virtuella maskiner. Detta är på grund av att Docker använder sig av ett lager-system när det gäller containrar och deras komponenter. När Docker används, tillhandhålls inget Graphical User Interface (GUI) för att installera eller hanterar applikationer inuti en container, detta kan vara en nackdel då vissa utvecklare kan behöva ett GUI för att arbeta. Avsaknaden av ett GUI gör det svårare att få en Integrated Development Environment (IDE) att fungera ordentligt med en container för att till exempel avlusa kod.

Выпускная квалификационная работа 56 страниц, 19 рисунков, 11 источников, 8 приложений. Цель работы – разработка клиентской части веб-приложения «Мониторинг IT-конференций». В процессе работы был проведён анализ популярных фреймворков для веб-разработки, настроена интеграция с серверами CDN на базе сервиса Surge, создан Docker-образ с веб-приложением, настроена интеграция с GitHub Actions для CI/CD, настроен клиентский и серверный мониторинги на базе Sentry. В результате ВКР разработана клиентская часть на базе фреймворка Next.js для веб-приложения «Мониторинг IT-конференций». / Final qualification work 56 pages, 19 figures, 11 sources, 8 appendices. The purpose of the work is to develop the client part of the web application "Monitoring of IT conferences". In the process, we analyzed popular frameworks for web development, configured integration with CDN servers based on the Surge service, created a Docker image with a web application, configured integration with GitHub Actions for CI/CD, configured client and server monitoring based on Sentry. As a result of the final qualifying work, the client part was developed on the basis of the Next framework.js for the IT Conference Monitoring web application.

Embedded devices in the Internet of Things world mostly only have one connection channel, and smaller consumer devices usually communicate with other devices only over a wireless connection. Developers constantly upgrade the Internet of Things devices with Android phones connecting to the devices. If developers break the only possible connection, the devices become unusable, because the devices do not have a wired port. This study explores the options to test the wireless upgrade channel during the development workflow and implements a continuous integration pipeline for the devices. Literature in the field of continuous integration focuses primarily on Cloud and Web-related workloads. The few papers targeting embedded devices with continuous integration are primarily theoretical and discuss the possible advantages of utilizing continuous integration but do not implement a prototype. Our contribution creates a continuous integration pipeline for embedded devices, which automatically tests the update channel between Android phones and embedded devices over Bluetooth on every commit. To verify the correct functionality, we use previously faulty commits from the git history and run the pipeline with the buggy commit to check the pipeline’s functionality. The pipeline evaluation shows that the time improvements for our update validation process with continuous integration is insignificantly faster for the upgrade procedure. However, developers are required to test a combination of versions and here, the automated testing setup excels over the human testing method by being scalable. Furthermore, automated testing enables easier identification of the root cause for an issue and a faster delivery time of fixes. While the pipeline works reliably, we identify issues in adopting the continuous integration process by the developers. Additionally, the analysis summarizes essential tools and features to run the pipeline with an overview of required elements for similar projects. The work was created in cooperation with Wrlds Creations AB and we used the devices actively developed by the company. / Inbäddade enheter i Internet of Things världen har oftast bara en kommunikationskanal, och mindre konsumentenheter kommunicerar vanligtvis via en trådlös Bluetooth-anslutning. Utvecklarna uppgraderar ständigt enheterna med Android-telefoner som ansluts till enheterna. Om utvecklarna bryter den enda möjliga kommunikationskanalen blir enheterna obrukbara. Denna studien undersöks alternativen för att testa den trådlösa uppgraderingskanalen under utvecklingsarbetsflödet och implementeras en continuous integration pipeline för enheterna. Litteraturen inom området continuous integration fokuserar primärt på Cloud och webbrelaterade arbetsbelastningar. De få artiklar som är inriktade på inbäddade enheter med continuous integration är främst teoretiska och diskuterar de möjliga fördelarna med att använda continuous integration, men implementerar inte någon prototyp. Vårt bidrag skapar en continuous integration pipeline för inbäddade enheter, som automatiskt testar uppdateringskanalen mellan Android-telefoner och inbäddade enheter via Bluetooth vid varje commit. För att verifiera den korrekta funktionaliteten använder vi tidigare felaktiga commits från git-historiken och körde pipelinen med den felaktiga commit för att kontrollera funktionaliteten av pipelinen. Utvärderingen av pipelinen visar att tidsförbättringarna för valideringskanalen är obetydligt snabbare för hela uppgraderingsproceduren. Utvecklarna krävs dock testa en kombination av versioner och här är den automatiska testuppställningen bättre än den mänskliga testmetoden eftersom den är skalbar. Automatiserad testning gör det dessutom lättare att identifiera grundorsaken till ett problem och att leverera korrigeringar snabbare. Även om pipelinen fungerar på ett tillförlitligt sätt identifierar vi problem när det gäller utvecklarnas antagande av continuous integration-processen. Dessutom sammanfattas i analysen de viktigaste verktygen och funktionerna för att driva pipelinen med en översikt över vad som krävs för liknande projekt. Arbetet skapades i samarbete med Wrlds Creations AB och använde de enheter som företaget aktivt utvecklat.

With the upcoming 5G deployment and the exponentially increasing data transmitted over cellular networks, off the shelf hardware won't provide enough performance to cope with the data being transferred over cellular networks. To tackle that problem, hardware accelerators will be of great support thanks to their better performances and lower energy consumption. However, hardware accelerators are not a silver bullet as their very nature prevents them to be as flexible as CPUs. Hardware accelerators integration into Kubernetes and Docker, respectively the most used tools for orchestration and containerization, is still not as flexible as it would need. In this thesis, we developed a framework that allows for a more flexible integration of these accelerators into a Kubernetes cluster using Docker containers making use of an abstraction layer instead of the classic virtualization process. Our results compare the performance of an execution with and without the framework that was developed during this thesis. We found that the framework's overhead depends on the size of the data being processed by the accelerator but does not go over a very low percentage of the total execution time. This framework provides an abstraction for hardware accelerators and thus provides an easy way to integrate hardware accelerated applications into a heterogeneous cluster or even across different clusters with different hardware accelerators types. This framework also moves the hardware specific parts of an accelerated program from the containers to the infrastructure and enables a new kind of service, OpenCL as a service.