CI/CD i molnapplikationer som Google Cloud, Azure och AWS

Transkript

1 Linköpings universitet Institutionen för datavetenskap Examensarbete på grundnivå, 15hp Datateknik Vårterminen 2019 LIU-IDA/LITH-EX-G--19/003--SE CI/CD i molnapplikationer som Google Cloud, Azure och AWS CI/CD in cloud applications like Google Cloud, Azure and AWS Anton Andell Nigel Cole Wiktor Karlsson Eric Lilja Diba Rezaie David Thimren Andreas Zeijlon Handledare : Jonas Wallgren Examinator : Kristian Sandahl Linköpings universitet SE Linköping ,

2 Upphovsrätt Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: Anton Andell Nigel Cole Wiktor Karlsson Eric Lilja Diba Rezaie David Thimren Andreas Zeijlon

3 Sammanfattning Under VT 2019 ägde projektet rum varav denna rapport är ett av resultaten. Projektets mål var att skapa en CI/CD pipeline vars syfte var tänkt att frekvent kunna leverera färdigtestad kod till olika molntjänster som Google Cloud Platform, Amazon Web Services och Azure. Projektspecifikationerna gavs av företaget Skira för att skapa en snabbare integrationsprocess för nya utvecklare. Detta så en ny utvecklare skulle kunna lägga mer tid på att koda istället för att gräva ner sig i leverans-/testningsprocessen. Slutprodukten ger företag möjligheten att koda direkt på sitt utvecklingskluster.

4 Författarens tack Projektgruppen vill rikta ett stort tack till vår kund Skira som har gett oss möjligheten och resurserna för att genomföra projektet! Vi vill speciellt tacka Joel Glemne på Skira som funnits tillgänglig för rådgivning och givit oss tips och vägledning genom projektets gång. Vi vill slutligen även tacka vår handledare Jonas Wallgren som bistått med feedback och trevliga handledarmöten, och gett oss goda råd på hur gruppen kan förbättra sin presentationsteknik. Tack allihopa! iv

5 Innehåll Sammanfattning Författarens tack Innehåll Figurer Tabeller iii iv v viii ix Introduction 1 1 Inledning Motivering Syfte Frågeställning Avgränsningar Bakgrund Kundens syfte Tidigare erfarenheter Teori Code-server Kontinuerlig integration Kontinuerlig distribution Pipeline Mikrotjänster i Kubernetes Google Cloud Platform Docker Telepresence Spinnaker YAML Git och Git hook Molntjänster Canary-distribuering Seleniumtestning Google Cloud Registry Metod Kravinsamling Scrum Utvecklingsmetod v

6 4.4 Utbildning Erfarenhetsuppfångning Resultat Systembeskrivning Gemensamma erfarenheter Värde för kunden Kvalitetskrav Översikt över individuella bidrag Diskussion Resultat Metod Arbetet i ett vidare sammanhang Slutsats 28 A Decentraliserade moln och molntjänster av Anton Andell 30 A.1 Inledning A.2 Bakgrund A.3 Teori A.4 Metod A.5 Resultat A.6 Diskussion A.7 Sammanfattning B C Ger en microservice-arkitektur snabbare kodleverans till slutanvändare av Eric Lilja 37 B.1 Inledning B.2 Bakgrund B.3 Teori B.4 Metod B.5 Resultat B.6 Diskussion B.7 Slutsats En jämförelse mellan muterbar och icke-muterbar serverinfrastruktur av Andreas Zeijlon 44 C.1 Inledning C.2 Bakgrund C.3 Teori C.4 Metod C.5 Resultat C.6 Diskussion C.7 Slutsats D Datasäkerhet inom molntjänster - en litteraturstudie av Nigel Cole 49 D.1 Inledning D.2 Bakgrund D.3 Teori D.4 Metod D.5 Resultat D.6 Diskussion D.7 Slutsatser vi

7 E Metoder och kostnad för mjukvarukvalitet - en fallstudie av David Thimren 57 E.1 Inledning E.2 Bakgrund E.3 Teori E.4 Metod E.5 Resultat E.6 Diskussion E.7 Slutsatser F För- och nackdelar med Dockercontainrar jämfört med virtuella maskiner av Wiktor Karlsson 63 F.1 Inledning F.2 Bakgrund F.3 Teori F.4 Metod F.5 Resultat F.6 Diskussion F.7 Slutsats G Klimatpåverkan av molntjänster av Diba Rezaie 70 G.1 Inledning G.2 Bakgrund G.3 Teori G.4 Metod G.5 Resultat G.6 Diskussion G.7 Slutsatser Litteratur 76 vii

8 Figurer 2.1 Hur en CI/CD pipeline kan se ut Översikt av systemet. Dev syftar på utvecklingsklustret; Prod syftar på produktionsmiljön Ett flödesschema över inloggningen till systemet Visual Studio Code som körs med Ubuntu tillgänglig via en webbläsare Inloggningsidan för en utvecklare på utvecklingsklustret. Här loggar man in och skickas vidare till sin personliga Code-server-instans Överblick över ett kluster och ett par Code-server instanser som ligger och kör i utvecklingsklustret Systemanatomi A.1 En bild av hur framtida molnet och internet kan vara uppbyggt.[66] E.1 Uppdelning av kvalitetskostnad G.1 Greenpeace tabell över företagens energikonsumption viii

9 Tabeller F.1 Resultat av Docker/VM experiment ix

10 Definitionslista A/B-leverans A/B-leverans är en strategi där två olika kodversioner exponeras mot varsin halva av slutanvändarna. Kombinerat med datainsamling och statistik används det för beslutsunderlag. AWS AWS är en förkortning för Amazon Web Services och är en molntjänst som företaget Amazon erbjuder. Azure Azure är en molntjänst som företaget Microsoft erbjuder erbjuder. Bambi Bambi är namnet på systemet som projektgruppen har utvecklat. Canary leverans Canary leverans är en distributionsstrategi där en liten del av användarbasen får tillgång till en ny version som successivt sprids till fler användare om inga fel inträffat. CD CD står för Continous Deployment och är en strategi för distribution av kod där koden passerar automatiserade tester innan den släpps ut i produktion. CI CI står för Continous Integration och är en utvecklingsstrategi där utvecklare integrerar sin kod flera gånger om dagen i en delad kodbas. Genom detta går det att detektera problem tidigt. Container Container är mjukvara som packar upp kod och all dess beroenden. Fjärrutveckling Fjärrutveckling innebär utveckling mot en extern miljö där kommunikationen sker över internet. GCP GCP är en förkortning för Google Cloud Platform och är en molntjänst företaget Google erbjuder. Git Git är ett versionshanteringsprogram. Git hook Git hook är det generella namnet på de skript som körs, om man ställer in dem, vid olika gitkommandon. Hot reload Hot reload är en automatisk systemombyggning vid förändring av källkod. Jenkins Jenkins är ett ramverk för att utföra automatiserad tester. 1

11 Tabeller Microservice-arkitektur Microservice-arkitektur är en server som består av olika delsystem som sammarbetar. Mikrotjänst Mikrotjänst är ett självständigt delsystem som tillsammans med andra mikrotjänster utgör ett helt system. Nodemon Nodemon är ett verktyg som har möjlighet att övervaka en fil för kodförändringar och starta om den i dess fall. Pipeline Pipeline är en serie processer som ska utföras. Skaffold Skaffold är ett bibliotek som kan användas för att lyssna på kodändringar och bygga om koden vid ändring. TCP TCP står för Transmission Control Protocol och är ett kommunikationsprotocol som används på internet i stor utsträckning för kommunikationer mellan två datorer. User story User story är en kort beskrivning av vad en användare vill uppnå. User stories är ett snabbt sätt att hantera kravställning. Visual Studio Code Visual Studio Code är ett kodredigeringsprogram. 2

12 1 Inledning Detta kapitel går igenom syftet med projektet, motivering till varför projektet behövs, vilka frågeställningar som projektmedlemmarna har arbetat med och de avgränsningar som projektet hade. 1.1 Motivering När en mjukvaruutvecklare ska påbörja sitt nya jobb kan det läggas väldigt mycket tid på att sätta upp miljön på arbetsdatorn. Drömscenariot hade varit att med några kommandon kunna sätta upp miljön och kunna distribuera kod utan några krångligheter. Denna rapport innehåller ett förslag till en lösning på det problemet - Bambi. Med hjälp av Bambi går det att lösa varje ny mjukvaruutvecklares problem och det hjälper företaget att vinna tid på att deras anställda direkt kan börja bidra till företagets kodbas. 1.2 Syfte Syftet med denna rapport var att ge en detaljerad beskrivning av hur Bambi fungerar och hur utvecklingsprocessen har gått till för att slutresultatet skulle uppnås. Projektet skapades av företaget Skira och handlar om CI/CD i molnapplikationer som Google Cloud, Azure och AWS. Projektet utfördes med öppen källkod där tanken är att både företag och privatpersoner ska kunna ta del av resultatet. 1.3 Frågeställning Nedan följer de frågeställningar som lade grunden för vad projektet fokuserade på. 1. Hur kan Bambi implementeras för att skapa värde för kunden? 2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intressanta för framtida projekt? 3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur mycket av en CI/CD-pipeline-uppsättning kan automatiseras? 3

13 1.4. Avgränsningar 1.4 Avgränsningar Projektet var begränsat till 400 timmar per projektmedlem, det vill säga totalt 2800 timmar. 4

14 2 Bakgrund Nedan följer bakgrunden till arbetet. 2.1 Kundens syfte Projektgruppens kund Skira är ett ungt företag som skapades med syftet att ge bättre mat till fler människor, och har sedan det grundades utvecklat digitala tjänster för att skapa mer lönsamhet inom lantbruket [38]. Som många andra mindre företag vill man snabbt, enkelt och billigt kunna distribuera sina tjänster och har därför använt sig av molnlösningar för att åstadkomma detta. Det är också viktigt att smidigt kunna uppdatera sina tjänster, därför använder Skira som många andra företag en microservice-arkitektur för att åstadkomma detta. För att göra utveckling och leverans av tjänster snabb och smidig arbetar man ofta med någon sorts automatiserad pipeline. En pipeline ser huvudsakligen till att all kod som bidras till projektet håller god kvalitet och stämmer överens med de krav som företaget har specificerat. Detta gör att man med större säkerhet kontinuerligt kan leverera uppdateringar till kunder och samtidigt minimera risken att någonting går fel i sluttjänsten. Se fig. 2.1 för ett exempel på hur en pipeline kan se ut/fungera. Problemet med pipelines är ofta att det är mycket att konfigurera och sätta upp. Den består också av många olika oberoende delar som behöver extra ramverk för att kunna samarbeta på ett smidigt sätt. Skira presenterade en idé om att bygga ett system som skulle göra just pipeline-processen enklare att sätta upp och enklare att jobba med. Målet är att en ny utvecklare ska kunna börja utveckla med endast ett kommando, med funktioner som hot reload, fjärrutveckling, automatisk testning och leverantörsagnotisk distribution. De ville även att det skulle göras med öppen källkod då de kände att det är funktioner de hade velat ha när de började. Alltså byggs systemet för att förhoppningsvis göra utveckling enklare för många molntjänst-utvecklare. 5

15 2.2. Tidigare erfarenheter Figur 2.1: Hur en CI/CD pipeline kan se ut. 2.2 Tidigare erfarenheter Projektgruppen som utförde detta består av sex tredjeårsstudenter på civilingenjörsprogrammet i datateknik och en i mjukvaruteknik. De viktigaste erfarenheterna under de tre åren är från kursen i programutvecklingsmetodik och de större projektkurserna konstruktion med mikrodatorer för datorteknikerna och ett AI-projekt för mjukvaruteknikern där man arbetade i grupper om sju respektive sex personer. Från dessa kunde vi ta erfarenheter för att sätta upp bra dokumentations- och kommunikationsstandarder tidigt. Det fanns också viss erfarenhet inom gruppen om agil utvecklingsmetodik vilket gjorde att vi kunde börja arbeta agilt snabbt och smidigt. Några gruppmedlemmar hade mer kunskap inom området för detta projekt vilket gjorde att vi kunde fråga varandra och komma igång snabbt med utvecklandet. 6

16 3 Teori Nedan följer den teori som behövs som bas för att förstå arbetet. 3.1 Code-server Code-server är ett öppen källkodsprojekt skapat av företaget Coder Technologies Inc [15]. Code-server är en vidareutveckling av Microsofts Visual Studio Code [63] som möjliggör användare att interagera med Visual Studio Code via en webbläsare. 3.2 Kontinuerlig integration Kontinuerlig integration (CI) är en process som automatiserar en del av arbetsflödet genom att bygga systemet och testa det varje gång kodförändringar visas i versionshanteringen. Detta uppmuntrar utvecklare att dela med sig av kod och enhetstestning i den delade versionshanteringen. En stor fördel är att CI låter utvecklare arbeta enskilt utan problem med integrationen av kod. Små integrationer sker hela tiden istället för att göra stora integrationer med långa mellanrum [44]. 3.3 Kontinuerlig distribution Kontinuerlig distribution (CD) är en praktik som anammas i allt högre grad av industriledare inom mjukvara. CD innebär att flera utvecklare av ett och samma system alla ska leverera kod så ofta som möjligt. Alla former av kodförändringar, till exempel nya funktioner och buggfixar ska autonomt kunna föras till produktion och användare på ett säkert, snabbt och hållbart sätt. Kod ska alltid vara distribuerbar [52]. 3.4 Pipeline En traditionell CI/CD pipeline startas genom en kodförändring i kodbasen. Detta kommer att bygga ihop kod och testa den med enhetstester och integrationstester. Sedan levereras den nya versionen av koden. I Bambi är pipelinen strukturerad lite annorlunda. Istället för 7

17 3.5. Mikrotjänster i Kubernetes att bygga och testa kod genom pipelinen utförs de stadierna i utvecklingsmiljön och därefter levereras förändringarna till produktionsmiljö. [75]. 3.5 Mikrotjänster i Kubernetes Kubernetes är en plattform med öppen källkod för automatisk distribuering, skalning och hantering av behållare i ett kluster. Kubernetes används ofta med Docker, se 3.7. Mikrotjänster strukturerar en applikation till flera självständiga tjänster. Fördelarna är modularitet, lättviktiga protokoll och att det är lättare att förstå, utveckla och testa. Bambi skapar inte själv Kubernetes-kluster men använder sig av redan skapade kluster som användare förser Bambi med [87]. 3.6 Google Cloud Platform Google Cloud Platform, även förkortat GCP, är en samling av molntjänster skapad av företaget Google. Dessa tjänster består bland annat av lagring av diverse data, uppsättning och underhåll av Kuberneteskluster och körning av instanser av virtuella maskiner på Googles infrastruktur. Eftersom GCP är en samling molntjänster kan man dessutom välja var i världen man vill sätta upp sina resurser (Virtuella maskiner, Kuberneteskluster och så vidare) [39]. 3.7 Docker Docker är en typ av behållare som innehåller kod tillsammans med dess konfigurerade beroenden i en separat miljö. Docker har öppen källkod och är världsledande inom sitt område. Det är ett lättviktigt, självständigt och exekverbart paket med programvara som innehåller allt nödvändigt för att köra en applikation. Det fungerar väldigt likt en virtuell maskin, en dedikerad egen miljö som i praktiken är en egen dator. Den stora nyckelskillnaden är att Docker utnyttjar den lokala operativsystemkärnan istället för att ha ett eget operativsystem [27]. 3.8 Telepresence Telepresence är ett verktyg som hjälper till att avlasta lokala utvecklingsmiljöer genom att bara köra de tjänster som ska ändras lokalt. De andra tjänsterna körs på ett avlägset Kuberneteskluster som de lokala tjänsterna kan kommunicera med och då beter sig som ett komplett kluster utan att behöva köra hela klustret lokalt [21]. 3.9 Spinnaker Spinnaker är ett verktyg för att distribuera tjänster till många olika moln. De ger också möjligheten till många olika bra strategier för hur tjänster ska distribueras, som till exempel canary distribuering, se 3.13 [88] YAML YAML är ett dataserialiseringsformat som är lättläst och bekvämt att använda. Det används ofta till konfigurationsfiler [100] Git och Git hook Git är ett versionshanteringsprogram. Det används för att kunna klona en kodbas från en server till en lokal miljö och dessutom kan lokal kod levereras till servern. När gitkommandon 8

18 3.12. Molntjänster utförs kan man köra skript som reagerar på dessa kommandon. Dessa skript kallas för Git hooks och används för att utföra önskad logik [37] Molntjänster En molntjänst är en service tillhandahållen av en molntjänstleverantör och är tillgänglig för användare via internet och är ett alternativ till att en användare använder egna servrar. Molntjänster är lättanvända och skalar lätt, och både resurser och tjänster hanteras av molntjänstleverantören. Det finns flera funktioner som onlinedatalagring och backupsystem. Användare betalar oftast för datakraften de använder vilket kan leda till stora skillnader i kostnader mellan lugna och hektiska perioder. Några stora leverantörer är Amazon Web Services och Google Cloud Platform [6] Canary-distribuering Canary-distribuering exponerar kodförändringar till en liten del av slutanvändarna för att riskminimera potentiella fel med nya förändringar. Då det endast sker till en liten andel av användarna har det därmed en relativt liten påverkan där förändringar snabbt kan återställas vid fel. Tester för denna leverans är oftast automatiska och utförs vid avklarad testning. Denna typ av leverans tillåter utvecklingsteamet att snabbt evaluera resultatet av koden vare sig den nya koden gav de önskade resultaten eller inte [78] Seleniumtestning Selenium är ett verktyg som automatiserar webbläsare. Huvudsakligen används det för att automatisera webbapplikationer för teständamål. Testerna, som skapas av användaren, kan köras över olika webbläsare och plattformar som Windows, Linux och macos. Selenium är kostnadsfritt och är tillgängligt som öppen källkod [45] Google Cloud Registry Google Cloud Registry (GCR) är en tjänst tillhandahållen av Google för att lagra ens Dockercontainrar. [40] Används ofta i kombination med CI/CD för att ha ett samlat ställe att lagra och hantera sina mikrotjänser. 9

19 4 Metod Nedan följer den metod som projektet har följt för att uppnå resultatet beskrivet i denna rapport. 4.1 Kravinsamling Kraven för projektet samlades in från kunden Skira. Detta började med en projektgenomgång för vad projektet översiktligt skulle handla om. Efter det har två möten hållits med Skira för att mer specifikt samla in de krav som ställs på systemet. Speciellt under det andra mötet gav Skira en user story för att underlätta förståelsen för vem systemet var avsett för. Efter det skrevs en kravlista av alla gruppmedlemmarna i projektgruppen och sedan skickades denna in till kunden för bekräftelse att kraven stämde. 4.2 Scrum Scrum är ett ramverk för att utveckla och underhålla komplexa produkter, och är mycket vanligt för programvaruutveckling. Det är en agil utvecklingsmetod som bygger på en iterativ arbetsprocess, där man delar in arbetet i korta perioder, så kallade sprintar. Gruppen valde att en sprint skulle vara ungefär två veckor lång. Inför varje sprint höll utvecklingsledaren en planeringssession där gruppen bestämde vilka aktiviteter som skulle utföras under kommande sprint. Dessa aktiviteter samlades sedan i en lista som kallades backlog. Varje sprint avslutades med en återblick på vad som gick bra och vad som gick mindre bra under sprintens gång, och utifrån det infördes olika åtgärder inför nästa sprint. Gruppen hade två statusmöten i veckan, ett på tisdagar och ett på fredagar. Under dessa möten berättade varje gruppmedlem vad de gjort sedan senaste mötet, vilka problem de hade stött på, vad de ska göra fram till nästa möte och vad som hindrar dem. Det var ett tillfälle för gruppen att inspektera hur långt de hade kommit i sprinten och om några åtgärder behövde tas. Mötena fick ta max 15 minuter. Utvecklingsledaren agerade Scrum Master vars ansvar var att säkerställa att processen efterlevdes av projektgruppen, att synkronisera gruppmedlemmarna och avlägsna hinder för processen. 10

