Å skalere en SaaS etter lansering uten å ødelegge produktet

Alle feirer lanseringen. Nesten ingen advarer deg om delen som kommer etterpå — det merkelige, nervepirrende året da produktet som ga deg de første hundre kundene, begynner å svikte under vekten av de neste tusen. Ingenting dramatisk skjer. Ting blir bare tregere, mer ustabile, vanskeligere å endre. En tirsdag innser du at en funksjon som før tok en dag, nå tar en uke, og ingen kan helt si hvorfor. Det er der, ikke ved lanseringen, at de fleste SaaS-produkter stille vinnes eller tapes.

Vi har sittet med mange gründere akkurat på dette punktet. De holder ikke på å mislykkes — det er det forvirrende. Inntektene stiger, teamet vokser, demoene går bra. Men under overflaten stønner produktet. Supportsaker stiger raskere enn brukerne. Utrullinger som før var kjedelige, kommer nå med tilbakeholdt pust. Kodebasen som føltes smart for et år siden, føles nå som et minefelt der hver endring risikerer å utløse noe annet. De gjorde ingenting galt. De vokste bare fra det de bygde, og ingen fortalte dem at det var meningen at det skulle skje.

Så dette er guiden vi skulle ønske flere gründere hadde hatt før sprekkene dukket opp. Den handler ikke om hyperskala, Kubernetes eller hva en enhjørning gjorde ved femti millioner brukere. Den handler om den kjedelige, avgjørende mellomfasen — å gå fra det virker for noen få til det virker for mange — uten å skrive om alt, skremme bort kundene dine eller brenne ut teamet ditt. Målet er ikke en perfekt arkitektur. Det er et produkt som fortsetter å vokse i stedet for ett som stille begynner å gå i stykker.

Hva som faktisk går i stykker når en SaaS vokser

Her er delen som overrasker gründere mest: skaleringsproblemer ankommer nesten aldri som det dramatiske nedbruddet du vapner deg mot. Serveren tar ikke fyr. I stedet utvikler produktet en slags lavgradig feber. Sider som lastet umiddelbart, begynner å ta tre sekunder. En rapport som kjørte fint for tidlige kunder, tidsavbrytes for den store som nettopp signerte. Den samme feilen dukker opp igjen og igjen fordi to deler av koden i hemmelighet er avhengige av hverandre på en måte ingen dokumenterte.

Det som virkelig brister, er sjelden serverne dine — det er antagelsene dine. Tidlig bygde du for formen på de første brukerne dine: noen få kontoer, lite data, enkle arbeidsflyter, alle omtrent like. Vekst legger ikke bare til mer av det samme. Den legger til variasjon. En kunde med ti ganger så mye data. Et team som bruker en funksjon på en måte du aldri forestilte deg. En topp klokken ni mandag morgen, når alle logger inn samtidig. Hver av dem bryter stille en antagelse som ble bakt inn i koden din for et år siden, da det å bryte den var utenkelig.

De fire stedene der det har en tendens til å vise seg først, er forutsigbare. Databasen er nesten alltid kanarifuglen — spørringer som var umiddelbare på små tabeller, kryper etter hvert som dataene vokser. Det trege endepunktet: én eller to sider som gjør for mye arbeid per forespørsel, noe som går bra helt til trafikken hoper seg opp. Den skjøre utrullingen, der det å sende ut noe som helst har blitt skummelt fordi koden er for sammenfiltret til å overskue. Og supportbelastningen, som ikke er infrastruktur i det hele tatt, men er det sanneste tidlige signalet på at produktet ikke lenger passer til hvordan folk faktisk bruker det.

Fellen ved å løse problemer du ikke har ennå

Før vi snakker om å fikse ting, en advarsel som har reddet flere produkter enn noen optimalisering. Den største trusselen mot en voksende SaaS er ikke å ignorere skala — det er å jage den for tidlig. I det øyeblikket en gründer kjenner den første nedbremsingen, er instinktet å gripe etter arkitekturen de leste om på en kjent ingeniørblogg. Mikrotjenester. En meldingskø. Et oppsett med flere regioner. Å sharde databasen før den har en million rader.

Slik bruker du seks måneder og en formue på å bygge infrastruktur for en skala du ikke har nådd, mens selve produktet slutter å bevege seg. Verre, du har nå gjort hver fremtidig endring vanskeligere, fordi et distribuert system er dramatisk mer komplekst å bygge og feilsøke enn det enkle du hadde. Du byttet et problem du ikke hadde ennå, mot et garantert ett du har i dag: ingenting blir sendt ut.

