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

191–200 of 272 posts

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

#191

Post by reactordev »

MrDarcy wrote: post #177
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

If you don’t do it this way you fail the system design interview.

Nope, you didn’t use terracottax so you failed anyway. 6 months before you can reapply in case the first humiliation wasn’t enough. Boss was looking for AWS Glue in there and you didn’t use it.

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

#192

Post by fijiaarone »

pjmlp wrote: post #11
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?

Because it is still less management effort than taking full control of the whole infrastructure. Usually a decision factor between more serverless, or more DevOps salaries.

Pay 1 devops engineer 10% more and you'll get more than twice the benefit of 2 average engineers.

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

#193

Post by _heimdall »

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, regardless of context.

GraphQL, react, Tailwind, NextJS, and many others. They solve specific problems and those may be problems you have. No tool is a universally useful solution though, it takes real experience and knowledge to discern what your problems are and how to best tackle them.

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

#194

Post by markstos »

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…

I also thought Lambda looked promising at first, but we ultimately abandoned all our Lambda projects and started using containers as needed.

Lambda still requires that you need to update the Node runtime every year or two, while with your own containers, you can decide on your own upgrade schedule.

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

#195

Post by evantbyrne »

TheTaytay wrote: post #138
evantbyrne wrote: post #84

Earlier quoted context omitted.

ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.

Sounds useful! I hear mixed things about Swarm. You like it? Edit: found it. Cool! https://rove.dev/

Yeah I haven't had any issues with Swarm. Heard good things from people running substantial clusters. Would be interested in hearing about what rough edges people have run into as well!

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

#196

Post by evantbyrne »

torginus wrote: post #180
evantbyrne wrote: post #84

Earlier quoted context omitted.

ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.

Honestly I didn't have a good experience with ECS (Fargate) - I remember I had to write a ton of CF deployment scripts+bash scripts, setting up a private AWS docker registry, having a terrible time debugging while my CF deployment always failed, deploys taking forever, finding out that AWS is too miserly to pay Docker to use the official repo so they are stuck on the free tier, meaning sometimes deploys would fail du…

A lot of AWS requires way too much config. It is a mystery to me why AWS doesn't lean into extending the capabilities of App Runner. I actually built a whole continuous deployment PaaS for AWS ECS with a Heroku-like UX, ended up shutting it down eventually because although useful, their pricing is pretty awful. What I need to do is figure out how to bring it back, just minus the hosted service so I can use it on corporate projects that require AWS...

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

#197

Post by jmg_ »

> We built chproxy specifically because ClickHouse doesn't like thousands of tiny inserts. It's a Go service that buffers events and sends them in large batches. Each Cloudflare Worker would send individual analytics events to chproxy, which would then aggregate and send them to ClickHouse.

While I understand how this isn't the only thing that needed to be buffered, for Clickhouse data specifically I'd be curious why they built a separate service rather than use asynchronous inserts:

https://clickhouse.com/docs/optimize/asynchronous-inserts

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

#198

Post by [deleted] »

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…

[deleted]

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

#199

Post by hexbin010 »

Froztnova wrote: post #160
sgarland wrote: post #74

Earlier quoted context omitted.

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.

[dead]

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

#200

Post by mikeiz404 »

Hey "vercel security checkpoint", I'm repeatedly getting a code 99 "Failed to verify your browser" on an iphone with a VPN exits in California and Canada via proton VPN and Firefox Focus.

What gives?

``` sfo1::1760587368-8k6JCK3uO27oMpuTbnS4Hb3X2K9bVsc ```

Post reply on HN