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

211–220 of 272 posts

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

#211

Post by TZubiri »

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 once started working at a company that sold one of those visual programming things, and during training I was tasked with making a simple program, I was a bit overwhelmed with the amount of bugs and lack of tools to make basic features, so I made a prototype of the application I wanted in python, the plan was to port it later, I got it in a couple of days.

The tool developers weren't keen of the idea, they told me "Yeah, I can solve the problem with a script too, the challenge is to do it with our tool". And I thought it was kind of funny how they admitted that the premise of the tool didn't work.

It's like this holy grail panacea that arises 20 times every month, developers want to invent something that will avoid the work of actually developing, so they sunk-cost-fallacy themselves into a deep hole out of which they can only escape if they admit that they are tasked with automating, they cannot meta-automate themselves, and that they will have to gasp do some things manually and repeatedly, like any other working class.

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

#212

Post by swiftcoder »

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…

> 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

The problem here is that pretty much all services have dependencies - if they didn't, you could have already moved that logic client-side.

This bites edge-compute architectures really hard. You move compute closer to the client, but far from the DB, and in doing so your overall latency is almost always worse.

The most latency-friendly architecture is almost always going to be an in-memory DB on a monolithic server (albeit this comes with its own challenges around scaling and redundancy)

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

#213

Post by [deleted] »

hinkley wrote: post #151
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 a…

[deleted]

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

#214

Post by lexicality »

scuff3d wrote: post #207
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.

Yeah, the previous company I worked for started with a Django monolith that someone had come in and taken an axe to essentially at random until there were 20 Django "microservices" that had to constantly talk to each other in order to do any operation while trying to maintain consistency across a gigantic k8s cluster. They were even all still connected to the same original database that had served the monolith!

Unfortunately my campaign of "what if we stuck all the django back together and just had one big server" got cut short by being laid off because they'd spent too much money on AWS and couldn't afford employees any more.

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

#215

Post by fragmede »

stuartjohnson12 wrote: post #155
reactordev wrote: post #145

Earlier quoted context omitted.

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.

unfortunately they ruined it at the end with that /s

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

#216

Post by whstl »

themafia wrote: post #167
reactordev wrote: post #145

Earlier quoted context omitted.

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

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

> I don't need to build a custom upload client

GP said this is an app from the 2000s.

For S3 you do need to generate a presigned URL, so you would have to add this logic there somewhere instead of "just having a generic HTTP upload endpoint".

Unless the solution is "don't have the problem in the first place" the cloud limitations are just getting in the way here.

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

#217

Post by [deleted] »

kburman wrote: post #46
czhu12 wrote: post #33

Earlier quoted context omitted.

> Putting a latency-critical API on a stateless edge runtime Isn’t this the whole point of serverless edge? It’s understood to be more complex, with more vendor lockin, and more expensive. Trade off is that it’s better supported and faster by being on the edge. Why would anyone bother to learn a proprietary platform for non critical, latency agnostic service?

You're confusing network proximity with application architecture. Edge deployment helps connection latency. Stateless runtime destroys it by forcing every cache access through the network. The whole point of edge is NOT to make latency-critical APIs with heavy state requirements faster. It's to make stateless operations faster. Using it for the former is exactly the mismatch I'm describing. Their 30ms+ cache reads vs…

[deleted]

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

#218

Post by nigga1234 »

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…

[flagged]

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

#219

Post by fragmede »

khamidou wrote: post #201
_heimdall wrote: post #193

Earlier quoted context omitted.

> 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)

For the problem of eventual consistency, Google's Spanner and Firestore both provide strong or tunable global consistency. Instead of "eventual consistency because AWS doesn’t offer that", GCP has "we give you strong consistency at scale."
Post reply on HN