Een SaaS opschalen na de lancering zonder het product te slopen

Iedereen viert de lancering. Bijna niemand waarschuwt u voor het deel dat erna komt — het vreemde, zenuwslopende jaar waarin het product dat u uw eerste honderd klanten bezorgde begint te bezwijken onder het gewicht van de volgende duizend. Er gebeurt niets dramatisch. Dingen worden gewoon trager, wankeler, lastiger te veranderen. Op een dinsdag beseft u dat een functie die vroeger een dag kostte nu een week kost, en niemand kan precies zeggen waarom. Dat, niet de lancering, is waar de meeste SaaS-producten stilletjes gewonnen of verloren worden.

We hebben met veel oprichters precies op dit punt gezeten. Ze falen niet — dat is het verwarrende. De omzet stijgt, het team groeit, de demo's gaan goed. Maar onderhuids kreunt het product. Supporttickets stijgen sneller dan het aantal gebruikers. Deploys die vroeger saai waren gaan nu met ingehouden adem. De codebase die een jaar geleden slim aanvoelde, voelt nu als een mijnenveld waar elke wijziging iets anders kan laten afgaan. Ze hebben niets fout gedaan. Ze zijn gewoon ontgroeid wat ze gebouwd hadden, en niemand heeft hen verteld dat dat zo hoorde te gaan.

Dus dit is de gids die we meer oprichters toewensen voordat de scheuren verschijnen. Het gaat niet over hyperschaal, Kubernetes, of wat een eenhoorn deed bij vijftig miljoen gebruikers. Het gaat over het saaie, beslissende midden — de overgang van het werkt voor enkelen naar het werkt voor velen — zonder alles te herschrijven, uw klanten af te schrikken of uw team op te branden. Het doel is geen perfecte architectuur. Het is een product dat blijft groeien in plaats van een dat stilletjes begint te breken.

Wat er echt breekt wanneer een SaaS groeit

Dit is het deel dat oprichters het meest verrast: schaalproblemen komen bijna nooit als de dramatische storing waarop u zich schrap zet. De server vliegt niet in brand. In plaats daarvan ontwikkelt het product een soort sluimerende koorts. Pagina's die direct laadden duren plots drie seconden. Een rapport dat prima draaide voor vroege klanten loopt vast voor de grote die net tekende. Dezelfde bug blijft terugkomen omdat twee delen van de code stiekem van elkaar afhangen op een manier die niemand documenteerde.

Wat er echt breekt zijn zelden uw servers — het zijn uw aannames. In het begin bouwde u voor de vorm van uw eerste gebruikers: een paar accounts, weinig data, eenvoudige workflows, iedereen ongeveer hetzelfde. Groei voegt niet alleen meer van hetzelfde toe. Het voegt variatie toe. Een klant met tien keer zoveel data. Een team dat een functie gebruikt op een manier die u nooit had bedacht. Een piek om 9 uur maandag wanneer iedereen tegelijk inlogt. Elk daarvan schendt stilletjes een aanname die een jaar geleden in uw code is ingebakken, toen schending ervan ondenkbaar was.

De vier plekken waar het meestal eerst opduikt zijn voorspelbaar. De database is bijna altijd de kanarie — queries die direct waren op kleine tabellen kruipen naarmate de data groeit. Het trage endpoint: een of twee pagina's die per verzoek te veel werk doen, prima tot het verkeer zich opstapelt. De broze deploy, waar iets uitbrengen eng is geworden omdat de code te verstrengeld is om te overzien. En de supportlast, die helemaal geen infrastructuur is maar het zuiverste vroege signaal dat het product niet meer past bij hoe mensen het echt gebruiken.

De valkuil van problemen oplossen die u nog niet heeft

Voor we het over reparaties hebben, een waarschuwing die meer producten heeft gered dan welke optimalisatie ook. De grootste bedreiging voor een groeiende SaaS is niet schaal negeren — het is er te vroeg op jagen. Het moment dat een oprichter de eerste vertraging voelt, is de neiging om te grijpen naar de architectuur waarover hij las op een beroemde engineeringblog. Microservices. Een message queue. Een multi-regio-opzet. De database sharden voordat die een miljoen rijen heeft.

Zo besteedt u zes maanden en een fortuin aan infrastructuur voor een schaal die u nog niet heeft bereikt, terwijl het eigenlijke product stilstaat. Erger nog, u heeft nu elke toekomstige wijziging moeilijker gemaakt, want een gedistribueerd systeem is dramatisch complexer om te bouwen en te debuggen dan het eenvoudige dat u had. U ruilde een probleem dat u nog niet had in voor een gegarandeerd probleem dat u vandaag heeft: er wordt niets uitgebracht.

De discipline hier is dezelfde die in de eerste plaats goede producten maakt: los het probleem op dat voor u ligt, niet dat wat u zich gevleid voorstelt. Een saaie, goed begrepen monoliet die u snel kunt veranderen schaalt beter dan een modieus gedistribueerd systeem dat u niet durft aan te raken. Complexiteit is een kost die u elke dag betaalt, geen eenmalige aankoop.

