Ask HN: When to use Servers and when to go Serverless?

Have you considered that you may optimize excessively and way too early? People who would buy your product do not care whether it's serverless or not.

If people like product and it sells well, you will have time and money to refactor your product (I would still think twice before doing so).

Consider this: > remoteok.io is a single PHP file called "index.php" generating $2,342.04 in a day. No frameworks. No libraries.

If you want to start quickly with app that has signup and pay for content, consider this open source app: https://github.com/builderbook/builderbook I am a co-author.

If you really need passwordless-like flow, check out: https://www.npmjs.com/package/passwordless

You might wish to take a look at https://www.zappa.io

Your proposed use case seems like it aligns nicely...

There is always a server. Your question is do you want to pay someone else to run it for you.

Serverless on aws has terrible 95th percentile latency. As a result, it’s not a good fit for web apps. Why make life difficult? Put two small dynos behind a load balancer with a smallish db for $100/mo on heroku. Front it with cloudflare and cache liberally at the cdn level with invalidation on write.

To clarify, the cold starts are present on _every scale up_ operation with aws lambda ( plus cloudfront->api gateway->lambda ssl tcp connection overhead ). To keep 500 concurrent lambdas warm costs ~$300/mo.

The canonical example of serverless is for handling web requests i.e. 1 function per HTTP route. Database will still need to be on a static server. Managing user login / state etc. will be cumbersome across multiple different functions, however the email and payment processing handlers may be better candidates for serverless functions. A thin front-end and DB on static servers with serverless used for emails+payment processing would be a good initial architecture

This can be done serverless + static hosting (e.g. s3) + db (e.g. dynamo). And serverless is great for burst-y, well-defined tasks like sending emails or serving simple web pages.

However, serverless won't "scale infinitely". Users sessions are the big one (although if your dynamo table becomes the limiting factor, I'd say that's a successful company). Serving big files could get very expensive, so think about how the download is going to be done. Caching is also going to be more complex.

Finally, serverless tools are still a bit meh. I would just use the serverless framework, because it seems most general purpose. The more specific frameworks for e.g. web pages often end up limiting you because of the way they're designed.

Serverless has a learning curve. If this is an actual business decision, go servers for everything and worry about optimizing later. Will be much easier hiring for servers. If it's more of a learning exercise, go serverless all the way.

Don't forget: Size of files allowed to be uploaded be limited in serverless Execution time may be limited.

There are others, these 2 feature in some of my use

You can do all of your use cases with serverless, as guitarbill and others have explained. My approach is: when starting from scratch, start with serverless, and only when you hit its limits (I haven’t yet) go back to VMs. The rationale is that serverless will allow you to be production-ready quicker (at least from my perspective, seeing as I don’t have a strong sysadmin background), with less chance of shooting yourself in the foot security- or configuration-wise, for a fraction of the cost as long as your traffic isn’t huge. And you don’t have to get out of bed at 4am to fix a broken server :D

Only when you start hitting performance issues, or you absolutely can’t make a feature work, or you can significantly lower your bill by using VMs (taking into account the cost of managing these VMs) should you try with a classic architecture.

The closest analogy I can come up with is using a higher-level language (say Python) over a lower-level language like C. Unless you’re a C guru, you’ll end up implementing it faster and more safely in Python. And when/if you start hitting Python’s limitations (speed...), you can replace the critical parts with specific, highly tuned C code.