At skalere en SaaS efter lanceringen uden at ødelægge produktet

Alle fejrer lanceringen. Næsten ingen advarer dig om den del, der kommer efter — det mærkelige, nervepirrende år, hvor produktet, der gav dig dine første hundrede kunder, begynder at give efter under vægten af de næste tusind. Intet dramatisk sker. Tingene bliver bare langsommere, mere ustabile, sværere at ændre. En tirsdag indser du, at en funktion, der før tog en dag, nu tager en uge, og ingen kan rigtig sige hvorfor. Det er der, ikke ved lanceringen, at de fleste SaaS-produkter stille vindes eller tabes.

Vi har siddet med en masse stiftere lige ved dette punkt. De er ikke ved at fejle — det er det forvirrende. Omsætningen stiger, teamet vokser, demoerne går godt. Men under overfladen stønner produktet. Supportsager stiger hurtigere end brugerne. Udrulninger, der før var kedelige, kommer nu med tilbageholdt åndedræt. Kodebasen, der føltes smart for et år siden, føles nu som en minemark, hvor hver ændring risikerer at udløse noget andet. De gjorde ikke noget forkert. De voksede bare fra det, de byggede, og ingen fortalte dem, at det var meningen, det skulle ske.

Så dette er den guide, vi ville ønske, flere stiftere havde haft, før revnerne dukkede op. Den handler ikke om hyperskala, Kubernetes eller hvad en enhjørning gjorde ved halvtreds millioner brugere. Den handler om den kedelige, afgørende midte — at gå fra det virker for nogle få til det virker for mange — uden at omskrive alt, skræmme dine kunder væk eller udbrænde dit team. Målet er ikke en perfekt arkitektur. Det er et produkt, der bliver ved med at vokse i stedet for et, der stille begynder at gå i stykker.

Hvad der faktisk går i stykker, når en SaaS vokser

Her er den del, der overrasker stiftere mest: skaleringsproblemer ankommer næsten aldrig som det dramatiske nedbrud, du vapner dig imod. Serveren går ikke op i flammer. I stedet udvikler produktet en slags lavgradsfeber. Sider, der indlæstes øjeblikkeligt, begynder at tage tre sekunder. En rapport, der kørte fint for tidlige kunder, timer ud for den store, der lige har skrevet under. Den samme fejl dukker op igen og igen, fordi to dele af koden i hemmelighed afhænger af hinanden på en måde, ingen dokumenterede.

Det, der virkelig brister, er sjældent dine servere — det er dine antagelser. Tidligt byggede du til formen på dine første brugere: nogle få konti, lidt data, enkle arbejdsgange, alle nogenlunde ens. Vækst tilføjer ikke bare mere af det samme. Den tilføjer variation. En kunde med ti gange så meget data. Et team, der bruger en funktion på en måde, du aldrig forestillede dig. Et spids klokken ni mandag morgen, når alle logger ind på én gang. Hver af dem bryder stille en antagelse, der blev bagt ind i din kode for et år siden, da det at bryde den var utænkeligt.

De fire steder, hvor det har tendens til at vise sig først, er forudsigelige. Databasen er næsten altid kanariefuglen — forespørgsler, der var øjeblikkelige på små tabeller, kravler, efterhånden som dataene vokser. Det langsomme endpoint: en eller to sider, der laver for meget arbejde pr. forespørgsel, hvilket er fint, indtil trafikken hober sig op. Den skrøbelige udrulning, hvor det at sende noget som helst ud er blevet skræmmende, fordi koden er for sammenfiltret til at overskue. Og supportbelastningen, som slet ikke er infrastruktur, men er det sandeste tidlige signal om, at produktet ikke længere passer til, hvordan folk faktisk bruger det.

Fælden ved at løse problemer, du ikke har endnu

Før vi taler om at rette ting, en advarsel, der har reddet flere produkter end nogen optimering. Den største trussel mod en voksende SaaS er ikke at ignorere skala — det er at jage den for tidligt. I det øjeblik en stifter mærker den første opbremsning, er instinktet at gribe efter den arkitektur, de læste om på en berømt ingeniørblog. Mikrotjenester. En beskedkø. En multiregion-opsætning. At sharde databasen, før den har en million rækker.

Sådan bruger du seks måneder og en formue på at bygge infrastruktur til en skala, du ikke har nået, mens selve produktet holder op med at bevæge sig. Værre, du har nu gjort hver fremtidig ændring sværere, fordi et distribueret system er dramatisk mere komplekst at bygge og fejlfinde end det enkle, du havde. Du byttede et problem, du ikke havde endnu, for et garanteret et, du har i dag: intet bliver sendt ud.

