Moln

datorkraft som hyrs per timme av någon annan

Vad det är

Moln är det korta ordet för att hyra datorer som man aldrig får se, och det är den ärligaste beskrivningen av vad molnet, på engelska cloud computing och i svensk vardag ofta molntjänster, faktiskt är: en leverantör äger byggnaderna, strömmen och hårdvaran, och kunden slår på och av servrar, lagring och nätverk via en webbkonsol eller ett API och betalar för det som har använts. Varje arbetslast ”i molnet” körs ändå på en fysisk maskin i ett datacenter; någon annan har köpt den och hyr ut bitar av den till många kunder samtidigt.

En exakt definition kommer från amerikanska National Institute of Standards and Technology (NIST). Dess Special Publication 800-145, skriven av Peter Mell och Timothy Grance och publicerad i september 2011, beskriver cloud computing som en modell för nätverksåtkomst vid behov till en delad pool av konfigurerbara datorresurser, som kan tas i bruk och lämnas tillbaka med minimal administrativ insats. Den räknar upp fem kännetecken. Självbetjäning vid behov betyder en ny server utan att prata med någon. Bred nätverksåtkomst betyder att tjänsten nås över nätet från vanliga enheter. Resurspoolning betyder att kunderna delar leverantörens hårdvara och i regel väljer ett land eller ett datacenter, aldrig ett rack. Snabb elasticitet betyder att kapaciteten växer och krymper med efterfrågan. Mätt tjänst betyder att användningen mäts, och det är det som gör en faktura per timme eller per gigabyte möjlig.

En dedikerad server som hyrs per år, ändras via ett supportärende och faktureras till fast pris klarar få av de här proven. Det är hosting, ofta ett bra val, men ett annat avtal med en annan ekonomi.

Samma dokument delar in molntjänster i tre modeller. Med infrastruktur som tjänst (IaaS) hyr kunden virtuella maskiner, diskar och nätverk och patchar själv operativsystemet på dem. Med plattform som tjänst (PaaS) driftsätter kunden kod på leverantörens körmiljö. Med programvara som tjänst (SaaS) använder kunden en färdig tillämpning, t.ex. webbmejl. Till det kommer fyra driftsmodeller: publikt moln, öppet för vem som helst; privat moln, som tillhandahålls för en enda organisation och kanske står i dess egna lokaler; gemenskapsmoln, som delas av organisationer med gemensamma behov; och hybridmoln, två eller fler av dessa sammankopplade så att data och tillämpningar kan flyttas mellan dem. De mest kända publika molnen är stora plattformar som AWS, Azure och Google Cloud, och vid sidan av dem säljer mindre leverantörer vanliga virtuella maskiner till enklare priser.

Varför det spelar roll

Molnet förvandlar ett inköp till en löpande kostnad, och det är det mesta av beslutet sammanfattat på en rad. Att köpa servrar innebär att betala i förskott för kapacitet som har dimensionerats efter en gissning om nästa års mest belastade dag. Att hyra innebär att varje månad betala för det som är påslaget, med rätt att ändra svaret nästa vecka. För en ny produkt eller en säsongsverksamhet är den flexibiliteten värd ett påslag i priset. För en arbetslast som har haft samma storlek i tre år fortsätter påslaget att debiteras långt efter att någon senast hade nytta av flexibiliteten.

Det andra beslutet är hur högt upp i stacken man hyr. En virtuell maskin ligger nära en server som teamet redan förstår, och den flyttar mellan leverantörer med lite mer än en kopia av disken. En hanterad databas, en serverlös funktion eller ett proprietärt analysdatalager tar arbete från teamet, och var och en av dem är också en del av tillämpningen som är skriven mot ett enda företags gränssnitt. Den nyttiga vanan är att veta vad det skulle kosta att lämna varje hanterad tjänst, och att ta den kostnaden medvetet i stället för att upptäcka den mitt i en prishöjning.

Det tredje är ansvaret. Den som hyr hårdvara lämnar över byggnaden, strömmen och hypervisorn; vem som kan logga in, vilka portar som är öppna och om data har en kopia någon annanstans stannar hos kunden. De stora leverantörerna publicerar var sin modell för delat ansvar (shared responsibility model) som drar den gränsen, och kontona, konfigurationen och data ligger på kundens sida i varenda version.

Så ser det ut i praktiken

