
Ask HN: When to use Servers and when to go Serverless? - deadcoder0904
Currently trying to differentiate when to use Servers &amp; when to go Serverless.<p>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.<p>Servers are inherently costly. Even if we don&#x27;t use it to its full potential we need to always choose a higher plan than our current usage.<p>I want to know when can we go full Serverless.<p>Like I have 1 app where the flow is like -<p>1. User clicks on SignIn<p>2. Email is sent to the user with Magic Link<p>3. After Magic Link is clicked, user is logged in<p>4. User can then buy a product<p>5. After payment, user can download the product<p>6. User can Logout<p>Can this be done serverless ?<p>Also, which websites would be Serverless &amp; which would need Servers ?
======
guitarbill
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.

------
tima101
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](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)

~~~
fefb
Do you know how remoteok make money? Thanks

~~~
gadders
[https://www.indiehackers.com/interview/growing-a-
community-f...](https://www.indiehackers.com/interview/growing-a-community-
for-digital-nomads-to-33-000-mo-126df0fc5e)

------
mattwinslow
You might wish to take a look at [https://www.zappa.io](https://www.zappa.io)

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

~~~
Gustomaximus
Side 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
This is the link you want:
[https://github.com/Miserlou/Zappa](https://github.com/Miserlou/Zappa) yeah.
The other thing is probably dead.

------
stackzero
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

~~~
scarface74
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.

------
laurentl
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.

------
davidjnelson
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.

------
davidjnelson
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.

------
quintes
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

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