Meet voordat u iets verandert

Bijna elke oprichter die we in deze fase ontmoeten is ervan overtuigd te weten waar het probleem zit. De helft van de tijd heeft hij het mis — niet uit onzorgvuldigheid, maar omdat intuïtie een verschrikkelijke profiler is. Het deel van de code dat traag aanvoelt is vaak prima; de echte boosdoener is een of andere stille query die veertig keer draait op een pagina waar niemand bij stilstond. U kunt niet repareren wat u niet heeft gemeten, en gokken is hoe teams weken besteden aan het verkeerde optimaliseren.

U heeft geen chique observability-stack nodig om te beginnen. U heeft drie saaie cijfers nodig, altijd voor u. Welke endpoints zijn het traagst, en hoe traag onder echt verkeer. Welke databasequeries kosten de meeste totale tijd — niet de traagste enkele query, maar die waarvan de tijd zich optelt over duizenden aanroepen. En waar fouten echt gebeuren, met genoeg context om ze te reproduceren. Met die drie klaart de mist meestal binnen een dag op.

1. 1
   Zet basismonitoring aan

   Responstijden per endpoint, foutpercentages en slow-query-logging op de database. Hosted tools doen dit in een namiddag. U kunt geen cijfer verbeteren dat u niet ziet.
2. 2
   Vind de echte top drie

   Sorteer op totaal verbruikte tijd, niet op buikgevoel. Drie boosdoeners zijn bijna altijd goed voor de meeste pijn. Schrijf ze op — dat is uw echte roadmap.
3. 3
   Repareer er één, meet opnieuw

   Verander één ding, controleer dan de cijfers opnieuw. Bevestig dat het hielp voordat u verdergaat. Twee wijzigingen tegelijk en u weet nooit welke ertoe deed.
4. 4
   Stop wanneer het goed genoeg is

   Definieer 'snel genoeg' voordat u begint — bijvoorbeeld elke pagina onder een seconde bij de huidige belasting. Daarna is optimaliseren een tijdverslinder, geen winst.

Die laatste stap doet er meer toe dan hij lijkt. Prestatiewerk is oprecht verslavend; er is altijd nog een milliseconde af te schaven. Maar uw klanten voelen het verschil niet tussen 200 ms en 120 ms, en de uren die u eraan jaagt zijn uren die niet naar de functie gaan die het bedrijf werkelijk zou laten groeien. Meet, repareer de top drie, roep de overwinning uit, ga verder.

De database is bijna altijd de eerste muur

Als we geld zouden moeten inzetten op waar een groeiende SaaS zijn eerste echte plafond raakt, zouden we elke keer op de database wedden. Het is het ene deel van het systeem waar kleine vroege beslissingen het hardst opstapelen. Een query zonder index draait in een oogwenk op duizend rijen en loopt vast op een miljoen. De code veranderde niet. De data wel — en data groeit alleen maar.

Het goede nieuws is dat de database ook is waar de goedkoopste reparaties met de grootste impact zitten. De klassieke is de ontbrekende index: een enkele regel die een query van meerdere seconden in een direct resultaat verandert, omdat de database stopt met elke rij te scannen om de paar te vinden die hij nodig heeft. Vlak daarachter zit het N+1-queryprobleem — een pagina die, in plaats van één vraag te stellen, stilletjes dezelfde kleine vraag honderden keren in een lus aan de database stelt. Beide komen vaak voor, beide zijn onzichtbaar tot u kijkt, en beide zijn meestal een reparatie van een dag zodra u ze heeft gevonden.

Er is hier een volgorde om op te leunen, en het loont om die op volgorde te volgen in plaats van naar het einde te springen. Repareer eerst de queries — indexen, N+1's, het trage rapport. Voeg dan caching toe voor de data die constant gelezen wordt maar zelden verandert. Pas daarna heeft het zin om over read replica's, grotere instances of het uitsplitsen van data te praten. De meeste SaaS-producten hebben de latere stappen nooit nodig. Ze hadden alleen de eerste goed gedaan nodig.

Het product opschalen betekent opschalen hoe u het verandert

Dit is de verschuiving die oprichters overvalt: voorbij een bepaald punt gaat opschalen niet meer over het product dat meer gebruikers aankan en begint het over uw team dat meer verandering aankan. Toen het u en één ontwikkelaar was, had iedereen het hele systeem in zijn hoofd. U kon alles veranderen omdat u wist wat het zou raken. Bij vijf of tien mensen versplintert dat mentale model — en de code die ervan uitging dat iedereen alles wist wordt een last.

