Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving serverless led to performance improvement and a simplified architecture

unkey.com

Post reply on HN
Print view View original

201–210 of 272 posts

Re: Leaving serverless led to performance improvement and a simplified architecture

#201

Post by khamidou »

_heimdall wrote: post #193
jjice wrote: post #100

Like the article says, I think serverless has it's place, but I don't think it's for most applications. I can't see myself _ever_ using serverless services as a core part of my application for pretty much any startup, if I can avoid it. The infrastructure overhead is actually worse, IMO. Everything is so platform specific and it's much stranger to test and develop against locally. Each platform has a different way to…

> Like the article says, I think serverless has it's place, but I don't think it's for most applications I feel this way about many of the more popular trends over the last decade or so. A technology becomes popular because a really large organization uses it to solve problems that only really exist st that scale. Then they talk about how it works and many tend to take that as an indicator that the solution is ideal,…

A lot of it is because platforms need a wedge against AWS/Azure.

Take edge computing for example – most apps are CRUD apps that talk to a single database, but vendors keep pushing for running things on edge servers talking to databases with eventual consistency because hey, at least AWS doesn't offer that! (or it would cost you 10k/month to run that on AWS)

Re: Leaving serverless led to performance improvement and a simplified architecture

#202

Post by ch4s3 »

_heimdall wrote: post #193
jjice wrote: post #100

Like the article says, I think serverless has it's place, but I don't think it's for most applications. I can't see myself _ever_ using serverless services as a core part of my application for pretty much any startup, if I can avoid it. The infrastructure overhead is actually worse, IMO. Everything is so platform specific and it's much stranger to test and develop against locally. Each platform has a different way to…

> Like the article says, I think serverless has it's place, but I don't think it's for most applications I feel this way about many of the more popular trends over the last decade or so. A technology becomes popular because a really large organization uses it to solve problems that only really exist st that scale. Then they talk about how it works and many tend to take that as an indicator that the solution is ideal,…

That’s funny, I agree with all of those but tailwind which I find to be super convenient for small teams where most people aren’t css experts. Maybe that’s a specific problem but it feels pretty general to want convenience on top of base css stuff without writing and making it all yourself.

Re: Leaving serverless led to performance improvement and a simplified architecture

#203

Post by j45 »

sunrunner wrote: post #172
themafia wrote: post #167

Earlier quoted context omitted.

> Easy peasy. /s It actually is though. I don't need to build a custom upload client, I don't need to manage restart behavior, I get automatic restarts if any of the background workers fail, I have a dead letter queue built in to catch unusual failures, I can tie it all together with a common API that's a first class component of the system. Working in the cloud forces you to address the hard problems first. If you a…

> Working in the cloud forces you to address the hard problems first. It also forces you to address all the non-existent problems first, the ones you just wish you had like all the larger companies that genuinely have to deal with thousands of file upload per second. And don't forget all the new infrastructure you added to do the job of just receiving the file in your app server and putting it into the place it was g…

Enjoyed reading this, thanks for writing it.

People often don't know how different might be easier for their case.

Following others, or the best practices, when they might not apply in their case can lead to to social proof architecture a little too often.

Re: Leaving serverless led to performance improvement and a simplified architecture

#204

Post by jamesblonde »

themafia wrote: post #175
sunrunner wrote: post #172

Earlier quoted context omitted.

> Working in the cloud forces you to address the hard problems first. It also forces you to address all the non-existent problems first, the ones you just wish you had like all the larger companies that genuinely have to deal with thousands of file upload per second. And don't forget all the new infrastructure you added to do the job of just receiving the file in your app server and putting it into the place it was g…

> the ones you just wish you had You will have these problems. Not as often as the larger companies but to imagine that they simply don't exist is the opposite of sound engineering. > if they never got called in the first place due to misconfiguration Centralized logging is built into all these platforms. Debugging these issues is one of the things that becomes absurdly easy. > likely locked into your upload system T…

> The protocol provided by S3 is available through dozens of vendors.

But not all of the S3 API is supported by other vendors - the asynchronous triggers for lambdas and the CloudTrail logs that you write code to parse.

Re: Leaving serverless led to performance improvement and a simplified architecture

#205

Post by daxfohl »

daxfohl wrote: post #132
fabian2k wrote: post #6

Earlier quoted context omitted.

