Wat ben jij kwijt voor Serverless Hosting?

[Zaanone]

Hoi allemaal,
Ik ben van plan een project voor een klant te hosten op het Pro-plan van Railway.com en heb geen idee of dit slim is.

Wat is Railway?
Railway.com is een 'serverless' hosting platform, net als bijv Vercel, Heroku, Fly.io en Render.

De Stack:
• Backend: Directus, PostgreSQL en Redis op Railway.com.

• Frontend: Svelte, gehost op Cloudflare Workers, die de Directus API aanroept.

Het Project:
Het is een website waar gebruikers kunnen zoeken naar lokale evenementen. Een typische gebruikersstroom is: ⁠Home -> 'Vind evenementen in de buurt' (een geo-query) -> Detailpagina van een evenement. Het is dus een dynamische site die bij de meeste bezoeken de database zal raadplegen. Ons doel is om na een jaar wel te groeien naar 10.000 maandelijkse gebruikers of meer.

Mijn Zorg:
Ik ben gek op de developer experience van Railway. Als medior front-end developer is het heel handig dat de devops-dingen 'gewoon werken', en dat alles schaalt naar hoeveelheid gebruikers. Mijn grootste zorg zijn de onvoorspelbare kosten. Omdat Postgres en Redis altijd 'aan' staan, ben ik bang dat ik al snel de inbegrepen credits van het Pro-plan zal opmaken. Ik wil echt voorkomen dat ik zo'n verhaal word van "ik kreeg een verrassingsrekening van honderden euro's" na een piek in het verkeer (of DDOS-aanval o.i.d).

Vragen:

1. Heeft iemand ervaring met het draaien van een vergelijkbare 'always-on' stack (bv. Directus/Strapi + DB + Redis) op Railway (of ander serverless platform)? Hoe schaalden de kosten in de praktijk naarmate je groeide?

2. Is mijn angst terecht dat de inbegrepen credits snel worden opgebruikt? Bij welk gebruiksniveau (bezoekers/requests) zagen jullie de kosten aanzienlijk stijgen?

Alvast bedankt!!!

[Cartman!]

Ik heb iets van 8 jaar ervaring met serverless infra/projecten maar doe alles rechtstreeks bij AWS ipv via een tussenliggende dienst zoals jij ze noemt in je voorbeeld. Het antwoord is ook niet bijzonder ingewikkeld; kijk naar wat 1 user ongeveer kost qua requests en usage en vermenigvuldig dit met t aantal users dat je verwacht/wenst. Als je daarna schrikt van dat aantal moet je misschien kiezen voor een andere oplossing (direct bij AWS/<andere provider>). Geheel tegen m'n eigen principes in; met een goedkope VPS kun je prima wat verkeer draaien maar dan heb je veel meer verantwoordelijkheid voor de infra qua server (security) updates en backups ed.

[Merethil]

Zelfde hier als bij @Cartman! - alles op AWS; namelijk Cognito voor auth, API Gateway, Lambda, DynamoDB, S3, EventBus+SQS (voor async processing) en als CDN Cloudfront. We serveren nu ongeveer 50k gebruikers een simpele webshop, een "mijn-omgeving" en wat overige zaken, en zitten op een euro of 100 per maand. Het gros daarvan zit in storage, logging en Cloudfrontgebruik.

Zonder ook maar iets aan te passen kunnen we deze hele set prima schalen naar het tien of honderdvoudige, en de kosten zullen nog steeds meevallen voor het gros van de services. We hebben bijzonder weinig anders gevonden met de schaalbaarheid, de impact die je zelf op de kosten kan hebben en de vrijheid die het je biedt in alle keuzes die je kan maken, en zijn erg blij met deze setup.

[Ed Vertijsment]

Zonder al te diep in te gaan op je eigenlijke vraag (ik ga je niet vertellen wat je moet gaan doen):

10000 gebruikers per maand is niet per se heel veel (in technische termen), met een beetje een snelle applicatie (op basis van je beschrijving denk ik dat je daar aan denkt…), zal dat waarschijnlijk prima moeten draaien op een eenvoudige vps, dan heb je geen risico met credits en het geeft je wat flexibiliteit om klein te beginnen en eventueel later te migreren als je de cijfers kent.

Er is wat voor te zeggen in direct op de architectuur in te zetten mocht je daar toch heen willen (ik heb het gevoel dat de echte argumenten daarvoor nog niet hier genoemd zijn), maar dan heb je wel een risico op een vendor lock-in.

Dat laatste in acht nemen moet je nadenken of de kosten daar niet inzitten en moet je een risico inschatting maken van (eigenlijk) een niet aws.

Veel succes met kiezen.

[Cartman!]

Mag m'n eerdere reactie niet meer aanpassen maar als je spreekt over 'always-on' dan is je mindset niet voldoende serverless en ga je de voordelen die t heeft niet of te weinig behalen.

Puur serverless voor je use case zou bijv kunnen zijn om een SaaS CMS (DatoCMS, Contentful) te gebruiken voor beheer van je content/dat, een serverless database als DynamoDB of Aurora DSQL en een webhook om je DB bij te werken. Je frontend kan mogelijk geheel statisch geladen worden vanaf een bucket voor een CDN.