Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
“Scalability” eller på dansk “skalerbarhed” er et ord, vi intuitivt forstår meningen af, men der er utroligt mange forskellige svar, hvis man beder folk om at uddybe, hvad de lægger i ordet og hvad det betyder i sig selv.
Et flertal vil tolke ordet “scalability” ud fra en kontekst af load, for eksempel hvor mange besøgende, som et website er i stand til at håndtere på en tilfredsstillende måde - det er egentlig ikke forkert, men det er langt fra dækkende.
Scalability som begreb er andet og mere end blot at kunne håndtere mange requests - desværre er der langt mellem snapsene, også blandt arkitekter i softwarebranchen uanset præfix (enterprise-, domæne-, solution- eller lignende).
Det er synd og skam og fører i sidste ende til en dårlig slutbrugeroplevelse, når håndværkere og specialister på et projekt ikke har et fælles sprog til at italesætte og prioritere deres indsats i forhold til at sikre et skalerbart produkt og skalerbare processer.
Lad os begynde med begyndelsen: Scalability handler om vækst - uden at definere vækst nærmere end noget, der vokser opad eller udad.
Scalability er ikke en teknisk disciplin, tværtimod er det noget, alle mennesker har førstehåndserfaring med.
Tag en køretur i trafikken - vejbelægning såsom grus versus asfalt har en betydning for, hvor meget trafik en vej kan bære, inden dens maksimale kapacitet er nået og biler og traktorer vil begynde at holde i kø.
Øger man bredden på vejen, øger man også mængden og måske også typerne af trafik, en vej kan håndtere.
Måske skulle man bygge en cykelsti, så man får de svage trafikanter væk og så sætte hastighedsbegrænsningen op for dem, der er tilbage?
Fedt med vækst
Vækst er noget, der vokser, og vi opfatter som oftest vækst som noget positivt, så længe vi er i kontrol over væksten.
Det er som regel fedt at være et sted, der vækster, men vækster man og bliver ved med det, så rammer man på et tidspunkt nogle flaskehalsproblemer, der jo netop er udtryk for, at den maksimale kapacitet er nået på et givent område og er du ikke i kontrol, kan det være en smertefuld oplevelse.
Ukontrollerbar vækst fører sjældent noget godt med sig, der er masser af eksempler på firmaer og initiativer, som blev kvalt i deres egen succes - i sig selv et metafor for, at vækst ikke blev eller ikke kunne ske under kontrollerede forhold og derfor endte med at tage livet af sin vært.
Så vidt, så godt. Det er desværre ikke nok at vide, hvad vækst er, selvom det hjælper meget at have en fælles definition af begrebet.
En PowerPoint krydret med en røverhistorie om, at “vækst, det er noget, der vokser” og et billede af hhv. en grus- og asfaltvej er ikke brugbart, hvis man som konsulent bliver købt ind til at fixe akutte performanceproblemer på et e-commerce website, der mister penge hver dag på grund af lange svartider.
Løsningen kan være at sætte ekstra webservere op, men alting ligner som bekendt et søm, hvis det eneste værktøj i værktøjskassen er en hammer.
Det er reglen snarere end undtagelsen i min branche, at selv folk, der tjener endda meget gode penge på at udvikle software, ikke har en notation eller et metodevalg, når arkitekturen i en løsning skal løftes for at kunne håndtere flere brugere.
10 forskellige svar
Spørg 10 softwareudviklere om, hvad scalability er og du får mindst 10 forskellige svar.
Det er synd og skam, for ligesom der findes designmønstre i softwareudvikling, der ganske nøjagtigt dikterer, hvordan du bør skrive kode, så den løser problemer på en måde, der tilgodeser testbarhed, sikkerhed, support af koden i drift osv., så findes der også teknologi-agnostiske modeller til at beskrive scalability i relation til softwareudvikling.
Den, jeg vil dele med jer her, er en model, jeg første gang læste om i bogen The Art of Scalability af Martin L. Abbott og Michael T. Fisher.
Modellen er illustreret herunder:
Kort fortalt kan scalability ifølge forfatterne inddeles på 3 akser: X, Y og Z, hver med sine egne karakteristika:
Y-aksen
Også kaldet vertikal skalering. Y-akse skalering handler om at opdele transaktioner i logiske funktioner eller services, der individuelt kan skaleres efter behov.
Eksempler på Y-akse skalering:
- Separate services til at håndtere hhv. ordreflow og kundeoprettelser i sin webshop
- Quick-kasser i det lokale supermarked
- Bus-baner i områder med tæt trafik i myldretiden
Z-aksen
Z-akse skalering handler om, at man foretager en opsplitning af ensartede transaktioner ned i separate, logiske enheder.
Hver logisk enhed fungerer fuldstændig ens, men er kun ansvarlig for en delmængde af data.
Afgørelsen af, hvor en forespørgsel skal behandles, foregår ud fra oplysninger i den forespørgsel, der modtages, f.for eksempel navn, IP-adresse, landekode, køn eller andet - oplysningen ligger indlejret i forespørgslen og det er op til applikationen at afgøre, hvordan opsplitningen skal foretages.
Eksempler på Z-akse skalering:
- Dedikerede servere til at håndtere trafik i bestemte regioner (f.eks EU, USA og Asien)
- I tyske byer må du kun køre ind, hvis du har købt et grønt miljømærke, der skal være synligt i forruden
- Herre vs. dame omklædning i svømmehallen
Det er selve essensen af Scalecube-modellen, at den i sig selv skalerer uendeligt.
Man kan jo sagtens forestille sig, at der bag det velkendte Google-login gemmer sig hundredevis af processer på X-aksen og at eksempelvis auditering af Google-logins, der godt kunne ligge logisk på en Y-akse, inde i maven selv fordeler load på en Z-akse, der deler data ud på et stort antal fysiske diske afhængig af for eksempel din fødselsdato eller lignende.
Da jeg knækkede dén nød, så indså jeg pludselig, hvordan det er muligt at skalere infrastrukturen i sin webshop til at kunne håndtere hundreder af millioner forespørgsler fra millioner og atter millioner af kunder hver dag.
Det kan du bruge modellen til
Modeller og abstraktioner er meningsløse og en klasse A energivampyr, hvis de ikke er praktisk anvendelige, så i morgen på arbejde, hvad kan du som eksempelvis softwareudvikler bruge modellen her til?
Tjo... i morgen får du måske performanceproblemer på firmaets website, så du sætter en ekstra webserver ind.
Svartiderne bliver bedre, alle er glade. Men hvad var det lige, du rent faktisk gjorde?
Korrekt, du skalerede på X-aksen. Hvis man anskuer en webserver som en dims, der håndterer enslydende transaktioner (HTTP requests), så vil 2 dimser, der hver kan håndtere N transaktioner, give en båndbredde på N * 2 transaktioner.
Du arbejder her på X-aksen.
Ugerne går, trafikken vokser og det går fint indtil det punkt, hvor din database ikke længere kan følge med.
Yderligere X-akse skalering, det vil sige endnu flere webservere, gør kun ondt værre, for du ønsker formentligt ikke at lægge ekstra pres på en allerede overbebyrdet databaseserver, der er ved at smelte ned gennem gulvet.
Din kollega fra Drift fortæller, at websitet bliver kvalt hver dag mellem 17 og 22 og CPU’en er rødglødende, også i dagtimerne og specielt når medarbejdere trækker rapporter, fordi alt kører på samme jern.
Nu er det jo smart som applikationsudvikler at kunne pudse DevOps-profilen lidt ved at rejse sig og sige, at “Vi er nødt til at skalere databasen, den performer elendigt på grund af vores dygtige kollegaer fra marketing, der har sørget for masser af trafik til sitet. Drifterne har nu fortalt os hvad problemet er. Jeg foreslår derfor, at vi sætter ind og skalerer databasen på Y-aksen, så vi fremover vil køre webshoppen på sin egen server og al rapportering fra en ny instans. Vi vil både frigive ressourcer til vores webshop og samtidig får vi mulighed for at optimere den nye rapport-database til netop rapport-kørsler. Andre ideer?”.
Oplever nogen lange svartider?
Det kunne også være, at jeres trofaste kunder i USA oplever lange svartider, fordi I kører alting fra et datacenter i Europa.
Nuvel, så sørger I for at lave et replikeret setup, hvor alle kunder med en IP fra en amerikansk udbyder rammer et datacenter i USA og alle andre i resten af verden får serveret indhold fra datacenteret i Europa - eller omvendt.
Voila, du har nu skaleret din applikation på Z-aksen.
Min erfaring fra 12-15 år i skyttegravene er, at X- og Y akse skalering er de oftest brugte - man skal op i et virkeligt stort antal transaktioner, før Z-akse skalering giver mening, da det har nogle voldsomme arkitekturmæssige konsekvenser, når hele udviklingsstakken bliver sin egen selvstændige enhed, blot med forskellige data.
Tag for eksempel en usecase, hvor du ønsker en rapport hver time over et eller andet af interesse for forretningen. Med alt kørende i en enkelt database?
Ingen sag. Med fire datacentre, der hver indeholder 12 databaser med salgstal, der skal samkøres for at få et reelt billede? Hmmm….
I eksemplet ovenfor kunne man snildt komme frem til samme facit uden en model at tale ud fra, men det fjerner bare en masse støj, når alle taler samme sprog - den korrekte implementering af Scalecube-modellen er i sig selv med til at skalere organiseringen og planlægningen af projektet ved at sikre klar og tydelig kommunikation.
Med en model i hånden og en pædagogisk indsats behøver en snak om scalability heller ikke blive mere teknisk, end at en produktejer og måske - gys - ens nærmeste leder vil kunne følge med.
De vil - måske - med en smule vilje og lidt stædighed måske bedre være i stand til at forstå en rammen for den løsning, udviklere og driftsfolk i fællesskab træffer og måske - dobbelt-gys - føle en form for ejerskab over den beslutning, der endte med at blive implementeret.
Ønsketænkning?
Måske, men jeg er også lidt naiv af natur. Jeg trorfor eksempel på, at der i flertallet af mellem- og projektledere findes helstøbte mennesker, der faktisk gerne vil og hver dag prøver at forstå de overordnede linier i den teknik, de bliver stillet til ansvar for og som de betaler os konsulenter en formidabel hyre for at udvikle og vedligeholde.
Det kræver en indsats, men forskellen på succes og fiasko på it-projekter er som bekendt, hvorvidt forretningen er i stand til at fastholde den langsigtede vision og forstår, hvad de får for pengene hele vejen igennem.
En model for skalering er selvfølgelig ikke en sølvkugle, der kan slå alle monstre og vampyrer ihjel, men det er et del-element, der brugt rigtigt vil kunne bygge og forstærke broen mellem kodning og forretning.
Softwareudvikleren skal være med
I en verden, hvor løsninger i software kan implementeres på et uendeligt antal måder, så er man som softwareudvikler nødt til at kunne sætte en problemstilling omkring softwareperformance ind i den rette kontekst, inden man går i løsningsmode, for løsningen vil være vidt forskellig afhængig af de akser, som man vælger at give et løft for at kontrollere væksten og forbedre scalability.
Er du ekspert, seniorudvikler, konsulent eller lignende, så bør du overveje, om du vil kunne drage fordel af at have en model for scalability i værktøjskassen, som du kan trække frem ved passende lejligheder, hvor en diskussion om scalability har behov for en ramme og et fælles sprog, man kan diskutere og træffe beslutninger ud fra.
Jeg fandt for nogle år siden en, der virker for mig - det er den, du lige har læst om og er du nysgerrig efter mere, så kan du gøre det her.
Måske har du erfaring med andre modeller og måske bruger du dem endda aktivt?
Hvis du gør, så smid meget gerne et link i bunden eller skriv, hvor man kan finde mere viden, jeg er nysgerrig på, hvad der findes af materiale og vil gerne tage del i diskussionen efterfølgende i kommentartråden herunder.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.