New to WIP?
We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Topics
Back
Question
When to use Servers & 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 -
Also, which websites would be Serverless & which would need Servers ?
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 -
- User clicks on SignIn
- Email is sent to the user with Magic Link
- After Magic Link is clicked, user is logged in
- User can then buy a product
- After payment, user can download the product
- User can Logout
Also, which websites would be Serverless & which would need Servers ?
👋 Join WIP to participate
Hi Akshay,
"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." - there are solutions that fix it, example: github.com/FidelLimited/serve…
Me and my teammates have been using serverless technologies for a while. This is what we've learned:
1. Running Lambda functions is much cheaper for simple computationally intensive operations.
2. Traditional way of dealing with databases is not a good fit for serverless. Make sure that your DB server is ready to handle hundreds of simultaneous connections. Always close DB connections by the end of each lambda invocation.
3. Use terraform, cloudformation or serverless.js config to set up API endpoints, don't do it manually (otherwise it is a nightmare to set up staging or other envirionments).
4. Long running tasks (like log processing, etc.) are better to do on a server instance.
5. Lambda functions are great for running CRON jobs (using cloudwatch scheduler).
6. Think of a centralized logging solution in advance (Papertrail is a good option).
7. Ideally set up caching with Redis (has unlimited connections) to reduce the load on your DB or consider trying AWS Aurora: aws.amazon.com/rds/aurora/ It's a Postgres compatible solution for the serverless era. Let me know how it goes.
You should think carefully of how to implement authentication properly. The best fit would be using a JWT token.
Tj has recently introduced Up, which helps to deploy serverless websites as well (not only APIs): github.com/apex/up
We prefer having a Heroku instance or a static website running on a server and then using serverless for the API, because the limitation is that you can't use Websocket without a server.
In general, it's definitely fun and cost efficient to build a cloud solution using serverless technologies.
Guys, hit me up on Telegram (@mac_r) if you have any other questions!
Best,
Max
Thank you for such a wonderful answer, Max 👏
Can you answer the question about the app in which I mention the 6 steps above❓
I think its good for Serverless but not sure. Up is very good & I maybe use that or use Serverless Framework.
Also, regarding Databases I read during my Engineering that if 2 people perform the write operation simultaneously then it will probably have a race condition with incorrect values. How to solve that❓ I don't think its a serverless problem but if you can answer that :)
Also, whats the harm in keeping the database open❓Does it have any cost if I keep it open❓
You can implement any service you want fully on serverless unless you need to use Websocket (then you'd need to combine serverless API with a traditional server). To avoid race conditions you can look into transaction locking (ex: in Postgres): stackoverflow.com/questions/4… or you can set flags with a Redis caching layer. The reason why you should always close your DB connections is that functions create a new connection on each invocation. Considering that it's infinitely scalable, we get a bottleneck at the DB level. So your database solution should be ready to handle thousands of connections at the same time.
Thank you 🙌
I have no doubts now & if I have any when I actually build it, I will ask you later on. Thanks Max :)