4 ms·
Ask HN: When to use Servers and when to go Serverless?
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 ?
- tima101 8y agoHave 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 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 https://www.npmjs.com/package/passwordless
- deadcoder0904 8y agoI 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?
- fefb 8y agoDo you know how remoteok make money? Thanks
- mattwinslow 8y agoYou might wish to take a look at https://www.zappa.io https://www.zappa.io Your proposed use case seems like it aligns nicely...
- scoates 8y agoIndeed. (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.
- Gustomaximus 8y agoSide point if anyone from Zappo is reading; - There is a broken image link for me: http://prntscr.com/j8ta00 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.
- scoates 8y agoThis is the link you want: https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa yeah. The other thing is probably dead.
- jxub 8y agoZappa issues on Github are pretty stagnant though. My PR with the new AWS Paris availability zone support is still left even uncommented...
- dsl 8y agoThere is always a server. Your question is do you want to pay someone else to run it for you.
- davidjnelson 8y agoServerless 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.
- davidjnelson 8y agoTo 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.
- stackzero 8y agoThe 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
- scarface74 8y agoDatabases 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.
- guitarbill 8y agoThis 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.
- quintes 8y agoDon'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
- laurentl 8y agoYou 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.