Skalerbarhed er en vigtig komponent i virksomhedssoftware. Prioritering af den fra starten fører til lavere vedligeholdelsesomkostninger, bedre brugeroplevelse og større fleksibilitet.

Softwaredesign er en balancegang, hvor udviklerne arbejder på at skabe det bedste produkt inden for kundens tids- og budgetbegrænsninger.

Der er ingen vej uden om nødvendigheden af at indgå kompromiser. Der skal indgås kompromiser for at opfylde et projekts krav, uanset om de er tekniske eller økonomiske.

Tå ofte prioriterer virksomheder imidlertid omkostningerne højere end skalerbarheden eller afviser endog helt dens betydning. Dette er desværre almindeligt i big data-initiativer, hvor problemer med skalerbarhed kan sænke et lovende projekt.

Skalerbarhed er ikke en “bonusfunktion”. Det er den kvalitet, der bestemmer softwares livstidsværdi, og ved at bygge med skalerbarhed i tankerne sparer man både tid og penge i det lange løb.

Hvad er skalerbarhed?

Et system anses for at være skalerbart, når det ikke behøver at blive omdesignet for at opretholde effektiv ydeevne under eller efter en kraftig stigning i arbejdsbyrden.

“Arbejdsbyrde” kan henvise til samtidige brugere, lagerkapacitet, det maksimale antal transaktioner, der håndteres, eller noget andet, der skubber systemet ud over dets oprindelige kapacitet.

Skalering er ikke et grundlæggende krav til et program, idet uskalerbar software kan køre godt med begrænset kapacitet.

Det afspejler dog softwarens evne til at vokse eller ændre sig i takt med brugerens krav.

Alle programmer, der kan udvides ud over deres basisfunktioner – især hvis forretningsmodellen afhænger af deres vækst – bør konfigureres med henblik på skalerbarhed.

Fordelene ved skalerbar software

Skalerbarhed har både langsigtede og kortsigtede fordele.

I starten giver det en virksomhed mulighed for kun at købe det, de umiddelbart har brug for, og ikke alle de funktioner, der kan være nyttige senere hen.

For eksempel kan en virksomhed, der lancerer et pilotprogram for dataintelligens, vælge et massivt enterprise analytics-pakke, eller de kan starte med en løsning, der kun håndterer de funktioner, de har brug for i første omgang.

Et populært valg er et dashboard, der trækker resultater fra deres primære datakilder og eksisterende virksomhedssoftware.

Når de bliver store nok til at bruge flere analyseprogrammer, kan disse datastrømme tilføjes i dashboardet i stedet for at tvinge virksomheden til at jonglere med flere visualiseringsprogrammer eller bygge et helt nyt system.

Bygger man på denne måde, forbereder man sig på fremtidig vækst, samtidig med at man skaber et slankere produkt, der passer til de nuværende behov uden ekstra kompleksitet.

Det kræver også en lavere indledende finansiel udgift, hvilket er en vigtig overvejelse for ledere, der er bekymrede over størrelsen af big data-investeringer.

Skalering giver også plads til skiftende prioriteter. Den færdige analysepakke kan miste relevans, når en virksomhed ændrer sig for at opfylde kravene fra et marked i udvikling.

Valg af skalerbare løsninger beskytter den oprindelige teknologiinvestering. Virksomheder kan fortsætte med at bruge den samme software i længere tid, fordi den er designet til at vokse sammen med dem.

Når det er tid til at ændre, er det betydeligt billigere at bygge på solid, skalerbar software end at forsøge at tilpasse mindre fleksible programmer.

Der er også en kortere “ramp up”-tid for at bringe nye funktioner online end for at implementere helt ny software.

Som en sidegevinst behøver medarbejderne ikke meget uddannelse eller overtalelse for at tage det opgraderede system til sig. De er allerede fortrolige med grænsefladen, så arbejdet med de ekstra funktioner opfattes som en bonus snarere end en pligt.

Faldgruben fra fejl i forbindelse med skalering

Så, hvad sker der, når software ikke er skalerbar?

I begyndelsen er svagheden svær at få øje på. Arbejdsbyrden er let i de tidlige faser af en app. Med relativt få samtidige brugere er der ikke store krav til arkitekturen.

Når arbejdsbyrden stiger, opstår der problemer. Jo flere data, der lagres, eller jo flere samtidige brugere softwaren indsamler, jo mere belastes softwarens arkitektur.

Begrænsninger, der ikke syntes vigtige i begyndelsen, bliver en hindring for produktiviteten. Patches kan afhjælpe nogle af de tidlige problemer, men patches øger kompleksiteten.

Kompleksiteten gør det mere besværligt at diagnosticere problemer løbende (oversættelse: dyrere og mindre effektivt).

