Een webapplicatie die vandaag soepel draait, zegt weinig over volgend jaar. Groei kondigt zich zelden aan: een grote nieuwe klant, een campagne die aanslaat, een koppeling die het dataverkeer verdubbelt. Of je applicatie dat aankan, is op dat moment al lang beslist - door keuzes die je leverancier aan het begin van het traject maakte.
Die keuzes hoef je niet zelf te kunnen maken. Je moet wel kunnen toetsen of ze gemaakt zijn. Daarvoor is dit kader bedoeld: de vragen die je stelt, de antwoorden die vertrouwen geven en de signalen die op risico wijzen.
Schaalbaarheid wordt aan het begin beslist
Hoe duur groei later wordt, ligt vast in de architectuur: de manier waarop een applicatie is opgedeeld en hoe die delen samenwerken. Een applicatie die netjes is opgebouwd, groeit mee zonder dat alles opnieuw ontwikkeld hoeft te worden. In een applicatie waar alles met alles verweven is, betekent elke groeispurt verbouwen terwijl het verkeer doorloopt.
Meer techniek is daarbij niet automatisch beter. Microservices, waarbij een systeem wordt opgeknipt in losse diensten die apart kunnen schalen, klinken indrukwekkend, maar de beheerlast die ze meebrengen verdient zich pas bij flinke omvang terug. Voor de meeste organisaties is een goed gestructureerde applicatie in één geheel de verstandiger start; in ons artikel over microservices leggen we die afweging verder uit. Wantrouw dus zowel de leverancier die nooit over groei begint als de leverancier die meteen het zwaarste geschut voorstelt.
De vragen die het gesprek scherp maken
Je hebt geen technische achtergrond nodig om dit gesprek te voeren. Deze vragen dwingen concrete antwoorden af:
- Wat moet er aan het systeem veranderen als het aantal gebruikers vertienvoudigt?
- Waar zit het eerste knelpunt, en waar blijkt dat uit?
- Hoe testen jullie de belasting voordat de applicatie live gaat?
- Wat meten jullie zodra de applicatie draait, en wie grijpt in bij afwijkingen?
- Welke resultaten bewaren jullie tijdelijk, zodat het systeem niet elke aanvraag opnieuw hoeft te berekenen?
Antwoorden die vertrouwen geven
Een goede partner beantwoordt deze vragen zonder aarzelen en benoemt afwegingen in plaats van garanties. Het eerste knelpunt zit bijvoorbeeld vaak bij de database. Een sterk antwoord legt uit hoe die daarop is ingericht en wat de volgende stap wordt als de druk toeneemt: leesverkeer verdelen over meerdere kopieën, veelgevraagde gegevens tijdelijk opslaan, zware berekeningen buiten de piek uitvoeren.
Let ook op hoe de leverancier over meten praat. Loadtests, waarbij piekverkeer wordt nagebootst voordat gebruikers het voor hun kiezen krijgen, horen bij de oplevering. Monitoring hoort daarna doorlopend te laten zien hoe het systeem presteert. En misschien is het beste antwoord dat je kunt krijgen wel dat iets voor je situatie nog niet nodig is. Wie durft te schrappen, verkoopt je geen overbodige techniek.
Signalen die op risico wijzen
Sommige antwoorden verdienen een vervolgvraag. “Dat zien we wel als het zover is” betekent meestal: er is geen meetplan. Schaalbaarheid als verkoopterm, zonder testaanpak of metingen erachter, is een belofte zonder bewijs. En zonder monitoring na livegang zijn jouw gebruikers de eerste alarmbel.
Ook het omgekeerde is een signaal. Een architectuur die zo complex is dat alleen de bouwer hem nog doorgrondt, maakt je afhankelijk en maakt groei juist trager. Schaalbaarheid is geen kwestie van zoveel mogelijk techniek, maar van keuzes die passen bij waar je organisatie nu staat en waar ze heen wil.
Staat er een traject op stapel, of twijfel je of je huidige applicatie de volgende groeispurt aankan? Leg deze vragen naast het voorstel dat er ligt; aan de antwoorden herken je snel met wie je te maken hebt. En wil je weten hoe we dit zelf aanpakken, kijk dan bij webapplicaties en portalen: daar lees je hoe we applicaties ontwikkelen die met je organisatie meegroeien.