ExCom42s applicering av beslutsträden

Det första trädet utgår från beslutet av infrastrukturens lokalisering. Då företaget redan har en robust serverhall så bestämmer de sig för att förvalta sin egen infrastruktur och väljer därför alternativet “On Premise”. Dessutom har de ett högt säkerhetskrav och vill i den mån möjligt slippa externa tjänster som till exempelvis molntjänster.

Figur 5.5 - Företagets expansion av beslutsträd för infrastrukturens placering Figur 5.5 visar hur företaget har tagit det första beslutträdet och expanderat och använt det utifrån sina egna preferenser och behov. Efter beslutet att använda sig av den infrastrukturen de redan har så valde de att använda sig av virtuella maskiner att ha sin containermiljö på i och med deras redan

befintliga vana med denna teknik. Istället för att hantera var och en av dessa Systemet ska integrera med vårt

befintliga arbetssätt.

verktyg i vår dagliga arbete. Ett exempel är GitLab för

versionshantering av vår kod. Vi ser gärna att detta utnyttjas så mycket som möjligt i integrationen med kluster.

5

Systemet ska vara robust.

Våra kunder litar på att våra tjänster alltid är tillgängliga. Därför vill vi att det ska vara hög tillgänglighet på våra applikationer, även om något skulle gå fel så ska våra tjänster vara i drift i den mån som tillåts.

maskiner själva så valde de att använda sig av en plattform som gör den här uppgiften lättare. De kollade på olika alternativ och kom fram till att de mest intressanta är Citrix eller VSphere. Valet föll till slut på VSphere efter interna diskussioner där de kom fram till att det verktyget passar deras budget och miljö bäst.

Figur 5.6 - Företagets expansion av beslutsträd för tillvägagångssätt för drift

Träd nummer två innefattar beslutet om vilket sätt de ska drifta samtliga av företagets applikationer. Figur 5.6 visar hur företaget använder sig av en blandning av trädets olika grenar. Då de inte har en gedigen vana med teknik som innefattar containrar och därmed inte ett fullt förtroende för dess

stabilitet så väljer de att behålla deras nuvarande lösning för databasdrift, nämligen “Bare Metal” dvs fysiska maskiner. I deras fall är det

Windowsmaskiner. För resterande av deras applikationer, samt externa tjänster (som till exempel Redis), ämnar de att driftsätta i containrar. På grund av att Docker är marknadsledande inom detta så väljer de dem med motivationen att det förmodligen finns mest läromaterial inom Docker gentemot deras konkurrenter.

Figur 5.7 - Företagets expansion av beslutsträd som angår “Container Orchestration”

Det tredje trädet innefattar de beslut som behöver tas angående hur Container Orchestration ska hanteras. De väljer här att markera grenarna med etiketter utifrån deras egen uppfattning från litteraturstudien i syfte att hjälpa dem ytterligare att ta ett beslut. Då de som bekant inte har någon tidigare

erfarenhet av dessa system så väljer de det alternativ där de köper in en tjänst från en annan aktör som gör konfigureringen lättare. De inser också att de behöver välja mellan att ha en “mästarnod” gentemot flera. Fördelarna med att ha flera är att klustret blir mer robust och motståndskraftig då klustret står och faller med kontrollplanet, dvs “mästarnod(erna)”. Nackdelen är

kostnaden då det behöver flera maskiner. Då de bedömer att de har en relativt hög budget att lägga på säkerhet så väljer de det robusta alternativet. Till slut så väljer de mellan att ha antingen ett större antal mindre kluster eller att ha deras infrastruktur i ett och samma kluster. Ett större antal av mindre kluster har fördelarna att det är mer isolerat samt att det blir lättare att välja vilka i organisationen som ska ha tillgång till vissa delar. Ett enda stort kluster är däremot mer kostnadseffektivt, det är lättare att hantera och det utnyttjar resurserna på ett mer optimalt sätt [42]. Då de är en mindre organisation så anser de att de inte behöver kontrollera på någon djupare nivå vem som har tillgång till klustret och väljer därför ett enda stort kluster.

Figur 5.8 - Företagets expansion av beslutsträd som angår en containers livslängd

Till slut så beslutar sig företaget på deras lösning på hantering av containrars livslängd. De två första löven behöver nödvändigtvis inte vara exklusiva gentemot varandra utan kan med fördel kombineras, vilket inte är ovanligt. På grund av omfattningen på förändringar som Infrastructure as Code skulle innebära så väljer dock företaget att inte implementera något sådant i ett initialt skede. Då de redan versionshanterar med GitLab så väljer de att också implementera en pipeline i deras system. Valet som återstår med det här trädet är “Image Repository” dvs där lagringen av containrar sker. Även här har GitLab en lösning för ändamålet men på grund av de stora

säkerhetskraven så väljer ExCom42 att hantera lagringen själva. I regel finns egentligen bara två lösningar som passar företaget, nämligen Dockers egna sätt Docker Registry, vilket är en applikation som utvecklats av Docker själva och som är mycket anpassningsbar men kräver en hel del arbete för att

skräddarsy den till sina egna behov. Harbor däremot är en open

source-applikation som är mer robust direkt efter installation. Applikationen stödjer ett gediget webbläsargränssnitt och rollbaserad behörighet [41]. På grund av den medgörliga inlärningskurvan så väljer ExCom42 att

Figur 5.9 - Företagets preliminära skiss på en slutgiltig infrastruktur När ExCom42 har klarlagt beslutsträden så ritar de upp en skiss för hur en slutgiltig infrastruktur skulle kunna se ut (visas i figur 5.9). De fundamentala grunderna för deras strategi är nu klarlagda och det blir lättare att utforma detaljerna kring arbetet för migrationen.

6 Analys

Analysen diskuterar problemet med att utvärdera den här typen av bidrag och resonerar kring resultatet samt redovisar om de mål som sattes upp i

introduktionen har mötts. Kapitlet diskuterar också om de frågeställningar som togs upp i kapitel 4 har blivit besvarade.

6.1 Slutresultat

Resultatet av arbetet är tre centrala delar: studien om aspekterna i sig, strategikomponenter och de beslutsträd som presenteras i kapitel 5.

6.1.1 Strategikomponenter

Arbetet kring de delar som behöver närvara i en strategi härleder från de viktigaste komponenterna i en populärvetenskaplig rapport som beskriver just detta. Dessa komponenter är riktning, resurser, friktion, påverkan och

framsteg. Rapporten förklarar var och en av dem på ett enkelt och

övergripande sätt och varför de bör ligga som grund när man utformar en strategi inom vilket område som helst. Det kan däremot ses som negativt att beskrivningen av komponenterna är för generell och övergripande.

6.1.2 Beslutsträd

Beslutsträden behandlar de tekniska val som ett företag måste göra och resonerar kring dem för att förenkla det slutgiltiga beslutet. Rapporten redogör också för de rekommendationer som ges till företaget, alternativt för de beslut som redan tagits. Det ursprungliga syftet med beslutsträden var att göra det klart för beslutstagare vad det är som de tar beslut om, samt att göra det lättare att ta beslutet. Resultatet kan anses som att de uppfyller målen, även om det är diskutabelt hur mycket de hjälper. En stor brist med beslutsträden är att de inte kan existera utan texten och motiveringen som följer var och en av dem i kapitel 5.1.