Det er vondt å vente. Tenk skaleringsevne!

Husk på skaleringsevne allerede under utformingen av produktet. Hvis ikke kan det bli kjedelig å være bruker!

Har du noen gang sittet og trommet utålmodig på bordet, mens du venter på at en webside skal komme opp? Nesten gitt opp å handle et sted fordi det tar evigheter å få opp produktkatalogen? Sittet på maskinen på jobb og tenkt: «lurer på hvor mye av livet mitt jeg sitter og venter på denne maskinen»?

I så fall er du i godt selskap. Skaleringsevne (hvor mange samtidige brukere, eller hvor mye data en applikasjon kan håndtere før det begynner å påvirke hastigheten på systemet) er et ord som med stor selvfølgelighet står i alle tilbud og alle kravspesifikasjoner jeg har sett, men som ser ut til å magisk forsvinne når den tekniske arkitekturen kommer på bordet. Brukere ser ut til å ha akseptert at «ting på data tar tid». Og produkteiere likeså. Men behøver det å være slik?

Jeg lurer på om dette «forsvinningsnummeret» allerede begynner når kravspesifikasjonen skrives. «Skalerbart» står vanligvis å finne under «ikke-funksjonelle» krav, noe som insinuerer, og ofte fører til, at dette kommer på banen først etter at den funksjonelle spesifikasjonen er skrevet, og noen ganger langt ut i implementeringsløpet. Man har en idé om å «legge» på skalering til slutt, etter at det funksjonelle er på plass. Sannheten er at premissene for å få en applikasjon til å skalere godt, legges allerede med de funksjonelle kravene. Disse sammen med hvordan applikasjonen skal brukes, dikterer premissene for mulig skalering.

La oss ta en nærmere titt på akkurat det. I de fleste forretningsapplikasjoner er det behov for tilgang på data som er begrensende for skaleringen. Derfor blir dataflyten viktig for skalerbarheten. La oss se for oss en støtteapplikasjon til nødnummersentralen. Det er her helt essensielt at informasjonen som finnes er korrekt, oppdatert og at alle har tilgang på den siste informasjonen hele tiden. Å lage denne applikasjonen som et distribuert system, vil fort gi en jungel av oppdateringer som skal distribueres mellom en mengde klienter, og dermed øke sannsynligheten voldsomt for at kravet til korrekt og enhetlige data ikke oppfylles. Ingen god idé altså, og følgelig legger de funksjonelle kravene en sterk føring på hva slags skalering man kan bygge inn.

En applikasjon for personlig huskeliste derimot, har svært få krav til distribusjon av data, så den kan godt implementeres som et distribuert system, som vil gi store rom for god skalering. Noen vil påstå at ved å implementere for skytjenester, så kan vi skalere opp uavhengig av arkitektur ved å sette flere ressurser på under drift. Dessverre hjelper dette stort sett ikke for dataflyten i en applikasjon. Er det svært viktig at alle ser akkurat de samme dataene til en hver tid (slik som på nødnummersentralen), er behovet for en sentral datakilde ganske stort. Denne datakilden blir ikke mindre sentralisert, eller mindre nødvendig selv om man drifter tjenesten i skyen. Så uansett hvordan man setter opp drift, hvis skalering ikke er tatt med helt fra utformingen av en applikasjon, vil den heller ikke kunne skaleres i ettertid.

Som utvikler ser jeg altfor ofte at kravet til skalering kommer på banen for sent i utviklingsprosessen. Allerede under utformingen av de funksjonelle kravene setter man betydelige føringer for hvordan en applikasjon kan skalere. I tillegg til de funksjonelle kravene, er det også svært viktig med en god forståelse av hvordan en applikasjon skal brukes. Funksjonelle krav kan som kjent endre seg gjennom utviklingsfasen, mens bruksområdet til applikasjonen ofte i større grad er mer fast. God kjennskap til bruksområdet, kan derfor gi en pekepinn på hvordan de funksjonelle kravene kan komme til å endre seg over tid. Når forståelsen for krav og bruk er på plass, kan man legge en strategi for skalering. Og først når man har det, kan man lage en implementasjon som skalerer optimalt i forhold til funksjonaliteten.

Publisert