Hacker News Reader

Comment by PaulRobinson | Hacker News Reader

This is what people are missing on Lambda. It's pay-to-play, and for 90% of the sites out there, they're paying too much in comparison.

If you're running server instances 24x7 for an application that is doing < 25 requests/minute on average, you would probably find your hosting costs come down (perhaps to zero) and your reliability would increase considerably if you moved to Lambda-style applications.

serverless.io is a decent framework to get started (allows for local dev and testing, manages deployment) and is agnostic in terms of deployment target: AWS, IBM, Google coming soon, etc.

The only reason we're not rolling it out everywhere at work is because it assumes all developers are deploying directly from their term with god-like CloudFormation access. Nope, nope, nooope. We just need to build the deploy pipeline for it, and then off we go.

View on HN

But are they really paying too much? I can't think of a lot of products out there, especially those that have a recurring subscription, that don't required some sort of database. So you need a server running a database anyway. It seems that the subscription logic would be a very negligible addition to the instance you have to be running anyway.

To me it seems like the only sweet spot for lambda on a large scale would be for those that have consistent usage of a small instance that have some extra functions that need to be highly scalable and are very inconsistent.

For data storage, you can use aws DynamoDb (NoSQL), which has some generous monthly free tier.

You could use DynamoDB and S3 for persistence if you're taking the AWS route.

There are multiple alternatives to running your own DB service, and again, all pay-per-use.

In the original article the author suggested on a successful subscription a write to the MailChimp API (because that's the product). In that example, MailChimp is the DB. You don't have to run a copy of a DB locally if you architect things like that. Obviously if the call fails, you need to think about what you fall back to, which is why error handling is such a critical piece of the the Lambda ecosystem - as it should be for every ecosystem, really.

In this case you should really just dump the subscription on a queue (SQS) and process the payment to mailchimp on a different thread that can deal with errors.

Did you mean serverless.com? serverless.io is a parked domain...

This is doubly true with their generous free tier. It applies per-region so for some tasks you can spread workloads out across regions and reduce costs. Cronitor runs about 6 million multi-second lambda invocations a month for $20.

It's serverless.com

Reply on news.ycombinator.com