Skalbarhet är en viktig komponent i företagsprogramvara. Att prioritera den från början leder till lägre underhållskostnader, bättre användarupplevelse och högre smidighet.

Mjukvarudesign är en balansakt där utvecklare arbetar för att skapa den bästa produkten inom kundens tids- och budgetramar.

Det går inte att undvika nödvändigheten av kompromisser. Kompromisser måste göras för att uppfylla ett projekts krav, oavsett om de är tekniska eller ekonomiska.

Tot ofta prioriterar dock företag kostnader framför skalbarhet eller till och med avfärdar dess betydelse helt och hållet. Detta är tyvärr vanligt i initiativ för stora data, där skalbarhetsproblem kan sänka ett lovande projekt.

Skalbarhet är inte en ”bonusfunktion”. Det är kvaliteten som avgör programvarans livstidsvärde, och att bygga med skalbarhet i åtanke sparar både tid och pengar i det långa loppet.

Vad är skalbarhet?

Ett system anses vara skalbart när det inte behöver göras om för att bibehålla en effektiv prestanda under eller efter en brant ökning av arbetsbelastningen.

”Arbetsbelastning” kan avse samtidiga användare, lagringskapacitet, det maximala antalet transaktioner som hanteras eller något annat som driver systemet förbi dess ursprungliga kapacitet.

Skalerbarhet är inte ett grundläggande krav på ett program i och med att oskalerbara program kan fungera bra med begränsad kapacitet.

Det återspeglar dock programvarans förmåga att växa eller förändras med användarens krav.

Alla programvaror som kan expandera utöver sina basfunktioner – särskilt om affärsmodellen är beroende av dess tillväxt – bör konfigureras för skalbarhet.

Fördelarna med skalbar programvara

Skalbarhet har både lång- och kortsiktiga fördelar.

I början låter den ett företag köpa bara det de omedelbart behöver, inte alla funktioner som kan vara användbara längre fram.

Till exempel kan ett företag som lanserar ett pilotprogram för dataintelligens välja ett massivt analyspaket för företag, eller så kan de börja med en lösning som bara hanterar de funktioner som de behöver till en början.

Ett populärt val är en instrumentbräda som hämtar in resultat från deras primära datakällor och befintlig företagsprogramvara.

När de blir tillräckligt stora för att använda fler analysprogram kan dessa dataströmmar läggas till i instrumentpanelen istället för att tvinga företaget att jonglera med flera visualiseringsprogram eller bygga ett helt nytt system.

Byggandet på detta sätt förbereder för framtida tillväxt samtidigt som det skapar en smalare produkt som passar nuvarande behov utan extra komplexitet.

Det kräver också en lägre finansiell insats i början, vilket är ett viktigt övervägande för chefer som är oroliga för storleken på investeringar i stora datamängder.

Skalerbarhet ger också utrymme för förändrade prioriteringar. Den färdiga analyspaketet kan förlora sin relevans när företaget ändrar sig för att möta kraven från en marknad i utveckling.

Om man väljer skalbara lösningar skyddar man den initiala teknikinvesteringen. Företag kan fortsätta att använda samma programvara längre eftersom den är utformad för att växa tillsammans med dem.

När det är dags att förändra är det betydligt billigare att bygga på en solid, skalbar programvara än att försöka anpassa mindre flexibla program.

Det finns också en kortare ”ramp up”-tid för att ta upp nya funktioner på nätet än för att implementera en helt ny programvara.

Som en sidofördel kommer personalen inte att behöva mycket utbildning eller övertalning för att anta det uppgraderade systemet. De är redan bekanta med gränssnittet, så att arbeta med de nya funktionerna ses som en bonus snarare än som en syssla.

Fallhöjden av skalningsfel

Så, vad händer när programvaran inte är skalbar?

I början är det svårt att upptäcka svagheten. Arbetsbelastningen är lätt i de tidiga skedena av en app. Med relativt få samtidiga användare är det inte mycket krav på arkitekturen.

När arbetsbelastningen ökar uppstår problem. Ju mer data som lagras eller samtidiga användare programvaran samlar in, desto mer belastas programvarans arkitektur.

Begränsningar som inte verkade viktiga i början blir ett hinder för produktiviteten. Patchar kan lindra vissa av de tidiga problemen, men patchar ökar komplexiteten.

Komplexiteten gör det mer omständligt att diagnostisera problem på löpande basis (översättning: dyrare och mindre effektivt).

När arbetsbelastningen ökar bortom programvarans skalbarhet sjunker prestandan.

