Welke hosting past bij een SaaS met groeiplannen?

Het is de laatste werkdag van de maand. Je klanten doen hun maandafsluiting in je platform en de inlogpagina blijft hangen. Support krijgt de eerste mails binnen, je developer ziet niets vreemds in de code en de hoster vermoedt dat het aan de database of een externe koppeling ligt. Je klant ziet daar niets van. Die ziet een product dat het niet doet. Op zo'n middag merk je welke hosting bij je SaaS past, en vooral wie er eigenaar is van de storing.

Een brochurewebsite redt het prima op goedkope standaardhosting. Software waar klanten elke dag op werken, stelt andere eisen, en die eisen volgen uit hoe je applicatie gebruikt wordt. Daar begin ik dus mee, nog voordat er een server ter sprake komt.

Schrijf eerst op wat een uur uitval kost

Of je een VPS, een cloudplatform of een dedicated server nodig hebt, kun je pas zeggen als je dit op papier hebt:

• hoeveel gebruikers er tegelijk actief zijn, op een normale dag en op je drukste moment;
• welke processen nooit mogen uitvallen;
• wanneer je pieken vallen, bijvoorbeeld na een nieuwsbrief, rond maandafsluitingen of tijdens een campagne;
• hoe gevoelig de gegevens zijn die je verwerkt;
• wat een uur downtime kost aan omzet, productiviteit en vertrouwen.

Dat laatste punt is het lastigst, omdat vertrouwen moeilijk in euro's te vangen is. Maak toch een schatting, hoe grof ook. Met dat getal weet je hoeveel redundantie, monitoring en back-ups je platform waard is. Zonder die schatting koop je capaciteit die je niet gebruikt, of een omgeving die pas tekortschiet als je klanten er last van hebben.

Welke hosting past bij een groeiende SaaS?

Shared hosting sla ik voor SaaS over. Je deelt daar een server met andere klanten, en daarmee ook de grenzen aan rekenkracht, geheugen en processen. Een piek bij een buurman merk jij in je applicatie. De configuratie ligt grotendeels vast, je ziet weinig van wat de server doet en eigen eisen voor beveiliging of monitoring krijg je er lastig in. Ontstaat er vertraging, dan hoor je al snel dat het probleem misschien in je code zit, en dan begint het doorschuiven. De lage instapprijs weegt daar niet tegenop.

Start op een beheerde VPS

Voor de meeste SaaS-producten in de start- en groeifase is een VPS de logische basis. Je applicatie krijgt een afgeschermd deel van de servercapaciteit, je stemt de omgeving af op je software en opschalen gaat doorgaans redelijk eenvoudig. Dat werkt goed zolang je verkeer redelijk voorspelbaar is en de applicatie niet continu veel rekenkracht vraagt.

Het woord dat ertoe doet is beheerd. Updates, back-ups, monitoring, firewallregels en incidentopvolging moeten bij iemand liggen. Een onbeheerde VPS is uitgesteld risico, geen besparing.

Dedicated zodra de belasting constant hoog is

Draait je platform de hele dag zwaar, met een grote database, specifieke beveiligingseisen of klanten die vaste prestaties verwachten, dan is een eigen fysieke server de volgende stap. Je deelt de hardware met niemand, je bepaalt de volledige configuratie en je weet precies welke resources er zijn en wie het beheer doet. Voor een gevestigd platform geeft dat rust.

Je betaalt dan wel voor capaciteit die je ook moet benutten. Voor een jonge applicatie met enkele tientallen gebruikers is een complete server te groot en te duur.

Cloud pas als je pieken erom vragen

Cloudinfrastructuur is sterk als je belasting flink wisselt, als je internationale klanten bedient of als je geografische spreiding en hoge beschikbaarheid echt nodig hebt. Capaciteit beweegt sneller mee met de vraag, en database, opslag en applicatie kun je los van elkaar inrichten.

Ik kies cloud pas als die pieken terugkomen in het lijstje van hierboven. Een cloudomgeving vraagt een doordachte architectuur, kennis van netwerken, toegangsrechten en failover, en iemand die de kosten bewaakt. Zonder limieten en monitoring loopt de rekening op. Zonder die kennis bouw je een omgeving die lastiger te beheren is dan je product nodig heeft.

Kijk eerst naar trage queries, dan naar servers

