Live data from Hacker News

Ask HN: Is Serverless Overkill?

news.ycombinator.com

11–20 of 22 posts

Re: Ask HN: Is Serverless Overkill?

#11
post #10
post #8

When using serverless, you are paying more for the devops and other simplifications. Eventually the costs can outway the benefits, have seen this many times. Serverless has its place, but it is not going to usurp cloud computing norms. I'd also say things like Neon "serverless postgres" is not really serverless. It is using serverless as the de jour marketing term for managed postgres SaaS. I can get the same thing f…

(Neon CEO) What makes it not serverless in your opinion? This is our architecuture: https://neon.tech/docs/introduction/architecture-overview and no, you can not get the same from CloudSQL.

IYKYK

> ... and no...

not a great way to elicit feedback

Re: Ask HN: Is Serverless Overkill?

#13
post #5

Serverless enforces good architectural practices and is just fine for at least 80% of systems. By "just fine" I mean it leaves room for growth, puts you on a good architecture, and will have reasonable cost. There are times though when serverless may not be a good idea: - Atypical technology stack. If the stack you need, and actually need, isn't accounted for then you're on your own. - Continuous, 24x7 application lo…

Can you expand more on what these practices are, in your view?

Re: Ask HN: Is Serverless Overkill?

#14
It's actually the reverse, to my understanding. Serverless is great for low utilization projects. Then cloud servers like EC2. Then those old school hosts with cPanel. Then running everything from your own physical servers, setting up your own backup diesel generators, putting a server in Antarctica, etc, etc.

As tech progresses, it makes the abstraction levels better for those who need less power.

Re: Ask HN: Is Serverless Overkill?

#15

I've built some very small and simple systems in AWS Lambda such as email newsletter scripts. With a system like that I can get close to 100% reliability, never worry about the server crashing or overloading. My RSS reader answers webhooks with Lambda -- some of these systems have been cruising for years without maintenance.

Ditto. I have some not-small systems based on s3, lambda, SNS and SQS that have been running for years without issue - just quietly, and inexpensively doing their jobs.

New stuff I’m building is putting StepFunctions in rather than Lambda if at all possible, and DDB alongside S3 for indexing. I expect these to be nearly maintenance free (no runtime updates, no package updates, TTLs to expire data).

Re: Ask HN: Is Serverless Overkill?

#16
post #5

Serverless enforces good architectural practices and is just fine for at least 80% of systems. By "just fine" I mean it leaves room for growth, puts you on a good architecture, and will have reasonable cost. There are times though when serverless may not be a good idea: - Atypical technology stack. If the stack you need, and actually need, isn't accounted for then you're on your own. - Continuous, 24x7 application lo…

> Serverless enforces good architectural practices

I'd argue it's the opposite. Since everything gets "thrown away" per request you neglect on caching, memory leaks, subtle bugs etc.

You also need to make trade offs like focusing on cold start as opposed to peak performance etc.

Re: Ask HN: Is Serverless Overkill?

#17
post #16
post #5

Serverless enforces good architectural practices and is just fine for at least 80% of systems. By "just fine" I mean it leaves room for growth, puts you on a good architecture, and will have reasonable cost. There are times though when serverless may not be a good idea: - Atypical technology stack. If the stack you need, and actually need, isn't accounted for then you're on your own. - Continuous, 24x7 application lo…

> Serverless enforces good architectural practices I'd argue it's the opposite. Since everything gets "thrown away" per request you neglect on caching, memory leaks, subtle bugs etc. You also need to make trade offs like focusing on cold start as opposed to peak performance etc.