Disiplinen her er den samme som lager gode produkter i utgangspunktet: løs problemet foran deg, ikke det du smigres av å forestille deg. En kjedelig, velforstått monolitt du kan endre raskt, vil overskaleere et moteriktig distribuert system du er redd for å røre. Kompleksitet er en kostnad du betaler hver eneste dag, ikke et engangskjøp.

Mål før du endrer noe

Nesten hver gründer vi møter på dette stadiet, er overbevist om at de vet hvor problemet er. De tar feil omtrent halvparten av tiden — ikke fordi de er skjødesløse, men fordi intuisjon er en elendig profiler. Den delen av koden som føles treg, er ofte grei; den virkelige synderen er en eller annen stille spørring som kjører førti ganger på en side ingen tenkte på. Du kan ikke fikse det du ikke har målt, og å gjette her er hvordan team bruker uker på å optimalisere feil ting.

Du trenger ikke en fancy observerbarhetsstabel for å begynne. Du trenger tre kjedelige tall foran deg, hele tiden. Hvilke endepunkter er tregest, og hvor trege under reell trafikk. Hvilke databasespørringer tar mest total tid — ikke den tregeste enkeltspørringen, men den hvis tid legger seg sammen over tusenvis av kall. Og hvor feil faktisk skjer, med nok kontekst til å gjenskape dem. Med de tre letter tåken som regel innen en dag.

1. 1
   Slå på grunnleggende overvåking

   Responstider per endepunkt, feilrater og logging av trege spørringer på databasen. Skytjenester gjør dette på en ettermiddag. Du kan ikke forbedre et tall du ikke ser.
2. 2
   Finn de virkelige tre på topp

   Sorter etter total forbrukt tid, ikke magefølelse. Tre syndere står nesten alltid for det meste av smerten. Skriv dem ned — det er ditt egentlige veikart.
3. 3
   Fiks én, mål igjen

   Endre én eneste ting, sjekk så tallene på nytt. Bekreft at det hjalp før du går videre. To endringer på én gang, og du vil aldri vite hvilken som betydde noe.
4. 4
   Stopp når det er godt nok

   Definer 'raskt nok' før du begynner — si, hver side under et sekund ved nåværende belastning. Utover det er optimalisering en tidstyv, ikke en seier.

Det siste steget betyr mer enn det ser ut til. Ytelsesarbeid er genuint avhengighetsskapende; det er alltid enda et millisekund å barbere av. Men kundene dine kjenner ikke forskjellen mellom 200 ms og 120 ms, og timene du bruker på å jage det, er timer du ikke bruker på funksjonen som faktisk ville fått forretningen til å vokse. Mål, fiks de tre på topp, erklær seier, gå videre.

Databasen er nesten alltid den første veggen

Hvis vi måtte vedde penger på hvor en voksende SaaS treffer sitt første reelle tak, ville vi veddet på databasen hver gang. Det er den ene delen av systemet der små tidlige beslutninger hoper seg opp hardest. En spørring uten indeks kjører på et blunk på tusen rader og stopper opp på en million. Koden endret seg ikke. Dataene gjorde det — og data vokser bare.

Den gode nyheten er at databasen også er der de billigste, mest virkningsfulle fiksene bor. Den klassiske er den manglende indeksen: en enkelt linje som forvandler en flersekunders spørring til en umiddelbar, fordi databasen slutter å skanne hver rad for å finne de få den trenger. Rett bak den er N+1-spørringsproblemet — en side som, i stedet for å stille ett spørsmål, stille stiller databasen det samme lille spørsmålet hundrevis av ganger i en løkke. Begge er vanlige, begge er usynlige helt til du ser etter, og begge er som regel en endags-fiks når du først har funnet dem.

Det finnes en rekkefølge å lene seg på her, og det lønner seg å følge den i orden i stedet for å hoppe til slutten. Fiks spørringene først — indekser, N+1-er, den trege rapporten. Legg så til hurtigbufring for data som leses konstant, men endres sjelden. Først deretter gir det mening å snakke om lesereplikaer, større instanser eller å dele ut data. De fleste SaaS-produkter trenger aldri de senere stegene. De trengte bare at de første ble gjort skikkelig.

Å skalere produktet betyr å skalere hvordan du endrer det

Her er skiftet som tar gründere på senga: utover et visst punkt slutter skalering å handle om at produktet håndterer flere brukere, og begynner å handle om at teamet ditt håndterer mer endring. Da det var deg og én utvikler, holdt alle hele systemet i hodet. Du kunne endre hva som helst fordi du visste hva det ville berøre. Ved fem eller ti personer knuses den mentale modellen — og koden som antok at alle visste alt, blir en byrde.

