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

231–240 of 272 posts

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

#231

Post by _heimdall »

ch4s3 wrote: post #202
_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,…

That’s funny, I agree with all of those but tailwind which I find to be super convenient for small teams where most people aren’t css experts. Maybe that’s a specific problem but it feels pretty general to want convenience on top of base css stuff without writing and making it all yourself.

Is the main benefit you find related to the resets and design system built in to tailwind?

I've always found that I need to know CSS to really use tailwind, and I need to additionally know tailwind-specific syntax to do anything somewhat complex related to layout or conditional styling.

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

#233

Post by whstl »

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 firefighting, downtimes and billing issues were enough to keep the team busy instead of making new features.

I was freelancing but I didn't take the job after the "CTO" gave me a tour.

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

#234

Post by whstl »

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 spreading like wildfire, in all areas, not just development.

50 tools in ops/backend to make my life easier.

75 tools in the frontend to make my life easier.

45 different tools used by product to make my life easier.

20 used by HR to make my life easier.

10 used by office management to make my life easier.

None of them really do.

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

#235

Post by discomrobertul8 »

renlo wrote: post #209
wredcoll wrote: post #103

Earlier quoted context omitted.

Let me tell you about all the fun I'm having trying to execute my amazon lambda app locally so I can test before deploying...

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 environments and just deploy things there to test. At least that way you're dealing with the real SQS, S3, etc, and if you have integration problems there, they're actually real things you need to fix for it to work in prod - not just weird bandaids to make it work with Localstack too.

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

#236

Post by raw_anon_1111 »

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

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 be containerized).

If your client only supports SFTP, there is the SFTP Transfer Service on AWS that will allow them to send the file via SFTP and it is automatically copied to an S3 bucket.

Alternatively, there are products that treat S3 as a mountable directory and they can just use whatever copy commands on their end to copy the file to a “folder”

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

#237

Post by raw_anon_1111 »

markstos wrote: post #194
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.

Not if you deploy your container to Lambda…

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

#238

Post by awkward »

meekins wrote: post #223
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…

As someone with years of experience on serverless stuff on AWS I might be a bit biased BUT I'd argue serverless is the sweet spot for most applications. You need to remember however that most applications aren't your typical startups or other software products but simply some rather boring line of business software nobody outside the company owning it knows of. Concerning how IT departments in most non-software compa…

I like your angle, but most applications is a big difference from most companies. Serverless comes after deciding whether or not to break up the monolith, and after breaking up engineering into separate teams. It's a good way to manage apps with high variance in traffic while keeping cloud spend down.

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

#239

Post by raw_anon_1111 »

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.

Running on EC2 is hardly ever the correct answer. I’ve had to deploy to EC2 over the years and every method is a pain.

Just use Docker, there are plenty of services where deployment is simply - “hand your container to us and we run it”.

Even the most complicated popular ways to deploy Docker are simpler than deploying to a VM and a lot less error prone.

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

#240

Post by raw_anon_1111 »

sgarland wrote: post #68
randomtoast wrote: post #55

Earlier quoted context omitted.

If you're looking for a middle ground between VMs and serverless, ECS Fargate is a good option. Because a container is always running, you won't experience any cold start times.

Yes, though unless you’re provisioning your own EC2s for them to run on, you have no guarantee about the server generation, and IME AWS tends to provision older stuff for Fargate. This may or may not matter to you depending on your application’s needs, but there is a significant performance difference between, say, an m4 family (Haswell / Broadwell) and an m7i family (Sapphire Rapids) - literally a decade of hardware…

https://aws.amazon.com/blogs/aws/announcing-amazon-ecs-manag...
Post reply on HN