This thesis deals with design and implementation of personal data and consents to the processing of personal data management portal with multitenancy support. The work deals with theoretical basis for the portal design in the field of personal data protection and cloud software development. The final design is implemented and deployed in production environment.

Due to the growth of cloud computing in recent years, the use of virtualization has exploded. Virtual machines (VMs) and containers are both virtualization technologies used to create isolated computing environments. While VMs are created and managed by hypervisors and need their own full guest operating system, containers share the kernel of the host computers and do not need a full guest operating system. Because of this, containers are rumored to have less overhead involved, yielding higher performance and less resource usage compared to VMs.  In this paper we perform a literature study along with an empirical study to examine the differences between containers and virtual machines when it comes to cpu, memory and disk performance, cpu and memory resource utilization, and power consumption. To answer the question regarding performance, a series of benchmarks were run inside both a container and a VM. During these benchmarks the resource utilization of the host machine was also measured to answer the second question and to answer the third and final question the power draw was measured while some of the benchmarks were running. The results showed that the cpu performance was extremely similar between the two and memory performance seemed to be similar for the most part but fairly big differences were seen in favor of both depending on the benchmark in some cases. With disk performance the container was between 15-50% faster depending on the benchmark. As for resource usage, the cpu usage was the same for both technologies but memory usage differed greatly in favor of the container. The VM used between 3-4 GiB and the container between 70 MiB - 2.5 GiB depending on the benchmark. The power draw was the same for both technologies when under cpu and memory load but when idle the VM proved to draw around 40% more power.

Docker is a popular tool for virtualization that allows for fast and easy deployment of applications and has been growing increasingly popular among companies. Docker also include a large library of images from the repository Docker Hub which mainly is user created and uncontrolled. This leads to low frequency of updates which results in vulnerabilities in the images. In this thesis we are developing a tool for determining what vulnerabilities that exists inside Docker images with a Linux distribution. This is done by using our own tool for downloading and retrieving the necessary data from the images and then utilizing Outpost24's scanner for finding vulnerabilities in Linux packages. With the help of this tool we also publish statistics of vulnerabilities from the top downloaded images of Docker Hub. The result is a tool that can successfully scan a Docker image for vulnerabilities in certain Linux distributions. From a survey over the top 1000 Docker images it has also been shown that the amount of vulnerabilities have increased in comparison to earlier surveys of Docker images.

Because of the ease of use and effectiveness, Docker containers have become immensely popular among system administrators worldwide. Docker elegantly packages entire applications within a single software entity called images, allowing fast and consistent deployment over different host systems. However, it is not without drawbacks, as the close interaction with the operating system kernel gives rise to security concerns. The conducted systematic literature review aims to address concerns regarding the use of images from unknown sources. Multiple search terms were applied to a set of four scientific databases in order to find peer-reviewed articles that fulfill certain selection criteria. A final amount of 13 articles were selected and evaluated by using means of thematic coding. Analysis showed that users need to be wary of what images are used to deploy containers, as they might contain malicious code or other weaknesses. The use of automatic vulnerability detection using static and dynamic detection could help protect the user from bad images.

Reproducing distributed experiments is a challenging task for many researchers. There are many factors which make this problem harder to solve. In order to reproduce distributed experiments, researchers need to perform complex deployments which involve many dependent software stacks with many configurations and manual orchestrations. Further, researchers need to allocate a larger amount of money for clusters of machines and then spend their valuable time to perform those experiments. Also, some of the researchers spend a lot of time to validate a distributed scenario in a real environment as most of the pseudo distributed systems do not provide the characteristics of a real distributed system. Karamel provides solutions for the inconvenience caused by the manual orchestration by providing a comprehensive orchestration platform to deploy and run distributed experiments. But still, this solution may incur a similar amount of expenses as of a manual distributed setup since it uses virtual machines underneath. Further, it does not provide quick validations of a distributed setup with a quick feedback loop, as it takes considerable time to terminate and provision new virtual machines. Therefore, we provide a solution by integrating Docker that can co-exists with virtual machine based deployment model seamlessly. Our solution encapsulates the container-based deployment model for users to reproduce distributed experiment in a cost-effective and efficient manner. In this project, we introduce novel deployment model with containers that is not possible with the conventional virtual machine based deployment model. Further, we evaluate our solution with a real deployment of Apache Hadoop Terasort experiment which is a benchmark for Apache Hadoop map-reduce platform in order to explain how this model can be used to save the cost and improve the efficiency.