Dit is de echte reden waarom deploys eng worden. Het is niet dat de code van de ene op de andere dag slechter werd; het is dat niemand de blast radius van een wijziging nog volledig kan voorspellen. De oplossing is geen heldendaden of een releasestop. Het is investeren in de roemloze stellage die een groter team laat bewegen zonder elkaar voor de voeten te lopen: een geautomatiseerde testsuite die de voor de hand liggende breuk opvangt, deploys die routine zijn in plaats van ceremonieel, en een manier om een slechte release in seconden uit te zetten in plaats van te improviseren.

• Een testsuite die de handvol flows dekt die catastrofaal zouden zijn als ze braken — login, betaling, kernactie. Niet alles; de kritieke paar.
• Deploys die op een knop draaien, geen ritueel, zodat klein en vaak uitbrengen veilig wordt in plaats van zenuwslopend.
• Een snelle manier om terug te rollen, zodat een slechte release een gebeurtenis van vijf minuten is, geen incident dat de hele nacht duurt.
• Feature flags, zodat u code eerst naar enkele klanten kunt uitbrengen en direct kunt uitzetten als die zich misdraagt.
• Genoeg documentatie zodat de vakantie van één persoon niet een heel gebied van het product bevriest.

Niets hiervan komt in een demo terug. Niets ervan voegt direct een functie toe. En het is precies het werk dat een product dat blijft versnellen scheidt van een dat met elke nieuwe aanwerving trager maalt. De teams die goed opschalen zijn de teams die hun vermogen om het product veilig te veranderen als een functie op zich behandelen — want bij schaal is dat precies wat het is.

Een kort verhaal van het breekpunt

Om dit concreet te maken, hier een samenstelling op basis van werk dat we deden — details vervaagd, de vorm waarheidsgetrouw. Een kleine SaaS voor het beheren van buitendienstteams was goed gelanceerd en gegroeid tot een paar honderd betalende bedrijven. De oprichters waren in gelijke mate dolblij en uitgeput. Toen tekende hun grootste klant ooit: een firma met meer gebruikers en meer historische data dan hun vorige tien klanten samen.

Binnen een week was het dashboard waarin iedereen leefde tot een slakkengang vertraagd voor die klant — en, vreemd genoeg, ook voor iedereen anders. Supporttickets schoten omhoog. De oprichters gingen ervan uit dat ze een veel grotere server nodig hadden en zetten zich schrap voor een pijnlijke, dure herarchitectuur. Dat was het moment waarop wij erbij werden gehaald, en de neiging was begrijpelijk maar verkeerd.

We raakten de architectuur niet aan. We zetten slow-query-logging aan en keken een namiddag mee. De boosdoener was bijna gênant klein: het hoofddashboard laadde de takenlijst van elke gebruiker met een klassiek N+1-patroon, één query per taak afvurend. Voor een kleine klant betekende dat een paar dozijn onschuldige queries. Voor de nieuwe reus betekende het duizenden per pagina-load — wat, op gedeelde infrastructuur, het hele systeem voor iedereen omlaag trok.

De les die de oprichters meenamen was niet technisch. Het was dat het angstaanjagende schaalprobleem dat ze zich hadden voorgesteld — dat een herbouw en een kapitaalronde nodig had — bij meting een reparatie van twee dagen was die zich verschuilde achter een eng symptoom. Ze stonden op het punt maanden te besteden aan het verkeerde probleem oplossen. Die kloof, tussen de denkbeeldige crisis en de gemeten, is waar het meeste schaalgeld wordt verspild.

Wanneer het echt tijd is om een stuk te herbouwen

Al deze voorzichtigheid over voortijdig opschalen kan klinken als nooit refactoren, nooit herbouwen. Dat is het niet. Soms heeft een deel van het product werkelijk het einde van zijn leven bereikt, en is het opnieuw oplappen de dure keuze. De truc is het verschil zien tussen een echte structurele limiet en gewone groeipijnen die een gemeten reparatie zou aanpakken.

Het eerlijke signaal is dit: herbouw een component wanneer de kost van veranderen consistent hoger is geworden dan de kost van vervangen. Niet wanneer het lelijk is — lelijke code die stabiel is en zelden wordt aangeraakt is prima. U zoekt een deel van het systeem waar elke wijziging traag en riskant is, waar dezelfde bugs blijven terugkomen, waar nieuwe ontwikkelaars niet veilig kunnen werken, en waar u de goedkopere reparaties al heeft geprobeerd en op een muur stuitte. Wanneer meerdere daarvan tegelijk waar zijn, is een gerichte herschrijving van dat ene stuk de juiste keuze.

En als u herbouwt, herbouw dan een stuk — niet het product. De volledige herschrijving vanaf nul is de sirenenzang van opschalen, het ding dat schoon aanvoelt en uiteindelijk een jaar verzuipt terwijl concurrenten uitbrengen. Vervang de ene verrotte component, achter een duidelijke grens, terwijl de rest van het product blijft draaien en verdienen. Chirurgisch, niet heroïsch.

Veelgestelde vragen