Hacker News Reader

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

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

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.

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.

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, ECS, others) and I don't use those, yet at least.

Developer-specific sandbox environments with hot code reload is the golden standard here but Localstack is great if you can't do that due to (usually IT deparment-related, not technical) reasons.

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.

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

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.

That’s why Knative (Serverless on Kubernetes) accepts containers. It’s the standard packaging format that lets you lift and shift apps to many different platforms.

Lambda shifting to this model would be such a nice future. though even the lambda variants that can run containers have some painful issues.

What are the issues?

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 companies are, the minimal operational burden is a massive advantage and the productivity is great once you have a team with enough cloud expertise. Think bespoke e-commerce backends, product information management systems or data platforms with teams of a handful of developers taking responsibility for the whole application lifecycle.

The cloud expertise part is a hard requirement though but luckily on AWS the curriculum is somewhat standardized through developer and solutions architect certifications. That helps if you need to do handovers to maintenance or similar.

That said, even as a serverless fan, I immediately thought of containers when the performance requirements came up in the article. Same with the earlier trending "serverless sucks" about video processing on AWS. Most of the time serverless is great but it's definitely not a silver bullet.

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.

I've been doing AWS Lambda since it started up over 10 years ago. It solves a lot of problems for me. I don't ever have to worry about load balancing or scaling. I don't have to maintain a server. When it isn't being used, I am not paying for it. I've been running a pretty sophisticated project on Lambda for years, and I pay about $0.00/month for it. Most of the ~$0.45/mo I pay to AWS is in S3.

Lambda code is extremely easy to test locally, if you write it that way. I just run the file locally and it does what it would do in the cloud, there is literally no difference. But of course, YMMV depending on how you approach it.

I created my own build tools for Lambda about a month after Lambda was introduced as a product. It's been working great ever since. The workflow is very simple. When I update a file locally, it simply updates the Lambda function almost instantly. I can then test the Lambda live in the cloud. If I want to run the function locally, I just run it and it behaves the same way it would in the cloud. There's no need to run the function in AWS, if you write the code so it can be run locally. It's really, really easy to do, but I guess some people haven't figured that out yet.

I've never liked containers. It's always been way more opaque than writing Lambdas that can run locally as well as in the cloud.

Lambda does get expensive when call volume goes up. If you're handling 10rps typically, ECS becomes a lot cheaper.

It obviously depends on how long your request last but still.

As for running it locally, it depends what your upstream is. I can tell you that I've had to work around bugs in the marshalling from MSK for example. You would never find that locally. If it's just web requests, sure.

What scaling and load balancing do you need if you pay $0 per month?

But they weren’t building an application. They were building a library that would get integrated in other stateful server applications not running on Cloudflare. The performance benefit comes from running their auth colocated with their customers, not anything else.

Don’t all “serverless” platforms accept docker images? I know Cloud Run does.

If I understand correctly your concern is mostly with “serverless functions” which abstracts away even more.

Cloud Run is more akin to AWS ECS (on Fargate), which also uses containers.