20 4.3. Utvecklingsmetod 4.3 Utvecklingsmetod Projektet var uppdelat i två faser: förfasen där planering och kravverifiering framställdes och utvecklingsfasen då produkten skapades. Gruppen valde under utvecklingsfasen att arbeta efter Scrum-modellen. Nedan följer en beskrivning av Scrum och hur projektgruppen arbetat under förfasen och utvecklingsfasen Förfas Förfasen började med att rollerna teamledare, kvalitetssamordnare, utvecklingsledare, testledare, dokumentansvarig, analysansvarig och arkitekt delades ut utifrån preferenser från gruppmedlemmarna. Rollerna hade dessa ansvar i förfasen: Arkitekten var ansvarig för att leverera en översiktlig bild av systemet så att sprint 1 kan påbörjas i utvecklingsstadiet. Där ska komponenter och gränssnitt vara identifierade. Detta arbete dokumenterades i en arkitekturbeskrivning. Analysansvarig är ansvarig för att få en klar kravbild från kunden så att planeringen som utförs i förfasen är i linje med vad kunden förväntar sig. Analysansvarig ska också vara en förhandlingspart mellan gruppen och kunden för att ta fram rimliga krav i avtalet som projektgruppen ska genomföra. Kvalitetssamordnaren har som ansvar att definiera ett mätbart kvalitetskrav på projektet som sedan kan användas för utvärdering under utvecklingsstadiet och i förstudien. Konfigurationsansvarig har som ansvar att sätta upp en utvecklingsmiljö som är redo när utvecklingsstadiet börjar. Det inkluderar saker som versionshantering i Git. Testledaren har som ansvar att påbörja en testplan så att gruppen i utvecklingsstadiet kan få tidig återkoppling på sin kod. Utvecklingsledaren har som uppgift att under förstadiet ta fram en utvecklingsmetodik och se till att den efterföljs av resterande gruppmedlemmar. Den har även sista ordet i val av utvecklingsmiljö och språk. Teamledaren ska se till att allt arbete utförs i förfasen. Utöver det skapades en projektplan som beskrev hur arbetet skulle gå till och en kvalitetsplan som beskrev hur kvaliteten på projektet ska hållas. Även kravspcifikationen framställdes utifrån möten med kunden som beskriver vad produkten har för funktionella krav och designkrav Utvecklingsfas I utvecklingsfasen valdes Scrum som utvecklingsmetod. Arbetet delades in i olika iterationer och alla roller fick då nya ansvarsområden. Teamledaren har fortsatt ansvar för att projektets processer följs och att gruppen har en bra arbetsmiljö. Teamledaren ska också agera coach i den mån som det behövs för att lyfta medlemmar eller gruppen vidare vid problem. Analysansvarig har fortsatt kundkontakt för att se till att projektets innehåll håller sig inom ramarna för vad kunden förväntar sig. Hen är också ansvarig för att besvara möjliga frågor från gruppmedlemmar gällande kunden och dess förväntningar. Arkitekten ser till att en stabil arkitektur tas fram och implementeras och gör övergripande teknikval. Hen ska kontinuerligt dokumentera arkitekturval. 11

21 4.4. Utbildning Utvecklingsledaren har ansvar för den detaljerade implementationen av arkitekturen. Det innebär att leda och fördela utvecklingsarbetet mellan gruppens alla medlemmar och organisera utvecklarnas tester. Utvecklingsledaren har ansvar för att alla aktiviteter blir gjorda och att alla medlemmar alltid har något att göra. Testledaren tar beslut om systemets status och ser till att det sker verifieringar och valideringar i enlighet med testplanen. Resultatet av detta ska sedan sammanfattas i en testrapport. Kvalitetssamordnaren har yttersta ansvar för att planera och budgetera projektets resurser och därmed projektmedlemmarnas tid. I och med detta ska kvalitetssamordnaren se till att fånga upp de olika medlemmarnas kunskaper för att på effektivast möjliga sätt fördela arbetet mellan dem. Dokumentansvarig ska se till att potentiella förändringar av projektets krav eller andra parametrar som har dokumenterats uppdateras i enlighet med förändringen. Konfigurationsansvarig bestämmer vilka delar som ska versionshanteras och vad som ingår i en utgåva av projektet. Konfigurationsansvarig ser även till att versions- och konfigurationshantering underhålls och används av gruppens medlemmar enligt gruppens överenskommelse. 4.4 Utbildning Alla projektmedlemmar utbildades främst på två olika sätt - genom egen forskning inom det område hen arbetade på och under möten då alla utbildade varandra i sina områden. Utbildningen av varandra gjordes under återblicken av varje sprint där alla presenterade det arbete som gjorts, hur det fungerar samt vad de lärt sig. På detta sätt får alla en uppfattning om hur alla delar av projektet fungerar. 4.5 Erfarenhetsuppfångning För att samla in information om alla gruppmedlemmarnas tidigare erfarenheter hölls ett informellt möte där alla pratade om relevanta erfarenheter och i vilka projekt de arbetat tidigare. Detta gjordes genom en gruppdiskusion där alla medlemmar fick berätta om vilka projekt de haft tidigare och vad de lärt sig utifrån dem. Denna information användes senare när arbetsuppgifterna delades upp inför varje sprint. För att samla in erfarenheter under projektets gång hölls ett par scrummöten varje vecka. Under dessa möten kunde varje medlem dela med sig av sina erfarenheter om vad hen hade arbetat med och eventuella problem hen stött på till resten av gruppen. Efter varje sprint hölls även ett retrospektivt möte där gruppen identifierade vad som hade fungerat bra och mindre bra under sprinten. Detta gjorde så att gruppen kunde ta tillvara av de erfarenheter som samlats upp under den avklarade sprinten och förbättra utvecklingsprocessen till framtida sprintar. Gruppen såg även till att det fanns en öppen atmosfär där man lätt kunde fråga om hjälp från andra gruppmedlemmar. Detta gjorde bland annat att erfarenheter lättare kunde bytas ut mellan undergrupperna som var fokuserade inom olika områden. 12

22 5 Resultat Här presenteras en översiktlig beskrivning av den arkitektur som projektgruppen har implementerat, hur den kan skapa värde för kunden samt gruppens gemensamma erfarenheter. 5.1 Systembeskrivning Nedan presenteras en beskrivning av det systemet som har skapats under projektet Översiktlig beskrivning av systemet Systemet abstraheras på en hög nivå till tre moduler. Dessa moduler representerar de tre områdena i utvecklingen av Kubernetesapplikationer som systemet har som syfte att förenkla. Kubernetesapplikationer karakteriseras av att vara en uppsättning av individuella, självständiga moduler som kommunicerar sinsemellan. De tre områdena är utveckling, testning och leverans. Systemet har även beroenden till yttre tjänster. Dessa är tjänster för versionshantering som Gitlab, Github och Bitbucket samt molnleverantörer som Google Cloud Platform, Microsoft Azure och Amazon Web Services. Dessa anses som förutsättningar för att systemet ska kunna användas. En överblick av detta fås i figur 5.1. Arkitekturen är framtagen med målet att skapa ett modulärt system där individuella delar enkelt ska kunna bytas ut. Det var även viktigt att systemet var händelsedrivet så att de individuella modulerna inte behöver stå och vänta på varandra. En annan viktig faktor är att systemet ska kunna skala väl för att kunna möta ett behov av olika storlekar Lokal utveckling Modulen för lokal utveckling består i huvudsak av två open-source-projekt som heter Codeserver och Telepresence. Det kräver även att det finns en kopia av produktionsmiljön uppsatt, ett så kallat utvecklingskluster. Detta kluster kommer att användas för att en utvecklare ska ha möjlighet att se hur nya funktioner interagerar med det resterande systemet utan att själv behöva tillhandahålla produktionsmiljön lokalt på sin dator. Dessa två projekt ger oss möjligheten att erbjuda utvecklare hot reload och avlastar deras datorer genom att placera utvecklingsmiljöerna på en avlägsen server i utvecklingsklustret. 13

23 5.1. Systembeskrivning Figur 5.1: Översikt av systemet. Dev syftar på utvecklingsklustret; Prod syftar på produktionsmiljön. För hot reload skapades därmed ett skript som finns tillgängligt att köra var som helst på Code-servern. Det tar en inparameter för den tjänst man vill utveckla och använder därefter Telepresence för att byta ut denna tjänst på utvecklingsklustret mot en lokal variant. Skriptet vidarutvecklades dessutom genom utökning med en flagga som avgör hur skriptet ska exekveras. Det första alternativet är att köra utan flaggan. Detta medför att utvecklaren själv måste integrera någon form av omladdningsmodul i sin Dockerfil för den valda tjänsten. Ett exempel på detta kan vara Nodemon. Vid kodändring kommer därmed programmet som körs i Dockercontainern snabbt startas om med de nya ändringarna. Det andra alternativet är att köra skriptet med flaggan vilket medför att Dockercontainern både byggs och startas om varje gång det blir en kodändring. Detta tar ofta betydligt längre tid än det första alternativet men fungerar utan att utvecklarna behöver installera något själva som vid körning utan flagga. I bakgrunden av Code-server körs Ubuntu där de verktyg som utvecklarna behöver kan installeras och användas från webbläsaren. Utvecklingsmiljön är paketerad som en modifierbar Dockercontainer vilket gör att utvecklingsmiljön också kan förkonfigureras med den mjukvara som krävs för ett specifikt projekt Code-server Att använda Code-server som utvecklingsmiljö var en lösning som passade vår bild av vad kontinuerlig integration innebär. Det innebär dessutom att varje utvecklare har full tillgång till sin utvecklingsmiljö från alla webbläsare. Inloggningsprocessen illustreras i figur 5.2. Att logiskt placera utvecklingsmiljön inom utvecklingsklustret ger en direkt närhet till systemet som utvecklas utan att kräva extra resurser från utvecklarens utvecklingsmiljö. Det ger även möjligheten att utföra integrationstester i en kontrollerad miljö utan att behöva bygga systemet då de kan utföras direkt på utvecklingsklustret. Att slippa bygga systemet vid leverans ger en direkt reducering av tiden det tar att leverera kod till kunder och för utvecklare att få återkoppling på leveransen. Möjligheten att kunna fördefiniera vilken mjukvara som ska finnas i utvecklingsmiljön är även en funktion som för oss ett steg närmre den bild som målades upp av kunden - att en ny utvecklare ska kunna börja utveckla med så lite ansträngning som möjligt. En väldefinierad 14

24 5.1. Systembeskrivning miljö gör att alla verktyg som behövs för att utveckla kommer förinstallerade för alla nya utvecklare. Figur 5.2: Ett flödesschema över inloggningen till systemet. Figur 5.3: Visual Studio Code som körs med Ubuntu tillgänglig via en webbläsare. 15

25 5.1. Systembeskrivning För att få systemet att fungera i utvecklingsklustret krävdes det en strategi för att hantera flera samtida användare av systemet. Det gjordes genom att placera en extra nod i utvecklingsklustret som ser till att tillräckligt med utvecklingsmiljöer finns tillgängliga. Den mjukvaran är skriven i språket Python och använder sig av Kubernetes officiella Pythonklient [70] för att kommunicera med utvecklingsklustrets API. Vyn som presenteras för en utvecklare som ska använda sin utvecklingsmiljö visas i figur 5.4. Figur 5.4: Inloggningsidan för en utvecklare på utvecklingsklustret. Här loggar man in och skickas vidare till sin personliga Code-server-instans. Vi insåg också att alla användare kommer vilja installera egna bibliotek, ha egna konfigurationer och kunna skriva kod utan att den behöver levereras upp till Git. Vi löste detta genom att varje användare får en version av en basmiljö där hens egna ändringar och konfigurationer automatiskt sparas. Att placera utvecklingsmiljön i ett Kuberneteskluster i kombination med att använda till exempel Google Cloud Platform ger möjligheten att dynamiskt öka prestandan hos utvecklingsmiljöns hårdvara för att klara av tunga eller tidskritiska beräkningar Testning Denna modul har som ansvar att utföra enhets- och integrationstester av kubernetesapplikationen. Då utvecklingsmiljön är placerad i utvecklingsklustret kan integrationstester köras utan att hela systemet behöver byggas. Detta möjliggörs av Telepresence som skapar en koppling mellan de lokalt utvecklade funktionerna och det resterande systemet. Då testerna kommer att köras i utvecklarens miljö var utmaningen att kunna garantera att koden som lämnas in till kodbasen har klarat de tester som ställs som krav. Lösningen som togs fram var att förkonfigurera utvecklingsmiljön med Git hooks som ser till att testerna körs innan de kan levereras till kodbasen Leverans Denna modul har som ansvar att leverera testad kod från versionsantering till en produktionsmiljö. Denna produktionsmiljö ska finnas hos en eller flera molnleverantörer, således 16

26 5.1. Systembeskrivning var det viktigt att finna mjukvara med stöd för att leverera kod till olika molnleverantörer. Valet föll i första hand på Spinnaker som inte bara har stöd för att leverera kod till flera molnleverantörer utan också för att automatisera olika typer av leveranser som canary - och A/B -leverans. Spinnaker var dock överflödig i viss mängd då vi kunde lösa mycket av dess funktionalitet, som byggning och testning av containrar, på ett bättre sätt med hjälp av Code-server. Vi gjorde då också en egen enkel leveransmodul mer i linje med vår vision av kontinuerlig leverans. Detta gjorde vi mest för att se vad som är möjligt och för att visa vad man skulle kunna åstadkomma med Bambi vid vidare utveckling. I slutändan är det dock Spinnaker som uppfyller de krav vi har på arbetet Förkrav och konfiguration För att sätta upp ett fungerande system krävs det viss konfiguration och förutsättningar för att få Bambi att fungera. Detta kommer att diskuteras i denna sektion Förkrav Systemet är designat för att fungera i ett Kuberneteskluster i Google Cloud Platform [41]. Det krävs att det finns ett uppsatt utvecklingskluster med det system som ska utvecklas. Där kommer även Code-server instanserna att finnas. Förslagsvis bör det även finnas ett uppsatt produktionskluster som utvecklade förändringar av systemet ska levereras till. Det krävs även att Google Cloud Registry [40] är uppsatt och att vår version av Code-server finns lagrad där. Slutligen krävs det att Git används för versionshantering Konfiguration När förkraven är uppfyllda krävs det en ifylld YAML-konfigurationsfil för att få systemet att fungera. Den information som behövs är de kluster som ska användas av systemet, de testfiler som ska köras vid testning av systemet, en fungerande URL till kodbasen och en specifiering av de delsystem som systemet innehåller vid uppsättning av systemet. För ett fungerande system med sex aktiva användare bör vyn av ens Kubernetes- workloads se likt ut de workloads placerade i dev-cluster som visas i figur 5.5. Figur 5.5: Överblick över ett kluster och ett par Code-server instanser som ligger och kör i utvecklingsklustret. 17

27 5.1. Systembeskrivning Systemanatomi I förstadiet av projektet utformades en systemanatomi (se figur 5.6) för att få en översiktlig vy av systemet och för att identifiera olika systembehov. Den ger en översiktlig bild av funktionaliteten som systemet har. Figur 5.6: Systemanatomi 18

28 5.2. Gemensamma erfarenheter 5.2 Gemensamma erfarenheter Några viktiga erfarenheter från förfasen av projektet var bland annat kunskapen om hur man strukturerar ett projekt. Detta innebar till exempel att skapa värdefull dokumentation för projektet. Dokumentationen bestod av allt från kravspecifikation till projektplanering. Några av dessa dokument krävde dock ett flertal uppdateringar under projektets gång då gruppen, vid vissa tillfällen, bytte riktning i hur produkten skulle tas fram. Detta gav gruppen erfarenhet i att hålla projektdokumenten levande och synkroniserade med resten av projektet. I struktureringen av projektet skapades även ett gruppkontrakt där gruppens regler för projektet etablerades. Detta dokument inkluderade även en rollista för gruppmedlemmarna. Detta gjorde att gruppmedlemmarna fick erfarenhet av att ta ansvar för varsitt område i projektets utveckling. Förfasen gav även en möjlighet för gruppmedlemmarna att få insikt i och erfarenhet av viktiga begrepp som CI/CD och nybörjarkunskap i programvara som Docker och Kubernetes. Utvecklingsfasen gav gruppen erfarenhet av utvecklingsmetoden Scrum. Detta var dock en modifierad version av Scrum där dagliga möten byttes ut mot två möten per vecka. Utvecklingsmetoden gjorde så att gruppen kunde se framsteg och eventuella problem och veta vad de andra medlemmarna gjorde. Detta gjordes genom att under de två mötena per vecka låta gruppmedlemmarna berätta om sina erfarenheter och problem som de stött på sedan senaste mötet. Eftersom dessa möten hölls relativt ofta så minimerades risken att arbetet saktade upp eller att någon fastnade utan tillgång till hjälp från resten av gruppen. Utvecklingsfasen gav även djupare kunskap om, och erfarenhet av, den programvara som behövdes i projektet. Exempel på de mest allmänt förekommande programmen som gruppen fick mycket erfarenhet av under projektet var Docker och Kubernetes tillsammans med plattformen GCP. Även om mycket program och ramverk som försökte integreras in i produkten inte kom med i slutversionen så gav dessa ändå erfarenhet i hur de skulle kunna användas i framtiden. Ett exempel på detta är ramverket Spinnaker som till slut valdes bort på grund av svårighet att integrera på ett generellt sätt tillsammans med tidsbrist. En annan viktig erfarenhet projektgruppen fick var att arbeta mot en extern kund i företaget Skira. Ett exempel på en sådan erfarenhet var bland annat att utforma en produkt efter kundens önskemål. Att det var en extern kund gav även en ökad press för projektet där många av medlemmarna ville se projektet lyckas för att göra kunden nöjd. Framförallt har projektgruppen erhållit en ökad erfarenhet i problemlösning. 5.3 Värde för kunden Projektet har gett värde för kunden genom att sänka barriären som krävs för en ny utvecklare att kunna leverera kod till kundens slutanvändare. Detta genom att ge kunden möjlighet att leverera en förkonfigurerad miljö till dess anställda där all mjukvara som behövs för utvecklingen kan specificeras så att den görs tillgänglig för varje anställd. Det ger även möjlighet att automatisera tester utan att kräva extra byggtid vilket ger utvecklaren snabb återkoppling på nyutvecklad kod. Vidare skapar det värde för kunden att projektgruppen har undersökt hur man kan automatisera leveransen av koden till produktionsmiljön, oavsett om miljön hanteras av Googles, Amazons eller Microsofts molntjänster. Olika möjligheter för hur dessa processer och konfigurationer kan automatiseras har undersökts vilket ger kunden värde vid framtida undersökningar och implementationer då vi har gett underlag inom området. Då det är ett generellt system som har utvecklats krävs en viss manuell konfiguration för att systemet ska kunna identifiera produktions- och utvecklingsklustret, konfigurera leveransprocessen och definiera vilken mjukvara som behövs i utvecklingsmiljöerna. Dessa delar är av varierande svårighetsgrad beroende på komplexiteten hos kundens individuella utvecklingsbehov. Då varje system och projekt är unikt kommer det att skilja sig mellan dem 19