Da arbejdsbyrden stiger ud over softwarens evne til at skalere, falder ydelsen.

Brugerne oplever langsomme indlæsningstider, fordi serveren er for lang tid om at svare på anmodninger. Andre potentielle problemer omfatter nedsat tilgængelighed eller endog tabte data.

Alt dette fraråder fremtidig brug. Medarbejderne vil finde løsninger på upålidelig software for at få deres eget arbejde gjort.

Det sætter virksomheden i fare for et databrud eller værre.

Når softwaren er kundevendt, øger upålidelighed potentialet for afgang.

Google fandt ud af, at 61 % af brugerne ikke vil give en app en ny chance, hvis de havde en dårlig første oplevelse. 40 % går i stedet direkte over til en konkurrents produkt.

Skaleringsproblemer er heller ikke kun en begynderfejl, der begås af små virksomheder. Selv Disney løb ind i problemer med den oprindelige lancering af deres Applause-app, som skulle give seerne en ekstra måde at interagere med deres foretrukne Disney-shows på. Appen kunne ikke håndtere strømmen af samtidige brugere af streaming video.

Frustede fans efterlod negative anmeldelser, indtil appen kun havde en enkelt stjerne i Google Play-butikken. Disney-embedsmænd måtte tage appen ned for at reparere skaden, og den negative omtale var så voldsom, at den aldrig kom online igen.

Stilling af prioriteter

Nogle virksomheder undlader at prioritere skalerbarhed, fordi de ikke kan se den umiddelbare nytte af den.

Skalerbarhed bliver skubbet til side til fordel for hastighed, kortere udviklingscyklusser eller lavere omkostninger.

Der er faktisk nogle tilfælde, hvor skalerbarhed ikke er en ledende prioritet.

Software, der er beregnet til at være en prototype eller proof of concept med lav volumen, vil ikke blive stor nok til at skabe problemer.

Sådan kan intern software til små virksomheder med en lav fast grænse af potentielle brugere sætte andre prioriteter.

Endeligt, når ACID-overholdelse er absolut obligatorisk, træder skalerbarhed i baggrunden i forhold til pålidelighed.

Som en generel regel er skalerbarhed dog lettere og mindre ressourcekrævende, når den tages i betragtning fra starten.

For det første har valget af database en stor indflydelse på skalerbarhed. Det er dyrt og tidskrævende at migrere til en ny database. Det er ikke noget, der let kan gøres senere.

Principper for skalerbarhed

Flere faktorer påvirker den samlede skalerbarhed af software:

Brug

Brug måler antallet af samtidige brugere eller forbindelser, der er mulige. Der bør ikke være nogen kunstige grænser for brugen.

Og at øge den bør være så enkelt som at stille flere ressourcer til rådighed for softwaren.

Maximalt lagrede data

Dette er især relevant for websteder med mange ustrukturerede data: indhold uploadet af brugere, rapporter fra websteder og visse typer markedsføringsdata.

Data science-projekter falder også ind under denne kategori. Mængden af data, der lagres af disse typer indhold, kan stige dramatisk og uventet.

Hvorvidt de maksimalt lagrede data kan skaleres hurtigt, afhænger i høj grad af databasestilen (SQL vs. NoSQL-servere), men det er også afgørende at være opmærksom på korrekt indeksering.

Kode

Uerfarne udviklere har en tendens til at overse kodeovervejelser, når de planlægger for skalerbarhed.

Kode bør skrives, så den kan tilføjes eller ændres uden refaktorisering af den gamle kode. Gode udviklere sigter mod at undgå dobbeltarbejde og reducere kodebasens samlede størrelse og kompleksitet.

Applikationer vokser i størrelse, efterhånden som de udvikler sig, men ved at holde koden ren minimeres effekten og undgå dannelsen af “spaghettikode”.

Scaling Out Vs Scaling Up

Scaling Up (eller “vertikal skalering”) indebærer at vokse ved at bruge mere avanceret eller stærkere hardware. Der bruges diskplads eller en hurtigere centralprocessor (CPU) til at håndtere den øgede arbejdsbyrde.

Skalering opad giver bedre ydeevne end udskalering nedad. Alt er indeholdt ét sted, hvilket giver mulighed for hurtigere afkast og mindre sårbarhed.

Problemet med opskalering er, at der kun er så meget plads til at vokse. Hardware bliver dyrere, efterhånden som den bliver mere avanceret. På et vist tidspunkt støder virksomhederne på loven om aftagende afkast ved køb af avancerede systemer.

Det tager også tid at implementere den nye hardware.

På grund af disse begrænsninger er vertikal skalering ikke de bedste løsninger til software, der skal vokse hurtigt og med kort varsel.

