Applications found in both large and small enterprises need a communication method in order to meet requirements of scalability and durability. Many communication methods exist, but the most well-used are message queues and message brokers. The problem is that there exist many different types of message queues and message brokers with their own unique design and implementation choices. These choices result in different parameter sets, which can be configured in order to meet requirements of for example high durability, throughput, and availability. This thesis tests two different message brokers, Apache Kafka and RabbitMQ, with the purpose of discussing and showing the impact on throughput and latency when using a variety of parameters. The experiments conducted are focused on two primary metrics, latency and throughput, with secondary metrics such as diskand CPU-usage. The parameters chosen for both RabbitMQ and Kafka are optimized for maximized throughput and decreased latency. The experiments conducted are tested on a cloud platform; Amazon Web Services. The results show that Kafka outshines RabbitMQ regarding throughput and latency. RabbitMQ is the most efficient in terms of quantity of data being written, while on the other hand being more CPU-heavy than Kafka. Kafka performs better than RabbitMQ in terms of the amount of messages being sent and having the shortest one-way latency. / Applikationer som finns i både komplexa och icke-komplexa system behöver en kommunikationsmetod för att uppfylla kriterierna för skalbarhet och hållbarhet. Många kommunikationsmetoder existerar, men de mest använda är meddelandeköer och meddelandemäklare. Problemet är att det finns en uppsjö av olika typer av meddelandeköer och meddelandemäklare som är unika med avseende på deras design och implementering. Dessa val resulterar i olika parametersatser som kan konfigureras för att passa olika kriterier, exempelvis hög hållbarhet, genomströmning och tillgänglighet. Denna avhandling testar två olika meddelandemäklare, Apache Kafka och RabbitMQ med syfte att diskutera och visa effekterna av att använda olika parametrar. De utförda experimenten är inriktade på två primära mätvärden, latens och genomströmning, med sekundära mätvärden som exempelvis diskanvändning och CPU-användning. De parametrar som valts för både RabbitMQ och Kafka optimeras med fokus på de primära mätvärdena. Experimenten som genomförs testades på en molnplattform; Amazon Web Services. Resultaten visar att Kafka presterar bättre än RabbitMQ när det kommer till genomströmning och latens. Gällande inverkan av Kafka och RabbitMQ på mängden skriven data, är RabbitMQ den mest effektiva, medan den å andra sidan är mer CPU-tung än Kafka.

The majority of cloud storage platforms rely on a centralized structure, with the most popular being Microsoft Azure. Centralization causes consumers to rely on the provider to maintain accessibility and security of data. However, platforms such as Storj.io are based on a decentralized structure. To become decentralized, Storj.io uses blockchain technology in a means to create an automated consensus mechanism between the entities storing the data. There is however little research regarding performance and security issues on a decentralized platform based on blockchain technology. The purpose of this study is to identify the beneficial and non-beneficial aspects of using blockchain-based decentralized cloud storage as a substitute for centralized ones. The study focuses on performance and security. A comparative case study has been executed, consisting of an experiment and literature study. Quantitative data from an experiment was used in a hypothesis test to determine whether there were any performance differences between Microsoft Azure Blob Storage and Storj.io. A literature study generating qualitative data was then made to identify differences in security measures and from that also discuss potential security risks on a service like Storj.io. This study found that the performance of Storj.io was lower than Microsoft Azure’s Blob Storage. Causes of these results were identified to be due to the many more steps during resource allocation in Storj.io, compared to Blob Storage. Security risks identified in Storj.io through the literature study were generally connected to the consensus mechanism. However, research shows that it is very unlikely for the consensus mechanism to be compromised. Because Microsoft Azure’s service does not use a blockchain, these risks do not exist. For secure data transfer to Azure’s service, consumers have to implement encryption manually client-side. Therefore, this study could not conclude whether Storj.io is a safe alternative because a consumer using the Microsoft Azure service is responsible for implementing security measures. Conclusions drawn from this study are intended to act as new knowledge in the field of blockchain-based decentralized cloud storage. It is an outset to decide whether to use centralized cloud storage or blockchain-based decentralized cloud storage from a performance and security perspective. / Majoriteten av datalagringsmolntjänsterna är centraliserade, varav Microsoft Azure står som den mest använda molntjänsten. Centralisering innebär att konsumenten behöver lita på att värdföretaget hanterar tillgänglighet och säkerheten av data på bästa möjliga sätt. I kontrast mot en centraliserad molnplattform finns Storj.io som är en decentraliserad molnlagringstjänst. För att åstadkomma decentralisering använder sig Storj.io av blockkedjan som används för att uppnå den autonoma konsensusmekanismen mellan noderna som lagrar data. Syftet med denna studie är att identifiera för- respektive nackdelarna med en decentraliserad blockkedjebaserad molnplattform i jämförelse mot en centraliserad molnplattform. Specifikt fokuserar studien på prestanda och säkerhet. En komparativ fallstudie har utförts med ett experiment och en litteraturstudie som datainsamlingsmetoder. Den kvantitativa datan från experimentet användes i en hypotesprövning för att identifiera om det fanns någon skillnad i prestanda mellan Microsoft Azure och Storj.io. Litteraturstudien användes i syfte för att kunna styrka skillnader om säkerhetsåtgärder och säkerhetsrisker mellan molnplattformarna. Resultatet av denna studie visar att prestandan för Storj.io är lägre än Microsoft Azures molnplattform. De identifierade faktorerna som orsakade resultatet anses vara på grund av de flertal steg som krävs vid resursallokering för Storj.io. De säkerhetsrisker som uppstår hos Storj.io kom till i samband med konsensusmekanismen. För att en säkerhetsrisk skall uppstå mot konsensusmekanismen behöver det decentraliserade nätverket hotas med majoritet. Eftersom Microsoft Azure inte använder sig av blockkedjan uppstår inte dessa typer av säkerhetsrisker. För dataöverföring till Azures datalagringstjänst behöver konsumenten själv säkerställa en krypterad kommunikationskanal. I Storj.ios fall sköts alla typer av säkerhetsåtgärder automatiskt vilket eliminerar risken för säkerhetsattacker vid överföringar. Sammanfattningsvis tyder denna studie på att Storj.io inte är ett optimalt val vid prioritering av prestanda. Eftersom konsumenten som använder Microsoft Azures tjänst ansvarar för säkerhetsåtgärder drogs ingen direkt slutsats huruvida Storj.io är ett säkert substitut. Studien visar på att det existerar konensusrisker med en tjänst som Storj.io och det är upp till envar konsument att förlita sig på att dessa inte uppstår. De slutsatser som har dragits från denna studie är avsedda som ny kunskap inom fältet som berör decentraliserade molnplattformar baserade på blockkedjan. Studien kan användas som en utgångspunkt för val mellan en centraliserad och decentraliserad molntjänst baserad på blockkedjan med prioritet för prestanda och säkerhet.