29 5.4. Kvalitetskrav beroende på hur och vart de vill leverera sin kod. Detta gör att varje projekt kommer behöva definiera sin egen leveransprocess. 5.4 Kvalitetskrav Det kvalitetskrav vi arbetade mot blev uppfyllt. För att börja använda systemet behöver användaren endast gå in på inloggningssidan, och skriva in sina Git inloggningsuppgifter. Sedan loggar användaren in och kan börja bidra med kod till företaget. Detta uppfyller det krav att antal steg för en ny användare att börja använda systemet inte ska överstiga fem. 5.5 Översikt över individuella bidrag Projektets medlemmar har under projekttitden utfört mindre undersökningar av specifika områden kopplade till projektet. Denna del ger en kort översikt av de undersökningarna Decentraliserade moln och molntjänster av Anton Andell Mer och mer system idag läggs på molnen, och de flesta på Google Cloud Platform eller AWS. Detta gör att mycket av trafiken på internet går genom ett fåtal företag. Detta bidrag undersöker hur det är att istället använda ett decentraliserat moln i syftet att hålla internet decentraliserat Ger en microservice-arkitektur snabbare kodleverans till slutanvändare av Eric Lilja Detta bidrag undersöker systemarkitekturens påverkan på leveranstider. Den jämför en microservice-arkitektur med en monolitisk arkitektur och dess påverkan på leveranstider av kod till slutanvändare. Då projektet avser att automatisera leveransen av microserviceapplikationer blev det av intresse att se om microservice-arkitekturen främjar kontinuerlig leverans En jämförelse mellan muterbar och icke-muterbar serverinfrastruktur av Andreas Zeijlon Frågan om muterbar eller icke-muterbar serverinfrastruktur är fundamental för serverhantering och underhåll. Därför ska den här studien undersöka och jämföra deras för- och nackdelar för att komma fram till när man bör använda den ena framför den andra Datasäkerhet inom molntjänster - en literaturstudie av Nigel Cole I dagens samhälle flyttar produkter alltmer till molnet. Det finns många fördelar men datasäkerheten är inte tillräcklig. Med nya lösningar kommer alltid nya brister vilket kan utnyttjas av hackare. Denna undersökning har i syfte att ta reda på de åtgärder som kan göras för att skydda data vid användning av molntjänster och vad som är viktigt att veta vid val av distributionsmodell samt eventuella alternativ till molntjänster Metoder och kostnad för mjukvarukvalitet - en fallstudie av David Thimren Mjukvarukvalitet är en väldigt viktig och stor del av varje mjukvaruprojekt. Utan bra metoder och verktyg kan kvalitetsarbete kosta mer än vad det behöver och därför kommer denna studie beskriva hur vi arbetade med vår mjukvarukvalitet och hur mycket det kostade. 20

30 5.5. Översikt över individuella bidrag För- och nackdelar med Dockercontainrar jämfört med virtuella maskiner av Wiktor Karlsson Många nya former av virtualisering har på senaste tiden dykt upp i dagens samhälle varav en av dessa är containrar. Detta bidrag ger en översikt över för- och nackdelarna med Dockercontainrar, som har använts genomgående under projektet, jämfört med traditionella virtuella maskiner Klimatpåverkan av molntjänster av Diba Rezaie Företag börjar gå allt mer mot en microservice-arkitektur i sin verksamhet vilket bidrar till att molntjänsterna växer sig allt större. Då mer data belastar molnen krävs det mer elektricitet som driver datacentrerna för att hålla molntjänsterna uppe. Denna undersökning kommer att jämföra de tre största molntjänsterna (GCP, Azure och AWS) och dess klimatpåverkan. 21

31 6 Diskussion I detta kapitel presenteras diskussionen. 6.1 Resultat Nedan följer diskussionen om resultatet Implementationsval Vi fick av kunden en hel del krav på systemet men vi lämnades ändå med många valmöjligheter samt lite fria händer att skapa något användbart. Med valet att implementera Code-server tog vi bort många steg från den konventionella pipelinen och löste många av de problem vi ställdes inför i början av projektet. Under ett möte med kunden nämndes en önskan om att nya utvecklare ska kunna börja jobba med så lite uppsättning som möjligt och vi ansåg att Code-server skulle bidra mycket till detta. Med detta valet hade vi inte längre någon naturlig plats för testverktyg som Jenkins, så vi bestämde oss för att köra på lokal testning. Lokal testning brukar inte var att föredra men eftersom vår lokala miljö ligger på molnet så undkommer vi de flesta problemen med lokal testning. Vi kan nyttja faktumet att vi redan har en uppdaterad, färdigbyggd miljö och därifrån kan köra tester på systemet i helhet. En annan anledning att använda externa ramverk som Jenkins är att automatisera tester. För att lösa det valde vi att använda oss av enkla Git hooks då vi, eftersom vi har kontroll över miljön, kan tvinga på Git hooks och därigenom kontrollera alla leveranser. För slutprodukten ansåg vi det viktigt att användaren skulle kunna se hur deras ändringar i koden påverkade och samspelade med klustret utan att behöva gå igenom hela leveransprocesen. För att implementera den funktionaliteten valde vi att använda programmet Telepresence. Telepresence gav oss möjligheten att byta ut en mikrotjänst i klustret mot en lokal Dockercontainer. För automatisering av modulen bestämdes det att ett program skulle övervaka kodändringar i de filer man arbetade med. Vid förändring skulle containern laddas om så att förändringarana kunde observeras i systemet. För den övervakningen stod valet mellan att använda programmet Skaffold eller skapa en egen variant med hjälp av ett bashskript. Inledningsvis tänkte vi använda Skaffold men den 22

32 6.1. Resultat planen byttes snabbt ut då programmet inte hade all funktionalitet vi behövde för modulen. Ett bashskript valdes därmed istället. I början låg fokus bara på att få skriptet att kunna bygga och starta om hela Dockerfilen men när detta väl fungerade implementerades en flagga för ett annat alternativ. Detta alternativ var att låta utvecklarna själva lägga till en omladdningsmodul i Dockerfilen så att omladdningen av programmet skedde inifrån. Det skriptet gjorde vid detta alternativ var att montera in mappen som tillhörde tjänsten som skulle utvecklas. Detta innebär att filändringar i mappen på värddatorn medför ändringar i containrarnas mapp vilket då aktiverar den valda omladdningsmodulen. Dessa val implementerades för att ge framtida utvecklare mer frihet i att utveckla på det sätt som bäst passar dem. Skriptet har även möjlighet att vidareutvecklas i framtiden med lätt utökning av flera flaggor och alternativ. Något som var viktigt för kunden var att kunna distribuera applikationen till flera molnleverantörer. Här valde vi mellan att skriva en egen lösning och att integrera ett redan existerande bibliotek för att göra det enklare att använda. Att skriva en egen lösning och implementera de behövda strategierna däri verkade vara en väldigt tung uppgift så vi valde att använda oss av biblioteket Spinnaker. Spinnaker visade sig vara svårt att sätta upp och krävde mycket specifik användarinfo som skulle levereras till spridda delar av systemet. Vi insåg då att vi inte hade tid att integrera Spinnaker med vårt system. Vi bestämde oss i slutändan för att i största möjliga mån låta systemet vara kompatibelt med en framtida utökning med Spinnaker men implementerade istället en egen leveransmodul för att göra en smidig, enkel och integrerad leverans för att visa möjligheterna med, och vår vision för, projektet Vidareutveckling Bambi skapades inte med intentionerna att vara en helt färdig produkt vid slutet av projektet utan kunden ville ha något som kunde utvecklas vidare. Nedan kommer våra tankar om framtida förbättringar och ändringar Hot-reload/utveckling Här använder vi oss nu av Teleprecense i samarbete med en hot-reload-del för den Dockercontainer som körs. Teleprecense är skapat för utveckling på ett kuster från en lokal miljö. Vi är inte längre i en lokal miljö och Teleprecense är i viss mån lite överflödigt och en mer elegant lösning skulle kunna konstrueras. Teleprecense tillåter inte heller fler utvecklare på samma mikrotjänst och de tjänster som utvecklas kan störa varandra när flera utvecklar samtidigt. Här skulle det gynnas mycket av att en mer sofistikerad lösning som utnyttjar att utvecklingsmiljön ligger lokalt i klustret används. En sådan lösning är ett krav om antalet utvecklare blir många Code-server Code-servern är i ett tillräckligt fungerade skick och den har enligt oss inte någon hög prioritet att utvecklas vidare men även den har många saker som kan förbättras. Ett användargränssnitt för administratörer att installera nya bibliotek och konfigurera andra saker i det underliggande systemet hade varit användbart. Det hade varit bra att ha möjlighet till individuella installationer, program som en enskild utvecklare vill ha, utan att behöva installera det för alla utvecklare. Den hade även behövt ett snyggare användargränssnitt för att logga in i och ett sätt att slippa logga in två gånger för att komma åt Code-servern. Det är just nu också en del säkerhetsrisker som skulle behövas förbättras för att göra den helt användbar: hur vi hanterar användares Git inloggning och GCP autentisering. Vi hade också ett krav på 23

33 6.2. Metod att instansen som klustret körs på måste vara öppen för TCP-kommunikation. Detta implementerades utan större undersökning av vilka risker som det kan medföra Deployment Den implementerade deployment-logiken är för tillfället något enkel men uppfyller kraven ställda på projektet. I en organisation som agerar i en större skala kan det finnas ytterligare önskvärda konfigurationer och funktioner att implementera i framtiden. Det finns till exempel ingen lagring av vilka kodversioner som har klarat av vilka tester, något som kan behövas för att kunna verifiera att den kod som levereras har uppfyllt alla tester. Dessutom kan den informationen vara önskvärd på ett organisationellt plan för att ge en överblick av mjukvarans effektivitet. Den leveranslogik (Spinnaker) som först planerades att användas uppfyller dessa krav och mer, men blev för svårt att på ett generellt vis integreras in i systemet. Tills vidare blir rekommendationen att i en större skala använda Spinnaker och försöka integrera in det i vårt system om man vill ha en lösning som tar vara på att ett utvecklingskluster redan finns. Det skulle dock ta för mycket tid att specialisera sig på och konfigurera Spinnaker så att det kan integreras smidigare då detta har uppfattats som icke-trivialt Andra projekt/konkurrenter Det finns många som arbetar med att göra utvecklingspipelines smidigare och enklare. Vi kan inte säga att vi har förbättrat något från tidigare projekt men vi kan säga att vi gjort något lite annorlunda. Konkurrensen inom detta området är hård så vi valde att nischa oss lite och göra lösningen enklare än de flesta andra. Detta genom att ta bort lokal utveckling och därmed också kravet på externa ramverk för testing. Som det är nu är dock vår lösning låst till GCP och den passar inte för stora utvecklingsteam men båda dessa egenskaper kan ändras om utvecklingen fortsätter Lärdomar Vi började projektet med planen att sätta upp en mer traditionell pipeline men märkte efter ett tag att det var väldigt svårt att förenkla och gör smidigare. Alltså tog det ett tag innan vi kom in på den vägen vi är på nu. Utöver att studera ämnet i förstudien borde vi också undersökt konkurrenter och problem de har vid utvecklingen av liknande projekt. Detta hade kunnat göra att vi hade lagt mindre tid på sådant vi inte använde i slutändan. Vår iterativa arbetsprocess gjorde dock att vi efter ett tag kunde justera projektets riktning och inte fastna i den planering som först etablerades. Detta belyste fördelarna med ett iterativt arbetssätt för oss. Vi insåg också under projektets gång vikten av en bra aktivitets-/uppgiftsplanerning. Små isolerade deluppgifter gör det mycket enklare för många utvecklare att vara effektiva. En dålig planering och uppdelning gör att man ofta kan stå tomhänt utan något att göra. Vi har också sett vikten av att specialisera sig inom ett område. Det hade förmodligen hjälpt mycket om vi tidigt bestämt vem som skulle ha hand om vad i projektet så hade man sluppit upplärningstiden som kommer så fort man byter område. Eftersom det är ett studiearbete och alla vill lära sig så mycket som möjligt har vi dock ej gjort detta. 6.2 Metod I detta avsnitt diskuteras resultaten av de valda metoderna från kapitel 4. 24

34 6.2. Metod Informationsinsamling Erfarenhetsuppfångningen hjälpte till med att ge en uppfattning om gruppens kompetens. Det fanns moment som att till exempel sätta upp en server vilket endast en gruppmedlem hade gjort tidigare. I stort var de flesta områdena nya för gruppen och därför kunde inte arbetsuppgifter fördelas på ett effektivt sätt, istället arbetade alla med det de ville göra. Skapadet av kravlistan var lite problematiskt då projektet och området var abstrakt och nytt för projektgruppen. Dessutom var många av projektets krav i prioritet 2 för att ge projektgruppen en frihet att välja ut forskningsområde. Projektgruppen fick välja vilka krav de helst ville uppfylla vilket ledde till en del diskussioner då projektgruppen saknade kompetensen att förstå vilka krav som skulle vara bäst att följa. Senare under projektet, när projektgruppmedlemmarna fått mer erfarenhet, kunde ordentliga beslut tas angående vilka krav vi ville följa. Innan uppsättningen av krav borde projektgruppen utforskat fler olika projekt inom området och försökt fastställa en bild på hur vi ville att Bambi skulle se ut för att bäst uppfylla kundens krav. Under första iterationen följde Bambi en traditionell CI/CD-pipeline-struktur medan under andra iterationen användes en mer unik lösning istället för att endast använda redan skapade program. Det hade varit fördelaktigt att från första början ha gjort Bambi till en egenskapad variant av en CI/CD-pipeline men det är en lärdom vi tar med oss till framtiden Scrum Scrum har fungerat bra för projektgruppen. Den stora välgörande faktorn har varit att gruppen hållits uppdaterad om projektets olika delar där problem och bedrifter lyfts fram. En märkbart bristande faktor var att planeringen för varje sprint inte följdes ordentligt. Problemet kunde vara att aktiviteter tog längre tid än planerat utan att åtgärder infördes eller att förhinder av andra slag uppkommit. Deadlines hölls inte alltid ordentligt och uppgiften som skulle väljas av varje gruppmedlem vid Scrummötet lyckades inte alltid uppfyllas. Detta ledde successivt till att Scrummötets till nästa gång -punkt förlorade sin betydelse då inga framsteg hade gjorts sedan föregående möte. Detta var svårt att rätta till då det inte går att förutspå problem. Det som hjälpte en del var att omfördela resurserna sådan att arbetet inte stannade upp på en och samma aktivtet utan arbete kunde påbörjas inom andra områden. Det finns flera olika typer av utvecklingsmetoder som en mer traditionell vattenfallsmodel men för projektgruppen fungerade Scrum bra och var av störst intresse utifrån de kunskaper vi fått från tidigare kurser. De problem som togs upp utgör en liten nackdel jämfört med de fördelar som upplevdes. Dessutom var problemen ett resultat av att gruppen inte följde planeringen ordentligt och hade gett problem oavsett vilken utvecklingsmetod som följts. En bättre tidsuppskattning med en tidsbuffert på varje aktivitet hade nog också hjälpt en del. Generellt underskattades svårigheten hos och tidsåtgången för en del aktivteter Utvecklingsfas och utbildning Alla medlemmar har haft en specifik roll med ett visst ansvarsområde. Detta har fungerat bra och projektets medlemmar har sett till att deadlines, dokumentation och inlämningar följts där respektive ansvarig person påmint gruppen om dessa händelser. Alla har även hjälpt till att påminna varandra om större deadlines och andra viktiga evenemang som seminarier. Sprintarna utfördes med bra planering men problem som uppstod gjorde att aktivteter inte alltid var klara i tid. Antingen borde sprintsen innehållit färre funktioner alternativt skulle gruppen ha försökt tidsuppskatta arbetet bättre och fördela resurser på ett bättre sätt. Som nämnts tidigare är sådana problem inte specifika för de metoder som valts av projektgruppen. 25

35 6.3. Arbetet i ett vidare sammanhang Då alla medlemmar i projektgruppen utbildat sig själva har det varit svårt att lösa problem eftersom det inte funnits utomstående att få svar från bortsett från hemsidor på internet. Dessutom har det inte funnits tillräckligt med tid för att kunna utbilda alla medlemmar inom alla områden av projektet. Medlemmarna kan sina respektive delar och förstår resterande delar översiktligt men inte i varje detalj. Anledningen är att de olika områdena av Bambi oftast innehåller flera komplicerade program som samarbetar vilket är för tidskrävande att förklara i detalj. Viktigt att understryka är att alla medlemmar har tillräckligt med kunskap för att förstå hela Bambi men att medlemmarna inte kan varje kodrad Källkritik Mycket av vår information kommer från dokumentationen för de öppna källkodernas kodbas, alternativt deras hemsidor. En del av informationen kommer även från från vanliga webbsidor, forum och bloggar vilket i de sammanhangen är uppfattades som tillräckligt giltiga att använda då en del av programvaran och koncepten som används är så pass nya att det finns begränsat med information. För generell information om begrepp exempelvis vad en pipeline eller CI/CD är överensstämmer informationen från olika hemsidor. För programvara har främst dess egen dokumentation och webbsidor använts som källor. 6.3 Arbetet i ett vidare sammanhang Detta kapitel tar upp olika aspekter i ett vidare sammanhang i arbetet 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 internetuppkoppling och en webbläsare. Detta bidrar till att en utvecklare själv kan välja vilken dator eller enhet hen skulle vilja utveckla på 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 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 26

36 6.3. Arbetet i ett vidare sammanhang privatpersoner är systemet främst utvecklat för företag. Det åligger då företaget att testa systemet efter säkerhetsrisker då inte projektgruppen kan hållas till svars ifall ett dataintrång skulle ske. 27

37 7 Slutsats I de följande styckena presenteras de slutsatser som arbetet har gett genom att besvara rapportens 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 detta 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. Systemanatomin 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. 28

38 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 molnleverantö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/CDpipeline 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. 29

39 A 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äldigt 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 A.1.3 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? 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. 30

40 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årdvaran 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 internet 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 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 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 genomfö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 Platform as a Service (PaaS) PaaS är en modell där användaren jobbar med ett system där den kan installera egen mjukvara 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 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 31

41 A.4. Metod A 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 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 nyckelordet Decentralized", följt av olika funktionaliterer. Tillexempel Decentralized Database"eller Decentralized Computing". Jag använder mig också mycket av termen Smart contractpå liknande 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 studera 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 nuvarande 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ägagå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 A Decentraliserad beräkning och utveckling 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. Programmen ä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 Utveckling av applikationer Det finns redan en hel del olika plattformar ute som man kan utveckla decentraliserade applikationer 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 32

42 A.5. Resultat är dock något som förmodligen kommer att ändras i framtiden då det redan finns presenterade lösningar för detta.[25] Att skriva Smart-kontrakt kräver också lite annorlunda säkerhetsoch 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 Smartkontrakt 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 A Decentraliserad lagring Fillagring På den här fronten finns det redan några bra fungerande implementationer. Ethereum presenterar 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] Priserna sätter man själv men medelpriset per månad ligger 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 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 adresser. I ett nätverk som Sia måste man hämta hela filen i men Bluzelle kan man lägga alla adresser separat utspritt på nätverket. Om man nu endast vill ha en specifik adress så kan man hämta bara den sökta. Bluzelle implementerar alltså de vanliga databasfunktionerna 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 33

43 A.6. Diskussion Figur A.1: En bild av hur framtida molnet och internet kan vara uppbyggt.[73] A.6 Diskussion A.6.1 A Resultat 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 decentraliserade 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ätverken 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 applikationer 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 34

44 A.6. Diskussion ha serverar som hanterar överenskommelser och betalningar mellan förare och kunder skulle 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 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 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ätverket. Detta kan i de flesta fall kräva en adress/konto för att användaren ska kunna interagera direkt med applikationen. A 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 tillexemepel 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. 35

