Detta kapitel tar upp olika aspekter i ett vidare sammanhang i arbetet.
6.3.1
Samhälleliga aspekter
Bambi är utvecklat med öppen källkod för att göra systemet tillgängligt för användning och vidareutveckling för allihopa. Systemet är utvecklat för både privatpersoner och företag för att underlätta att komma igång med en omgivningskonfiguration som blir likartad för alla utvecklare. Bambi kommer också att vara tillgängligt på alla tekniska enheter med en inter- netuppkoppling och en webbläsare. Detta bidrar till att en utvecklare själv kan välja vilken dator eller enhet hen skulle vilja utveckla på.
6.3.2
Miljöaspekter
Utifrån ett miljöperspektiv är strömförbrukningen av den tekniska enheten man använder sig av en faktor. Sverige är, jämfört med andra länder, generellt duktigt på att använda sig av grön energi (exempelvis vind eller vatten), däremot kan systemet användas där energin kommer från smutsig energi (som kolkraftverk). [32] Detta kan likväl sägas om de datacenter som utvecklarnas tjänster körs av antingen använder datacentrerna sig av grön eller smutsig energi. Detta är tyvärr väldigt svårt för utvecklarna att styra över. Besluten ligger mer på en statlig nivå eller på företagen vars tjänster man använder sig av.
Bambi förskjuter tunga beräkningar och därmed energikonsumptionen från lokala datorer till stora serverhallar. Detta kan också skapa förändringar i konsumentbeteenden då behovet att ha en uppdaterad lokal dator med mycket processorkraft minskar. För mer information kring datacentrernas energikonsumption och deras påverkan se kapitel G.
6.3.3
Etiska aspekter
Beroende på vilka projekt som är tänkt att köras på Bambi är det viktigt att köra Bambi från säkra enheter så att inte känslig information som finns i projektet kan läcka ut. Det är även viktigt att tänka på vilka trådlösa nätverk som utvecklarnas enhet är uppkopplad i då även det kan leda till att obehöriga kan komma åt projektet. Även om Bambi kan användas av
6.3. Arbetet i ett vidare sammanhang
privatpersoner är systemet främst utvecklat för företag. Det åligger då företaget att testa sy- stemet efter säkerhetsrisker då inte projektgruppen kan hållas till svars ifall ett dataintrång skulle ske.
I de följande styckena presenteras de slutsatser som arbetet har gett genom att besvara rap- portens frågeställningar.
1. Hur kan Bambi implementeras för att skapa värde för kunden?
För att använda produkten måste företaget i förväg sätta upp och konfigurera Bambi och det- ta görs genom att koppla produkten till sitt utvecklings- och produktionskluster i GCP. När man gjort detta ger Bambi främst en sänkt kostnad för att ta in nya utvecklare till ett befintligt system på ett företag. Bambi ger även möjligheten att lägga till CI/CD till sin arbetsprocess.
2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som
kan vara intressanta för framtida projekt?
De erfarenheter vi har lärt oss och kan ta vidare till framtida projekt är främst hur svårt och mycket arbete det är att sätta upp CI/CD-pipelines. Det är ett väldigt stort och komplicerat område som är svårt att få generaliserat. Med andra ord är det en viktig kunskap att ha i framtida projekt att det ej är rimligt att ta för givet att sådant går snabbt och är enkelt att sätta upp utan det kommer ta längre tid än man tror. Vi har också fått mycket erfarenheter inom agil utveckling och har provat på några olika metoder och mallar för hur utvecklingsmetoder kan följas.
3. Vilket stöd kan man få genom att skapa och följa upp en
systemanatomi?
Systemanatomin gav gruppen en första översiktlig bild av hur systemets olika delar skulle interagera med varandra och gav också en bra bild över vad som behövde göras. Systemana- tomin visade vilka delar som berodde av andra och då kunde man se vilka delar som kunde arbetas med parallellt. Den ger en möjligheten att enklare dela upp och effektivisera arbetet.
4. Hur mycket av CI/CD pipelines uppsättningen kan automatiseras?
Det visade sig att installationen av en CI/CD-pipeline är väldigt svår att på ett generellt sätt automatisera på grund av att konfigurationen kommer se olika ut för alla projekt. Alla moln- leverantörer kräver egna uppsättningar och kommunicerar med olika API:er. Varje projekt kommer att vilja köra sina egna tester och också bestämma hur de ska köras. Vi kunde få till en standardiserad programinstallation men användarna kommer troligen att vilja modifiera den till sina egna projekt. En lösning vi hade för att slippa en del konfiguration var att flytta den lokala utvecklingen till utvecklingsklustret uppe i molnet. Slutsatsen är att en CI/CD- pipeline bara kan automatiseras till en viss punkt, sedan krävs att användaren skräddarsyr den för sitt eget ändamål. Det vi kan göra är att abstrahera större delen av uppsättningen för att underlätta för olika projekt.
A
Decentraliserade moln och
molntjänster av Anton Andell
A.1
Inledning
Idag ligger de flesta av de tjänster vi använder på molnet, där molnet ofta är stora system ägda av stora företag som Google och Amazon[4]. Det har den senaste tiden blivit väl- digt populärt med blockchain och internet of things. Detta har även startat drömmen om att decentralisera molnet ett tillitslöst system med många noder som hjälps åt med berkä- ningskraft och lagring till ett lägre pris med privat datahantering och alltid är tillgängligt[12].
A.1.1
Syfte
I den här rapporten vill jag jämföra att ha tjänster på ett decentraliserat moln med att använda de moln som används nu, ur både utvecklar- och användarsynvinkel.
A.1.2
Frågeställningar
1. Vilka sorts applikationer/tjänster skulle gynnas av ett decentraliserad tillitslöst moln istället för ett centraliserat?
2. Behöver användare anpassa sig för att använda ett system på ett decentraliserat och tillitslöst moln jämfört med ett centraliserat?
3. Hur behöver utvecklare anpassa sig för att utveckla mot ett decentraliserat och tillitslöst moln jämfört med ett centraliserat?
A.1.3
Begränsningar
Blockchain och decentralisering handlar ofta mycket om att eliminera mellanhänder och att ha makten över sin egen data. Denna rapport kommer att inte fokusera på dessa aspekter. Det kommer inte heller vara någon djupare förklaring av bakomliggande tekniker. Rapporten kommer däremot bara ta upp lösningar som är tillitslösa.
A.2. Bakgrund
A.2
Bakgrund
Termen cloud gjordes först känd av dåvarande chefen på Google Eric Schmidt 2008 och har därefter använts mer och mer. Idag används molnlösningar av många, av företag för att smidigt och billigt lägga upp olika tjänster och privatpersoner för att spara datorkraft och få mer lagringsplats. När folk tänker på molntjänster kommer ofta tjänster som Google cloud, Aws och Azure upp då de är de störst inom molnlösningar.[4]
Under internets tidiga år var de vanligt att ett företag utvecklade en tjänst, satte upp hård- varan och tillhandahöll den själva. Detta gjorde att de behövde ha anställda som skötte dessa system och ha lokaler för dem med mera. Idag har de flesta företag sina tjänster på ett moln och betalar ofta en summa beroende på hur mycket lagring och kraft de konsumerar vilket ofta gör det billigare och smidigare att utveckla olika produkter. I och med detta har inter- net blivit mer och mer centraliserat och den mesta trafiken går till samma punkter. Många, inklusive jag, tycker att internet borde vara ett fritt internationellt medium ägt av ingen. Just därför är det väldigt intressant att undersöka fördelar med decentralisering som inte har just med nämda begränsningar (se A.1.3) att göra.
A.3
Teori
A.3.1
Blockchain och decentraliserade applikationer(smart-kontrakt)
Nedan beskrivs två viktiga begrepp inom området decentralisering.A.3.1.1 Blockchain
Alla projekt som presenteras i denna artikeln är baserade och byggda på en slags blockchain. Blockchain är en distribuerad databas där alla data är uppdelade i olika block, som ligger som i en kedja, i tidsordning, där alla block har godkänts av en majoritet av alla noder i nätverket. Denna kedja är också helt deterministisk och kan därför verifieras av vem som helst för att se att alla regler följs.[19] Det är just detta som bidrar till den tillitslösa decentraliserad miljön.
A.3.1.2 Smart-kontrakt
Smart-kontrakt är en benämning på applikationer som kan köras på ett tillitslöst nätverk, oftast en blockchain. Det kan allstå exekveras utan att någon har särskild auktoritet över ge- nomförandet. Detta gör att man tillexempel skulle kunna implementera röstning eller bevisa ägarskap utan någon mellanhand. [23]
A.3.2
Molntjänster
Denna del beskriver de tjänster som brukar erbjudas den som vill använda molnet[4]
A.3.2.1 Platform as a Service (PaaS)
PaaS är en modell där användaren jobbar med ett system där den kan installera egen mjukva- ra och köra den. Leverantören håller all hårdvara och den icke användarintalerade mjukvaran som operativsystem osv, de erbjuder också mjukvara för testning och databashantering.
A.3.2.2 Infrastructure as a Service (IaaS)
IaaS är en modell där användaren har kontroll över mjukvara och lagring. Här kan man installera eget operativsystem med mera. Leverantören har då kontroll över nätverkstraffik och den underliggande hårdvaran
A.3.2.3 Software as a Service (SaaS)
SaaS ger användaren en platform att snabbt lägga upp sin mjukvara på och öppna den för världen där molnleverantören tar hand om allt underliggande.
A.3.2.4 Data as a Service (DaaS)
DaaS är en tjänst som många moln har som ger användaren lagringsutrymme på molnet där leverantören sköter allt.
A.4
Metod
För att hitta svar på mina frågor kommer jag studera projekt som bidrar till att bygga ett decentraliserat moln. För att hitta relevanta projekt använder jag mig mycket av nyckelor- det Decentralized", följt av olika funktionaliterer. Tillexempel Decentralized Database"eller Decentralized Computing". Jag använder mig också mycket av termen Smart contractpå lik- nande sett, tillexempel smart contract api call". På grund av att alla projekt inom detta område är väldigt unga så är de svårt att säga om de kommer att kunna genomföra det de lovar. Här försöker jag förstå hur de ska åstadkomma det så långt jag kan. Jag kommer också undersö- ka de företag och människor som står bakom projekten för att se om de verkar trovärdiga. Dock kommer lösningar med fungerande versioner att prioritetras. Jag kommer även stude- ra forskning inom decentralisering och smart-kontrakt. Jag kommer också använda mig av relevant hastighet och prisdata för fungerande tjänster. För att hitta bra information om nu- varande moln tjänster och protokoll använder jag mig mycket av Google Scholar istället för Google. Här kommer man långt på bara temren cloud men använde lite andra termer så som cloud history.
A.5
Resultat
I undersökningen av decentraliserade molnlösningar hittade jag många spännande tillväga- gångsätt men inga som ännu har en fullständig lösning då området fortfarande är väldigt nytt. Jag kommer därför dela upp resultatet i decentraliserad beräkning och utveckling samt lagring och databas.
A.5.1
Decentraliserad beräkning och utveckling
A.5.1.1 Beräkning
De som nu har den största och mest använda plattformen för decentraliserad beräkning är Ethereum, de erbjuder en plattform där man kör sina egna applikationer i ett pay as you go format där varje operation är ett par bytes och har en kostnad på nätverket. Program- men är skrivna i något som kallas EVMcode vilket är en sorts bytekod.[9] Det finns även högnivåspråk som Solidity som kompileras till EVMcode vilket har gjort utvecklingen av smart-kontrakt möjlig för många utvecklare.[35]
A.5.1.2 Utveckling av applikationer
Det finns redan en hel del olika plattformar ute som man kan utveckla decentraliserade ap- plikationer till, där den största är Ethereum. De flesta av dessa tjänster har sina egna språk och miljöer att utveckla i och har endast stöd för just sitt egna språk. I Ethereums fall så är hela nätverkets som en stor virituell maskin som kör allas applikationer, så som utvecklare slipper man allt som har med konfigurationer av olika miljöer att göra. Utöver detta finns ännu ingen parallelisering i dessa applikationer vilket gör dem långsamma och dåliga på att utnyttja det stora nätverket som hade varit perfekt för stora parallella beräkningar. [12] Detta
A.5. Resultat
är dock något som förmodligen kommer att ändras i framtiden då det redan finns presentera- de lösningar för detta.[25] Att skriva Smart-kontrakt kräver också lite annorlunda säkerhets- och ekonomiskt tänkande. För att ett Smart-kontrakt ska kunna köra behöver det innehålla pengar, dessa pengar måste vara säkra och vara skyddade från att bli spenderade av attacker och liknande.[23] Det är inte heller möjligt att direkt anropa externa api-er från ett Smart- kontrakt på grund av blockchains deterministiska natur. Här behövs en mellanhand om man skulle vilja använda externa api-er, ett program som lyssnar på Smart-kontraktet och vid viss ändring anropar ett api och sedan skickar svaret från det api till kontraktet. [56]
A.5.2
Decentraliserad lagring
A.5.2.1 Fillagring
På den här fronten finns det redan några bra fungerande implementationer. Ethereum presen- terar i sitt whitepaper ett tillvägagångsätt till detta där man ska kunna lagra data hos noder på nätverket mot betalning, dock ingen nuvarande implementation. [9] Ett projekt som har ett fungerande nätverk är Sia. På deras nätverk kan man redan nu lagra data utan risk att förlora data. De har dock en del begränsningar just nu. Man måste ladda ner deras egna program för att lägga upp filer och äga deras egna valuta för att kunna använda nätverket. [22] Priser- na sätter man själv men medelpriset per månad ligger 2019-03-03 på 0.22 Euro per terabyte samt en uppladdning och nedladdnings bandbredd kostnad på 0.02 euro per terabyte.[20] I jämförelse tar google 7 dollar per terabyte, dock har de en stor skillnad i trafikmängd.[14]
A.5.2.2 Databas
För de flesta tjänster räcker det inte med att kunna köra beräkningar utan man behöver oftast också nån form av lagring. Och det räcker även sällan med fillagring utan man behöver ofta en databas. Det skulle tekniskt sett vara möjligt att sköta allt med Ethereum Smart-kontrakt, men att lagra i ett Smart-kontrakt kostar runt 4444 dollar per MB vilket är en stor summa.[71] Bluzelle skapar en lösning till detta, en decentraliserad databas. Deras teknik är väldigt lik projektet Sia, dock anpassad för de mindre datamängder som kan sparas. Sia har en minsta lagringschunk på 40MB. Ta som exempel en databas som har en stor fil av många emailadres- ser. I ett nätverk som Sia måste man hämta hela filen i men Bluzelle kan man lägga alla email- adresser separat utspritt på nätverket. Om man nu endast vill ha en specifik emailadress så kan man hämta bara den sökta. Bluzelle implementerar alltså de vanliga databasfunktioner- na create, read, update och delete. [73] Bluzelle presenterar också en bra bild i sitt whitepaper som visar deras mål och vision, och även den framtid som undersöks i denna rapporten. Se fig. A.1
Figur A.1: En bild av hur framtida molnet och internet kan vara uppbyggt.[73]
A.6
Diskussion
A.6.1
Resultat
A.6.1.1 Jämförelse med molntjänster
I Teoridelen tog jag upp PaaS, IaaS, SaaS och DaaS för att sedan kunna jämföra om de de- centraliserade tjänsterna kunde bidra med samma funktionaliteter. Som i alla dessa tjänster så håller leverantören/nätverket hårdvaran. Och eftersom de flesta decentraliserade nätver- ken nu fungerar som stora förkonfigurerade virituella maskiner så har de ännu inte möjlighet att erbjuda PaaS och IaaS. Däremot är SaaS och DaaS väl implementerade i diverse nätverk som har nämnts tidigare. Att skapa och lägga upp egen mjukvara på ett nätverk alltså SaaS erbjuds av till exempel Ethereum. Databas och annan monllagring alltså DaaS är något som erbjuds av tillexempel Sia och Bluzelle.
Mjukvara på Ethereum är dyrt och ineffektivt att köra, det är en plattform för applika- tioner som kräver tillitslöshet och är just nu inte lämpad för tyngre beräkningar direkt i plattformen. Om man till exempel skulle vilja utveckla en applikation likt Uber och slippa
A.6. Diskussion
ha serverar som hanterar överenskommelser och betalningar mellan förare och kunder skul- le en decentraliserad applikation passa utmärkt. Men om man vill göra en applikation för att köra tillexempel MATLAB online skulle man just nu inte vinna något på att använda en decentraliserad plattform.
Decentraliserad datalagring var det som överaskade mig mest i undersökningen. Att lagra data är just nu billigare att göra i Sia än på Google. Att ha en decentraliserad databas kan då också vara relevant i framtiden. En centraliserad applikation med en decentraliserad databas kan jag se vara väldigt relevant då det på senare tid blivit mer krav på att ha kontroll över sin egen data. Exempel som också visas i Bluzelles whitepaper är en applikation som Facebook med all sin egen logik som använder en decentraliserad databas där varje användare äger all data om sig själv och låter Facebook använda den men kan om de vill bryta all kontakt och låsa in sin data. Fördelar här är också priset då det också är det billigare alternativet. Dock tror jag att det kan bero på antalet användare. Det är väldigt mycket mer användare på Googles lagringstjänst än vad det är på Sia. Hastigheter är också något som är svårt att uttala sig om av samma anledning.
A.6.2
Frågor
I denna sektionen kommer jag diskutera och försöka på svara frågeställningen.
A.6.2.1 Vilka sorts applikationer/tjänster skulle gynnas av ett decentraliserad moln istället för ett centraliserat?
Decentraliserade molntjänster är forfarande i ett väldigt ungt skede. Så det korta svaret just nu är de applikationer som skulle gynnas av att bli av med mellanhänder till exmepel Uber som nämnts tidigare. Men vi har även sett att applikationer som kräver lagring och databas speciellt med känslig data i alla fall borde fundera på att använda sig av en decentraliserad lösning för den delen av applikationen. Vi kommer i framtiden att få se hur priset på dessa tjänster kommer att påverkas men just nu är priset konkurrerande.
A.6.2.2 Behöver användarna anpassa sig för att använda ett system på ett decentraliserat moln gentemot ett centraliserat?
En applikation som är på ett decentraliserat moln eller använder sig av decentraliserade tjänster kommer i vissa fall kräva mer av användaren. I fallet med data kan användare ha mer makt och därmed kan kräva lite extra kunskap från dess sida. Utöver detta sker just nu all kommunikation till en decentraliserad applikation genom det decentraliserade nätver- ket. Detta kan i de flesta fall kräva en adress/konto för att användaren ska kunna interagera direkt med applikationen.
A.6.2.3 Hur behöver utvecklare anpassa sig för att utveckla mot ett decentraliserat moln gentemot ett centraliserat?
Utvecklare behöver just nu anpassa sig till språk och låsa sig till ett decentraliserat nätverk. Det finns projekt som jobbar för att förbättra kommunikationen mellan nätverk, som tillex- emepel ICON[36]. Projekten är också begränsade till sekvensiell exekvering av program. De har inte heller full kontroll över hastighet då programmen kan bara köras så snabbt nätverket klarar av. De går inte att skala upp hur mycket som helst. Att använda sig av decentraliserad lagring borde inte göra någon större skillnad. Eventuellt ger det lite mer jobb att sätt upp en lokal kopia att testa mot. Kontakt med externa api-er görs också på ett annorlunda sätt och kräver någon sorts mellanhand i nuläget.
A.6.3
Metod
Detta arbete är gjort på ett väldigt nytt område och inte mycket forskning existerar. Detta har gjort att arbete inte är baserad på många vetenskapliga artiklar, det är istället baserad på de olika projekten som håller på att utvecklas och jag har med hjälp av deras visioner försökt få fram relevant information. Arbetet kräver då av läsaren en hel del tillit och efterforskning