Användarna upplever långsamma laddningstider eftersom servern tar för lång tid på sig för att svara på förfrågningar. Andra potentiella problem är minskad tillgänglighet eller till och med förlorade data.

Allt detta avskräcker från framtida användning. Anställda kommer att hitta lösningar för opålitlig programvara för att få sina egna jobb gjorda.

Det sätter företaget i riskzonen för ett dataintrång eller värre.

När programvaran har kontakt med kunderna ökar opålitligheten potentialen för churn.

Google fann att 61 % av användarna inte kommer att ge en app en andra chans om de hade en dålig första erfarenhet. 40 % går istället direkt till en konkurrents produkt.

Skaleringsproblem är inte heller bara ett nybörjarmisstag som görs av små företag. Till och med Disney stötte på problem vid den ursprungliga lanseringen av appen Applause, som var tänkt att ge tittarna ett extra sätt att interagera med favoritserier från Disney. Appen kunde inte hantera flödet av samtidiga användare av strömmande video.

Frustade fans lämnade negativa recensioner tills appen hade en enda stjärna i Google Play-butiken. Disney-tjänstemän var tvungna att ta ner appen för att reparera skadan, och den negativa publiciteten var så intensiv att den aldrig kom tillbaka på nätet.

Sätta prioriteringar

En del företag misslyckas med att prioritera skalbarhet eftersom de inte ser den omedelbara nyttan av den.

Skalbarhet skjuts åt sidan till förmån för snabbhet, kortare utvecklingscykler eller lägre kostnader.

Det finns faktiskt en del fall där skalbarhet inte är en ledande prioritet.

Mjukvara som är tänkt att vara en prototyp eller ett konceptbevis med låg volym kommer inte att bli tillräckligt stor för att orsaka problem.

På samma sätt kan intern mjukvara för små företag med en låg fast gräns för antalet potentiella användare sätta andra prioriteringar.

Slutligt, när ACID-överensstämmelse är absolut obligatorisk får skalbarhet stå tillbaka för tillförlitlighet.

Som allmän regel är dock skalbarhet enklare och mindre resurskrävande när den beaktas från början.

För det första har databasvalet en stor inverkan på skalbarheten. Att migrera till en ny databas är dyrt och tidskrävande. Det är inte något som enkelt kan göras i efterhand.

Principer för skalbarhet

Flera faktorer påverkar programvarans övergripande skalbarhet:

Utnyttjande

Utnyttjande mäter antalet möjliga samtidiga användare eller anslutningar. Det bör inte finnas några konstgjorda gränser för användningen.

Att öka den bör vara lika enkelt som att göra mer resurser tillgängliga för programvaran.

Maximalt lagrade data

Detta är särskilt relevant för webbplatser som innehåller mycket ostrukturerade data: innehåll som laddas upp av användare, rapporter från webbplatsen och vissa typer av marknadsföringsdata.

Datavetenskapsprojekt faller också under denna kategori. Mängden data som lagras av dessa typer av innehåll kan öka dramatiskt och oväntat.

Om den maximalt lagrade datamängden kan skalas snabbt beror i hög grad på databasstilen (SQL- respektive NoSQL-servrar), men det är också viktigt att vara uppmärksam på korrekt indexering.

Kod

Oerfarna utvecklare tenderar att förbise kodöverväganden när de planerar för skalbarhet.

Kod bör skrivas så att den kan läggas till eller ändras utan att den gamla koden behöver refaktoriseras. Bra utvecklare strävar efter att undvika dubbelarbete, vilket minskar kodbasens totala storlek och komplexitet.

Applikationer växer i storlek när de utvecklas, men genom att hålla koden ren minimeras effekten och det förhindras att ”spaghettikod” bildas.

Scaling Out Vs Scaling Up

Scaling Up (eller ”vertikal skalning”) innebär att man växer genom att använda mer avancerad eller starkare hårdvara. Diskutrymme eller en snabbare central processorenhet (CPU) används för att hantera den ökade arbetsbelastningen.

Skalering uppåt ger bättre prestanda än skalning utåt. Allt finns på ett och samma ställe, vilket ger snabbare avkastning och mindre sårbarhet.

Problemet med att skala upp är att det bara finns så mycket utrymme att växa. Hårdvaran blir dyrare när den blir mer avancerad. Vid en viss punkt stöter företag på lagen om minskad avkastning när de köper avancerade system.

Det tar också tid att implementera den nya hårdvaran.

På grund av dessa begränsningar är vertikal skalning inte den bästa lösningen för mjukvara som behöver växa snabbt och med liten notis.