45 A.7. Sammanfattning 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 för att själv bestämma vilka källor som är rimliga att utgå ifrån. Detta är inte ett optimalt upplägg men det är så det ser ut inom detta fält just nu. Eftersom de flesta av dessa projekt verkar inom en oreglerad omgivning är det många projekt som lovar mycket utan någon aning om hurvida det är genomförbart för att dra in investerare. A.6.4 Vidare studier Detta ämne är nytt och stort att utforska. Det finns många olika projekt och förslag med nya och spännande approcaher för att lösa diverse problem. Det hade varit spännade att undersöka hur mycket en nuvarande molntjänst som Google skulle förlora/tjäna på att bidra till ett decentraliserat moln, till exempel med sin beräkningskraft till Ethereum och lagring till Sia och Bluzelle. Det hade också varit intressant att undersöka hastigheter och konstruktion av smart-kontrakt eller likande applikationer för tyngre decentraliserad beräkning. A.7 Sammanfattning Att decentralisera molnet är något som är möjligt men hur effektivt det kommer att bli är svårt att säga i ett så här tidigt skede. Det finns redan vissa fördelar med de decentraliserade nätverken som en möjlighet att eliminera mellanhänder men i stor utsträckning skulle man just nu gynnas av att använda traditionella molntjänster. Utvecklingen går dock fort framåt och det är enligt mig viktigt för att hålla internet fritt och inte centraliserat runt ett fåtal företag. 36

46 B B Ger en microservice-arkitektur snabbare kodleverans till slutanvändare av Eric Lilja B.1 Inledning Kontinuerlig leverans (efter engelskans continuous delivery) är en praktik som implementeras i allt högre grad av industriledare inom mjukvara [82]. Det är även en viktig funktionalitet i det system (Bambi) som under projektets gång utvecklades. Kontinuerlig leverans innebär att flera utvecklare av ett och samma system alla ska leverera kod till slutanvändare så ofta som möjligt. En microservice-arkitektur är en systemstruktur som blir allt mer populär för att på ett enkelt sätt utveckla webbapplikationer och system på ett modulärt sätt och samtidigt dynamiskt kunna skala upp beräkningskapaciteten av individuella delsystem för att hantera fler användare [24]. Ett populärt exempel på ett system utvecklat på detta vis är tjänsten Netflix. Redan år 2015 bestod deras tjänst av flera hundra mikrotjänster och dagligen levererades tusentals kodändringar till deras produktionsmiljö [48, s. 34]. B.1.1 Syfte Denna text har som syfte att undersöka om mjukvara utvecklad enligt en microservicearkitektur kan underlätta, och därmed ge snabbare och mer frekventa kodleveranser jämfört med om den mjukvaran var utvecklad enligt en monolitisk arkitektur. Motiveringen till att undersöka arkitekturens påverkan på kontinuerlig leverans grundas i att microservicearkitektur är en ny domän inom mjukvaruutveckling och därav saknar akademisk utbredning [31], [11]. B.1.2 Frågeställning Rapporten kommer i huvudsak att bearbeta och försöka svara på följande frågeställning: 1. Ger mjukvara som är designad enligt en microservice-arkitektur möjlighet till snabbare och mer frekventa leveranser till slutanvändare än om en monolitisk arkitektur används? 37

47 B.2. Bakgrund För en mer nyanserad frågeställning kommer även följande frågor beaktas av rapporten som behandlar hur olika externa faktorer kan tänkas påverka resultatet från Frågeställning 1: B Är resultatet från Frågeställning 1 densamma oavsett storleken på utvecklingsgruppen av mjukvaran? 3. Är resultatet från Frågeställning 1 densamma oavsett storleken på kodbasen som utvecklas? Avgränsningar Studien kommer endast jämföra en microservice-arkitektur med en monolitisk arkitektur. Andra typer av arkitekturer kommer inte att beaktas av detta arbete. Det kommer även antas att i implementationen av en microservice-arkitektur så kan varje mikrotjänst kompileras ned till ett individuellt system som kan levereras enskilt från resterande mikrotjänster. B.1.4 Ordlista Definition Produktionsmiljö Kodbas Kodleverans Mikrotjänst Slutanvändare CI/CD pipeline Betydelse Produktionsmiljön syftar på den hård- och mjukvara som slutanvändare av ett system interagerar med. Kodbas syftar på den kod som tillsammans utgör systemet. Det finns ofta en centralt lagrad och versionshanterad version av systemet som utvecklare utgår från när ny funktionalitet skall läggas till. Kodleverans syftar på processen mellan det att en ny funktion har utvecklats i en lokal miljö av en utvecklare tills dess att den funktionen finns tillgänglig i produktionsmiljön. Mikrotjänst (efter engelskans microservice) är en avgränsad bit mjukvara med ett tydligt ansvarsområde. All kommunikation till och från mikrotjänsten sker ofta över ett nätverksprotokoll. Slutanvändare syftar på de personer som använder eller påverkas av ett system. CI/CD Pipeline syftar på den automatiserade processen att utföra integrationstester och leverera ny kod till produktionsmiljön. B.2 Bakgrund Projektgruppen har haft som uppgift att utveckla en CI/CD-system. Mer specifikt var projektgruppens system utformad att hantera mjukvara designad enligt en microservicearkitektur. Problemet som systemet skulle adressera var hur man på ett effektivt och enkelt sätt kan automatisera enhets- och integrationstestning av mjukvara så att den kan levereras enligt olika strategier så frekvent som möjligt till slutkunder, detta med så få problem som möjligt. Med detta i åtanke så formades ett intresse av att se om mjukvara designad enligt en microservice-arkitektur ger en mer effektiv kontinuerlig leverans av kod än om ett motsvarande system designats enligt en monolitisk arkitektur. 38

48 B.3. Teori B.3 Teori Detta kapitel presenterar den teori som ligger till grund för studien. De områden som presenteras beskriver de specifika områden som studien behandlar. B.3.1 Kontinuerlig leverans Kontinuerlig leverans (CD, efter engelskans continuous delivery) innebär att på ett automatiserat sätt leverera mjukvara till slutanvändare så frekvent som möjligt. CD har sedan dess introduktion år 2006 fått allt mer fotfäste de senaste åren. De huvudsakliga fördelarna med CD beskrivs som [49]: B.3.2 Minskad risk vid leverans av ny kod till följd av en automatiserad, reproducerbar testprocess. Detta leder ofta till mer frekventa leveranser. Minskade kostnader och färre upprepade manuellt utförda uppgifter till följd av automatisationen. Snabbare återkoppling från användarna till följd av mer frekventa leveranser. Detta leder oftast till nöjdare kunder då deras synpunkter kan adresseras snabbare och mer frekvent. Microservice-arkitektur En microservice-arkitektur syftar på en systemstruktur där ett stort system bryts ner till små, självständiga komponenter, så kallade mikrotjänster. Varje mikrotjänst kan utvecklas, testas och levereras individuellt vilket gör att individuella delar kan skalas för att möta enskilda behov [67] och det reducerar komplexiteten för utvecklare som ska sätta sig in i systemet [96]. Systemstrukturen innebär att varje mikrotjänst har en liten påverkan på andra, den kommunikation som existerar mellan två mikrotjänster sker oftast via ett REST-gränssnitt [2]. Då varje enskild mikrotjänst existerar utan intern inverkan från andra komponenter kan implementationen av mikrotjänsten förrändras över tid utan att det påverkar resterande delar av systemet. B.3.3 Monolitisk arkitektur En monolitisk arkitektur är på många sätt motsatsen till en microservice-arkitektur. Ofta kan hela systemet kompileras ner till en enda fil som utgör hela systemet. Det gör ofta att systemet begränsas till enskilda programspråk och ramverk [67]. B.4 Metod Den huvudsakliga frågeställningen samt delfrågorna kommer att utredas genom en litteraturstudie och en beskrivning av de personliga erfarenheterna som har erhållits från att ha utvecklat och testat ett system för kontinuerlig leverans. Information till litteraturstudie hittades genom att söka på nyckelord såsom CI/CD, microservice, continuous delivery och software i olika kombinationer i Google Scholar. De studier som hittades via sökningarna hänvisade även till andra studier inom området som då även inkluderades i min studie. Då området som undersöktes är nytt och saknar en bred akademisk utbredning sattes inga avgränsningar gällande publiceringstid på de källor som har beaktats. Inkluderingen av mina personliga erfarenheter görs i hopp om att tillföra nyans till frågeställningen utöver det material som har bearbetats. 39

49 B.5. Resultat B.5 Resultat Detta kapitel beskriver det resultat som har framkommit av litteraturstudien samt de personliga erfarenheter från utvecklingen av en CI/CD Pipeline. B.5.1 Avgörande faktorer Här beskrivs de faktorer hos arkitekturen som har identifierats ha en avgörande betydelse för hastigheten för kodleveranser. Dessa faktorer kan ha både direkt och indirekt tidspåverkan. B Byggtid En faktor med direkt tidspåverkan är byggtid. Med byggtid menas tiden det tar att bygga den mjukvara som ska bytas ut i produktionsmiljön. Den största påverkan detta har är på tiden det tar för en utvecklare att få återkoppling om hur leveransen har gått. Ju snabbare en utvecklare kan få återkoppling om att det har uppstått problem under leveransprocessen desto mer insatt i de ändringar som har gjorts kommer utvecklaren att vara. Närheten i tid till felsökningsprocessen gör den mer effektiv. Ett dokumenterat exempel från företaget Paddy Power visar att när de bröt ner sitt monolitiska system till 11 mikrotjänster så minskade tiden det tog att leverera ny kod från 30 minuter till 3 minuter [11]. B Integrationstid Ytterligare en faktor som är betydande för snabba leveranstider är integrationstid. Med integrationstid menas hur snabbt lokala ändringar av kodbasen kan integreras i den centrala kodbasen. En stor skillnad mellan en monolitisk arkitektur och en microservice-arkitektur är just integrationen av förändringar. En monolitisk arkitektur innebär även en monolitisk kodbas där olika grupper måste integrera externa förändringar innan de kan leverera egna ändringar till den centrala kodbasen. Det kräver ett samspel mellan de olika utvecklingsgrupperna för att integrera ändringar och komplexiteten växer naturligt med antal personer som ska samarbeta i en kodbas. Utöver samspelet att koordinera utvecklares förändringar kan det även uppstå problem med att besluta att koden ska levereras. När en utvecklingsgrupp har integrerat in sina förändringar i den monolitiska kodbasen är det inte säkert att alla de andra utvecklingsgrupperna som ska samspela är redo att leverera. Detta försenar kodleveranser ytterligare [11]. B Leveranskomplexitet Mängden individuella system som ska levereras till produktionsmiljön ökar markant med en microservice-arkitektur. Det innebär att leveranserna sträcker sig över flera utvecklingsgrupper där varje grupps leverans ska integreras i produktionsmiljön med det resterande systemet vid varje leverans. Detta gör att automatiserad leverans beskrivs som en essentiell del av implementationen av en microservice-arkitektur [2]. Automatiserad leverans sätter krav på att varje enskild komponent av systemet ska levereras med specifikationer för dess ihopbyggnad och hur dess miljö ska se ut. Jämfört med en monolitisk arkitektur kan en microservice-arkitektur bestå av flera olika programspråk som kan köras på olika operativsystem. Vidare krävs det också att det finns integrationssystem på plats som autonomt kan integrera mikrotjänsterna till ett enhetligt, fungerande system. Den ökade automatiseringen gör att microservice-arkitekturen beskrivs som att vara den första arkitekturen lämpad för kontinuerlig leverans [31]. Trots den ökade mängden system som ska levereras till produktionsmiljön har det visats att om tillräckliga system är implementerade kan det göras storskaligt utan en ökning av felleveranser [50]. 40

50 B.6. Diskussion B.5.2 Personliga erfarenheter Något som blev tydligt under utvecklingen och utvärderingen av CI/CD-systemet som projektgruppen utvecklade var att tiden det tar att få återkoppling på den kod som har lämnats in för versionshantering är avgörande för framgången med kontinuerlig leverans. Om tiden till återkoppling överstiger några minuter påbörjas ofta en annan uppgift och de ändringar som har gjorts glöms snabbt bort. Effekten av att leverera egenskriven kod har också haft en positiv effekt då det finns en bekantskap med den kod som kan behöva felsökas. Under utvecklingen av ett CI/CD-system upplevdes det som att konfigurationen av att automatisera leveransen av en mikrotjänst var komplex och tidskrävande. För varje ny mikrotjänst behöver det adderas nya enhets- och integrationstester samt en leveransprocess som ska integreras in i den centraliserad leveransprocessen. Det kan även tänkas finnas olika nivåer för integrationstester för olika versioner av systemet som kan öka konfigurationskomplexiteten ytterligare. Då utökningar av ett system med mikrotjänster (och därmed dess kodbas) ofta resulterar i skapandet av nya mikrotjänster leder det ofta till att förgreningar i leveransprocessen måste skapas. Det är något som under projektets gång har upplevts som icke-trivialt och tidskrävande. Detta skiljer sig mot en monolitisk serverakrkitektur där hela systemet alltid måste testas och det därmed inte krävs några förgreningar när kodbasen utökas. Det CI/CD-system som utvecklades av projektgruppen delades upp till tre individuella delsystem som kunde levereras enskilt. Det gav därför även erfarenheter om att kontinuerligt leverera mikrotjänser. Det kunde uppstå problem i projektgruppen när systemet delades upp till mikrotjänster och utvecklingen delegerades ut till olika subgrupper. Det hände ibland att processen som krävdes för en ny gruppmedlemmen att leverera kod till det delsystemets produktionsmiljön var okänd. Det skapade en initial fördröjning av leveransen då det var varje utvecklares ansvar att leverera koden. När den processen klargjordes för utvecklaren upplevdes det dock som en snabbare process än om ansvaret att leverera all nyskriven kod skulle placeras på en extern part. Komplexiteten av leveransprocessen upplevdes öka i takt med att systemets kodbas ökade. Det gjorde att inlärningen av leveransprocessen blev snabbare när endast en av delmängd av den totala processen behövdes läras. Det upplevdes heller aldrig hämmande att inte känna till leveransprocessen för ett delsystem som man själv inte utvecklade. Projektgruppen saknade dock en fullt automatiserad kodleverans som i bästa fall helt hade integrerats in i versionshanteringsprocessen och därmed tagit bort kravet att lära sig en ny leveransprocess. B.6 Diskussion I detta kapitel diskuteras studiens metod och resultat. B.6.1 Resultat Nedan diskuteras resultatet som framkom av studien. Diskussionen är uppdelad i tre delar som motsvarar de tre frågeställningar som rapporten ska bearbeta. B Arkitekturens påverkan på kontinuerlig leverans Det framgår tydligt från litteraturen att det finns en stark koppling mellan en microservicearkitektur och kontinuerlig leverans. Självständigheten hos varje mikrotjänst upplevs som den stora styrkan i sammanhanget. Det gör att utvecklingsgrupper av enskilda mikrotjänster kan leverera kod till produktionsmiljön utan att behöva koordinera alla sina förändringar 41

51 B.6. Diskussion med de andra utvecklingsgrupperna. Det ger varje grupp möjligheten att självständigt bestämma när deras förändringar ska levereras till produktionsmiljön. Varje leverans blir dessutom mindre komplex då endast en delmängd av det totala systemet hanteras i leveransen. Ytterligare en faktor där en microservice-arkitektur har en fördel i sammanhanget är byggtiden. Möjligheten att endast byta ut ett delsystem och inte det fullständiga systemet ger avsevärda direkta tidsskillnader i leveransprocesssen. Det möjliggör snabbare iterationer av användaråterkoppling och felsökning vilket sannolikt leder till mer frekventa leveranser då potentiella problem kan adresseras snabbare. Ett potentiellt problem med microservice-arkitekturen är den ökade komplexiteten till följd av den större mängden system som ska levereras. Det ställer krav på att en ordentlig infrastruktur för att autonomt hantera leveranserna finns på plats. I fallet med en monolitisk arkitektur är det alltid samma system som ska levereras vilket kräver en mindre generell leveransprocess då den endast behöver täcka ett fall. Den ökade mängden delsystem skapar framförallt fördröjning vid skapandet av en ny mikrotjänst då dess specifika bygg- och leveransschema måste integreras in i den generella leveransprocessen. Detta eftersom de olika mikrotjänsterna kan ha olika hårdvarukrav eller använda olika kompilatorer till de olika programspråk som mikrotjänsterna är byggda av. B Hur påverkar utvecklingsgruppens storlek Nedbrytningen till självständiga mikrotjänster tycks ha en mer positiv effekt jämfört med en monolitisk arkitektur när systemets utvecklingsgrupp växer. Detta då det finns få beroenden mellan delar av systemet som kontinuerligt behöver integreras mellan de olika mikrotjänsterna vid varje leverans. Ju större en utvecklingsgrupp av ett monolitiskt system är desto fler ändringar kommer det finnas att integrera ihop vilket leder till större fördröjningar och mindre frekventa leveranser. Om utvecklingsgruppen är mindre kommer dessa fördelar minska. Integreringstiden vid leveranser kommer dock fortfarande vara mindre om två utvecklare gör interna ändringar i varsitt delsystem än om de gör samma ändringar i ett monolitiskt system eftersom de i det monolitiska systemet behöver integrera ihop ändringarna innan det kan lagras i deras kodbas. B Hur påverkar kodbasens storlek Det tycks även finnas fördelar med microservice-arkitekturen som förstärks när kodbasens storlek växer. En större kodbas leder till längre byggtider och det visar sig att byggtiden kan minska markant vid leverans när en microservice-arkitektur används. Skillnaden tror jag får större effekter i större system eftersom jag tror att minskningen från 30 minuter till 3 minuter får en större inverkan än minskningen från 30 sekunder till 3 sekunder. Detta eftersom leveranser fortfarande kommer ske relativt sällan under en dag så en 27 sekunders förbättring sparar en troligtvis bara några få minuter per dag. En större kodbas leder sannolikt även till en ökad mängd mikrotjänster men som jag beskrev under rubrik B har detta även visats kunna hanteras utan ökade mängder felleveranser och därmed utan någon ytterligare negativ påverkan. Dessa fördelar ges så fort det finns två eller fler mikrotjänster i systemet (annars blir det per definition monolitiskt) om man bortser från potentiellt overhead som krävs för att sätta upp separata system. B.6.2 Metod Den fakta som har beaktats i litteraturstudien är inom ett område som saknar utbrett akademiskt underlag, något som understryks av flera av de studier som arbetet baserats på. Det 42

52 B.7. Slutsats underlaget har dessutom varit av mer utforskande karaktär snarare än att ha försökt besvara en enskild frågeställning. Det resultat som mina personliga erfarenheter har gett är baserade på ett litet projekt och det förblir därmed ovisst hurvidare de är tillämpbara på en större skala. B.7 Slutsats Här presenteras de slutsatser som kan tydas av resultatet och diskussionen genom att svara på frågeställningen från avsnitt B.1.2 i respektive ordning. B.7.1 Ger en microservice-arkitektur möjlighet till snabbare och mer frekvent kodleverans? Sammanfattningsvis visar detta arbete att en microservice-arkitektur ger utvecklare möjlighet att snabbare leverera kod till slutanvändare än en monolitisk arkitektur. Detta då det har visats stora förbättringar vad gäller byggtid och integrationstid vid leveranser. Det har dessutom visats att en ökad mängd delsystem som ska levereras inte behöver betyda fler felleveranser. Den större mängd individuella system som ska levereras innebär dock en större initial ansträngning när ny funktionalitet ska adderas till systemet då en ny leveransprocess måste sättas upp. Jag vill dock argumentera för att den ansträngningen ger god avkastning över tid. B.7.2 Är resultatet densamma oavsett storlek på utvecklingsgruppen? Att fördelarna gällande integrationstiden förstärks när utvecklingsgruppen växer är tydligt. Fler utvecklare av ett system leder till fler förändringar som behöver integreras ihop. Att bryta ner systemet till självständiga delsystem minskar således antalet utvecklare och förändringar som behöver synkroniseras vid varje leverans. Dessa fördelar visas så fort olika delsystem utvecklas. Inga nackdelar med användningen av en microservice-arkitektur vid olika storlekar av utvecklingsgruppen har kunnat identifieras och således blir slutsatsen att resultatet stämmer oavsett storlek på utvecklingsgruppen. B.7.3 Är resultatet densamma oavsett storlek på kodbasen som utvecklas? Resultatet tycks även gälla oavsett kodbasens storlek. Vid en större kodbas blir fördelarna av kortare byggtider mer betydande då systemet även kommer ta längre tid att byggas ihop men även med en mindre kodbas kommer uppdelningen ge fördelar då endast en delmängd av det totala systemet behöver byggas vid leverans. 43