För en internationell kund handlade det om fakturan. Kundens AWS-miljö hade överdimensionerats och samlat på sig tjänster som inte längre användes, så månadskostnaden hade glidit långt ur proportion till verksamheten. Arbetet började med en genomgång av vad som faktiskt kördes, tog bort de dubblerade och onödiga tjänsterna och dimensionerade resten efter verklig efterfrågan i stället för efter gissningar om värsta tänkbara fall. Sedan flyttades arbetslasterna från AWS till billigare hosting, i etapper, så att verksamheten fortsatte att gå under hela flytten. Kostnaderna sjönk ungefär tiofalt, utan någon förlust i produktivitet.

Företagets egen drift går åt motsatt håll: allt ligger på en enda liten instans. Det är en molninstans med en kärna, 512 MB minne och 10 GB disk, och av de 512 MB återstår ungefär 464 MB för tjänsterna. Inom det utrymmet terminerar den TLS för sju domäner och kör en git-forge, en onion-tjänst för Tor, en Gemini- och en Gopher-server, krypterade säkerhetskopior och spärrning av intrångsförsök. Att också onion-tjänsten fick plats på en så liten instans visades med en dags mätningar i stället för att antas: minst ungefär 310 MB av 464 var hela tiden tillgängligt, swap användes till 2,6 % och processorn var sysslolös 99,7 % av tiden. Maskinen kostar mindre per månad än en lunch, och e-post hålls medvetet borta från den, eftersom en e-postserver behöver marginal som den här maskinen redan har gjort av med.

Att hyra innebär också att lita på leverantörens kopia tills något kontrollerat ersätter det förtroendet. Allt som företaget har låg på en enda molninstans, och leverantörens ögonblicksbild var hela återställningsberedskapen: i samma konto som maskinen, inte krypterad av någon här och aldrig använd för en enda återställning. Nu skickar en systemd-timer en krypterad, deduplicerad restic-ögonblicksbild till lagring hos en annan leverantör via SFTP, gallrar bland ögonblicksbilderna och kontrollerar deras integritet, och ett dödmansgrepp pingas bara när körningen lyckas. En gång i månaden hämtar en övning tillbaka en känd fil och jämför den, så det som testas är en återställning.

Var det går fel

Molnen själva fallerar mer sällan än vanorna runt dem, och de vanliga problemen är långsamma, tysta och dyra.

Räkningen växer medan produkten behåller sin storlek. Resurser samlas på hög: en testserver som fick stå kvar efter testet, en disk som fortsätter att faktureras sedan maskinen raderats, ögonblicksbilder som sparas för evigt, en lastbalanserare framför ingenting. Att flytta data ut från en leverantör, eller mellan dess regioner, mäts och debiteras också, så den som skickar loggar och säkerhetskopior över de gränserna betalar för varje kopia. Märk varje resurs med en ägare och ett syfte, sätt upp ett budgetlarm och läs fakturan rad för rad en gång i månaden.

Kapaciteten dimensioneras för en dag som aldrig kommer. Maskinstorlekar väljs en gång, vid start, utifrån en gissning om värsta fallet, och gissningen lever längre än de som gjorde den. Mät vad en arbetslast använder under en vanlig vecka och under en hektisk, dimensionera efter det med marginal och låt den automatiska skalningen krympa lika villigt som den växer.

Leverantörens ögonblicksbild behandlas som säkerhetskopian. Den ligger i samma konto, bakom samma inloggningsuppgifter och hos samma företag som maskinen den skyddar, så en stulen inloggning eller ett avstängt konto tar servern och dess enda kopia på samma gång. En riktig säkerhetskopia ligger bakom andra inloggningsuppgifter, helst hos en annan leverantör, krypterad med en nyckel som den leverantören aldrig har, och läses tillbaka med jämna mellanrum.

Skyddet stannar där standardinställningarna lämnade det. De vanliga öppningarna är en brandväggsregel som släpper in SSH från hela internet, en långlivad åtkomstnyckel i en utvecklares dotfiler, ett administratörskonto som används för vardagsarbete och en lagringsbucket som gjordes publik för en enda demo. Ge den minsta åtkomst som gör jobbet, välj kortlivade inloggningsuppgifter, kräv en andra faktor vid varje mänsklig inloggning och håll konfigurationen i kod, så att varje ändring av den granskas.

Att lämna leverantören visar sig kräva en omskrivning. Varje proprietär kö, körmiljö för funktioner och databasdialekt binder koden lite hårdare till en enda leverantör. Håll grunden på öppna gränssnitt där det är billigt, som PostgreSQL, containrar och vanliga virtuella maskiner, och skriv ner utträdeskostnaden för varje proprietär tjänst redan när den införs.

Läs mer

Ordlista