Dette er den virkelige grunnen til at utrullinger blir skumle. Det er ikke at koden ble verre over natten; det er at ingen lenger fullt ut kan forutsi sprengradiusen til en endring. Løsningen er ikke heltedåd eller en stopp for utsendelser. Det er å investere i det uglamorøse stillaset som lar et større team bevege seg uten å trå hverandre på tærne: en automatisert testpakke som fanger de åpenbare havariene, utrullinger som er rutine i stedet for seremonielle, og en måte å skru av en dårlig utgivelse på sekunder i stedet for å famle i panikk.

• En testpakke som dekker de få flytene som ville vært katastrofale om de gikk i stykker — innlogging, betaling, kjernehandling. Ikke alt; de kritiske få.
• Utrullinger som kjører på en knapp, ikke et ritual, så det å sende ut smått og ofte blir trygt i stedet for nervepirrende.
• En rask måte å rulle tilbake, så en dårlig utgivelse er en femminutters-hendelse, ikke en hele-natten-hendelse.
• Funksjonsflagg, så du kan sende kode ut til noen få kunder først og skru den av umiddelbart om den oppfører seg dårlig.
• Nok dokumentasjon til at én persons ferie ikke fryser et helt område av produktet.

Ingenting av dette dukker opp i en demo. Ingenting av det legger direkte til en funksjon. Og det er nøyaktig det arbeidet som skiller et produkt som fortsetter å akselerere fra ett som maler tregere for hver nye ansettelse. Teamene som skalerer godt, er de som behandler evnen sin til å endre produktet trygt som en funksjon i seg selv — for i skala er det nøyaktig hva det er.

En kort historie fra bristepunktet

For å gjøre det konkret, her er et sammensatt tilfelle hentet fra arbeid vi har gjort — detaljene utvisket, formen tro mot virkeligheten. En liten SaaS for å styre feltserviceteam hadde lansert godt og vokst til noen få hundre betalende selskaper. Gründerne var like deler begeistret og utslitt. Så signerte deres største kunde noensinne: et firma med flere brukere og mer historisk data enn de forrige ti klientene til sammen.

I løpet av en uke hadde dashbordet som alle levde i, bremset ned til en kryping for den kunden — og, merkelig nok, for alle andre også. Supportsaker skjøt i været. Gründerne antok at de trengte en langt større server og vapnet seg til en smertefull, dyr omarkitektur. Det var øyeblikket vi ble hentet inn, og instinktet var forståelig, men feil.

Vi rørte ikke arkitekturen. Vi slo på logging av trege spørringer og fulgte med en ettermiddag. Synderen var nesten pinlig liten: hoveddashbordet lastet hver brukers oppgaveliste med et klassisk N+1-mønster og avfyrte én spørring per oppgave. For en liten kunde betydde det noen titalls harmløse spørringer. For den nye giganten betydde det tusenvis per sidelasting — noe som, på delt infrastruktur, dro hele systemet ned for alle.

Lærdommen gründerne tok med seg, var ikke teknisk. Den var at det skremmende skaleringsproblemet de hadde forestilt seg — det som krevde en ombygging og en finansieringsrunde — var, da det ble målt, en todagers-fiks som gjemte seg bak et skummelt symptom. De hadde vært på nippet til å bruke måneder på å løse feil problem. Det gapet, mellom den innbilte krisen og den målte, er der mesteparten av skaleringspengene sløses bort.

Når det virkelig er tid for å bygge om en del

All denne forsiktigheten rundt for tidlig skalering kan leses som refaktorer aldri, bygg aldri om. Slik er det ikke. Noen ganger har en del av produktet genuint nådd slutten av levetiden sin, og å lappe den igjen er det dyre valget. Trikset er å skille en virkelig strukturell grense fra vanlige vekstsmerter som en målt fiks ville håndtert.

Det ærlige signalet er dette: bygg om en komponent når kostnaden ved å endre den konsekvent har blitt høyere enn kostnaden ved å erstatte den. Ikke når den er stygg — stygg kode som er stabil og sjelden rørt, er grei. Du ser etter en del av systemet der hver endring er treg og risikabel, der de samme feilene stadig kommer tilbake, der nye utviklere ikke kan jobbe trygt, og der du allerede har prøvd de billigere fiksene og truffet en vegg. Når flere av disse er sanne samtidig, er en fokusert omskriving av akkurat den ene delen det riktige valget.

Og når du bygger om, bygg om en del — ikke produktet. Den fulle omskrivingen fra bunnen er skaleringens sirenesang, det som føles rent og ender med å senke et år mens konkurrentene sender ut. Erstatt den ene råtne komponenten, bak en klar grense, mens resten av produktet fortsetter å kjøre og tjene. Kirurgisk, ikke heroisk.

Vanlige spørsmål