Since everything gets "thrown away" as you say (though it's not per request), you actually have to focus more on caching in order to maintain any kind of session state (if required by your application).

Memory leaks are an interesting matter because, you're right: you really don't care. All the pieces parts comprising your system are continually restarting without impacting the overall resiliency of the system. In fact, quite the opposite is happening - the system is more resilient due to all the mini restarts.

You will have to learn techniques for handling cold starts, there's a few different ways to go about it and which one is appropriate, including not worrying about it at all, is dependent on your application and the cold load ramp-up experienced.

Re: Ask HN: Is Serverless Overkill?

#18
post #17
post #16

Earlier quoted context omitted.

> Serverless enforces good architectural practices I'd argue it's the opposite. Since everything gets "thrown away" per request you neglect on caching, memory leaks, subtle bugs etc. You also need to make trade offs like focusing on cold start as opposed to peak performance etc.

Since everything gets "thrown away" as you say (though it's not per request), you actually have to focus more on caching in order to maintain any kind of session state (if required by your application). Memory leaks are an interesting matter because, you're right: you really don't care. All the pieces parts comprising your system are continually restarting without impacting the overall resiliency of the system. In fa…

> you actually have to focus more on caching

You lose a lot of layers of caching since there's no point in it. You focus on rather poor caching, i.e. you have to use an external cache. You can't store this as part of the current session and access it for the next request, e.g. by the same user.

> you really don't care

That's on the surface. It's like having a hidden illness that only gets you when something else breaks and suddenly 100s of errors pile up.

> the system is more resilient

It pretends to be. You often get bugs that aren't so obvious and never get fixed because it's now hidden so deep.

> You will have to learn techniques for handling cold starts

The nuance here is you're learning to prefer faster cold starts at all costs including trading for warm start performance. It's making the world worse.

Re: Ask HN: Is Serverless Overkill?

#19
post #18
post #17

Earlier quoted context omitted.

Since everything gets "thrown away" as you say (though it's not per request), you actually have to focus more on caching in order to maintain any kind of session state (if required by your application). Memory leaks are an interesting matter because, you're right: you really don't care. All the pieces parts comprising your system are continually restarting without impacting the overall resiliency of the system. In fa…

> you actually have to focus more on caching You lose a lot of layers of caching since there's no point in it. You focus on rather poor caching, i.e. you have to use an external cache. You can't store this as part of the current session and access it for the next request, e.g. by the same user. > you really don't care That's on the surface. It's like having a hidden illness that only gets you when something else brea…

> External caches are resilient to total failure and the need to failover to another environment.

> Memory leaks are a non-issue - seriously, you're processing the transaction and durably storing the result and going away. I've seen systems written this way that have been running for over 20 years.

> The system is more resilient, there's no pretense to it. I have anecdotal data from many projects developed by many teams in multiple companies now that show the business disruptions have decreased and decreased considerably.

> Not all systems are affected the same way by cold starts, some aren't affected at all. You do have to plan for it and understand how cold starts affect your system and whether any remediation is required.

> It's making the world worse - that's a subjective opinion. I call faster time to delivery with fewer business disruptions better. We're currently delivering capabilities the business thought would take far longer to develop and would cost a lot more in operations costs. I call that making the world better.

Re: Ask HN: Is Serverless Overkill?

#20
post #19
post #18

Earlier quoted context omitted.

> you actually have to focus more on caching You lose a lot of layers of caching since there's no point in it. You focus on rather poor caching, i.e. you have to use an external cache. You can't store this as part of the current session and access it for the next request, e.g. by the same user. > you really don't care That's on the surface. It's like having a hidden illness that only gets you when something else brea…

> External caches are resilient to total failure and the need to failover to another environment. > Memory leaks are a non-issue - seriously, you're processing the transaction and durably storing the result and going away. I've seen systems written this way that have been running for over 20 years. > The system is more resilient, there's no pretense to it. I have anecdotal data from many projects developed by many te…

> I've seen systems written this way that have been running for over 20 years.

So? History and same mistakes have repeated for centuries in many areas. Does that make it good?

> I have anecdotal data from many projects developed by many teams in multiple companies now that show the business disruptions have decreased and decreased considerably.

And so? Someone else likely has anecdotal data otherwise. How do you even show this? Was everything else the same except this "server" vs "serverless" change? That in itself is impossible unless you know how to freeze time. Lots of variables in your company are likely different every week or month. People come and go. The market changes. Etc.

> some aren't affected at all.

Like if you close your eyes and pretend it doesn't exist? Sure. If you don't care it definitely doesn't exist otherwise cold starts are always slower, the end. It's not just about the programming language, jit, VMs or anything. It's a worse outcome.

> that's a subjective opinion

It's objective based on your measures of objectiveness - as seen above.

> I call faster time to delivery with fewer business disruptions better.

Is that a given? How did you jump to this? Either approach has its complexities. I've seen "serverless" take longer to deliver.

> I call that making the world better.

How does that make it better? What does doing better than an estimate have to do with serverless? You can do that regardless.

We're here just going over the straw man. Where's your actual argument? About server vs serverless. Not something else.

Post reply on HN