Disciplinen her er den samme, som skaber gode produkter i første omgang: løs problemet foran dig, ikke det, du smigres af at forestille dig. En kedelig, velforstået monolit, du kan ændre hurtigt, vil overskale et moderigtigt distribueret system, du er bange for at røre. Kompleksitet er en omkostning, du betaler hver eneste dag, ikke et engangskøb.

Mål, før du ændrer noget

Næsten hver stifter, vi møder på dette stadie, er overbevist om, at de ved, hvor problemet er. De tager fejl omkring halvdelen af tiden — ikke fordi de er skødesløse, men fordi intuition er en elendig profiler. Den del af koden, der føles langsom, er ofte fin; den virkelige synder er en eller anden stille forespørgsel, der kører fyrre gange på en side, ingen tænkte på. Du kan ikke rette det, du ikke har målt, og at gætte her er, hvordan teams bruger uger på at optimere den forkerte ting.

Du behøver ikke en fancy observerbarhedsstak for at starte. Du behøver tre kedelige tal foran dig, hele tiden. Hvilke endpoints er langsomst, og hvor langsomme under reel trafik. Hvilke databaseforespørgsler tager mest samlet tid — ikke den langsomste enkelte forespørgsel, men den, hvis tid lægger sig sammen over tusindvis af kald. Og hvor fejl faktisk sker, med nok kontekst til at gengive dem. Med de tre letter tågen som regel inden for en dag.

1. 1
   Slå grundlæggende overvågning til

   Svartider pr. endpoint, fejlrater og logning af langsomme forespørgsler på databasen. Hostede værktøjer gør dette på en eftermiddag. Du kan ikke forbedre et tal, du ikke kan se.
2. 2
   Find de virkelige top tre

   Sortér efter samlet forbrugt tid, ikke mavefornemmelse. Tre syndere står næsten altid for det meste af smerten. Skriv dem ned — det er din egentlige køreplan.
3. 3
   Ret en, mål igen

   Ændr én enkelt ting, tjek så tallene igen. Bekræft, at det hjalp, før du går videre. To ændringer på én gang, og du vil aldrig vide, hvilken der betød noget.
4. 4
   Stop, når det er godt nok

   Definér 'hurtigt nok', før du starter — sig, hver side under et sekund ved nuværende belastning. Ud over det er optimering et tidsslug, ikke en sejr.

Det sidste trin betyder mere, end det ser ud til. Ydeevnearbejde er ægte vanedannende; der er altid endnu et millisekund at barbere af. Men dine kunder mærker ikke forskellen mellem 200 ms og 120 ms, og timerne, du bruger på at jage det, er timer, du ikke bruger på funktionen, der faktisk ville få forretningen til at vokse. Mål, ret de top tre, erklær sejr, gå videre.

Databasen er næsten altid den første mur

Hvis vi skulle vædde penge om, hvor en voksende SaaS rammer sit første rigtige loft, ville vi vædde på databasen hver gang. Det er den ene del af systemet, hvor små tidlige beslutninger ophober sig hårdest. En forespørgsel uden indeks kører på et øjeblik på tusind rækker og går i stå på en million. Koden ændrede sig ikke. Dataene gjorde — og data vokser kun.

Den gode nyhed er, at databasen også er der, hvor de billigste, mest virkningsfulde rettelser bor. Den klassiske er det manglende indeks: en enkelt linje, der forvandler en flersekunders forespørgsel til en øjeblikkelig, fordi databasen holder op med at scanne hver række for at finde de få, den har brug for. Lige bag den er N+1-forespørgselsproblemet — en side, der i stedet for at stille ét spørgsmål stille stiller databasen det samme lille spørgsmål hundredvis af gange i en løkke. Begge er almindelige, begge er usynlige, indtil du kigger, og begge er som regel en endags-rettelse, når du først har fundet dem.

Der er en rækkefølge at læne sig op ad her, og det betaler sig at følge den i orden i stedet for at springe til slutningen. Ret forespørgslerne først — indekser, N+1'ere, den langsomme rapport. Tilføj så caching for de data, der læses konstant, men ændres sjældent. Først derefter giver det mening at tale om læsereplikaer, større instanser eller at opdele data. De fleste SaaS-produkter får aldrig brug for de senere trin. De havde bare brug for, at de første blev gjort ordentligt.

At skalere produktet betyder at skalere, hvordan du ændrer det

Her er skiftet, der overrumpler stiftere: ud over et bestemt punkt holder skalering op med at handle om, at produktet håndterer flere brugere, og begynder at handle om, at dit team håndterer mere forandring. Da det var dig og én udvikler, holdt alle hele systemet i hovedet. Du kunne ændre hvad som helst, fordi du vidste, hvad det ville berøre. Ved fem eller ti personer knuses den mentale model — og koden, der antog, at alle vidste alt, bliver en byrde.