53 C C En jämförelse mellan muterbar och icke-muterbar serverinfrastruktur av Andreas Zeijlon C.1 Inledning Traditionellt sett har serverarkitekturer varit muterbara tack vare dess kortsiktiga flexibilitet. En utvecklare kan, i en muterbar infrastruktur, enkelt öppna en SSH-tunnel till en uppkopplad server och utföra uppdateringar och buggfixar utan att slutanvändarna drabbas av ett driftstopp. Alternativet till muterbar infrastruktur är motsatsen icke-muterbar serverarkitektur där inga ändringar kan göras när servern väl är uppkopplad. För att utföra uppdateringar eller buggfixar måste man skapa en helt ny server, dirigera om datatrafik till den och riva ned den gamla. [98] Den här rapporten är en del av ett större kandidatprojekt om kontinuerlig integrationstestning och koddistribuering för utveckling i molntjänster, där en icke-muterbar serverinfrastruktur har använts. Därav väcktes intresset för en djupdykning i ämnet muterbarhet inom serverinfrastrukturer. C.1.1 Syfte Syftet med denna undersökning är att studera muterbar och icke-muterbar serverinfrastruktur för att sedan jämföra deras användbarhet i olika användningsområden. Undersökningen ämnar att svara på följande frågeställningar. C.1.2 Frågeställningar 1. Vilka fördelar och nackdelar finns det med muterbar serverinfrastruktur? 2. Vilka fördelar och nackdelar finns det med icke-muterbar serverinfrastruktur? 3. I vilka situationer bör man använda icke-muterbar serverinfrastruktur hellre än muterbar? 44

54 C.2. Bakgrund C.1.3 Avgränsningar Den här undersökningen kommer inte att gå in på den samhälleliga eller etiska aspekten då ämnet är av teknisk natur. C.2 Bakgrund Projektgruppen hade som uppgift att undersöka hur långt man kunde automatisera en CI/CD-pipeline(kontinuerlig integration/kontinuerlig leverans) för mjukvara med mikrotjänstarkitektur i molntjänster som Google Cloud, Microsoft Azure och Amazon Web Services. Systemet består av tre moduler, var och en med icke-muterbar serverinfrastruktur. Systemet körs i Dockercontainrar i ett kubernetes kluster. Servrarna är byggda från en kodmall som kallas Docker Image [79]. Ur detta väcktes ett intresse att undersöka fördelar och nackdelar med en sådan infrastruktur jämfört med en mer traditionell muterbar serverinfrastruktur. C.3 Teori I det här kapitlet beskrivs teorin bakom de områden och begrepp som behandlas i rapporten. C.3.1 Definitionen av muterbar serverinfrastruktur Ordet muterbar, från engelskans mutable [58], betyder att någonting har förmågan att mutera, det vill säga att den kan undergå förändring. En muterbar serverinfrastruktur betyder därför helt enkelt att servern är benägen att förändras under sin livstid. Den kan uppdateras med nya funktioner, få buggfixar och säkerhetsuppdateringar. C.3.2 Definitionen av icke-muterbar serverinfrastruktur Icke-muterbar, från engelskans immutable [57], är motsaten till muterbar, alltså att någonting inte har förmågan att ändras. En icke-muterbar serverinfrastruktur betyder därför att servern inte kan förändras på något sätt efter att den blivit uppkopplad. Servern måste ersättas av en ny om uppdateringar ska ske. C.4 Metod Nedan beskrivs metoden som användes för att besvara frågeställningen i avsnitt C.1.2. Tillvägagångssättet för att få svar på undersökningens frågeställningar utgick från en litteraturstudie av publicerade artiklar, internetkällor och bloggar för att samla in relevant information om fördelarna och nackdelarna med muterbara/icke-muterbara serverinfrastrukturer. Webbsökning och då framförallt Google har använts för att hitta pålitliga källor. Speciellt har Google Scholar använts. Google scholar är en sökmotor för att enkelt söka efter vetenskapliga publiceringar och artiklar. Källorna har undersökts noggrant och med stor omsorg kontrollerats. Framför allt genom att bakgrundskontrollera författaren till varje artikel och undersöka om det kan finnas en underliggande agenda bakom källan. Har författaren erfarenhet av att ha jobbat med ämnet? Finns det någon annan källa som kan styrka det författaren säger? Kan författaren ha ett eget personligt intresse av att vinkla informationen? Därefter togs ett beslut om källan var tillräckligt vetenskaplig för att kunna användas i denna rapport. Den informationen som har samlats in under litteraturstudien ligger till grund för resultatet och diskussionen av denna rapport. 45

55 C.5. Resultat C.5 Resultat I det här kapitlet presenteras det resultat som åstadkommits efter att ha följt metoden. Frågan om muterbar vs icke-muterbar infrastruktur är fundamental för serverhantering och underhåll. Det finns för- och nackdelar med båda infrastrukturerna. Innan virtualisering och molntjänster var tillgängligt för allmänheten, var serverinfrastrukturen anpassad för fysiska servrar. Fysiska servrar är väldigt dyra och omständiga att bygga och underhålla och därför ville man inte gärna byta ut dem så ofta, utan istället uppdatera redan existerande servrar. Därav har muterbar serverinfrastruktur sitt ursprung ifrån fysiska servrar. En sådan infrastruktur är nämligen väldigt flexibel och möjliggör att servrar kan förändras på plats regelbundet. Den erbjuder bra kortsiktig flexibilitet och har därför länge varit den populära vägen att gå när man sätter upp sin server. [98] Utmaningen som kommer med muterbar serverinfrastruktur kan vara att när ett problem upptäcks så kanske inte buggfixar rullas ut till alla system som kan påverkas av det problemet, vilket leder till olika konfigurationer och versioner bland servrar. Då kan det bli så att mjukvara och skript, som funkar på vissa maskiner, inte kommer funka på andra, vilket leder till inkonsekventa beteenden hos servrarna, ett fenomen som kallas configuration drift [65]. Till exempel om en server får mer trafik än alla andra, och någon justerar den så att den nu har en annan konfiguration än alla andra servrar. Det behöver inte nödvändigtvis vara en dålig sak att den servern har en unik konfiguration, om sådana ändringar versionshanteras noggrant så att det är enkelt att återskapa eller återbygga den. Annars kan det leda till en så kallad snowflake server. En snowflake server är en server som är helt unik och annorlunda från resten av servrarna i systemet. Den har under en lång tid finjusterats och uppdaterats för att fungera på ett specifikt sätt utan noggrann versionshantering eller dokumentation, vilket har lett till att man inte längre kan återskapa servern. Det leder till en rädsla att röra servern för man vet inte vad som kan hända. [65] I takt med att virtualisering och molntjänster blev allt mer tillgängligt behövde man inte längre ta hänsyn till att hårdvaran var dyr att bygga om eller ersätta, vilket ledde till början på en ny sorts infrastruktur - icke-muterbar. Istället för att ändra på existerande servrar kunde man enkelt radera virtuell hårdvara och starta upp ny utan extra kostnader. Icke-muterbar serverinfrastuktur är alltså infrastruktur som, när den väl distribuerats, inte kan modifieras. Den här sortens infrastruktur är ofta associerad med kontinuerlig kodleverans i molntjänster där just virtuell hårdvara utnyttjas. När ändringar eller uppdateringar behöver göras, utför man inte konfigurationsuppdateringar på en existerande server. Istället bakas konfigurationen in i en mall, till exempel en Docker Image. Sedan byggs nya instanser av existerande servrar från den nya mallen för att ersätta gamla servrar. Det gör att man snabbt och enkelt kan bygga och riva ned miljöer i molnet utifrån en konfigurationsmall, och varje server har då exakt likadan konfiguration. Nya miljöer kan skapas i molnet inom några minuter. Detta gör icke-muterbar infrastruktur till en mycket mer genomförbar möjlighet för 96 procent[13] av företag som använder sig av molntjänster. [65] Sammanfattningsvis finns dessa fördelar och nackdelar med muterbar och icke-muterbar serverinfrastruktur: Fördelar med muterbar infrastruktur Uppdateringar är oftast snabbare och kan anpassas till varje individuell server. 46

56 C.6. Diskussion Istället för att behöva skapa en ny server från scratch, kan man uppdatera den existerande servern. IT-personal lär känna servern på en personlig nivå vilket kan hjälpa att fixa problem snabbare. Den enda hållbara lösningen om man arbetar med fysiska servrar. Nackdelar med muterbar infrastruktur Tekniska problem är svårare att felsöka eller återskapa eftersom varje server har en unik konfiguration. Fenomenet kallas configuration drift. Det finns en risk för så kallade snowflake servers". Det är lätt hänt att ändringar i en server inte dokumenteras, vilket gör versionsspårning mycket svårare. Att leverera servrar är vanligen en lång process på grund av behovet av en manuell konfiguration. Större risk för oförutsägbart beteende hos servern. Fördelar med icke-muterbar infrastruktur Versionsspårning och att gå tillbaka till tidigare versioner är mycket enklare. ITavdelningen kan hålla koll på varje ny server eller virtuell maskin som används. Testning är enklare att utföra tack vare konsekventa konfigurationer mellan olika servrar. "Configuration drift"är inte möjligt. Om en server är uppe och kör, så vet ITpersonalen det exakta tillståndet hos den servern och kan därför undvika oväntade överraskningar. Snowflake servers"är inte möjligt. Nackdelar med icke-muterbar infrastruktur Infrastrukturen är helt och hållet omöjlig att modifiera när den väl är på plats. Det gör att om en sårbarhet upptäcks så måste alla servrar med samma konfiguration få en säkerhetsuppdatering. Den förbättrade smidigheten och dynamiken kan ibland fungera dåligt med traditionell IT-säkerhetspraxis. C.6 Diskussion Diskussionen kommer delas upp i följande. C.6.1 Resultat Resultatet av den litteraturstudie som utfördes visar på att muterbar serverinfrastruktur, som traditionellt varit standard, passar bra i situationer där man behöver kortsiktig flexibilitet eller då man arbetar med fysiska servrar. Fördelarna med en sådan infrastruktur gör att den passar bra för den som behöver snabba uppdateringar och inte har så stort behov av versionsspårning eller tydlig dokumentation. Finns inte möjligheten att ha sin server hos en molntjänst där man kan utnyttja virtuella maskiner, är muterbar infrastruktur den enda hållbara lösningen. 47

57 C.7. Slutsats Icke-muterbar serverinfrastruktur lämpar sig bäst i kombination med en molntjänst där man kan utnyttja virtuella maskiner. Fördelarna med en sådan struktur gör det möjligt att nästan helt eliminera oförutsägbart beteende hos servern eftersom att en icke-muterbar server alltid gör samma sak. C.6.2 Metod Metoden som användes för att svara på frågeställningen var en litteraturstudie av publicerade artiklar, internetkällor och bloggar. Det tillvägagångssättet valdes för att få information från ett så brett perspektiv som möjligt på teknikvärldens inställning till muterbar och icke-muterbar serverinfrastruktur. Undersökningen krävde mycket efterforskning i artiklar eftersom ämnet var ganska tekniskt komplext och nytt. Den äldsta källan som har använts är från Den här metoden var ett bra sätt att få en övergriplig bild över ämnet från ett brett urval av informationskällor men det är svårt att kunna dra några egna slutsatser som inte redan dragits av andra mycket mer kunniga inom området. Något sorts eget experiment som komplement till litteraturstudien hade varit att föredra. C.7 Slutsats Här presenteras de slutsatser som kan tydas av resultatet och diskussionen genom att svara på frågeställningen från avsnitt C.1.2. C.7.1 Vilka fördelar och nackdelar finns det med muterbar serverinfrastruktur? Fördelarna med muterbar serverinfrastruktur är att istället för att behöva skapa en ny server kan man uppdatera den existerande. Det gör att man kan göra snabba förändringar genom att SSH:a in i servern. Det gör att man kan få ut uppdateringar snabbare och smidigare. Nackdelarna med muterbar serverinfrastruktur är att det finns en risk för "configuration drift"vilket gör felsökning svårare och det kan ta lång tid att hitta buggar. Det är också stor risk att ändringar, speciellt små, inte dokumenteras vilket gör versionsspårning svårare. Finns också stor risk för oförutsägbart beteende. C.7.2 Vilka fördelar och nackdelar finns det med icke-muterbar serverinfrastruktur? Icke-muterbar serverinfrastruktur gör versionspårning mycket enklare. Det är lätt att dokumentera. Testning är enklare att utföra tack vare konsekventa konfigurationer mellan servrar och "configuration drift"är inte längre möjligt. Man vet alltid det exakta tillståndet av en server som är uppkopplad. Nackdelarna med icke-muterbar infrastruktur är självklart att servern är helt och hållet omöjlig att modifiera när den väl är på plats. C.7.3 I vilka situationer bör man använda icke-muterbar serverinfrastruktur framför muterbar? Icke-muterbar serverinfrastruktur bör användas när man har tillgång till virtuella maskiner som till exempel i en molntjänst där man enkelt kan spinna upp och ned kapaciteten. Den lämpar sig särskilt vid användning av kontinuerlig kodleverans tack vare förutsägbarheten. Servern beter sig alltid likadant varje gång vilket är kärnan i kontinuerlig kodleverans där man vill distribuera paket och dess beroenden på samma sätt varje gång. I en miljö där virtuella maskiner inte går att utnyttja är det bäst att använda sig av en muterbar serverinfrastruktur. 48

58 D D Datasäkerhet inom molntjänster - en litteraturstudie av Nigel Cole D.1 Inledning Den ökända The Fappening-incidenten var ett uppvaknande för många människor som trodde att deras data var säkra. Väldigt många kändisar hade nakenbilder i Apples icloud som läcktes på 4chan och spreds över hela internet. Användare förväntar sig att data som sparas på molntjänster är i säkert förvar men tyvärr finns det sårbarheter i molntjänster som kan leda till sådana här incidenter[34]. Data i moln är för det mesta säker men det beror också på vad molnleverantören har för säkerhet och vad kontraktet innebär för användaren. Generellt kan datasäkerhetshänsyn associerad till molntjänster delas in i två kategorier: säkerhetsproblem hos molnleverantör och säkerhetsproblem hos användare. Oavsett är det ett delat ansvar bland båda partier[7]. Molnleverantören behöver se till att infrastrukturen är säker och att deras klientdata och applikationer är skyddade medan kunden måste se till att deras applikation är säker och har ordentliga autentiseringsåtgärder som starka lösenord. D.1.1 Syfte Syftet med denna litteraturstudie är att ta reda på hur användare av molntjänster kan förstärka sin datasäkerhet och vad som kan vara bra att veta vid val av distributionsmodell(se D.3.1). D.1.2 Frågeställning Huvudsakligen ska arbetet försöka att besvara följande frågeställning: 1. Vilka åtgärder ska en användare vidta för att minimera risken för dataintrång vid användning av molntjänster? 2. Ur ett datasäkerhetsperspektiv, vad är viktigt att veta vid val av distributionsmodell? 3. Finns det säkrare alternativ till molntjänster? 49

59 D.2. Bakgrund D.1.3 Begränsningar Undersökningen av åtgärder som användare kan vidta för att förstärka säkerheten hos sin data kommer att vara översiktlig och inte alltför ingående. Vid undersökning av distributionsmodeller ska endast en översiktlig undersökning göras då det är ett väldigt stort område. Sist ska alternativen till molntjänster vara översiktliga då fokus ligger på datasäkerhet och inte på alternativens teknik. D.2 Bakgrund Allting i samhället är på något sätt i kontakt med molntjänster och frågan om hur säker data är i moln, speciellt på grund av The Fappening, var av stort intresse då projektgruppen började arbeta med molntjänster. Mina erfarenheter av molntjänster sträcker sig inte mer än till Google Drive, Dropbox och Apple icloud. Personligen använder jag Google Drive för att lagra arbeten, andra människors Dropbox används för studier och icloud lagrar alla bilder som tas med mobiltelefonen. Tankar om hur säker min data egentligen är i molnet var intressant och är anledningen till att detta arbete utförts. D.3 Teori I detta kapitel förklaras väsentliga begrepp och metoder. Vissa av de teoretiska delarna är i vanliga fall väldigt stora områden med olika användningsområden och är därför förklarade ur ett datasäkerhetsperspektiv då det är endast det som är av intresse. D.3.1 Distributionsmodeller för moln Generellt kategoriseras molntjänster in i tre olika typer; infrastruktur som tjänst, plattform som tjänst och mjukvara som tjänst. Dessa distributionsmodeller förklaras nedan och är av intresse då det inte finns en generell säkerhetslösning som fungerar för alla modeller. D Infrastruktur som tjänst (IaaS) Den mest nedskalade varianten av distributionsmodellerna är infrastruktur som tjänst(iaas). Kunder hos en sådan tjänst får tillgång till virtuella maskiner, servrar och lagring av data. Den är väldigt anpassningsbar och skalar lätt. Den levereras från olika fysiska servrar medan gränssnittet representerar detta som om hårdvaran befann sig i samma miljö där olika virtuella komponenter kan hanteras. Oftast används den av företag som vill utöka sin egen miljö, separera e-handel från andra med lastbalansering vid hög belastning och lägga delar av sin verksamhet i molnet för backup eller avlastning av sin miljö[90]. D Plattform som tjänst (PaaS) Distributionsmodellen som tar IaaS ett steg längre är plattform som tjänst(paas). Till skillnad från IaaS fås bland annat operativsystem, utvecklingsverktyg och databashantering utöver det IaaS ger. Det minskar kodningstid då programkomponenter är inbyggda i plattformen, till exempel säkerhetsfunktioner och katalogtjänster. En annan fördel är att kostnad och hantering av programvarulicenser, programinfrastruktur och utvecklingsverktyg oftast ingår i Paas. PaaS används ofta för webbappar[5]. D Mjukvara som tjänst (SaaS) Mjukvara som tjänst(saas) är en mjukvarudistributionsmodell som bygger på IaaS och PaaS som låter användare få tillgång till molnapplikationer genom alla typer av internetanslutningar. Facebook är ett exempel på SaaS. Med SaaS, olikt IaaS och PaaS, kan en tjänst sättas 50

60 D.4. Metod upp direkt utan att behöva oroa sig över allting underliggande som de andra modellerna behöver hantera. En SaaS är licensbaserad jämfört med traditionella metoden där produkten betalas för en gång och installeras[81]. D.3.2 Zero-Knowledge Zero-Knowledge innebär att endast användaren har nyckeln till dens konto och data. Molntjänsten har inte en kopia av nycklarna som icke Zero-Knowledge-tjänster brukar ha. Istället för att faktiskt visa nyckeln bevisar användaren till molntjänsten att den innehar nyckeln. Kort sagt innehar användaren ett privat lösenord som är matematiskt länkad till molntjänstens publika lösenord. Molntjänsten kan då verifiera att de hör ihop men molntjänsten kan inte spåra tillbaka och generera nyckeln[91]. En väldigt viktig sak att ha i åtanke är att olika Zero-Knowledge-tjänster erbjuder ett sätt att återfå sitt lösenord. Medan detta kan vara en bra fallskärm att ha ifall man tappar bort lösenordet betyder det att det finns en möjlighet att få tag i nyckeln. Alltså är frågan om användaren litar på företaget eller inte. En användare kan annars använda sig av en Zero-Knowledge-tjänst som inte har denna funktion och då kan ingen annan få tag på nyckeln. Risken är då att förlust av nyckel betyder att datan är då också helt borta. D.4 Metod Då detta är en litteraturstudie bestod materialet av information från diverse webbsidor och vetenskapliga artiklar. För att svara på frågeställningen söktes information med nyckelorden: cloud, computing, security, problems, issues, vulnerabilities och alternatives. Först delades områden upp utefter de olika frågeställningarna. Syftet för första frågan var att hitta olika praxis som kan vara användbara för att minimera risken för dataintrång vilket presenterades överblickligt. För andra frågan söktes information för säkerhetsrisker i varje distributionsmodell, översiktligt, följt av en generell säkerhetsmodell till de olika distributionsmodellerna. För sista frågan söktes alternativ till molntjänster. D.5 Resultat I detta kapitel representeras resultat av litteraturstudien. D.5.1 Åtgärder för att förstärka sin datasäkerhet I detta avsnitt visas de fynd av metoder och tekniker som hittats vid sökning av åtgärder för att förstärka sin datasäkerhet. D Kryptera datan som lagras i molntjänster Istället för att lagra data direkt kan datan först krypteras. Detta tvingar hackare som fått tag på data att behöva komma åt krypteringsnyckeln eller gissa sig fram vilket kan vara svårt och extremt tidskrävande. Alltså kan program som komprimerar och krypterar filer med ett lösenord användas vilket är en säker metod för att skydda data[53]. D Välj en molnleverantör beroende på dess säkerhetspolitik Det finns väldigt många molnleverantörer och vilken molnleverantör en användare väljer brukar ha pris som faktor. Utifrån ett säkerhetsperspektiv är det oftast de stora molnleverantörerna som Amazon och Google som är säkra alternativ då de har resurserna för att ha sin säkerhet på topp nivå men oavsett val av molnlevernatör är säkerhetspolitiken av yttersta vikt. Efter val av molnleverantör bör säkerhetsverktyg användas för att ta reda på vilka säkerhetsåtgärder som behöver hanteras på användarens sida[72]. 51

