Vad är skalbarhet?
Skalbarhet är ett systems förmåga att hantera växande last – fler användare och mer data – utan att behöva skrivas om och utan att kostnaden skenar. Man skalar antingen vertikalt, med en kraftfullare maskin, eller horisontellt, med fler maskiner som delar på jobbet. Det är ett designval som är dyrt att montera in i efterhand.
Skalbarhet är ett ord som dyker upp så fort ett system börjar bli framgångsrikt – eller när man hoppas att det ska bli det. Det handlar i grunden om en enkel fråga: vad händer när många fler vill använda tjänsten samtidigt? Här är vad skalbarhet betyder och hur du bör tänka kring det som beställare.
Definitionen
Skalbarhet är ett systems förmåga att hantera växande last – fler användare, mer data, fler transaktioner – utan att behöva skrivas om från grunden och utan att kostnaden skenar okontrollerat. Ett skalbart system kan följa med när verksamheten växer, i stället för att bli en flaskhals som bromsar den.
Poängen är att tillväxt inte ska kräva en kris. Ett väl byggt system går från hundra till hundratusen användare genom att det får mer resurser, medan ett dåligt skalbart system kör i taket och kräver en dyr ombyggnad just när allt annat går bra. Skalbarhet handlar alltså om att göra framgång hanterbar.
Två sätt att skala: vertikalt och horisontellt
Det finns i grunden två sätt att ge ett system mer kapacitet, och skillnaden är lätt att ta till sig.
Vertikal skalning betyder att man gör den maskin man redan har kraftfullare – snabbare processor, mer minne, mer lagring. Det är som att byta upp sig till en större och starkare bil. Enkelt och snabbt, men det tar förr eller senare slut: en enskild maskin kan bara bli så stor, och till slut finns ingen större att köpa.
Horisontell skalning betyder i stället att man lägger till fler maskiner som delar på arbetet. I stället för en jättelastbil sätter man in flera vanliga lastbilar som kör tillsammans. Det skalar i praktiken hur långt som helst, men kräver att systemet är byggt för att fördela jobbet över flera maskiner – och det är en sak man måste tänka på tidigt, inte lägga till på slutet.
Skalbarhet är ett designval
Här ligger den viktigaste insikten för en beställare: skalbarhet är inte en knapp man trycker på när trycket kommer, utan ett val som byggs in i systemets grund.
Ett system som från början antagits ha en handfull användare kan vara byggt på ett sätt som helt enkelt inte går att skala horisontellt. Att rätta till det senare kan innebära att stora delar måste byggas om – dyrt, tidskrävande och riskabelt, ofta mitt under den tillväxt som utlöste behovet. Att däremot bygga med skalbarhet i åtanke från start kostar sällan mycket extra, men sparar enormt om framgången kommer. Det är därför frågan hör hemma i designfasen, inte i en framtida panik.
En nykter tumregel
Samtidigt är det lätt att överdriva åt andra hållet. Att bygga ett system för miljontals användare när man har tusen är slöseri – det kostar tid och pengar, och gör lösningen mer komplex och svårförvaltad än den behöver vara. Många projekt har fastnat i att lösa problem de aldrig fick.
Den sunda avvägningen är att bygga för nästa storleksordning, inte för Google. Sikta på att klara ungefär tio gånger dagens last utan ombyggnad. Det ger gott om marginal att växa in i, utan att ni betalar för en skala ni aldrig når. När ni närmar er den nya nivån tar ni nästa kliv då. Så håller ni både kostnad och komplexitet i schack.
Ett konkret scenario
Tänk en e-handel inför sin första riktigt stora kampanj. Vardagstrafiken är blygsam, men under en helg väntas besökarna mångdubblas. Ett skalbart system möter det genom att tillfälligt starta fler maskiner som delar på lasten, och trappar sedan ner igen när ruschen lagt sig – man betalar för den extra kapaciteten bara när den behövs.
Ett system utan den förmågan står i stället inför ett val mellan att krascha under trycket eller att i förväg köpa – och betala för – en jättemaskin som mest står oanvänd. Skillnaden är just skalbarhet, och den är byggd långt innan kampanjen. Vill ni veta om ert system är rustat för tillväxt, tittar vi på Weapp gärna på arkitekturen som en del av våra tjänster innan lasten sätter den på prov.
Vanliga frågor
Vad är skalbarhet, enkelt förklarat?
Det är ett systems förmåga att växa utan att gå sönder. När fler användare loggar in och mängden data ökar ska tjänsten fortsätta fungera lika bra, utan att bli långsam eller kräva att allt byggs om. Ett skalbart system klarar att gå från hundra till hundratusen användare genom att man ger det mer resurser – inte genom en total omskrivning.
Vad är skillnaden mellan vertikal och horisontell skalning?
Vertikal skalning innebär att man ger den befintliga maskinen mer kraft – snabbare processor, mer minne. Det är enkelt men tar förr eller senare slut, för en maskin kan bara bli så stor. Horisontell skalning innebär i stället att man lägger till fler maskiner som delar på lasten. Det skalar mycket längre, men ställer högre krav på hur systemet är byggt från början.
Går det att göra ett system skalbart i efterhand?
Det går, men det är ofta dyrt och ibland smärtsamt. Skalbarhet är i grunden ett designval som påverkar hur systemet byggs från början. Ett system som antagits ha få användare kan behöva byggas om i grunden för att klara många. Därför lönar det sig att tänka igenom förväntad tillväxt tidigt, även om man inte bygger för mer än man realistiskt behöver.
Måste vi bygga för miljontals användare från start?
Nej, och det vore ofta slöseri. Att bygga för en skala ni inte är i närheten av kostar tid och pengar i onödan och gör systemet mer komplext än det behöver vara. Den nyktra tumregeln är att bygga för nästa storleksordning – tio gånger dagens last – inte för Google. Det ger marginal att växa utan att överdimensionera lösningen.
Hur vet jag om mitt system är skalbart?
Fråga hur det beter sig när lasten mångdubblas: fortsätter det fungera genom att man lägger till resurser, eller kräver det ombyggnad? Ett tecken på god skalbarhet är att systemet kan växa horisontellt, med fler maskiner. Om svaret är att allt hänger på en enda server som bara kan bli större, finns en gräns för hur långt lösningen bär.