Dette er den virkelige grund til, at udrulninger bliver skræmmende. Det er ikke, at koden blev værre i løbet af en nat; det er, at ingen længere fuldt ud kan forudsige sprængradiussen af en ændring. Løsningen er ikke heltemod eller et stop for udsendelser. Det er at investere i det uglamourøse stillads, der lader et større team bevæge sig uden at træde hinanden over tæerne: en automatiseret testsuite, der fanger de åbenlyse nedbrud, udrulninger, der er rutine i stedet for ceremonielle, og en måde at slukke en dårlig udgivelse på sekunder i stedet for at famle i panik.

• En testsuite, der dækker de få flows, der ville være katastrofale, hvis de gik i stykker — login, betaling, kernehandling. Ikke alt; de kritiske få.
• Udrulninger, der kører på en knap, ikke et ritual, så det at sende småt og ofte ud bliver sikkert i stedet for nervepirrende.
• En hurtig måde at rulle tilbage, så en dårlig udgivelse er en femminutters-begivenhed, ikke en hele-natten-hændelse.
• Feature flags, så du kan sende kode ud til nogle få kunder først og slukke for den øjeblikkeligt, hvis den opfører sig dårligt.
• Nok dokumentation til, at én persons ferie ikke fryser et helt område af produktet.

Intet af dette dukker op i en demo. Intet af det tilføjer direkte en funktion. Og det er præcis det arbejde, der adskiller et produkt, der bliver ved med at accelerere, fra et, der maler langsommere med hver ny ansættelse. De teams, der skalerer godt, er dem, der behandler deres evne til at ændre produktet sikkert som en funktion i sig selv — for ved skala er det præcis, hvad det er.

En kort historie fra bristepunktet

For at gøre det konkret, her er et sammensat tilfælde hentet fra arbejde, vi har lavet — detaljerne udvisket, formen tro mod virkeligheden. En lille SaaS til at styre feltserviceteams var lanceret godt og vokset til nogle få hundrede betalende virksomheder. Stifterne var lige dele begejstrede og udmattede. Så skrev deres største kunde nogensinde under: et firma med flere brugere og mere historisk data end deres forrige ti klienter tilsammen.

Inden for en uge var dashboardet, som alle levede i, sænket til en kravlen for den kunde — og, mærkeligt nok, for alle andre også. Supportsager steg eksplosivt. Stifterne antog, at de havde brug for en langt større server og vapnede sig til en smertefuld, dyr genarkitektur. Det var det øjeblik, vi blev hentet ind, og instinktet var forståeligt, men forkert.

Vi rørte ikke arkitekturen. Vi slog logning af langsomme forespørgsler til og holdt øje en eftermiddag. Synderen var næsten pinligt lille: hoveddashboardet indlæste hver brugers opgaveliste med et klassisk N+1-mønster og affyrede én forespørgsel pr. opgave. For en lille kunde betød det nogle få dusin harmløse forespørgsler. For den nye kæmpe betød det tusindvis pr. sideindlæsning — hvilket, på delt infrastruktur, trak hele systemet ned for alle.

Lærdommen, stifterne tog med sig, var ikke teknisk. Det var, at det skræmmende skaleringsproblem, de havde forestillet sig — det, der krævede en genopbygning og en finansieringsrunde — var, da det blev målt, en todages-rettelse, der gemte sig bag et skræmmende symptom. De havde været på nippet til at bruge måneder på at løse det forkerte problem. Det gab, mellem den indbildte krise og den målte, er der, hvor det meste af skaleringspengene spildes.

Hvornår det virkelig er tid til at genopbygge en del

Al denne forsigtighed omkring for tidlig skalering kan læses som refaktorér aldrig, genopbyg aldrig. Sådan er det ikke. Nogle gange har en del af produktet ægte nået enden af sin levetid, og at lappe den igen er det dyre valg. Tricket er at skelne en virkelig strukturel grænse fra almindelige vækstsmerter, som en målt rettelse ville håndtere.

Det ærlige signal er dette: genopbyg en komponent, når omkostningen ved at ændre den konsekvent er blevet højere end omkostningen ved at erstatte den. Ikke når den er grim — grim kode, der er stabil og sjældent rørt, er fin. Du leder efter en del af systemet, hvor hver ændring er langsom og risikabel, hvor de samme fejl bliver ved med at vende tilbage, hvor nye udviklere ikke kan arbejde sikkert, og hvor du allerede har prøvet de billigere rettelser og ramt en mur. Når flere af disse er sande på én gang, er en fokuseret omskrivning af netop den ene del det rigtige valg.

Og når du genopbygger, så genopbyg en del — ikke produktet. Den fulde omskrivning fra bunden er skaleringens sirenesang, det der føles rent og ender med at sænke et år, mens konkurrenterne sender ud. Erstat den ene rådne komponent, bag en klar grænse, mens resten af produktet bliver ved med at køre og tjene. Kirurgisk, ikke heroisk.

Almindelige spørgsmål