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

241–250 of 272 posts

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

#241

Post by raw_anon_1111 »

evantbyrne wrote: post #84
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.

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.

I’ve used a modified version of this for 8 years - I didn’t write it. Updating your ECS Docker image is just passing in the parameter of your new image and updating the cloudformation stack.

https://github.com/1Strategy/fargate-cloudformation-example/...

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

#242

Post by ljm »

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.

I think the entire concept of HTML and CSS when it comes to browser-based app development (as opposed to styling documents) is just not that ergonomic compared to a native equivalent.

It might have seen a lot of improvements over the years to make it more flexible but I can't imagine any serious project raw dogging CSS in favour of pulling in some kind of framework or abstraction to make it manageable.

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

#243

Post by ljm »

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 dealt with a microservice style serverless backend that was spread out across roughly 50 Go-based lambdas, one per API endpoint, with a few more for SQS and Cognito triggers. Was deployed via CloudFormation. Testing locally was an absolute nightmare even with Localstack.

Made me wish for a simple VPS, an ansible script to setup nginx and fail2ban and all that shit, and a deployment pipeline that scp'd a single binary into the right place.

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

#244

Post by mattmanser »

dalberto wrote: post #162
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…

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

What are you isolating it from? Everything runs on it's own box these days anyway.

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

#245

Post by mattmanser »

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…

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.

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

#246

Post by lumost »

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've observed massive back office pipelines using dozens of interconnected lambda, batching, streaming, distributed storage for ephemeral data and other rube Goldberg contraptions to build what was ultimately a cron job on a modest server running for 1 hour.

Being in the cloud doesn't mean you need to accept timeouts/limitations. CDK+fargate can easily run an ephemeral container to perform some offline processing.

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

#247

Post by JTbane »

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.

Also, if you're trying to run lean and cheap you can go very far with just a simple VPS like Hetzner.

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

#248

Post by dhruv_ahuja »

whstl wrote: post #234
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.

I find myself exhausted after a time, when I have to switch between 2-3 apps and many more tabs trying to co-ordinate things or when debugging issues with a teammate. And this is with me working professionally for only ~3 years.

I think the tools are nice to use early on but quickly become tough to manage as I get caught up with work, and can't keep up with the best way to manage them. Takes a lot of mental effort and context switching to manage updates or track things everywhere.

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

#249

Post by lumost »

raw_anon_1111 wrote: post #236
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

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.

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

#250

Post by ch4s3 »

_heimdall wrote: post #231
ch4s3 wrote: post #202

Earlier quoted context omitted.

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.

You need to know a little css but way less. I don’t think I’ve ever gotten backed into using !important with tailwind.
Post reply on HN