61 D.5. Resultat D Zero-Knowledge-tjänster Som nämnts ovan kan man kryptera data innan man använder molntjänster. De åtgärder som tagits upp har varit fokuserade på datasäkerhet för att skydda sig från hackare men det kan även finnas anledning att skydda sin data mot molnleverantören. Oftast kommer företag att ha kopior av kundens nycklar för att verifiera användares inloggningsuppgifter. Problemet som uppstår är att molnleverantören alltid kommer att ha möjlighet att komma åt användares data. Om ett företag har möjlighet att byta ut användares lösenord har de möjlighet att komma åt all data. Zero-Knowledge motverkar detta genom sättet krypteringen utförs(se D.3.2). Viktigt att notera är att de Zero-Knowledge-tjänster som hittats under detta arbete är specifika för datalagring vilket tillhör distributionsmodellen SaaS. Dessutom har inte dessa tjänster funktionalitet som de andra större företagen erbjuder, till exempel skulle inte Bambi kunna användas på de tillgängliga Zero-Knowledge-tjänsterna då det krävs betydligt mer funktionalitet än vad tjänsterna erbjuder. D.5.2 Säkerhetsrisker och lösningar inom distributionsmodellerna Det finns säkerhetsåtgärder som kan tillämpas på alla distributionsmodeller men eftersom modellerna är olika finns det flera typer av säkerhetsrisker som kan vara specifika för respektive distributionsmodell. Det finns oerhört många säkerhetsåtgärder som behöver utföras och därför har endast de större generella riskerna varit av intresse. I detta avsnitt lyfts dessa säkerhetsrisker fram tillsammans med en generell säkerhetsmodell som täcker en större del av de generella säkerhetsriskerna. D Säkerhetsrisker inom IaaS IaaS är benägen till olika grader av säkerhetsrisker beroende på typen av distributionsmodell som används för att leverera denna tjänst. Ett privat moln(molntjänst där användaren hanterar och äger allting själv, specifikt hårdvaran) har oftast betydligt mindre risker än ett offentligt moln(motsatsen till ett privat moln där molntjänstleverantörer hanterar distributionsmodellerna och äger hårdvaran) då det inte är lika tillgängligt som de offentliga. Då IaaS är huvudsakligen uthyrning av hårdvara är den fysiska säkerheten av yttersta vikt. Den behöver skyddas lika väl från oavsiktliga fysiska olyckor som avsiktlig sabotage. Förutom hårdvaran i sig är det viktigt att det är säkert med överföringen av data då den kan avlyssnas. I en vanlig molnmiljö överförs data genom flera utomstående enheter[66]. D Säkerhetsrisker inom PaaS Säkerhetsrisker för PaaS, utöver de från IaaS som även behöver åtgärdas, är värdintrång och nätverksintrång där data behöver vara säker och otillgänglig mellan olika applikationer som kan befinna sig på plattformen. Säkerheten för applikationer som utvecklare skapar kommer behöva hanteras av utvecklarna men säkerheten på plattformen ska se till att data förblir otillgänglig mellan applikationer. Detta innefattar självklart inte de fall då en utvecklare vill att data ska delas mellan applikationer. I de fallen delas data via applikationer och inte via plattformen i sig för att förhindra otillåten dataåtkomst mellan applikationer[66]. D Säkerhetsrisker inom SaaS SaaS bygger på IaaS och PaaS vilket betyder att även deras säkerhetsåtgärder behöver hanteras. Med SaaS är det viktigt att användare inte kan se varandras data. Det finns mycket, precis som med de andra modellerna, som behöver säkerställas som dataintegritet och tillgången till ens data.[66] Det viktigaste att veta om SaaS ur perspektivet av datasäkerhet är att molntjänstssystem är väldigt koncentrerade på grund av virtualiseringsteknologi som tillåter 52

62 D.5. Resultat en server att hantera datan av flera klienter. Om någon hackar en server riskeras alltså flera virtuella maskiner eller data på den servern[60]. D Säkerhetsmodell för distributionsmodellerna I Robust Security Model for CloudComputing Applications [89] har en generell robust säkerhetsmodell för molnapplikationer tagits fram. Viktigt att notera är att denna modell är gjord för att att alla delar ska användas tillsammans men det är vad varje säkerhetslager täcker för säkerhetsrisker som är av intresse för de olika distrbutionsmoddellerna. Säkerhetslager för IaaS: Nätverkssäkerhet som datasäkerhet, dataintegritet och tillgänglighet. Stark autentisering. URL-förändringar av molntjänsten behöver notifiera alla klienter för att undvika länkbytesattack. Skanna för sårbarheter och granska konfigurationen för IaaS med jämna tidsintervall. Bra protokoll för att backa upp data. Säkerhetslager för PaaS: Tvåstegsverifiering. Förbjud delning av kontouppgifter mellan användare och applikationer. Var vaksam över obehörig aktivitet. Specificera mänskliga resurser som en del av överenskommelsen mellan molnleverantör och användare. API mellan PaaS och SaaS måste göras på ett lämpligt sätt. Transparens måste ges för övergripande informationssäkerheten och hanteringspraxis. Även för överensstämmelserapportering. Säkerhetslager för SaaS: Dataintegritet ska underhållas med ordentlig kryptering. Det ska inte gå att imitera en användare. Datasegration måste hanteras försiktigt. API-beroenden behöver specificeras ordentligt. Notifikationssystem vid säkerhetsintrång. D Fördelning av ansvar för de olika distributionsmodellerna Ansvaret mellan användare och molnleverantör varierar beroende på distributionsmodell. IaaS ger användare som mest kontroll över systemet bland distributionsmodellerna medan SaaS ger användare som minst kontroll över systemet. Användare och molnleverantörer är ansvariga för datasäkerheten för det de har kontroll över. Det betyder att molnleverantören ansvarar som mest över datasäkerheten med SaaS och minst med IaaS. Samtidigt minskas användarens ansvar för datasäkerheten när molnleverantörens kontroll ökar[74]. 53

63 D.6. Diskussion D.5.3 Säkrare alternativ till molntjänster Detta avsnitt representerar de metoder och tekniker som hittats under arbetet. D Undvik molntjänster vid hantering av känslig data En generell och logisk åtgärd för att undvika ett problem är att inte ge upphov till det problemet. Molntjänster är till viss del säkra och ofta kan användare använda sig av dem utan större bekymmer men om datan är känslig är det bäst att helt undvika molntjänster och lagra den känsliga datan på privat hårdvara. D Privat server Beroende på önskad användning kan en egen server vara bättre utifrån ett säkerhetsperspektiv. Användare har fysisk kontroll över hårdvaran då och eliminerar flera risker som nämnts i D.5.2.1[10]. D.6 Diskussion I detta kapitel diskuteras D.5 och D.4. D.6.1 Åtgärder för att förstärka datasäkerheten Att kryptera data gör det betydligt mycket svårare för hackare, eller molnleverantörer, att komma åt datan som lagras i molntjänster. Har användaren data som är känsligt men ändå vill använda sig av molntjänster är det bäst att kryptera datan vilket ökar datasäkerheten. Molntjänsten bör då ha bra säkerhetspolitik sådan att flera av de mest kritiska säkerhetsriskerna täcks. Som nämnts i D bör resterande säkerhetsrisker åtgärdas på användarens sida. Att använda Zero-Knowledge-tjänster är ett bra alternativ då mycket av datasäkerheten redan är åtgärdad med bra kryptering. Dessutom kan det vara viktigt att skydda data även från molnleverantören. Data krypteras redan med Zero-Knowedge-tjänster, likt D.5.1.1, med den stora skillnaden att molnleverantören inte heller har tillgång till kontonyckeln till skillnad från icke Zero-Knowledge-tjänster som har en kopia av nyckeln. Alltså, Zero- Knowledge-tjänster har varken information om nyckeln eller vad som finns i kontot vilket icke Zero-Knowledge-tjänster har(se D.5.1.3). Viktigt att påpeka, om det inte redan är uppenbart, är att de resultat som representeras i D.5.1 gäller SaaS, förutom D som behandlar alla distributionsmodeller. De är specifika för datalagring och inte för att utföra funktionalitet på lägre nivå som finns på IaaS och PaaS. Till exempel skulle inte det vara möjligt att skapa och underhålla Bambi på en Zero- Knowledge-tjänst då det inte finns funktionalitet som Google och Amazon erbjuder. D.6.2 Säkerhetsrisker och lösningar inom distributionsmodellerna Först och främst kommer det finnas störst möjlighet till ett säkert system genom att ha egen hårdvara. Då ansvarar användare för allting inom datasäkerheten och därför måste användare vara säkra på att deras kompetens räcker, eller anlita konsulter, för att skapa ett tillräckligt säkert system. Bland de olika distributionsmodellerna finns det olika säkerhetsrisker som behöver åtgärdas. Med IaaS får användaren som mest kontroll över systemet och därmed behöver användaren hantera säkerhetsåtgärder för PaaS och SaaS. Med PaaS hanteras mindre säkerhet då en större del av kontrollen förts över till molnleverantören och sist har SaaS minst ansvar av distributionsmodellerna. 54

64 D.7. Slutsatser Finns kompetensen att utveckla ett säkert system är det bästa att alltid ha så mycket kontroll som möjligt över systemet. Det blir det optimala fallet men det kräver också mycket jobb. Vid val av distributionsmodell behöver användaren välja en som fungerar för arbetet som ska utföras. Sedan är valet beroende på hur mycket arbete användaren vill lägga ner för datasäkerheten. För vissa arbeten kan det krävas att användaren använder sig av IaaS och PaaS för att kunna få mer kontroll på systemet medan i andra fall kan det räcka med SaaS. Finns flera valmöjligheter kan man följa D som visar vad man kan göra för varje distributionsmodell. Utifrån den kan man få en ungefärlig bild av allting som behöver göras för varje typ och avväga vad som passar en bäst. D.6.3 Säkrare alternativ till molntjänster Det är självklart att egna lagringsmedia, till exempel ett USB-minne, undviker flera av säkerhetsriskerna som molnet har då allting endast är tillgängligt via direkt fysisk kontakt. Det kommer alltid förbli det säkraste metoden för att undvika att människor kommer åt datan. Problemet är att om användaren förlorar hårddisken förloras även datan. En privat server ger den högsta potentiella datasäkerhet då användaren har kontroll över all hårdvara. Problemet som uppstår är att allt ansvar för datasäkerheten ligger hos användaren och inte en stor molnleverantör. Om användaren är erfaren, eller har råd att anlita konsulter, inom datasäkerhet kan detta anses vara det säkraste alternativet. D.6.4 Metod Den största svårigheten vid sökning av information var att avgöra om informationen var giltig eller inte. Det finns referenser som är från några år tillbaka och frågan man kan ställa är om problemet fortfarande är ett bekymmer idag. I fallet med säkerhetsproblemen i de olika säkerhetsmodellerna bör all information vara aktuell då de säkerhetsriskerna alltid existerar, om något kan det hittas fler att lägga till. Sedan är informationen i D.5.1 fortfarande relevant och Zero-Knowledge-tjänster är relativt nytt och hett i dagens samhälle med alla skandaler med att användarinformation säljs till andra företag. Sist så är informationen i D.5.3 logisk. D.7 Slutsatser I detta kapitel dras slutsatser utifrån resultaten och diskussionen. D.7.1 Vilka åtgärder ska en användare vidta för att minimera risken av dataintrång vid användning av molntjänster? Det finns många åtgärder som kan vidtas för att minimera risken för dataintrång. Dessutom utvecklas det flera nya koncept som är specifika för att skydda användares data. Utifrån resultaten och diskussionen kan vi se att kryptering av data är en bra och beprövad metod som används för både datan som lagras och kontouppgifter för att komma åt datan. Dessutom är det bäst att ha Zero-Knowledge-tjänster om man endast ska använda datalagring. Att läsa på om molnleverantörernas säkerhetspolitik och tillsätta egna säkerhetsåtgärder för det som saknas är också viktigt. D.7.2 Ur ett datasäkerhetsperspektiv, vad är viktigt att veta vid val av distributionsmodell? Det viktigaste är att först välja en distributionsmodell som fungerar för arbetet som ska utföras. Sedan, om det finns ett val, är att välja en distributionsmodell beroende på de säkerhetsåtgärder som krävs. Användare med kompetens, eller medel för att hyra konsulter, skulle kunna välja IaaS eller PaaS för att ha störst kontroll över säkerheten. Annars är det oftast okej 55

65 D.7. Slutsatser att använda sig av molntjänster som har större kontroll och hanterar mycket av säkerheten då det oftast är säkert mot utomstående, dock kan molnleverantörerna kanske komma åt användardatan lättare. Att ha i åtanke är säkerhetsriskerna och ansvarfördelningen i de olika distributionsmodellerna. D.7.3 Finns det säkrare alternativ till molntjänster? Idag är den säkraste metoden att helt och hållet separera sin data från molnet och internet. Då kan inte säkerhetsriskerna som tagits upp i D uppstå. Riskerna som finns då är förlust av hårdvaran, inklusive stöld, och fysiska skicket av den, till exempel att hårvaran går sönder på grund av olycka eller slitage. Sedan kan en privat server vara av intresse som imiterar molntjänsterna men att användaren är helt och hållet i kontroll över hårdvaran. Det blir då en ekonomisk fråga istället men är det bästa fallet ur ett datasäkerhetsperspektiv. 56

66 E E Metoder och kostnad för mjukvarukvalitet - en fallstudie av David Thimren E.1 Inledning Kvaliteten på mjukvaruprodukter är idag viktigare än någonsin och för att uppnå hög kvalitet på sin produkt är det viktigt att följa metoder och använda rätt verktyg. Detta är vad denna rapport kommer fokusera på, hur projektgruppen arbetade för att öka kvaliteten i sin mjukvaruprodukt och vilka metoder och verktyg som har använts. Sist presenteras även en analys av hur mycket det arbetet har kostat. E.1.1 Syfte Syftet med denna rapport är att undersöka vilka metoder och verktyg som rekommenderas att använda för framtagning av mjukvarukvalitet, och att undersöka vad värdet av kvalitet är på en mjukvaruprodukt. Syftet är även att redovisa hur mycket kvalitetsarbetet kostar. E.1.2 Frågeställning Huvudsakligen ska rapporten försöka att besvara följande frågeställningar: E Hur har vi arbetat med kvalitet i projektgruppen? 2. Hur mycket kostade vårt kvalitetsarbete? Avgränsningar Rapporten kommer gå in på hur vi arbetade med kvalitet i projektgruppen och kommer därför inte kunna ta upp alla möjliga sätt att arbeta med det. E.2 Bakgrund Som en oerfaren kvalitetssamordnare trodde jag att kvalitet i mjukvaruprojekt existerade endast på grund av bra utvecklare, att det var något som dyker upp automatiskt. Jag gick då 57

67 E.3. Teori in i arbetet och trodde att man inte behövde lägga mycket resurser på att arbeta med just kvalitet. Det visade sig att för att få kvalitet i sin produkt måste man lägga ner mycket tid och planering och det är inte lika trivialt som jag trodde. E.3 Teori Nedan följer teorin som kommer arbetas med under denna rapport. E.3.1 ISO/IEC ISO/IEC är en standard inom mjukvaruutveckling för att underlätta samarbete med mjukvarukvalitet. Den delar upp mjukvarukvalitet i sex olika områden [47]. E.3.2 Funktionalitet: Hur väl mjukvaran uppfyller de krav som ställs på den. Pålitlighet: Hur väl mjuvaran kan utföra sin uppgift under en tidsperiod. Användbarhet: Hur väl mjuvaran kan användas av användare. Underhållbarhet: Hur väl man kan utföra specifika ändringar i mjukvaran. Portability: Hur väl mjukvaran kan flyttas från en miljö till en annan. Effektivitet: Hur väl mjukvaran använder sina resurser för att utföra sin funktionalitet. Scrum Scrum är en arbetsmetod som är väldigt populär för mjukvaruprojekt [83]. E Scrum-möten Scrum-möten är ungefär 15 minuter långa som hålls varje dag där alla medlemmar i projektet berättar vad de gjort, vilka svårigheter de har haft sen senaste mötet, vad de ska göra tills nästa möte och vilka hinder de kommer ha som skulle kunna komma i vägen för deras arbete. Genom att göra detta hålls alla medlemmar uppdaterade om vad alla andra i gruppen gjorde och om någon behövde hjälp var det ett lätt sätt att få fram det till alla medlemmar i projektet. Detta ökar produktiviteten av alla medlemmar och i sin tur kvaliteten på produkten. E Sprints Arbetet delas upp i sprints som är 2-3 veckor långa där man arbetar med vissa valda aktiviteter för att sedan kunna testa dem och reflektera över sprinten. Detta ökar kvaliteten då alla medlemmar alltid vet vad de ska jobba med och man kan se iterativ framgång i produkten. E Retrospektiv Efter varje sprint utvärderas den i ett retrospektivemöte där man går igenom vad som gick bra och dåligt, och vad som borde förändras till nästa sprint. Fördelen med att göra detta är att kvaliteten på sprintarna ökar för varje sprint man gjort då man kan dra lärdomar av de tidigare. 58

68 E.4. Metod E.3.3 Kostnad Kostnaden för kvalitet (COQ) kan beräknas som summan av 4 olika kostnader som visas i fig. E.1 [1]. Figur E.1: Uppdelning av kvalitetskostnad Prevention costs: Kostnaderna för att förhindra dålig kvalitet, inkluderar till exempel arbetsmetodik, kvalitetsplanering och utbildning. Appraisal costs: Kostnaderna för att kontrollera att kvalitetskraven har blivit uppfyllda, alltså till exempel inspektion och testning. Internal failure costs: Dessa kostnader är kopplade till att ta hand om buggar och andra fel i produkten innan den har levererats till kunden, till exempel bugfixing och omarbetningar. External failure costs: Dessa kostnader är kopplade till de fel och buggar i produkten som kunden hittar efter leverans av produkten, med andra ord kostnaden för återlämningar av produkten eller andra klagomål. E.4 Metod Här behandlas de aktiviteter och steg som klassas som kvalitetsarbete under projektets gång. E.4.1 Planering I förfasen av projektet skrevs ett antal dokument för att hjälpa utvecklingen av produkten. Dessa var till exempel projektplan, kvalitetsplan och kravspecifikation. Projektplanen beskrev hur arbetet av projektet skulle gå till, hur arbetsmetoden skulle se ut och vilka roller och deras uppdrag var. Kvalitetsplanen beskrev hur kvalitet skulle försäkras inom projektet, vilka standarder som skulle användas, hur beslut skulle fattas, hur utbildning av medlemmar skulle gå till och vad målet med kvaliteten var. Kravspecifikationen beskrev vilka krav som kunden hade på projektet och för att ha hög kvalitet i ett mjukvaruprojekt är det väsentligt att uppfylla alla krav i kravspecifikationen. E.4.2 Scrum I detta projekt användes den agila utvecklingsmetoden Scrum för det är en populär utvecklingsmetod. Vi använde dock en variant på den där vi endast hade två Scrum-möten i veckan och två veckor långa sprintar. Genom att använda Scrum skulle kvaliteten i arbetet öka. E.4.3 Kvalitetsmål Målet med vårt kvalitetsarbete var att uppfylla det önskemål vi fick från vår kund. Det var att underlätta för nya arbetare att sätta upp ett företags system och på så kort tid som möj- 59