At that point, why should I use serverless at all? If I have to think about the lifetime of the servers running my serverless functions?

It can be good for connecting AWS stuff to AWS stuff. "On s3 update, sync change to dynamo" or something. But even then, now you've got a separate coding, testing, deployment, monitoring, alerting, debugging pipeline from your main codebase, so is it actually worth it? But no, I'd not put any API services/entrypoints on a lambda, ever. Maybe you could manufacture a scenario where like the API gets hit by one huge spi…

Actually I don't even think connecting AWS services to each other is a good reason in most cases. I've seen too many cases where things like this start off as a simple solution, but eventually you get a use case where some s3 updates should not sync to dynamo. And so then you've got to figure out a way to thread some "hints" through to the lambda, either metadata on the s3 blob, or put it in a redis instance that the lambda can query, etc., and it gets all convoluted. In those kinds of scenarios, it's almost always better just to have the logic that writes to s3 also update dynamo. That way it's all in one place, can be stepped through in a debugger, gets deployed together, etc.

There are probably exceptions, but I can't think of a single case where doing this kind of thing in a lambda didn't cause problems at some point, whereas I can't really think of an instance where putting this kind of logic directly into my main app has caused any regrets.

Re: Leaving serverless led to performance improvement and a simplified architecture

#206

Post by scuff3d »

Serverless seems to me like the tech version of the classic sales technique. You see it every Black Friday, get them in the door with the cheap alluring offers, then upsell the shit out of them. And in the case of serverless, lock them with as many provider specific services as possible.

I feel like we're headed the same direction with AI right now. It creates as many problems as it solves, and the solution is always to pay them for the newer faster model and use more tokens. With all the new AI security threats coming to light we'll start seeing them offer solutions for that too. They'll sell you the threats and the solutions, and the entire developer community will thank them for it.

Re: Leaving serverless led to performance improvement and a simplified architecture

#207

Post by scuff3d »

gloomyday wrote: post #60

I think developers are drowning in tools to make things "easy", when in truth many problems are already easy with the most basic stuff in our tool belt (a compiler, some bash scripts, and some libraries). You can always build up from there. This tooling fetish hurts both companies and developers.

I'm working on a project right now that should be two or three services running on a VM. Instead we have 40+ services spread across a K8s cluster with all the Helm Chart, ArgoCD, CICD pipeline fun that comes with it.

It drives me absolutely nuts. But hey if the company wants to pay me to add all that stuff to my resume, I guess I shouldn't complain.

Re: Leaving serverless led to performance improvement and a simplified architecture

#208

Post by conradfr »

leptons wrote: post #144
jjice wrote: post #100

Like the article says, I think serverless has it's place, but I don't think it's for most applications. I can't see myself _ever_ using serverless services as a core part of my application for pretty much any startup, if I can avoid it. The infrastructure overhead is actually worse, IMO. Everything is so platform specific and it's much stranger to test and develop against locally. Each platform has a different way to…

I've been doing AWS Lambda since it started up over 10 years ago. It solves a lot of problems for me. I don't ever have to worry about load balancing or scaling. I don't have to maintain a server. When it isn't being used, I am not paying for it. I've been running a pretty sophisticated project on Lambda for years, and I pay about $0.00/month for it. Most of the ~$0.45/mo I pay to AWS is in S3. Lambda code is extreme…

What scaling and load balancing do you need if you pay $0 per month?

Re: Leaving serverless led to performance improvement and a simplified architecture

#209

Post by renlo »

wredcoll wrote: post #103
jjice wrote: post #100

Like the article says, I think serverless has it's place, but I don't think it's for most applications. I can't see myself _ever_ using serverless services as a core part of my application for pretty much any startup, if I can avoid it. The infrastructure overhead is actually worse, IMO. Everything is so platform specific and it's much stranger to test and develop against locally. Each platform has a different way to…

Let me tell you about all the fun I'm having trying to execute my amazon lambda app locally so I can test before deploying...

Localstack makes that pretty easy. Before Localstack I had a pre-staging environment (dev) target I would deploy to. Their free/community offering includes a Lambda environment; you deploy your dev "Lambda" locally to docker, using the same terraform / deploy flow you'd normally use but pointed at a Localstack server which mimics the AWS API instead. Some of their other offerings require you to pay though (Cloudfront, ECS, others) and I don't use those, yet at least.
Post reply on HN