Hacker News Reader

Comment by fulafel | Hacker News Reader

Is the headline benefit really paying only for use? Trading increased complexity & dev effort for this seems like a backwards development when vm/container/heroku-style hosting is so cheap & getting cheaper.

View on HN

The complexity and dev effort is higher initially because the paradigm is so different from "localhost" development. But once the initial boilerplate and yak-shaving work is done, serverless can actually be easier to manage because you deal at a much smaller functional level.

I have never used "serverless", but how does that differ from say a Django app?

You have the initial boilerplate setting up the project, then you map urls to functions. Once the initial setup is done its trivial to map a new urls to new functions.

I am genuinely curious as I can't really work out what all the hype is about regarding serverless. Am I missing something?

I think this list can give a helpful picture if you remember that it's written by marketing people at a serverless company: https://serverless.com/blog/when-why-not-use-serverless/

It downplays/skips over the complexity costs from learning, configuring, debugging, deploying, testing, etc the big zoo of woven together cloud services. Ideally you'd also want some dev time and cognitive capacity left over to think about your domain problems...

Yes. So in serverless, there is no concept of a long running service. So you can't listen on port 3000 and have any routing within the app. You will rather write one function, add a route to it via API Gateway and then use it in your app. You can probably use django library to help you write code in django style but you can't use it fully for e.g. 1) you can't do migrations in serverless the same way, 2) everytime your function is invoked Django will map the database to models, etc so it could be very slow.

Django actually has a serverless story now: https://www.agiliq.com/blog/2019/01/complete-serverless-djan...

So your original comment said

"But once the initial boilerplate and yak-shaving work is done, serverless can actually be easier to manage because you deal at a much smaller functional level."

Everything you just described in your second comment, sounds like it would make things more difficult.

Suppose you have set up everything to get you going with a single route. Now, adding another route/handler is just deploying another function. And you deal with everything at this function level and never the entire "monolith".

You get all the advantages of breaking free from a "monolith", independent iteration, scale, federated management. Consider a big team which writes 100s of routes/handlers, then you can just federate the ownership easily.

Not very great for a solo-dev kind of projects, I agree.

Reply on news.ycombinator.com