Utskalning (eller ”horisontell skalning”) används i mycket större utsträckning för företagsändamål.

När man skalar ut växer programvaran genom att använda mer – inte mer avancerad – maskinvara och sprida den ökade arbetsbelastningen över den nya infrastrukturen.

Kostnaderna är lägre eftersom de extra servrarna eller CPU:erna kan vara av samma typ som för närvarande används (eller någon kompatibel typ).

Skalering sker också snabbare eftersom ingenting behöver importeras eller byggas om.

Det finns dock en liten kompromiss i fråga om hastighet. Horisontellt skalad programvara begränsas av den hastighet med vilken servrarna kan kommunicera.

Den skillnaden är dock inte tillräckligt stor för att märkas av de flesta användare, och det finns verktyg som hjälper utvecklare att minimera effekten. Därför anses skalning ut vara en bättre lösning när man bygger skalbara applikationer.

Guidelines for Building Highly Scalable Systems

Det är både billigare och enklare att ta hänsyn till skalbarhet under planeringsfasen. Här är några bästa metoder för att införliva skalbarhet från början:

Använd programvara för belastningsbalansering

Programvara för belastningsbalansering är avgörande för system med distribuerad infrastruktur (som horisontellt skalade tillämpningar).

Denna programvara använder en algoritm för att sprida arbetsbelastningen över servrar för att se till att ingen enskild server blir överbelastad. Det är en absolut nödvändighet för att undvika prestandaproblem.

Lokaliseringen spelar roll

Skalerbar programvara gör så mycket nära klienten (i applikationslagret) som möjligt. Att minska antalet gånger apparna måste navigera i den tyngre trafiken nära kärnresurserna leder till högre hastigheter och mindre stress på servrarna.

Edge computing är något annat att tänka på. Med fler tillämpningar som kräver resurskrävande tillämpningar minskar effekterna av områden med låg signal och nätverksfördröjningar genom att hålla så mycket arbete som möjligt på enheten.

Cache där det är möjligt

Var medveten om säkerhetsfrågor, men caching är ett bra sätt att undvika att behöva utföra samma uppgift om och om igen.

Leda med API

Användare ansluter sig via en mängd olika klienter, så att leda med API som inte utgår från en specifik klienttyp kan tjäna alla.

Asynkron behandling

Det hänvisar till processer som är uppdelade i diskreta steg som inte behöver vänta på att det föregående steget är färdigt innan de behandlas.

En användare kan till exempel få se en ”skickad!” medan e-postmeddelandet fortfarande är tekniskt bearbetat.

Asynkron bearbetning tar bort några av de flaskhalsar som påverkar prestandan för storskalig programvara.

Begränsar samtidig åtkomst till begränsade resurser

Dubblera inte arbetet. Om fler än en begäran begär samma beräkning från samma resurs, låt den första bli klar och använd bara det resultatet. Detta ökar hastigheten samtidigt som det minskar belastningen på systemet.

Använd en skalbar databas

NoSQL-databaser tenderar att vara mer skalbara än SQL-databaser. SQL skalar läsoperationer tillräckligt bra, men när det gäller skrivoperationer strider det mot begränsningar som är avsedda att upprätthålla ACID-principerna.

Skalering av NoSQL kräver mindre strikt efterlevnad av dessa principer, så om ACID-efterlevnad inte är ett problem kan en NoSQL-databas vara det rätta valet.

Konsultera PaaS-lösningar

Plattform-as-a-service lindrar en hel del skalbarhetsproblem eftersom PaaS-leverantören hanterar skalning. Skalning kan vara lika enkelt som att uppgradera prenumerationsnivån.

Se på FaaS

Function-as-a-service utvecklades från PaaS och är mycket nära besläktad. Serverless computing erbjuder ett sätt att bara använda de funktioner som behövs vid varje given tidpunkt, vilket minskar onödiga krav på backend-infrastrukturen.

FaaS håller fortfarande på att mogna, men det kan vara värt att titta på som ett sätt att sänka driftskostnaderna och samtidigt förbättra skalbarheten.

Glöm inte underhållet

Inställ programvaran för automatiserad testning och underhåll så att arbetet med att underhålla den inte blir oöverskådligt när den växer.

Bygg med siktet inställt på framtiden

Prioriterar du skalbarheten förbereder du ditt företag för framgång. Tänk på det tidigt och du kommer att skörda fördelarna med smidighet när det behövs som mest.

Söker du efter programvara som kan växa med ditt företag? Boka ett kostnadsfritt möte med en av våra utvecklare för att prata om vart du behöver gå och hur vi kan hjälpa dig dit!