Microservices is a new software design concept for developing scalable, loosely coupled services with a smaller codebase than the traditional monolithic approach. The designed microservices can communicate using several protocols, such as Advanced Message Queuing Protocol (AMQP) or HTTP/REST. Software developed using microservices design offers the developers great flexibility to choose a preferred technology stack and make independent data storage decisions. On the other hand, containerization is a mechanism that packages together the application code and dependencies to run on any platform uniformly and consistently. Our work utilizes Docker and Kubernetes to manage a containerized application. The Docker platform bundles the application dependencies and runs them in the containers. Moreover, Kubernetes is used for deploying, scaling, and managing containerized applications. On the other hand, microservices-based architecture brings many challenges as multiple services are being built and deployed simultaneously in this design. Similarly, a software developer faces many questions such as where to physically deploy the newly developed service? For example, place the service on a machine with more computing resources or near another service which it often needs to communicate with? Furthermore, it is observed in previous studies that the microservices may bring performance degradation due to increased network calls between the services. To answer these questions, we develop a unique microservices-based containerized application that classifies images using deep learning tools. The application is deployed into the Docker containers, while Kubernetes manages and executes the application on the on-premise machines. In addition, we design experiments to study the impact of container placement on the application performance in terms of latency and throughput. Our experiments reveal that Communication Aware Worst Fit Decreasing (CAWFD) obtained 49%, 55%, and 54% better average latency in microservice placement scenario two. This average latency is lower than CAWFD in scenario one in the 100, 300, 500 images group. Simultaneously, the Spread strategy displayed minimal performance because the Kubernetes scheduler determines the container placements on the nodes. Finally, we discover that CAWFD is the best placement strategy to reduce the average latency and enhance throughput. / Microservices är ett nytt mjukvarudesignkoncept för att utveckla skalbara, löst kopplade tjänster med en mindre kodbas än den traditionella monolitiska metoden. Tjänsterna kan kommunicera med flera protokoll, till exempel AMPQ eller HTTP/REST. Programvaran som utvecklats med hjälp av mikroservicedesign erbjuder en utvecklare stor flexibilitet att välja en föredragen teknikbunt och fatta oberoende datalagringsbeslut. Dessutom är containerisering en mekanism som grupperar applikationskoden och beroenden för att köra på vilken plattform som helst enhetligt och konsekvent. Vårt arbete använde Docker och Kubernetes för att hantera de containeriserade applikationerna. Docker plattformen buntar programberoenden och kör dem i behållarna. Samtidigt används Kubernetes för distribution, skalning och hantering av containeriserade applikationer. Å andra sidan ger mikrotjänstbaserad arkitektur många utmaningar. Många tjänster byggs och distribueras samtidigt i denna design. På samma sätt står en mjukvaruutvecklare inför många frågor. Som, var ska de placera den nyutvecklade tjänsten? Till exempel, placera tjänsten på en maskin med fler datorer och nära en annan tjänst där de ofta behöver kommunicera med varandra. Vidare har det observerats i tidigare studier att mikrotjänsterna försämrar prestandan på grund av ökade nätverkssamtal mellan tjänsterna. För att besvara dessa frågor har vi utvecklat en unik mikrotjänstbaserad containeriserad applikation. Den klassificerar en bild med hjälp av djupa inlärningsverktyg. Programmet distribueras till Docker-behållarna, medan Kubernetes hanterar och kör programmet på lokala datorer. Dessutom utformade vi ett par experiment för att studera behållarnas inverkan på applikationsprestanda när det gäller latens och genomströmning. Våra experiment avslöjar att Communication Aware Worst Fit Decreasing (CAWFD) fick 49%, 55% och 54% bättre genomsnittlig latens i scenario två med mikrotjänstplacering. Denna genomsnittliga latens är lägre än CAWFD i scenario ett i gruppen 100, 300, 500 bilder. Samtidigt visade Spreadstrategin minimal prestanda eftersom Kubernetes-schemaläggaren bestämmer behållarplaceringarna på noderna. Slutligen upptäcker vi att CAWFD är den bästa placeringsstrategin för att minska den genomsnittliga latensen och förbättra genomströmningen.

