Ask HN: When to use Servers and when to go Serverless? | Hacker News Reader

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

33 pointsdeadcoder090418 comments

Currently trying to differentiate when to use Servers & when to go Serverless.

Serverless will scale infinitely, although it has 1 small cost of cold starts but if the site is used regularly then cold start is not needed.

Servers are inherently costly. Even if we don't use it to its full potential we need to always choose a higher plan than our current usage.

I want to know when can we go full Serverless.

Like I have 1 app where the flow is like -

1. User clicks on SignIn

2. Email is sent to the user with Magic Link

3. After Magic Link is clicked, user is logged in

4. User can then buy a product

5. After payment, user can download the product

6. User can Logout

Can this be done serverless ?

Also, which websites would be Serverless & which would need Servers ?

View on HN

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.

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

I know RemoteOK very well :)

I know people don't care whether it is serverless or not. But that's not the point. The point is reducing cost.

Why should I pay for services I don't use?

Why should I write the same code twice (once for server & once for serverless)? Although a lot of that would be same but I still need to write a lot of config to run serverless.

Why should I worry about Scaling?

Do you know how remoteok make money? Thanks

Open the website and press Post a Job.

https://www.indiehackers.com/interview/growing-a-community-f...

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

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

Indeed. (Zappa contributor here.) It especially aligns with the (below) concern of "why should I write code twice?".

For the most part, your code will work in both places the same, if you have a Python WSGI app.

Side point if anyone from Zappo is reading;

- There is a broken image link for me: http://prntscr.com/j8ta00

- This websites feels a bit information light. Its like its been written to be like the cool clean startups vs the focus being on providing key information and ability to get there easily. That said I'm low on the technical scale so maybe the githup link and style suits most great.

This is the link you want: https://github.com/Miserlou/Zappa yeah. The other thing is probably dead.

Zappa issues on Github are pretty stagnant though. My PR with the new AWS Paris availability zone support is still left even uncommented...

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

Databases need to be on a server, but not your server. If you're going with AWS, there is Aurora, different flavors of RDS, or DynamoDB.

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.

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.

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

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

Reply on news.ycombinator.com