Skalering udad (eller “horisontal skalering”) er langt mere udbredt til virksomhedsformål.

Ved udskalering vokser softwaren ved at bruge mere – ikke mere avanceret – hardware og sprede den øgede arbejdsbyrde over den nye infrastruktur.

Der er lavere omkostninger, fordi de ekstra servere eller CPU’er kan være af samme type, som anvendes i øjeblikket (eller en hvilken som helst kompatibel type).

Skalering sker også hurtigere, da intet skal importeres eller genopbygges.

Der er dog en lille modydelse i forhold til hastighed. Horisontalt skaleret software er begrænset af den hastighed, hvormed serverne kan kommunikere.

Den forskel er dog ikke stor nok til at blive bemærket af de fleste brugere, og der findes værktøjer, der kan hjælpe udviklere med at minimere effekten. Derfor anses udskalering for at være en bedre løsning, når der bygges skalerbare applikationer.

Retningslinjer for opbygning af systemer med høj skalerbarhed

Det er både billigere og nemmere at overveje skalerbarhed i planlægningsfasen. Her er nogle bedste fremgangsmåder til at indarbejde skalerbarhed fra starten:

Brug load balancing software

Load balancing software er afgørende for systemer med distribueret infrastruktur (som horisontalt skalerede applikationer).

Denne software bruger en algoritme til at sprede arbejdsbyrden på tværs af servere for at sikre, at ingen enkelt server bliver overbelastet. Det er en absolut nødvendighed for at undgå ydelsesproblemer.

Location matters

Skalerbar software gør så meget nær klienten (i app-laget) som muligt. Reduktion af antallet af gange, hvor apps skal navigere i den tungere trafik nær kerneressourcerne, fører til højere hastigheder og mindre stress på serverne.

Edge computing er noget andet, der skal overvejes. Med flere applikationer, der kræver ressourceintensive applikationer, mindsker det virkningen af områder med lavt signal og netværksforsinkelser at holde så meget arbejde som muligt på enheden.

Cache, hvor det er muligt

Vær opmærksom på sikkerhedshensyn, men caching er en god måde at undgå at skulle udføre den samme opgave igen og igen.

Led med API

Brugere opretter forbindelse via en række forskellige klienter, så led med API, der ikke forudsætter en bestemt klienttype, kan betjene dem alle.

Asynkron behandling

Det henviser til processer, der er opdelt i diskrete trin, som ikke behøver at vente på, at det foregående trin er afsluttet, før de behandles.

For eksempel kan en bruger få vist en “sendt!” meddelelse, mens e-mailen teknisk set stadig er ved at blive behandlet.

Asynkron behandling fjerner nogle af de flaskehalse, der påvirker ydeevnen for software i stor skala.

Begræns samtidig adgang til begrænsede ressourcer

Du må ikke gøre dobbeltarbejde. Hvis mere end én anmodning beder om den samme beregning fra den samme ressource, skal du lade den første blive færdig og blot bruge det resultat. Dette øger hastigheden og reducerer samtidig belastningen af systemet.

Brug en skalerbar database

NoSQL-databaser har tendens til at være mere skalerbare end SQL-databaser. SQL skalerer læseoperationer godt nok, men når det kommer til skriveoperationer, er det i konflikt med restriktioner, der skal håndhæve ACID-principperne.

Skalering af NoSQL kræver mindre streng overholdelse af disse principper, så hvis ACID-overholdelse ikke er et problem, kan en NoSQL-database være det rigtige valg.

Overvej PaaS-løsninger

Platform-as-a-service afhjælper en masse skaleringsproblemer, da PaaS-leverandøren håndterer skaleringen. Skalering kan være lige så let som at opgradere abonnementsniveauet.

Se på FaaS

Function-as-a-service er udviklet fra PaaS og er meget nært beslægtet. Serverless computing giver mulighed for kun at bruge de funktioner, der er nødvendige på et givent tidspunkt, hvilket reducerer unødvendige krav til back-end-infrastrukturen.

FaaS er stadig ved at modnes, men det kan være værd at se nærmere på som en måde at reducere driftsomkostningerne på og samtidig forbedre skalerbarheden.

Glem ikke vedligeholdelse

Sæt software op til automatiseret test og vedligeholdelse, så arbejdet med at vedligeholde den ikke løber løbsk, når den vokser.

Byg med øje for fremtiden

Prioriterer du skalerbarhed, forbereder du din virksomhed på succes. Overvej det tidligt, og du vil høste fordelene ved smidighed, når der er mest brug for det.

Søger du efter software, der kan vokse med din virksomhed? Aftal en gratis aftale med en af vores udviklere for at tale om, hvor du skal hen, og hvordan vi kan få dig dertil!