Idag är det vanligt att hantera, beskriva och konfigurera sin datainfrastruktur såsom processer, serverar och miljöer i maskinläsbara konfigurationsfiler istället för fysisk hårdvara eller interaktiva konfigureringsverktyg. Automatiserad datainfrastruktur blir mer och mer vanligt för att kunna fokusera mer på utveckling och samtidigt få ett stabilare system. Detta har gjort att antalet verktyg för automatisering av datainfrastruktur skjutit i höjden det senaste årtiondet. Lösningar för automatisering av olika typer av datainfrastrukturer har blivit mer komplexa och innehåller ofta många verktyg som interagerar med varandra. Det här kandidatarbetet jämför, väljer ut och sätter ihop existerande plattformar och verktyg och skapar ett privat moln som infrastruktur för utveckling. Detta för att effektivera livscykeln för en serverbaserad runtime-miljö. En jämförelse av molnplattformarna OpenStack, OpenNebula, CloudStack och Eucalyptus baserad på litteratur, lägger grunden för molnet. Molnplattformen kompletteras därefter med andra verktyg och lösningar för att fullborda livscykelautomatiseringen av runtime-miljöer. En prototyp av lösningen skapades för att analysera praktiska problem. Arbetet visar att en kombination av OpenStack, Docker, containerorkestrering samt konfigureringsverktyg är en lovande lösning. Lösningen skalar efter behov, automatiserar och hanterar verksamhetens konfigurationer för runtime-miljöer.

There currently does not exist a way for creating digital twins’information and transferring it between networks , but container-basedvirtualization could be a possible solution. One of those techniques isDocker, which is an engine to isolate a software and can bring benefits toimprove the workflow of software development. Making changes withDocker is very fast as it uses the copy-on-write model, it can containerizeapplications in minutes. This study will design a scenario with twodevices sending a data packet between each other to simulate theproblem. The results from the study is further investigate and analyze toanswer the question of whether the container-based virtualization can bea possible solution for creating digital twins. The result from the scenariois Docker works equal or worse when used with a low-cost computinghardware compared to a computing hardware. It is speculated that theresources used in the images is a factor that can affect the performance,but the hardware is also another factor that can affect it. / Det finns för närvarande inget sätt att skapa digitala tvillingar ochöverföra den mellan nätverk, men containerbaserad virtualisering kanvara en möjlig lösning. En av containerbaserad virtualisering tekniker ärDocker, som är en motor för att isolera en programvara och kanframbringa fördelar för att förbättra arbetsflödet för programutveckling.Att göra ändringar med Docker är mycket snabbt tack vare användningav copy-on-write-modellen. Denna studie kommer att utforma ettscenario med två enheter som skickar ett datapaket mellan varandra fratt simulera överföringsprocessen. Mätresultat från studien bliranalyserad för att besvara frågan om containerbaserad virtualisering kanvara en möjlig lösning för att skapa och skicka digitala tvillingar.Resultatet från scenariot är att Docker fungerar lika eller sämre när detanvänds med en låg kostnad datorhårdvara jämfört med endatorhårdvara. Det spekuleras att resurserna som används i datapaketetär en faktor som kan påverka prestandan, men hårdvaran är också enannan faktor som påverkar det.

