Is serverless worth it in some cases?

I'd much rather offload more specific responsibilities to my lambda functions than put my entire API in lambda. I've worked on several projects that grew beyond the limitations of lambda / serverless and required extensive rework. Other commenters have mentioned cold start and runtime issues. Another issue is that if you have constant load, your lambdas become defacto instances, but are much more expensive. Lambda is great for "bursty" compute. If you have constant load but you want scaling, you could try running your workload on a cluster.

Serverless is an absolutely awesome solution for certain kinds of problems (e.g., asynchronous event routing, among many many others). But if you find yourself wondering how to deal with cold-start times, or how to deal with a very long running call, then you have probably strayed down the wrong path.

If you are building an application that spans multiple services I would discourage against serverless. Testing and Debugging serverless is a nightmare and not worth the time spent to understand where things went wrong. Add to it the half baked libraries and frameworks that are supposed to make you deploy apps in a sinch.

You’d be better off with a monolith or bunch of services running independently woven together by some message bus

Aside from my service business, I am a solo bootstrapper building an MVP in the professional services space. Think support services for SMBs. Even with my beginner/intermediate skills, I've got multiple workflows processing data/creating reports in a matter of minutes. I am guessing when up and running, the framework and analytical processes will save me 2 staffers of time (and the headache of not dealing with people who don't see the potential for the business or think in growth terms). My overall structure consists of a combo of Eventbridge, Step Functions, Lambdas (naturally), S3, and Dynamodb, Amplify, not to mention accessing a bunch of third party APIs.

There is no way I could have attempted this without serverless. Yes, a number of pieces are costly relative to running my own servers but if the idea is viable, I have a path to significant cost savings. Such as turning the step functions from standard to express workflows, moving lambdas to arm64, swapping lambdas for service integrations in step functions state machines and then moving to fargate containers (mix of standard and spot) and lastly to EC2. The overall tools available are a great balance of speed to market vs. cost. The flexibility is infinite (aka so many ways of doing things has slowed this noob down somewhat) and I am grateful to AWS for providing so much capability to a relative blind truffle pig in tech.

I use serverless messaging services extensively (AWS SQS, GCP Pub/Sub etc.) and these are very robust and easy to use solutions. They are also not very expensive. Coupled with Lambda or GCF, it takes away a lot of pain. Of course there are downsides. It's about what tradeoffs are feasible.

Event driven/message driven stateless systems are the primary use case. The ROI of it is complicated at best. For green field development with seasoned/serverless trained engineers there's no question that you should use serverless. It gets muddy when you have to factor in legacy applications, new/untrained engineers, or applications where state or persistence must be maintained. I am a huge advocate for serverless because, when done correctly, it can very easy to maintain, deploy, develop and save you a lot of money in the process.

I would not use serverless for running anything long-running such as databases, cache stores, batch processing that takes more than just a few minutes, services that must maintain state, etc.

Short running cron jobs, jobs or functions you want to fire off adhoc with API calls without building all of the boilerplate around that, or an environment for execution of arbitrary code provided by third parties you want to sandbox.

We're running a 1M DAU mobile game with a monolithic Lambda function with zero issues.

Zero action was needed when we launched, extra functions spun up automatically and that was it.

We could scale 10-30x without needing to request more function quota from AWS.

I see the business befit in serverless in a lot of ways but I don't think its necessarily a good thing for developers, its a good thing for business in some cases but its highly proprietary.

I run a few AWS Lambda functions approximately 850k times per week as part of my business.

Running a server would've been a pain to validate the need for the problem I'm solving, and I managed to scale that up beyond 2 million times per week as my customer's needs changed without my input.

Eventually, it'll be more economical to use a server 24/7 of course, but it'd cost significantly more than the premium I'm paying for serverless to move over (at the moment).

You can't just put your API in Lambda and expect to to scale infinitely. Serverless runs on servers, so it very much depends what that API actually does. For example, if your API runs a query on your database, the limit to how it scales will depend on how quickly your database instance can run that query.

Because of the benefits, I basically default to serverless and consider alternatives as necessary.