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

151–160 of 272 posts

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

#151

Post by hinkley »

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…

We became the flagship customer for a division of AWS that was responsible for managing SSL certificates. We were doing vanity URLs and vanity URLs generally require individual SSL certificates for each domain name. We needed thousands and AWS tools for cert management at the time was really only happy with hundreds and they had backlog items to fix it but those were behind a year or two of other work. It took them about three months to get far enough along for our immediate needs. It's surprising the parts of AWS that have not adjusted to outliers that don't seem really to be that exceptional.

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

#152

Post by hinkley »

mulmen wrote: post #146
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.

Some architectural arguments I kick myself for not establishing a bibliography of all of my justifications. The thing with mastering something is that you copy the rules into the intuitive part of your brain and you no longer have to reason through it step by step like Socrates's lectures. You just know and you do.

The biggest one I regret is "communicating through the file system is 10x dumber than you think it is, even if you think you know how dumb it is." I should have a three page bibliography on that. Mostly people don't challenge you on this, but I had one brilliant moron at my last job who did, and all I could do was stare at him like he had three heads.

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

#153

Post by marcosdumay »

brap wrote: post #142
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 c…

Oh, it's a very good rule of thumb. It's probably not universal, but it's really close to it.

the problem is that nobody designs the dependencies flexible enough to let them run without fine-control. And the main application always wants to change the way it uses the dependencies, so it always needs further flexibility.

You can build an exception to the rule if you explicitly try. But I'm not sure one appears naturally. The natural way to migrate your server into the edge is by migrating entire workloads, dependencies included. You can split the work like you said, you just can't split single endpoints.

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

#154

Post by bunderbunder »

sunrunner wrote: post #148
bunderbunder wrote: post #116

Earlier quoted context omitted.

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 (wo…

What's even more dangerous is when senior tech leadership used to be technical but haven't actually got their hands dirty in 5 or 10 years, and don't realize that this means they aren't actually holding all the cards when they try to dictate these kinds of tactical, detail-oriented technical decisions.

I see this a lot in startups that grew big before they had a chance to grow up.

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

#155

Post by stuartjohnson12 »

reactordev wrote: post #145
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…

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

> Uploads to an S3 bucket can trigger a lambda… don’t complicate things.

I read this and was getting ready to angrily start beating my keyboard. The best satire is hard to detect.

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

#156

Post by jasonjayr »

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…

Just to help future readers, there is an ecosystem of "tus" uploaders and endpoints, that chunk uploads, and feature resumeable uploads, that would be ideal for this kind of restriction:

https://tus.io/

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

#157

Post by hvb2 »

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…

Lambda does get expensive when call volume goes up. If you're handling 10rps typically, ECS becomes a lot cheaper.

It obviously depends on how long your request last but still.

As for running it locally, it depends what your upstream is. I can tell you that I've had to work around bugs in the marshalling from MSK for example. You would never find that locally. If it's just web requests, sure.

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

#158

Post by isoprophlex »

reactordev wrote: post #145
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…

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

Every day we stray further from the light

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

#159

Post by hvb2 »

cogman10 wrote: post #115
Esophagus4 wrote: post #71

Earlier quoted context omitted.

For certain workloads :) And that is actually the advantage of serverless, in my mind. For some low-traffic workloads, you can host for next to nothing. Per invocation, it is expensive, but if you only have a few invocations of a workload that isn't very latency sensitive, you can run an entirely serverless architecture for pennies per month. Where people get burned is moving high traffic volumes to serverless... the…

Exactly. I've always found that how people want to use lambda is the exact opposite of how to use it cost effectively. I've seen a lot of people want to use lambdas as rest endpoints and effectively replace their entire API with a cluster of lambdas. But that's about the most expensive way to use a lambda! 1 request, one lambda. Where these things are useful is when you say "I have this daily data pull and ETL that I…

> Where these things are useful

All the backend processing and just general 'glue' in your architectures

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

#160

Post by Froztnova »

sgarland wrote: post #74
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.

It’s that, and the fact that precious few people seem to understand fundamentals anymore, which is itself fed by the desire to outsource everything to 3rd parties. You can build an entire stack where the only thing you’ve actually made is the core application, and even that is likely to be influenced if not built by AI. The industry is creating learned helplessness.

The other troubling thing is that if you do invest time into learning fundamentals, you'll be penalized for it because it won't be what you're interviewed on and probably won't be what you're expected to do on the job.
Post reply on HN