Purpose – The purpose of this paper is to explore the possibility to effectivize local networks and databases using unikernels and compare this to containers. This could also apply to reliability of executing programs the same way on different hardware in software development. Method – Two experiments have been performed to explore if the purpose could be realized, quantitative data have been gatheredand displayed in both cases. Python-scripts have been used to start C-scripts, acting client and server. Algorithms have been timed running in unikernels as well as in containers along with compared measurements of memory in multiple simultaneous instantiations. Findings – Intermittent response times spiked made the data hard to parse correctly. Containers had a lower average response time when running lighter algorithms. The average response times of unikernels dives below that of containers when heavier programs are simulated. Few minor bugs were discovered in Unikraft unikernels. Implications – unikernels havecharacteristics that make them more suitable for certain tasks compared to their counterpart, this is also true for containers. Unikraft unikernels are unstable which makes it seem like containers are faster during lighter simulations. Unikernels are onlyfaster and more secure if the tools used to build them does so in a manner that makes them stable. Limitations – The lack of standards, the lack of a support community together with the fact that unikernels is a small and niche field means that unikernels have a relatively high learning curve. Keywords – Unikraft, Unikernels, Docker, Container / Syfte – Syftet med denna studie är att undersöka möjligheten att effektivisera lokala nätverk och databaser med hjälp av unikernels och att jämföra denna möjlighet med containrar. Detta kan även gälla utveckling av programvara för att säkerställa att programvaran exekveras på servern på exakt samma sätt som den tidigare gjort lokalt på utvecklarens lokala dator. Metod – Två experiment utförs för att undersöka om det går besvara syftet, kvantitativa data samlas in i båda fallen, datan är även redovisad kvantitativt. Python-script används föratt starta C-script som agerar klient och server. Tidtagning på algoritmer i unikernels respektive containrar samt minnesanvändning vid multipel instansiering mättes för att analyseras och jämföras. Resultat – Intermittenta svarstids-toppar gjorde datan från unikernels svår att korrekt utvärdera. Containrar hade ett lägre medelvärde på svarstider vid mindre krävande algoritm-användning. Unikernels medelvärde dyker under container-svarstiderna när mer krävande program simuleras. Några små buggar upptäcktesi Unikraft unikernels. Implikationer – Unikernels har egenskaper som gör de mer passande för vissa uppgifter jämfört med dess motsvarighet medan detsamma gäller för Containrar. Unikraft unikernels är instabila och ger därfören bild av att containrar vidmindre processorkrävande program faktiskt är snabbare än unikernels. Unikernels är bara snabbare och säkrare i den mån verktyget som bygger dem, gör det på ett sätt att de är stabila. Begränsningar – Avsaknaden av standarder, avsaknaden av ett communitysom kan svara på frågor tillsammans med att unikernelsär ett litet och nischat fält gör att unikernels har en relativ hög inlärningskurva. Nyckelord – Unikernel, Unikraft, Container, Docker

Cloud-based video processing is an area depending heavily on the hardware’s ability to process huge amounts of packets. Nowadays, we can observe industry drifting away from commonly used FPGAs in lieu of a more flexible software approach. Docker container has been considered a promising technology for constructing video streaming pipelines as it provides a fast and easy way to package and distribute software. Recent developments in the Network Function Virtualization field showed that fast packet processing frameworks like Intel Data Plane Development Kit (DPDK) have a potential to improve the performance of network function chains. This technology could be an enabler for software video processing to approach hardware solutions, yet it is still in quite an early stage and generates many questions about usage, deployment, and performance. This thesis shows that it is possible to build packet processing pipelines using DPDK, running dozens of video processing microservices simultaneously on a single machine. The project implementation was evaluated in terms of latency and throughput and behaviour of co-running applications on a single CPU core was modelled. / Molntjänster Inom området videobearbetning är starkt beroende av hårdvarans förmåga att kontinuerligt bearbeta mycket stora mängder paket. Idag har det blivit vanligt inom professionell användning att välja bort tidigare vanliga FPGA-baserade lösningar, till förmån för mer flexibla mjukvarubaserade lösningar. Docker containers har setts som en lovande teknologi för att konstruera pipelines för strömmande video, då de erbjuder ett snabbt och enkelt sätt att paketera och distribuera mjukvara. Utvecklingen inom virtualisering av nätverksfunktioner (NFV) har visat att ramverk för snabb paketprocessning, såsom Intel DPDK, har potential att förbättra prestandan hos kedjor av nätverksfunktioner. Denna teknologi gör det möjligt för mjukvarubaserad videobehandling att hävda sig i jämförense med hårdvarubaserade varianter. Den är dock relativt ny och oprövad och det kvarstår många öppna frågor om användning, driftsättning och prestanda. Detta examensarbete visar att det är möjligt att bygga paketbearbetande pipelines med DPDK, som kör dussintals nätverksfunktioner samtidigt på en maskin. En implementation har konstruerats och utvärderats med fokus på latens och flöde, och beteendemönster för applikationer som kör samtidigt på samma CPU har modellerats.