69 E.5. Resultat ligt börja koda och bidra till ett projekt. Vårt kvalitetsmål var då att det maximala antalet kommandon för att sätta upp produkten fick vara fem och syftet med detta var att höja produktens användbarhet. E.4.4 Kravinsamling För att öka chansen för att få kvalitetskraven uppfyllda utfördes vår kravinsamling vid två kundmöten. På första mötet förklarade kunden sina krav och utifrån det skrev vi upp dem som vi hade tolkat dem. På andra mötet presenterade vi vår tolkning och diskuterade med kunden för att gemensamt komma fram till så bra krav som möjligt. E.4.5 Beräkning av kostnad För att beräkna kostnaden av vårt kvalitetsarbete uppskattade vi antalet timmar som lades ner på de olika kvalitetsaktiviteterna i en tabell. E.5 Resultat Nedan presenteras resultatet. E.5.1 Planering Genom att skriva de dokument som togs upp i metoden fick vi en bra plan att arbeta enligt vilket ledde till att alla visste vad de skulle jobba med vilket i sin tur ledde till ökad effektivitet i både arbetet och produkten. Genom att planera projektet noggrant ökar prevention costs något men minskar både internal och external failure costs vilket troligtvis ger en sänkt kostnad totalt. E.5.2 Scrum Den arbetsmetod vi använde hjälpte oss enormt under projektets gång då vårt tillvägagångssätt för att uppnå kraven ändrades några gånger under projektet. Genom att då ha en agil arbetsmetod blev det lättare att upptäcka när en lösning inte skulle fungera och även lättare att fokusera om efter att en sprint hade avslutas. Detta gjorde att vi inte fastnade på en dålig lösning för länge vilket ledde till att mer tid kunde läggas på de lösningar som fungerade. Detta arbete läggs främst på prevention costs, men även några delar inom scrum kan räknas som appraisal costs, som testning, och tack vare en bra arbetsmetod kan internal failure costs sänkas, vilket troligtvis även det ger en sänkt kostnad totalt. E.5.3 Kvalitetsmål Kvalietsmålet uppfylldes då antal steg att börja använda systemet är färre än fem. Detta gjorde att användbarheten hos systemet ökade och kunden fick sitt önskemål uppfyllt. Arbetetskostnaden för detta läggs under appraisal costs och tack vare det uppfyllda kvalitetsmålet blev external failure costs lägre. E.5.4 Kravinsamling Att ha två möten med kunden ledde till att båda parterna kunde förstå och hålla med om kraven. Detta ledde till att den produkt som vi skapade mötte kundens förväntningar och höjde produktens funktionalitet. Detta arbete läggs främst på prevention costs och tack vare de bra kraven vi fick fram kan external failure costs sänkas vilket gav en total sänkt kostnad. 60

70 E.6. Diskussion E.5.5 Kvalitetskostnad Kostnaden för vårt kvalitetsarbete ses i tabellen nedan som beskriver hur mycket alla aktiviteter har kostat i timmar, dessa värden togs fram genom att analysera alla medlemmars tidsrapportering och summera ihop alla de olika aktiviteterna. Timmarna för prevention och appraisal costs är ganska exakta men internal och external costs är uppskattade grovt. Typ Timmar Prevention costs 600 Appraisal costs 200 Internal failure costs 100 External failure costs 50 Totalt 950 Om man jämför det med det totala antalet spenderade timmar ser man att vi spenderade ungefär 34% av vår budget på kvalitetsarbete. E.6 Diskussion Nedan följer diskussionen. E.6.1 Planering Den planering vi utförde var väl anpassad för storleken på vårt projekt. Vi spenderade ganska mycket tid på den men jag tror att med hjälp av de dokument som skrevs och de val av standarder vi gjorde kunde den totala kostnaden sänkas. Kravspecifikation hjälpte till att sänka external failure costs, projektplanen hjälpte att sänka internal failure costs och även kvalitetsplanen hjälpte att sänka internal failure costs. E.6.2 Scrum Jag tror valet att använda Scrum var bra. Det finns många resurser online som beskriver hur det fungerar och vad man behöver göra för att det blir enkelt att börja processen. Det passade även vårt projekt väldigt väl då vi gjorde många ändringar och därför behövde en agil arbetsmetodik som var väl anpassad för just det. Vi kunde även valt till exempel Kanban men eftersom ingen hade erfarenhet av det gjorde vi nästan ingen research om det utan valde Scrum direkt. E.6.3 Kvalitetsmål Det kvalitetsmål vi valde var väl anpassat för att uppnå den användbarhet som kunden sökte i produkten. Det var dock inte ett så väl formulerat mål. Målet kunde tolkas på flera sätt då kommandon inte var exakt definierade vilket ledde till att det var svårt att kontrollera att målet var uppnått. Något som troligtvis bidrog till detta var att när vi skapade kvalitetsmålet hade vi andra idéer om hur produkten skulle vara byggd och målet ändrades inte när vi ändrade vår lösning. Något som bidrog till svårigheten att sätta upp ett bra formulerat kvalitetsmål var att det var svårt att veta i planeringsfasen hur vår produkt kunde se ut då ingen av oss hade särskilt stor erfarenhet av ett liknande projekt tidigare. Men eftersom vi ändå lyckades uppnå målet och kunden var nöjd anser jag att det ändå var värt att arbeta med. 61

71 E.7. Slutsatser E.6.4 Kravinsamling Det sätt vi utförde vår kravinsammling på var både effektivt och bra strukturerat. De två kundmöterna gav oss nog med tid att diskutera med kunden och komma överens om vad kraven skulle vara. Detta bidrog mycket till kvaliteten på produkten. E.6.5 Kvalitetskostnad Då det är väldigt svårt att uppskatta internal och external failure costs blir beräkningen av hur mycket kvalitetsarbetet har kostat svår att utföra. Till exempel tog den planering vi gjorde mycket tid att utföra men hur mycket mer tid arbetet hade tagit och vilken den extra internal failure costs hade blivit om vi inte hade gjort planeringen är otroligt svår att utföra. Det man får göra är att undersöka hur andra företag och projektgrupper utför sin planering och välja det som verkar passa sitt projekt. Med det sagt är 34% spenderad tid på kvalitetsarbete nog lite för mycket då den optimala kostnaden borde ligga runt 10-15% [1]. Men den innehåller även mycket uppskattade siffror och vi kan heller inte lägga till någon vinst från försäljning av vår produkt. E.7 Slutsatser Sättet vi arbetade på i projektet var för det mesta bra. Den arbetsmetod, planering och vår kravinsamlingsmetod hjälpte troligtvist väldigt mycket med att sänka den totala kostnaden för kvalitet men det kvalitetsmål vi arbetade med var nog i slutändan en dålig investering. Vi borde troligtvist bestämt ett mer exakt kvalitetsmål då det hade varit enklare att arbeta mot och enklare att testa om målet var uppfyllt. Det skulle också göra att målet skulle vara svårare att misstolka. Då beräkning av kvalitetskostnad är svårt att uppskatta är det svårt att dra några konkreta slutsatser från endast ett projekt. Jag tror det säkraste man kan göra för att sänka kvalitetskostnaden i sitt projekt är att se vad andra projektgrupper gör och följa de standarder som finns för kvalitetsarbete i industrin. 62

72 F F För- och nackdelar med Dockercontainrar jämfört med virtuella maskiner av Wiktor Karlsson F.1 Inledning Konsten av att kunna emulera en dator i en annan dator är en av virtualiseringens grundtankar. Att till exempel inte kunna köra ett gammalt program på grund av en uppdatering av operativsystem kan, för många, bli en stor frustration.virtualiseringstekniken låter däremot en del av datorn hållas isolerad där man kan köra vilket operativsystem man önskar. Så var kommer Dockercontainrar in i bilden? Att få sin programvara att fungera på många användares datorer med olika versioner av bibliotek och tjänster är något många företag runtom i världen brottas med dagligen. Företagets program kanske kräver en specifik, äldre version av den stödjande programvaran Java. Om många användare har olika versioner av just denna stödjande programvara kan detta skapa problem med att få företagets program att fungera på allas datorer. Dockercontainrar, likt virtuella maskiner, har fördelen att få välja och behålla versioner av de bibliotek och tjänster som krävs konstanta. Användarna kan därefter köra containern vilket i sin tur kör programmet med rätt versioner av alla bibliotek och stödjande programvara. Så vad borde man använda? Dockercontainrar eller virtuella maskiner? F.1.1 Syfte Syftet med studien var att skapa en djupare förståelse för programvaran Docker och deras containrar i jämförelse med virtuella maskiner. Vilka är de stora skillnaderna mellan en Dockercontainer och en virtuell maskin? Studien undersökte även i vilka sammanhang Dockercontainrar och virtuella maskiner har fördelar och nackdelar gentemot varandra. F.1.2 Frågeställning De huvudsakliga forskningsfrågorna för studien var: 1. Vilka är fördelarna/nackdelarna med att använda Dockercontainrar istället för virtuella maskiner? 63

73 F.2. Bakgrund F I vilka sammanhang kan det vara bättre att använda Dockercontainrar istället för virtuella maskiner? 3. Påverkar valet/typen av container i frågeställning 1 och 2 det slutgiltiga resultatet? Avgränsningar Studien undersökte i första hand fördelar och nackdelar med Dockercontainrar. Andra typer av containers som undersöktes enligt frågeställning 3 jämfördes inte med virtuella maskiner utan jämfördes istället endast med Dockercontainrar för att se om det fanns någon märkbar skillnad mellan dem. F.2 Bakgrund Dockercontainrar är en relativt ny uppfinning vilken först introducerades år 2013 men har blivit världsledande i sitt område [30]. De underliggande faktorerna för mitt intresse av det valda studieämnet emanerade till stor del just från sammanknytningen till projektet i programvaran Docker. I min åsikt är det intressant att både virtuella maskiner och Dockercontainrar ofta har samma mål, detta i att sätta upp en isolerad miljö där man har tillgång till exakt de bibliotek, tjänster och program man behöver. Detta skapade personligt intresse för vilket av dessa alternativ som är bäst eller om de ens är alternativ till varandra i första början. Någon av dem kanske passar bättre vid specifika tillfällen vilket jag då ville undersöka. Det fanns även ett personligt intresse för att reda ut varför Docker är så populärt och världsledande när det kommer till containrar. Mina tidigare erfarenheter av studieämnet med virtuella maskiner och Docker var relativt varierade. Jag har använt virtuella maskiner sedan tidigare och genomgående under hela projektet för att nå en Linuxmiljö från min Windows desktop. Docker är däremot något som först introducerades för mig i början av projektet så jag hade ej några tidigare erfarenheter inom det området. F.3 Teori Den underliggande teori som kan vara bra att känna till för att förstå innehållet i studien och dess resultat beskrivs nedan. F.3.1 Virtualisering Virtualisering kan beskrivas som skapandet av virtuella resurser (t.ex minne) vilka är avskurna från omvärlden. Det finns många olika typer av virtualisering. Några exempel på detta är minne-, applikations-, data- och nätverksvirtualisering. För att kunna skapa en traditionell virtuell dator krävs använding av just virtualisering. Formen av virtualisering som krävs är hårdvaruvirtualisering vilket är en av de mer kända former av virtualisering [46]. Dockercontainrar bygger däremot på operativsystems-nivå virtualisering. F.3.2 Virtuell maskin Hårdvaruvirtualisering är grunden för virtuella maskiner och grundtanken bakom dem är att kunna separera värddatorn från en ny, virtuell, emulerad dator inuti värddatorn. För att detta ska fungera måste den virtuella datorn tilldelas virtuella resurser i form av till exempel lagringsutrymme och processorkraft. Att den har dessa virtuella resurser innebär även att den virtuella datorn inte har någon direkt tillgång till värddatorns fysiska hårdvara. Att man kan intereagera med den virtuella maskinen via ett fönster i den fysiska värddatorn ändrar inte faktumet att den virtuella maskinen är helt isolerad från värddatorns hårdvara. Detta öppnar många intressanta användningsområden. Exempel på hur detta koncept kan tillämpas är 64

74 F.4. Metod att till exempel exekvera program som är inkompatibla med vissa bibliotek och program på värddatorn [61]. Virtuella maskiner brukar även ofta förkortas som VM. F.3.3 Avbild (Docker) En Dockeravbild är grunden för att använda sig av Dockercontainrar. När en Dockeravbild exekveras skapas en Dockercontainer. Man kan se avbilden som en mall för skapandet av containers. Innan själva exekveringen har avbilden byggts ihop med hjälp av en Dockerfil. Dockerfilen kan baseras på andra avbilder som till exempel olika distributioner av Linux. Den beskriver dessutom vilka bibliotek som ska inkluderas och kommandon som ska exekveras när avbilden byggs ihop, men även vad som ska hända när avbilden själv exekveras [28]. F.3.4 Container (Docker) En Dockercontainer är en behållare som exekverar kommandon och program. Innan själva exekveringen måste allt som behövs pakteras in i behållaren vilket i detta fall är en Dockeravbild. Detta medför en isolerad miljö där programmen som körs inuti containern har tillgång till allt de behöver. Bortsett från programmet som ska köras kan detta kan vara saker som specifika versioner av stödjande programvara och bibliotek. Detta koncept gör det lätt att få programmet man vill köra att fungera på olika datorer och miljöer då containern redan har allt den behöver [26]. F.4 Metod För att kunna besvara frågeställningarna om för-/nackdelar och vilka situationer som gynnar de olika alternativen, tillämpades i första hand en studie av litteratur som var relaterat till områdena i fråga. Denna studie bestod bland annat av att analysera och reflektera över den litteratur inom områdena men även genom granskning av relaterat videomaterial. För att kunna få en så välbaserad litteraturstudie som möjligt skulle de källor som användes antingen vara från trovärdiga utgivare eller jämföras mot ett flertal andra källor. Detta för att garantera att den information som användes som underlag var pålitlig och faktabaserad. I första hand undersöktes källor som skulle ligga som underlag för studien via internet. Om något inte kunde hittas eller besvaras via detta tillvägagångssätt bestämdes att vanlig litteratur kunde användas istället. De söktermer som användes som grundpelare för studien var virtualisering, virtuella maskiner och Docker samt för och nackdelar tillsammans med de tidigare nämnda söktermerna. Videomaterial användes endast för att reflektera och jämföra med andra funna källor. Den information som samlades in jämfördes med de personliga erfarenhtererna av Docker, virtuella maskiner och virtualisering som hade samlats upp under projektets gång. För att kunna se om det var någon märkbar prestandaskillnad för en vardaglig användare mellan att använda en virtuell maskin och att använda en Dockercontainer genomfördes ett test där viss mätdata samlades in. Testet utgick från att bygga respektive skapa en Dockercontainer och en virtuell maskin och se vilken som blir klar snabbat med en enkel uppgift. Testet utfördes med Linuxdistributionen Ubuntu Dockercontainern och den virtuella maskinen kördes dessutom från samma värddator men ej samtidigt. För testet med den virtuella maskinen användes programmet VirtualBox för att sätta upp en virtuell maskin på värddatorn i fråga. Uppgiften som utfördes var ett enkelt Pythonprogram som räknade upp till ett stort tal och tar tiden. Den data som samlades in var bland annat tiden för att klara programmet från att containern körs och den virtuella maskinen startar, hur lång tid det tog för byggandet/skapandet av containern/virtuella maskinen och hur stort lagrinsutrymme de olika alternativen använde. 65

75 F.5. Resultat F.5 Resultat De resultat som samlades in under studien beskrivs nedan och är uppdelade i för- och nackdelar med Dockercontainrar jämfört med virtuella maskiner, när de olika alternativen borde användas och resultatet från experimentet som beskrevs i metoden. F.5.1 Experimentresultat Från experimentet som beskrevs i andra halvan av metoden så samlades en del intressant mätdata. Den första mätdatan var tiden som togs för att bygga respektive skapa en Dockercontainer och en virtuell maskin. Att bygga Dockercontainern tog 32 sekunder där tiden för nedladdning av Ubuntu-avbilden och de delar som behövdes för att köra Pythonprogrammet. Denna tid blev däremot mycket mindre då dessa komponenter redan var nedladdade och det tog då endast 2 sekunder att bygga containern. Att skapa en virtuell maskin med Ubuntu som operativsystem tog däremot ca 6,5 minuter, betydligt längre tid än Dockercontainern. När Dockercontainern hade byggts och den virtuella maskinen hade skapats granskades deras inverkan på lagringsutrymme. Dockercontainern tog endast 162 MB medans den virtuella maskinen tog upp cirka 6 GB i lagringsutrymme. Den sista mätdatan som samlades in för experimentet var hur lång tid det tog för de två alternativen att starta och sedan utföra ett Python program. Dockercontainern hade även här en fördel i att det endast tog cirka 16 sekunder att starta containern och utföra uppgiften. Att starta den virtuella maskinen och utföra uppgiften tog 34 sekunder. Det kan dock vara värt att påpeka att det tog lite mindre tid för den virtuella maskinen att klara uppgifterna än Dockercontainern om tiden för start av den virtuella maskinen inte inräknades. Det sammanfattade och slutgiltiga resultatet visas i tabell F.1. Tabell F.1: Resultat av Docker/VM experiment Byggtid [s] Start till klar [s] Lagringsutr. [MB] VM ~ ~6000 Dockercontainer 32 alt F.5.2 F Fördelar Resurser Att ha stor påverkan på lagringsutrymme är något som är ganska vanligt när det gäller virtuella maskiner. Att skapa en virtuell maskin kan bli väldigt krävande på värddatorn. Att till exempel installera distributionen Ubuntu på en virtuell maskin tar flera GB i lagringsutrymme för att kunna användas någorlunda bra. När man väl har byggt ihop en Dockeravbild som grundas på Ubuntu och som innehåller några enstaka kommandon som behövs för att lösa en specifik uppgift så kan storleken ibland endast behöva vara några 100MB. [3]. Problemet för virtuella maskiner är i detta fall mängden onödig overhead som inte egentligen behövs för att lösa de enstaka kommandon man vill. En Dockercontainer är däremot väldigt effektiv när det kommer till detta då den bara använder sig av det den behöver för att lösa containerns uppgifter. F Hastighet En annan fördel med Dockercontainrar är deras hastighet. Tiden att bygga ihop en Dockeravbild och sedan exekvera dess container är ofta väldigt låg. Detta beror givetvis på vad som paketeras in i filen men tiden kan ofta ändå anses var relativt låg. Att däremot behöva starta 66

