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

251–260 of 272 posts

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

#251

Post by 827a »

mattmanser wrote: post #245
827a wrote: post #222

Earlier quoted context omitted.

I deeply disagree. Docker’s key innovation is not its isolation; it’s the packaging. There is no other language-agnostic way to say “here’s code, run it on the internet”. Solutions prior to Docker (eg buildpacks) were not so much language agnostic as they were language aware. Even if you allow yourself the disadvantage that any non-Docker solution won’t be language-agnostic: how do you get the code bundle to your ser…

Running script 1 is harder than running script 2? It's all the same stuff. Docker just wraps what you'd do in a VM. For the slight advantage of deploying every server with a single line, you've still got to write the mutli-line build script, just for docker instead. Plus all the downsides of docker.

Docker images are self-running. Infrastructure systems do not have to be told how to run a Docker image; they can just run them. Scripts, on the other hand, are not; at the most simple level because you'd have to inform your infrastructure system what the name of the script is, but more comprehensively and typically because there's often dependencies the run script implies of its environment, but does not (and, frankly, cannot) express. Docker solves this.

> Docker just wraps what you'd do in a VM.

Docker is not a VM.

> Plus all the downsides of docker.

Of which you've managed to elucidate zero, so thanks for that.

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

#252

Post by wredcoll »

discomrobertul8 wrote: post #235
renlo wrote: post #209

Earlier quoted context omitted.

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…

I had a horrible time with Localstack. It's very similar to AWS but not exactly the same, so you hit all kinds of annoying edges and subtle bugs or differences and you're basically just doing multi-cloud at that point. The same kinds of problems you encounter with slightly inaccurate mocks in automated testing. The better solution in my experience is to create an entirely different account to your production environm…

How do you keep the accounts in sync? Isn't deploying to remote a fairly slow process?

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

#253

Post by raw_anon_1111 »

lumost wrote: post #249
raw_anon_1111 wrote: post #236

Earlier quoted context omitted.

And while you are being sarcastic, this is the Right Way to use queues. Upload file to S3 -> trigger an SNS message for fanout if you need it -> SNS -> SQS trigger -> SQS to ETL jobs. The ETL job can then be hosted using Lambda (easiest) or ECS/Docker/Fargate (still easy and scales on demand) or even a set of EC2 instances that scale based on the items in a queue (don’t do this unless you have a legacy app that can’t…

If I have a user facing upload button, why can't I simply have a webserver that receives the data and pushes it into s3 via multi-part upload. Something that can be written in a framework of your choice in 10 minutes with 0 setup? For uploads under 50 MB you could also skip the multipart upload and take a naive approach without taking a significant hit.

You can - you generate the pre-signed S3 URL and they upload it to the place your URL tells it to.

https://fullstackdojo.medium.com/s3-upload-with-presigned-ur...

And before you cry “lock in”, S3 API compatible services are a dime a dozen outside of AWS including GCP and even Backblaze B2.

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

#254

Post by ljm »

jrm4 wrote: post #183

This really is confirming my theory that the problem here is that "serverless" is so ill-defined that even it's own name is nonsensical. Like, there are still servers. Appears just about as intelligent as calling them "electricity-less." I mean, yes, I no longer think about electricity when deploying things, but that doesn't tell me anything meaningful about what's going on here.

It's more like cgi-bin as a service.

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

#255

Post by not_kurt_godel »

whstl wrote: post #216
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…

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

The solution is to use the appropriate tool for the job. If you're locked in to highly crusty legacy software, it's inevitably going to require workarounds. There are good technical reasons why arbitrary-size single-part file uploads are now considered an anti-pattern. If you must support them, then don't be shocked if you wind up needing EC2 or other lower-level service as a point of ingress into your otherwise-serverless ecosystem.

If we want to treat the architectural peculiarities of GP's stack as an indictment of serverless in general, then we could just as well point to the limitations of running LAMP on a single machine as an indictment of servers in general (which obviously would be silly, since LAMP is still useful for some applications, as are bare metal servers).

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

#256

Post by naasking »

whstl wrote: post #233
callamdelaney wrote: post #229

I once got a job for a company whose entire stack was aws lambda. Not like a normal 'hey we have this flask application which handles 100 endpoints and we just use lambda to handle a call' - more like 'every singe route or function is its own lambda function'. I left inside 2 weeks.

Saw this with an infamous 996 AI startup where the founders vibe coded their app. Their app had like 3 or 4 pages, that was all, but every endpoint was a Lambda call. Every frontend log entry was a Lambda call. Every job execution was a Lambda call that called a dozen others. That was their idea of an architecture. Even with 100k dollars a month on cloud, more than their entire dev team cost. The constant firefightin…

In principle, serverless should be very efficient and cheap if all code is running the same VM. The heterogeneous architecture must make it expensive. Maybe serverless using WASM will one day make it cheap.

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

#257

Post by hunterpayne »

danpalmer wrote: post #178

30ms p99 for a cache read! Serverless might have been a problem, but I'm not sure it was the problem. In my experience a p99 of 2ms is more typical - 30ms is the sort of time I'd expect for p99 on a database query in production serving. You don't need process-local caches to get the sort of performance they're looking for, and there are good reasons why most teams avoid stateful processing, it's much harder to get ri…

Fun fact, the overhead for a DB query (not including the network latency) is about 250 microseconds (or 0.25ms). And a typical DB kernel can do at least 16MB/core second of throughput. So that 30ms query I would expect is scanning several GB of data to find its results. Try doing that yourself and your latency would probably grow into seconds. Systems programming is hard...

PS moving from stateful processing to something with a distributed cache is moving from RAM to network. That's at least a 10x drop off in throughput.

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

#258

Post by hunterpayne »

wltr wrote: post #125
seethishat wrote: post #30

Earlier quoted context omitted.

Servers go down. What is the plan to get them "backup" and running ;)

