3 ms·

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

by jjice 1y ago

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 test, and the abstraction layers that exist (unless this has changed recently) always had pitfalls, since there are no true standards. I'd much rather have a docker image as my deliverable "executable" so I can test, but still abstract away some stuff, like environment setup. Giving me a minimal Linux environment and filesystem feels like the most comfortable level of abstraction for me to develop well and also deploy and run in production effectively. I can also run that on demand or (most commonly) run that as a server that sits and waits for requests.

wredcoll 1y ago
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...
- renlo 1y ago
  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.
  - meekins 1y ago
    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.
  - discomrobertul8 1y ago
    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.
    - wredcoll 1y ago
      How do you keep the accounts in sync? Isn't deploying to remote a fairly slow process?
  - ljm 1y ago
    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.
dprotaso 1y ago
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.
- tacticus 1y ago
  Lambda shifting to this model would be such a nice future. though even the lambda variants that can run containers have some painful issues.
  - dprotaso 1y ago
    What are the issues?
brap 1y ago
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.
- lifty 1y ago
  Cloud Run is more akin to AWS ECS (on Fargate), which also uses containers.
leptons 1y ago
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.
- hvb2 1y ago
  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.
- thunderfork 1y ago
  [dead]
- conradfr 1y ago
  What scaling and load balancing do you need if you pay $0 per month?
vlovich123 1y ago
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.
_heimdall 1y ago
> 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.
- khamidou 1y ago
  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)
  - fragmede 1y ago
    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."
- ch4s3 1y ago
  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.
  - _heimdall 1y ago
    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.
meekins 1y ago
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.
- awkward 1y ago
  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.

by jjice 1y ago

wredcoll 1y ago

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

renlo 1y ago
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.
- meekins 1y ago
  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.
- discomrobertul8 1y ago
  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.
  - wredcoll 1y ago
    How do you keep the accounts in sync? Isn't deploying to remote a fairly slow process?
- ljm 1y ago
  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.

dprotaso 1y ago

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.

tacticus 1y ago
Lambda shifting to this model would be such a nice future. though even the lambda variants that can run containers have some painful issues.
- dprotaso 1y ago
  What are the issues?

brap 1y ago

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.

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

leptons 1y ago

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.

hvb2 1y ago
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.
thunderfork 1y ago
[dead]
conradfr 1y ago
What scaling and load balancing do you need if you pay $0 per month?

vlovich123 1y ago

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.

_heimdall 1y ago

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

khamidou 1y ago
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)
- fragmede 1y ago
  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."
ch4s3 1y ago
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.
- _heimdall 1y ago
  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.

meekins 1y ago

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.

awkward 1y ago
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.