Server met vaste prijs of facturering op basis van gebruik?

Draait je app de hele tijd en is het verkeer redelijk voorspelbaar, dan verrast een server met vaste prijs je minder. Is het verkeer heel laag of schiet het plotseling flink omhoog, dan kunnen platforms met facturering op gebruik zinvoller zijn. Dit is minder een technische keuze dan een vraag welke regel op je factuur blijft groeien.

De onderstaande vergelijking gebruikt geen prijzen, omdat tarieven per eenheid per platform verschillen en vaak veranderen. In plaats daarvan krijg je een manier om met je eigen cijfers te rekenen.

Waarvoor rekent elk model?

Elke rij is een afweging en geen van beide modellen wint ze allemaal.

Wanneer is facturering op basis van gebruik zinvoller?

• Het project is nieuw en krijgt bijna geen verkeer. Dekt een gratis abonnement het, dan heeft betalen voor een server weinig zin.
• Je publiceert een kortlevende demo of campagnepagina. Een server opzetten is het niet waard voor iets dat over een paar weken sluit.
• Je verkeer piekt plotseling en scherp. Eén server heeft op dat moment misschien de capaciteit niet, en een platform vangt dat voor je op.
• Je bezoekers zitten over de hele wereld en je wilt elk van hen van dichtbij beantwoorden.
• Je wilt nooit met updates, back-ups of monitoring te maken hebben en betaalt daar graag voor.

Wanneer is een server met vaste prijs zinvoller?

• Je app doet voortdurend achtergrondwerk: queueworkers, geplande taken, WebSocket-verbindingen.
• Je wilt de database, de cache en de app naast elkaar. Delen ze één machine, dan brengt elk geen eigen factuur mee.
• Je AI-functies leveren langlopende antwoorden. Waar je op functieduur wordt gefactureerd, verhoogt elk traag antwoord de kosten.
• Je budget moet vooraf bekend zijn. Het maandbedrag staat van tevoren vast, dus het einde van de maand bevat geen verrassingen.
• Je serveert veel afbeeldingen of bestanden en verkeer is je grootste kostenpost geworden.

Hoe reken je zelf de cijfers uit?

Raad niet, maar haal de cijfers van de afgelopen drie maanden op. Ben je nog niet live, gebruik dan het verkeer dat je verwacht en noteer dat het een schatting is.

1. Noteer het maandelijkse verkeer in GB, het aantal verzoeken en de totale functieduur.
2. Noteer je buildminuten. Elke push is een build, dus deze post groeit snel bij een team dat vaak oplevert.
3. Tel extra's op, zoals teamplekken, een database en een cache.
4. Vermenigvuldig elk met het tarief per eenheid op de actuele prijzenpagina van het platform. Dat geeft je de factuur van een gewone maand.
5. Herhaal de som alsof het verkeer tien keer zo hoog was. Dat is je factuur van een slechte maand.
6. Vergelijk beide uitkomsten met het maandbedrag van een server die je app comfortabel kan dragen.

Baart het bedrag van de slechte maand je geen zorgen en heb je geen zin in onderhoud, blijf dan waar je bent. Kost een gewone maand al meer dan de server, of zou de slechte maand het bedrijf pijn doen, dan verdient een server serieuze aandacht.

Wat kost een vaste prijs?

Is de server van jou, dan worden sommige taken ook van jou. Kies hiervoor in de wetenschap wat ze zijn:

• Het besturingssysteem en de apps bijgewerkt houden is jouw taak. Publicatiepanelen nemen een deel van dat werk over, niet alles.
• Er groeit niets automatisch mee als de capaciteit opraakt. De server wordt traag en jij bent degene die hem opschaalt.
• Eén server is één enkel punt van uitval. Terwijl hij herstart, reageert je app even niet.
• Je antwoordt vanaf één locatie. Verre bezoekers zien meer latency en een content delivery network ervoor kan helpen als dat voor jou telt.

Kun je beide gebruiken?

Ja, de keuze hoeft niet alles of niets te zijn. Een gangbare opzet houdt de interface op een platform dat op gebruik factureert en draait de backend, de database en de queueworkers op een server met vaste prijs. Het meeste verkeer gaat naar de interface, terwijl het constante werk dat een rekening opblaast, op de server een vast bedrag blijft. De prijs is dat je twee plekken in de gaten moet houden en de verbinding ertussen moet beveiligen. Heb je één app, dan is deze opzet meestal meer complexiteit dan het waard is, dus begin op één plek.

De middenweg: git push op je eigen server

Vaak is het grootste verschil tussen de twee modellen het gemak, en dat verschil wordt kleiner. Open source publicatiepanelen zoals Coolify geven je dezelfde werkwijze op je eigen server: je koppelt een GitHub-repository, elke push wordt gebouwd en gaat live, je beheert omgevingsvariabelen en domeinen in een webinterface en het paneel vraagt het certificaat aan. Je houdt root-toegang en je kunt alles vanuit het paneel beheren als je dat liever hebt.

Bij Seturack worden de opties Coolify en Next.js met dit paneel geïnstalleerd geleverd. Je kiest een grootte met een schuifregelaar en schaalt later op vanuit je paneel. Bij opschalen blijven het IP en de gegevens hetzelfde en betaal je alleen het verschil voor de resterende dagen. Dagelijkse back-ups zijn bij de prijs inbegrepen en het verkeer is onbeperkt. De servers staan in Istanbul. Op de prijzenpagina kun je groottes vergelijken.

Kant-en-klaar bij Seturack: Next.js, Coolify.