Veel prestatieproblemen ontstaan in de database, en dat merk je pas als je groeit. Met meer gebruikers, transacties en historische data worden zoekopdrachten zwaarder. Een dashboard dat bij tien klanten direct opent, kan bij duizend klanten secondenlang laden als queries en indexen niet goed zijn ingericht. Meer serverkracht lost een slechte query niet altijd op.

Zet daarom monitoring op trage queries aan voordat je over een upgrade praat. Let daarnaast op snelle schijven, genoeg geheugen en databaseback-ups die je echt kunt terugzetten. Wordt de omgeving groter, dan is het verstandig om database en applicatie van elkaar te scheiden, zodat een zware rapportage de rest van je platform minder snel meesleept.

Andersom kan goed geschreven software op een onderbemeten omgeving alsnog traag aanvoelen. Wie de code en de server allebei overziet, vindt de echte oorzaak sneller.

Vraag wie de storing als eerste ziet

Een uptime van 99,9 procent klinkt uitstekend tot je het omrekent: op jaarbasis is dat ruim acht uur mogelijke uitval. Het maakt bovendien veel uit wanneer die uren vallen. Een storing in een rustige nacht is iets anders dan een storing tijdens de dagelijkse piek van je klanten.

Het percentage zegt dus weinig. Deze vragen aan een hoster zeggen meer:

• Hoe ontdekken jullie een storing?
• Wie grijpt in, en hoe snel heb ik iemand met verstand van zaken aan de lijn?
• Is er monitoring op beschikbaarheid, serverbelasting, schijfruimte en de kritieke processen van mijn applicatie?
• Hoe houden jullie mij op de hoogte als het onderzoek langer duurt?

Een goede hostingpartner wacht niet op het eerste bericht van een klant. Die ziet afwijkingen vroeg, zoekt uit wat er verandert en grijpt in voordat een klein probleem een incident wordt.

Een back-up telt pas na een testherstel

Een kopie op dezelfde server helpt weinig als juist die server defect raakt. Een beschadigde database, een verkeerde deployment of ransomware vragen om meer dan één hersteloptie. Spreek dus af hoe vaak er een back-up gemaakt wordt, hoe lang versies bewaard blijven en hoe snel een herstel kan.

Zet daarna een testherstel in de agenda. Laat een recente back-up terugzetten en controleer of de applicatie draait en de data klopt. Pas dan weet je dat je back-upbeleid werkt.

Bepaal ook je hersteldoelen. Moet de applicatie binnen een uur weer draaien, of is een werkdag acceptabel? Mag je hooguit vijftien minuten aan data kwijtraken, of valt een dag verlies nog te overzien? Dat zijn bedrijfsbeslissingen. De techniek volgt ze.

Leg vast wie in productie mag komen

Een SaaS verwerkt klantgegevens, gebruikersaccounts, documenten en bedrijfsprocessen. Een SSL-slotje dekt daar maar een klein deel van. De rest zit in toegangsbeheer, tijdige updates, netwerksegmentatie, logging, versleuteling en een plan voor incidenten.

Waar het in de praktijk vastloopt, is verantwoordelijkheid. Schrijf voor je eigen omgeving op wie de applicatie-updates doet, wie het besturingssysteem bijwerkt, wie op kwetsbaarheden controleert, wie toegang heeft tot productie en wie een herstel mag starten. Staat er bij een van die regels een vraagteken, dan verlies je precies daar tijd op het moment dat het snel moet.

Wat ik altijd geregeld wil zien, ook bij een klein platform: strikte toegangsrechten, gescheiden omgevingen voor ontwikkeling en productie, actuele software en gecontroleerde deployments.

Laat je roadmap je hosting sturen

Hosting voor een SaaS beweegt mee met nieuwe functies, groei, koppelingen en veranderend gebruik. Daarom telt wie er aan de andere kant zit. Vertraagt een koppeling, zorgt een release voor extra belasting of is er database-optimalisatie nodig, dan wil je iemand spreken die je omgeving kent en meedenkt over komende pieken en risico's. Bij LJPc horen ontwikkeling en hosting bij dezelfde technische verantwoordelijkheid. Dat houdt de lijn kort.

Kies een basis die je huidige gebruik betrouwbaar aankan, meet wat er gebeurt en schaal op wanneer data en gebruik daar aanleiding toe geven.

Pak vandaag je roadmap erbij en zet naast elke grote productstap wat die met je platform doet. Een nieuwe rapportagemodule, een koppeling met een ERP-systeem of een grote nieuwe klant kan het profiel van je platform fundamenteel veranderen. Bespreek die lijst met je hostingpartij voordat de bouw begint.