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

141–150 of 272 posts

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

#141

Post by brap »

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…

Don’t all “serverless” platforms accept docker images? I know Cloud Run does.

If I understand correctly your concern is mostly with “serverless functions” which abstracts away even more.

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

#142

Post by brap »

daxfohl wrote: post #134

I don't think "serverless is bad" is necessarily the full lesson here. The bigger lesson is when a service has dependencies, moving that service closer to the client (without also moving those dependencies) will counterintuitively make the e2e experience slower, not faster. Prefer building physically near your dependencies. If that's not fast enough, then you have to figure out how to move or sync all your dependenci…

I don’t know if this is a good rule of thumb, I think it really depends on what you use the dependencies for, how often you need them, etc.

Consider for example a single DB dependency. Should the server be close to the DB or the client? It depends. How often does the client need the server? How often does the server need the DB? Which usecases are expected to be fast and which can be sacrificed as slow? What can be cached in the server? What can be cached in the client? etc etc.

And then of course you can split and do some things on the server and some in the edge…

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

#143

Post by jrs235 »

ecshafer wrote: post #96
whstl wrote: post #49

Earlier quoted context omitted.

> the documentation is closer to marketing than truthful technical documentation I participated in AWS training and certification given by AWS for a company to obtain a government contract and I can 100% say that the PAID TRAINING itself is also 100% marketing and developer evangelism.

100% agree with you. I took a corporate training, and at one point crammed for the developer cert. It it just marketing. There is never a question where the answer is "Just run this service on EC2 yourself". It is about maximizing your usage of AWS services.

Platform dependency/lockin is never mentioned as a con[cern].

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

#144

Post by leptons »

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 extremely easy to test locally, if you write it that way. I just run the file locally and it does what it would do in the cloud, there is literally no difference. But of course, YMMV depending on how you approach it.

I created my own build tools for Lambda about a month after Lambda was introduced as a product. It's been working great ever since. The workflow is very simple. When I update a file locally, it simply updates the Lambda function almost instantly. I can then test the Lambda live in the cloud. If I want to run the function locally, I just run it and it behaves the same way it would in the cloud. There's no need to run the function in AWS, if you write the code so it can be run locally. It's really, really easy to do, but I guess some people haven't figured that out yet.

I've never liked containers. It's always been way more opaque than writing Lambdas that can run locally as well as in the cloud.

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

#145

Post by reactordev »

akdev1l wrote: post #87
voodooEntity wrote: post #37

As someone who worked with serverless for multiple years (mostly amazon lambda but others too) i can absolutely apporove the authors points. While it "takes away" some work from you, it adds this work on other points to solve the "artificial induced problems". Another example i hit was a hard upload limit. Ported an application to a serverless variant, had an import API for huge customer exports. Shouldnt be a proble…

The way to work around this issue is to provide a presigned S3 url Have the users upload to s3 directly and then they can either POST you what they uploaded or you can find some other means of correlating the input (eg: files in s3 are prefixed with the request id or something) I agree this is annoying and maybe I’ve been in AWS ecosystem for too long. However having an API that accepts an unbounded amount of data is…

Uploads to an S3 bucket can trigger a lambda… don’t complicate things. The upload trigger can tell the system about the upload and the client can continue on their day.

Uploader on the client uses presigned url. S3 triggers lambda. Lambda function takes file path and tells background workers about it either via queue, mq, rest, gRPC, or doing the lift in workflow etl functions.

Easy peasy. /s

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

#146

Post by mulmen »

voodooEntity wrote: post #37

As someone who worked with serverless for multiple years (mostly amazon lambda but others too) i can absolutely apporove the authors points. While it "takes away" some work from you, it adds this work on other points to solve the "artificial induced problems". Another example i hit was a hard upload limit. Ported an application to a serverless variant, had an import API for huge customer exports. Shouldnt be a proble…

The hardest problem in computer science is coping a file from one computer to another.

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

#147

Post by conductr »

voodooEntity wrote: post #102
akdev1l wrote: post #87

Earlier quoted context omitted.

The way to work around this issue is to provide a presigned S3 url Have the users upload to s3 directly and then they can either POST you what they uploaded or you can find some other means of correlating the input (eg: files in s3 are prefixed with the request id or something) I agree this is annoying and maybe I’ve been in AWS ecosystem for too long. However having an API that accepts an unbounded amount of data is…

Well i partly agree, and if i would be the one building the counterpart, i prolly had used presigned s3 urls also. In this specific case im getting oldschool file upload request from software that was partly written before the 2000s - noones gonne adjust anything any more. And ye, just accepting giant size uploads is far from good in terms of "Security" like DoS - but ye we talking about stupidly somewhere between 10…

I find with these types of customers it’s always easier to just ask them to save files locally and grant me privileges to read the data. Sometimes they’ll be on Google, Dropbox, Microsoft, etc and I also run a SFTP for this in case they want to move them over to my service.

Then I either batch/schedule the processing or give them an endpoint to just to trigger it (/data/import?filename=demo.csv)

It’s actually so common that I just have the “data exchange” conversation and let them decide which fits their needs best. Most of it is available for self service configuration.

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

#148

Post by sunrunner »

bunderbunder wrote: post #116
kburman wrote: post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

I would not assume this was a "rookie mistake". I've been here once or twice, and a common story is that engineers don't want to do it a certain way, but management overrules them for some vague hand-wavy reason like, "This way is more modern." Another common story is that you know you're not choosing the most [scalable|robust|performant|whatever] design, but ancillary constraints like time and money push you into a…

> but management overrules them for some vague hand-wavy reason like, "This way is more modern."

This matches my experience. It's very difficult to argue against costly and/or inappropriate technical decisions in environments where the 'Senior Tech Leadership' team are just not that technical but believe they are, and so are influenced by every current industry trend masquerading as either 'scalable', 'modern' or (worst of all) 'best practice'.

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

#149

Post by hinkley »

"Taking hand off of boiling kettle decreased anxiety and increased focus in 97% of study participants."

Stephen King's Dark Tower series never resonated with me and I got stuck in book two. But it has one of my favorite philosophical insults of all time:

"Those who [X] have forgotten the faces of their fathers."

I feel like there's a collective amnesia just beginning to wear off as people remember the Fallacies of Distributed Computing and basic facts about multitasking. And that amnesia absolutely feels to me as if everyone has forgotten the faces of their fathers.

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

#150

Post by vlovich123 »

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…

But they weren’t building an application. They were building a library that would get integrated in other stateful server applications not running on Cloudflare. The performance benefit comes from running their auth colocated with their customers, not anything else.
Post reply on HN