76 F.6. Diskussion upp en virtuell maskin tar betydligt längre tid. Att starta en container tar ofta bara milisekunder medan en virtuell maskin kan ta betydligt längre tid än så för sin uppstart [77]. Om förhållandena inte ändras mellan aktiviteter så behöver man självklart inte skapa nya/starta om den virtuella maskinen utan bara exekvera nya uppgifter. Det är då inte lika stor skillnad vilket dessutom stöds av experimentet som utfördes i denna studie. F.5.3 F Nackdelar Isolering En viktig nackdel för Dockercontainrar är faktumet att de inte är exakt lika säkra som till exempel en virtuell maskin. Detta beror på skillnaderna i hur de två olika virtualiseringsverktygen är strukturerade. Virtuella maskiner använder hårdvaruvirtualisering och är fullt isolerade från omvärlden och har sitt eget operativsystem, separerat från värddatorns operativsystem. Dockercontainrar däremot, använder sig av samma Kernel som värddatorn [51]. Detta innebär att om något skulle ske eller påverka Värddatorns operativsystem så kan detta även påverka de containers som körs. F.5.4 Situationer Eftersom Dockercontainrar har möjligheten att lätt kunna skapa nya instanser från samma Dockeravbild och dessutom dela upp ett större arbete i mindre delar så passar detta val av virtualiseringsverktyg särkilt bra in i en microservicearkitektur. Utvecklare kan med Dockercontainrar kontinuerligt skapa och leverera ut funktionella bitar av sitt program och som har möjlighet för vidarutveckling [29]. En annan situation då Dockercontainrar kan anses som ett bättre alternativ till virtuella maskiner är om man har för avsikt att snabbt sätta upp en miljö med specifika förhållanden som kanske behöver ändras under testningen. Om något behöver testas som kräver ändring av miljön programmet körs i så går det att relativt snabbt, bygga om containern och fortsätta vad man höll på med [54]. Det rekommenderas däremot att kombinera Dockercontainrar och virtuella maskiner för att få det bästa från båda världarna och eftersom de fungerar bra tillsammans [69]. F.5.5 Andra containertyper Ett alternativ till Dockercontainrar som medför ökad säkerhet är rkt som skapades av CoreOS år Detta virtualiseringsverktyg ger dessutom möjlighet att skapa containers från Dockeravbilder. Problem med säkerhet på grund av isolering är inte lika stort med rkt containerns eftersom rkt har mer justerbara alternativ när det kommer till just isolering. [18]. Vid en prestandajämförelse av Dockercontainrar med rkt visades att Dockercontainrar en aning ledande. Dockercontainrar är till exempel lite bättre när det kommer till stresstester och CPU-belastning vid sändning och mottagning av data över nätverk [99]. Bortsett från dessa två containeralternativ verkar användning av andra containrar relativt låg. Exempel på några andra alternativ är LXD och OpenVZ [84]. F.6 Diskussion Analys av studiens resultat och hur metoden som användes fungerade i praktiken beskrivs nedan. Avsnittet går dessutom översiktligt in på studiens plats i ett bredare sammanhang. F.6.1 Resultat Utifrån resultatet av litteraturstudien och experimentet så framgår det att Dockercontainrar definitivt har en del områden där de är överlägsna jämfört mot virutella maskiner. Utifrån experimentet och mina personliga erfarenheter känns det dock som VM kan erbjuda en aning 67

77 F.6. Diskussion bättre interaktivitet för nybörjare. Att till exempel ha tillgång till ett virtuellt skrivbord för en virtuell maskin som liknar den sortens skrivbord som används på värddatorn gör det lätt för en nybörjare att navigera och utföra de uppgifter som behövs. Detta är inte svårt att sätta upp och mycket går att göra automatiskt. Att kunna interagera med en Dockercontainer är däremot en aning svårare. Först och främst är det svårt att få en visuell representation av arbetsmiljön inuti en container. Det går däremot självklart att öppna ett terminalfönster där man exekvera sina kommandon vilket dock kräver att användaren är van vid att navigera i ett terminalfönster och kan en del kommandon. Det går självklart att få fram vissa GUI alternativ men detta medför lite extra krångel än vad som ofta behövs för att få ett fungerande virtuellt skrivbord på en virtuell maskin. När det kommer till varför just Docker och rkt är de mest populära containernalternativen antar jag att det är på grund av att just Docker är världsledande i sitt område och rkt strax därefter vilket kan leda till att det finns ont om incitament att välja något av de andra alternativen om inte någon specifik feature eftersökes. Dem viktigaste lärdomarna från studien är vilket de två virtualiseringsverktygen har för förhållande till varandra. När är det bättra än det andra? Detta tillsammans med vetskapen att man inte alltid behöver välja ett av de två alternativen utan istället kombinera dem till något ännu bättre. F.6.2 Metod Metoden för studien var i första hand en litteraturstudie som användes som underlag tillsammans med personliga erfarenheter av virtualiseringsverktygen. Det som skulle kunnat gå att förbättra med detta tillvägagångssätt är hitta och använda mer källor från tidskrifter eller andra typer av peer reviewed texter. Det var dock svårt att hitta bra källor inom området som hade dessa egenskaper och var relevanta för studien. Bortsett från detta så var de använda söktermerna bra och gav information inom relevanta områden. Den andra delen av metoden bestod av ett litet experiment. I detta experiment skulle en Dockercontainer skulle jämföras med en virtuell maskin. Den data som skulle samlas in var byggandet och skapandet av en Dockercontainer och den virtuella maskinen. Deras storlek och tid från uppstart tills dess att dem hade klarat Pythonprogrammet samlades också in. Experimentet utfördes i början av studien före insamlingen av resterande data om för- /nackdelar mellan virtualiseringsverktygen. Detta gav en bra grund för att kunna verifiera de källor som användes vid några av jämförelserna under för-/nackdelar mellan de två alternativen. Det kan vara värt att poängtera att experimentet inte grundades på något tidigare experiment vilket gjorde att metoden blev lite mer osäker. Experimentet som utfördes kan ses som ett mindre pilot-experiment och kan fungera som grund för liknande och större experiment i framtiden. Detta när det kommer till hur man till exempel analyserar och samlar in data. F.6.3 Studien i ett bredare sammanhang Sett utifrån ett bredare sammanhang kan studien användas för att ge insikt i skillnaderna mellan de två virtualiseringsverktygen för alla som vill. En miljöaspekt som studien kan tänkas påverka är om flera personer får kunskap om hur lite lagringsutrymme som behövs för Dockercontainrar jämfört med virtuella maskiner. Man kanske då kommer undan med att skapa mindre antal hårdvarukomponenter för lagring vilket kan spara naturresurser. Detta eftersom virtuella maskiner ofta är betydligt större än Dockercontainrar. 68

78 F.7. Slutsats F.7 Slutsats Utifrån resultat och analysen av studien går det att dra vissa slutsatser. De fördelar som Dockercontainern har över virtuella maskiner är att de är mycket snabbare att sätta upp och använda och de tar dessutom upp mycket mindre lagringsutrymme. Nackdelarna som upptäcktes under studien är bland annat att det kan bli lite problem med säkerhet då Dockercontainrar alla delar samma Kernel vilket kan vara ett säkerhetsproblem om man inte vet vad man gör. Det kan dessutom vara en aning svårare att navigera sig fram i en Dockercontainer än via ett virtuell skrivbord för en virtuell dator. De användsningsområden då Dockercontainern kan vara bättre än den virtuella maskinen är bland annat i en agil microservicearkitektur. Dockeravbilder kan snabbt byggas och levereras utan större problem. De kan dessutom vara mer användbara än virtuella maskiner när man snabbt måste sätta upp en specifik miljö för att utföra någon uppgift eller köra något mindre program. Det går också dra slutsatsen att det nödvändigtvis inte måste vara ett val mellan Dockercontainrar och virtuella maskiner. Detta för att de två virtualiseringsverktygen har bra förutsättningar att kunna användas tillsammans, beroende på situationen. Den alternativa av containertyp som används mest efter Docker är rkt. Detta verktyg ska vara lite säkrare än Docker då man kan konfigurera isoleringsparametrar men vara en aning sämre när det kommer till prestanda och CPU-belastning. De andra alternativen för Docker verkar inte särskilt populära och används nog bara när utvecklaren söker specifika egenskaper eller beteenden. 69

79 G G Klimatpåverkan av molntjänster av Diba Rezaie G.1 Inledning I dagens IT-samhälle växer molntjänsterna och både privatpersoner och företag ansluter sig till sådana tjänster för att kunna lagra allt från privat information som bilder till företagsdata. All data som finns på molnen behöver lagras någonstans och detta sker på datacentrer, vilka är massiva lagringsanläggningar som konsumerar enorma mängder energi - energi som bland annat kommer från kolkraftverk. Det är viktigt att se på hur molntjänsterna drivs och hur det påverkar klimatet. Klimatförändringar är något som sker i detta ögonblick, överallt runt hela världen, och det blir allt viktigare för privatpersoner och framförallt företag att göra miljömedvetna val. G.1.1 Syfte Syftet med denna undersökning är att ta reda på vilka av de stora molndistributörerna (Amazon Web Services, Google Cloud Platform, Microsoft Azure) som har minst klimatpåverkan genom sina molntjänster. Detta är för att öka medvetenheten hos företag som ska använda sig av dessa molntjänster och att de gör ett miljömedvetet val. G.1.2 Frågeställning Denna undersökning ska besvara följande frågeställningar: 1. Vilket av företagen Amazon Web Services, Google Cloud Platform och Microsoft Azure erbjuder molntjänster med minst klimatpåverkan? 2. Hur kan ett företag som erbjuder molntjänster minska sin klimatpåverkan? 70

80 G.2. Bakgrund G.2 Bakgrund Jordens resurser har tyvärr sin begränsning och för att kunna se till att planeten lever ett långt och väl liv behöver varje individ bli miljömedveten och aktivt kunna ta beslut som ser till att bevara vår planet. Som en framtida civilingenjör inom datateknik är det naturligt att komma i kontakt med energikrävande resurser. Då är det viktigt att veta att med lite undersökning går det att finna alternativ/lösningar som inte tär på planeten. Då detta projekt har fokus på molntjänster och användarna själva får valmöjligheten att distribuera till valfri molntjänst kan det vara bra att upplysa om vilket alternativ som har minst klimatpåverkan. G.3 Teori Detta avsnitt tar upp teorin för att kunna besvara frågeställningarna. G.3.1 Molntjänst En molntjänst är en IT-tjänst som hanterar exempelvis program, processorkraft och datalagring vilket flyttas ut till nätet och hanteras av ett annat företag. Tanken är att slippa ha egen IT-personal och IT-utrustning och på så sätt spara på pengar och resurser. För att räknas som en molntjänst ska vissa krav uppfyllas som att man ska kunna beställa, ändra och ta bort tjänster utan någon mänsklig inblandning. Förutom det ska man kunna komma åt tjänsterna från olika uppkopplade enheter, exempelvis via en dator, mobil eller surfplatta. Molntjänster tar oftast en månads- eller årsavgift beroende på vilka eller hur mycket av tjänsterna som konsumenterna använder sig av [64]. G.3.2 Amazon Web Services Amazon Web Services (AWS) startades år 2006 och erbjuder sina kunder IT-tjänster i form av molntjänster. Kunderna betalar för den lagring de använder sig av och har inga bindningstider, vilket gör AWS attraktivt på marknaden. AWS ägs av företaget Amazon - vilket är världens största e-handelsföretag [92]. År 2018 var AWS ledande inom molntjänst-branschen och var större än både Microsoft Azure och GCP tillsammans [59]. G.3.3 Google Cloud Platform Google Cloud Platform (GCP) startades år 2008 och är företaget Googles molntjänst. Även hos Google betalar kunden endast för lagringen som de använder sig av. GCP erbjuder konkurrenskraftiga priser och ägs utav ett av världens mest etablerade internetföretag (inriktat på internetrelaterade produkter och tjänster) [80]. G.3.4 Microsoft Azure Microsoft Azure startades år 2010 och är företaget Microsofts molntjänst. Hos Microsoft Azure kan man välja olika betalningsmetoder, men alternativet pay-as-you-go existerar även här där kunden endast betalar för lagringen man använder för varje månad. Inga bindningstider gäller även här. Microsoft Azure ägs av världens största företag inom programvaruutveckling [62]. 71

81 G.3. Teori G.3.5 Greenpeace Greenpeace är en global oberoende miljöorganisation som arbetar bland annat med att hejda klimatförändringarna. Organisationen grundades år 1971 och arbetar med att hålla myndigheter och företag ansvariga för sina handlingar [43]. G.3.6 Växthuseffekt Växthuseffekten beror på att växthusgaser (exempelvis vattenånga, koldioxid, metan och lustgas) absorberar vissa våglängder av den värmestrålning som är på väg att lämna jorden. Detta leder till att jorden värms upp där den naturliga växthuseffekten är nödvändig för allt liv på jorden. När mängden växthusgaser ökar leder det till att jordens medeltemperatur ökar och förstärker växthuseffekten [68]. G.3.7 Fossila bränslen Fossila bränslen består av organiska kol- och väteföreningar som bildats under hundratusentals år. De har sitt ursprung framförallt i döda växtdelar och små djur på havsbotten som har bildats om till olja, gas och kol. Förbränning av fossila bränslen ger utsläpp av koldioxid som bidrar till växthuseffekten [8]. G.3.8 Datacenter En datacenter är en byggnad eller en plats i en byggnad där företag förvarar och styr servrar och lagringsutrustning. Dessa kör processer, applikationer och lagrar data. Elektriciteten som driver datacentrerna kan genereras från olika sorters energikällor. Vissa leverantörer satsar enbart på förnybara energikällor medan andra leverantörer fortfarande levererar elektricitet genererad från icke förnybara energikällor [93]. G.3.9 Förnybara energikällor Vindkraft Ett vindkraftverk består av ett torn, en rotor och ett maskinhus. När rotorn börjar snurra produceras det elektricitet då rotorn är kopplad till en generator. Vindkraft är en energikälla som är beroende av vädret - ju mer det blåser desto mer elektrisk energi producerar den [33]. Solenergi Produktion av solenergi använder sig av solceller som genererar likström när de exponeras för ljus. Detta sker genom att det skapas en elektrisk spänning mellan solcellens metallskikt, vilka består av ett mönstrat metallskikt på dess framsida och mer heltäckande metallskikt på dess baksida. För att solenergi ska vara så effektivt som möjligt krävs stora ytor och ett elnät som klarar av att överföra all el [33]. Vattenkraft Vattenkraftverk kan producera stora mängder energi genom att vattnets lägesenergi utnyttjas mellan två nivåer. En generator börjar drivas då vatten samlas i stora dammar och passerar en turbin på sin väg. Rotationen på turbinens blad genererar elektricitet och genom att lagra vatten i stora vattenmagasin kan man styra hur mycket elektricitet som ska produceras genom att successivt släppa fram vatten [33]. G.3.10 Icke förnybara energikällor Kolkraft Kol är ett fossilt bränsle där stenkol och brunkol producerar energi genom att det mals 72

82 G.4. Metod ned till ett fint pulver som torkas och sedan förbränns så snabbt som möjligt. Värmeenergi genereras vilket skapar ånga som driver turbinerna med propellerliknande blad. När turbinaxeln roterar mycket snabbt av ångan produceras el då en generator sitter i andra änden av turbinaxeln. Eldning med kol ger effekter på miljön genom att den sprider giftiga ämnen i atmosfären och släpper ut mycket koldioxid som bidrar bland annat till den globala uppvärmningen och förstärker växthuseffekten [85]. Naturgas Naturgas är ett fossilt bränsle som utvinns både på land och till havs. Den fungerar genom att naturgasen antänds i en gasturbin under tryck och högt temperatur, vilket leder till att förbränningsgaser produceras. Förbränningsgaserna driver i sin tur en turbin som driver en generator och el produceras. Detta likt kolkraftverken bildar koldioxid som bidrar till den globala uppvärmningen och förstärker växthuseffekten [86]. Kärnkraftverk Kärnkraftverk producerar energi som utvinns genom klyvning av atomkärnor, vilket kallas för fission. Fissionen värmer vatten och bildar ånga. Ångan driver i sin tur en turbin som driver en generator och på så sätt produceras det el. Som bränsle används uran-325 som är en isotop av grundämnet uran. [95] Kärnkraft har låga koldioxdutsläpp och är i den aspekten bra för klimatpåverkan. Däremot har kärnkraftverk ett högaktivt avfall som måste lagras säkert under väldigt lång tid [94]. G.4 Metod I detta avsnitt kommer metoden för att besvara frågeställningarna i avsnitt G.1.2 att beskrivas. G.4.1 Litteraturstudie För att undersöka fakta kring energiförbrukning av de olika molntjänsterna som Amazon, Google och Microsoft använder sig av krävdes litteraturstudie där artiklar från olika nyhetssidor, organisationer och bloggar har granskats och jämförts noggrant. Tillvägagångssätten som har använts främst för att få fram relevant information har varit genom sökmotorerna Google samt Google scholar. Mycket av informationen som flera hemsidor refererade till var organisationen Greenpeace artiklar Make IT Green: Cloud computing and its contribution to climate change [42], Clicking Clean: Who is winning the race to build a green internet? [16] och How Green is Your Cloud [17]. G.5 Resultat I det här avsnittet presenteras resultatet av frågeställningarna i avsnitt G.1.2. G.5.1 Vilket av företagen Amazon Web Services, Google Cloud Platform och Microsoft Azure erbjuder molntjänster med minst klimatpåverkan? I Greenpeace rapport från januari 2017 Clicking Clean: Who is winning the race to build a green internet? har Greenpeace betygsatt företagen beroende på hur mycket grön energi som företaget konsumerar gentemot fossila bränslen/kärnkraftverk. Betygsskalan går från A-F där A är högst betyg och F lägst [16]. 73

83 G.6. Diskussion Figur G.1: Greenpeace tabell över företagens energikonsumption. I figur G.1 (som är siffror från 2016) går det att se att Google har fått högst betyg med 56 % förnybar energi, Microsoft på tur med 32 % förnybar energi och sist Amazon web services med 17 % förnybar energi. I en artikel nyligen publicerad av gizmodo [59] nämns det att Amazon annonserade år 2014 att deras datacentrer skulle drivas på 100 % förnybar energi. De två första åren satsade Amazon mycket på förnybar energi, men sedan dog det löftet sakta ut. Konkurrenten Google nådde redan sitt mål med 100 % ren energi mål under början av 2018 [76] och Microsoft är inte långt därifrån då de i fjol skrev på ett stort avtal för solenergi [55]. Jämfört med de andra stora spelarna är Amazon den enda som inte gjort framsteg inom klimatförändringsfrågan. Utifrån siffrorna i tabellen går det att se att Google helt klart erbjuder grönast energi i sina tjänster. Googles molntjänst Google Cloud Platform blir isåfall alternativet som är bäst utifrån klimatperspektivet, Microsoft Azure andra och Amazon Web Services sist. G.5.2 Hur kan ett företag som erbjuder molntjänster minska sin klimatpåverkan? Det som företagen främst kan göra är att satsa på datacentrer som finns på platser där det är enkelt att använda sig av förnybar energi (exempelvis Sverige). Om inte det är möjligt får man använda sig av existerande datacentrer och på något sätt se till att elektriciteten drivs av förnybar energi istället. Ifall det är svårt att få tag på förnybar energi skulle företagen kunna finansiera infrastrukturen för att kunna transportera den gröna elen. Det skulle även kunna gå att skriva algoritmer för att sänka energikonsumptionen hos datacentrer. I artikeln Performance evaluation of a Green Scheduling Algorithm for energy savings in Cloud computing [97] beskriver författarna hur algoritmer kan stänga av oanvända servrar och startar om de för att minimera antalet körande servrar. Detta leder då till att mindre energi konsumeras och på så sätt kan man minska sin energikonsumption. G.6 Diskussion I detta avsnitt följer en diskussion om frågeställningarna som undersökningen baserats på. G.6.1 Fördelar med förnybara energikällor Fördelarna med förnybara energikällor är att de inte finns i en bestämd mängd som exempelvis icke förnybara energikällor. Detta innebär att vi inte behöver ta slut på naturens resurser och kan lämna icke förnybara energikällor (exempelvis som kol och naturgas) även till framtida generationer. Förnybara energikällor bidrar inte heller till förstärkt växthuseffekt och 74