Ask HN: Is serverless worth it in some cases? | Hacker News Reader

Ask HN: Is serverless worth it in some cases?

7 pointscodegeek18 comments

I know serverless etc. gets flak from a lot of us (for genuine reasons) and in many cases, you are better off with servers. However, there must be cases when it does make sense.

What would those be ? The idea is def. exciting that I can put an API behind something like Lambda and may be an API gateway and boom, it can scale infinitely. Is anyone truly getting good ROI from serverless ? Would love to hear positive use cases and benefits.

View on HN

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 don't have cold starts it would be cheaper to host away from serverless. If you do have cold starts your traffic levels might be better served on a traditional server. Are there that many people who fit somewhere in the middle where serverless makes sense?

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

Maybe I am wrong I haven’t found a proper framework or facility to get a web application backed by Postgres to serverless without a lot of frustration

You want to stick to tech that doesn't need a VPC in my experience -- as soon as your Lambda's are VPC-bound things gets messy and slow.

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.

Us too - a B2B app with quite spikey load.

We use a Lambda monolith with NestJS framework behind API GW and CloudFront - it works pretty well for us... Bits of SQS, SNS and DynamoDB all hang together quite nicely...

What kind of mobile game? Candy Crush and Fortnite have very different server requirements.

A non-realtime one with no PvP.

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.

Reply on news.ycombinator.com