But is this not needed with the so-called cloud systems?

Only if that system is stateless. If you have any sort of internal memory that sticks around between requests, then either you face a cold start problem (because of empty caches) or you somehow need to persist that state somewhere. And persisting that state either means you need a backup solution or your latency is terrible because you are hitting network for something that only needs to hit RAM.

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

#259

Post by aeldidi »

827a wrote: post #222
mattmanser wrote: post #140

Earlier quoted context omitted.

Docker is much like microservices. Appropriate for a subset of apps and yet touted as being 'the norm' when it shouldn't be. There are drawbacks to using docker, such as security patching and operational overhead. And if you're blindly putting it into every project, how are you mitigating the risks it introduces? Worse, the big reason it was useful, managing dependency hell, has largely been solved by making develope…

I deeply disagree. Docker’s key innovation is not its isolation; it’s the packaging. There is no other language-agnostic way to say “here’s code, run it on the internet”. Solutions prior to Docker (eg buildpacks) were not so much language agnostic as they were language aware. Even if you allow yourself the disadvantage that any non-Docker solution won’t be language-agnostic: how do you get the code bundle to your ser…

This is a really nice insight. I think years of linux have kind of numbed me to this. I've spent so much time on systems which use systemd now that going back to an Alpine Linux box always takes me a second to adjust, even though I know more or less how to do everything on there. I think docker's done a lot to help with that though since the interface is the same everywhere. A typical setup for me now is to have the web server running on the host and everything else behind docker, since that gives me the benefit of using the OS's configuration and security updates for everything exposed to the outside world (firewalls, etc).

Another thing about packaging. I've started noticing myself subconsciously adding even a trivial Dockerfile for most of my projects now just in case I want to run it later and not hassle with installing anything. That way it gives me a "known working" copy which I can more or less rely on to run if I need to. It took a while for me to get to that point though

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

#260

Post by aeldidi »

mattmanser wrote: post #245
827a wrote: post #222

Earlier quoted context omitted.

I deeply disagree. Docker’s key innovation is not its isolation; it’s the packaging. There is no other language-agnostic way to say “here’s code, run it on the internet”. Solutions prior to Docker (eg buildpacks) were not so much language agnostic as they were language aware. Even if you allow yourself the disadvantage that any non-Docker solution won’t be language-agnostic: how do you get the code bundle to your ser…

Running script 1 is harder than running script 2? It's all the same stuff. Docker just wraps what you'd do in a VM. For the slight advantage of deploying every server with a single line, you've still got to write the mutli-line build script, just for docker instead. Plus all the downsides of docker.

There's another idea too, that docker is essentially a userspace service manager. It makes things like sandboxing, logging, restarting, etc the same everywhere, which makes having that multi-line build script more valuable.

In a sense it's just the "worse is better" solution[0], where instead of applying the good practices (sandboxing, isolation, good packaging conventions, etc) which leads to those benefits, you just wrap everything in a VM/service manager/packaging format which gives it to you anyway. I don't think it's inherently good or bad, although I understand why it leaves a bad taste in people's mouths.

[0]: https://en.wikipedia.org/wiki/Worse_is_better

Post reply on HN