Hacker News Reader

Comment by pea | Hacker News Reader

Great to see Lambda stepping up their serverless game. We're big fans of this approach and are hacking on something similar to this at StackHut[1], but:

* Mostly OSS to avoid lock-in

* Git integration

* Full stack specification (OS, dependencies, etc.)

* Python/ES6 support (Ruby and PHP coming)

* Client libs so you can call your functions 'natively' in other languages.

It would be awesome to hear what people would like us to build for them. Here is a blog-post on how to build a PDF -> image converter: http://blog.stackhut.com/it-was-meant-to-be/

[1] https://stackhut.com

View on HN

I think your pricing scheme[1] could put a lot of people off. I fall into the category where I'd be fine on the free tier (< 10 private services), and yet I don't want a free service.

I know if it's free, then it's going to be under some kind of fair usage policy, and you're going to rate limit me or have some kind of restrictions eventually. There's no way it can be sustainably free if I start to push it really hard. I'd prefer to just know the limits upfront, or have some kind of usage based pricing.

[1]. http://stackhut.com/#/pricing

Hey Jake -- thanks for your feedback, that is really helpful.

We're going to add some better pricing. How would you like this to work?

- per month, flat rate, ups w/ usage - per request - per compute / storage

We really like the idea of only paying for the compute you actually use a la lambda; one of my gripes with Heroku was having to pay $x when the server was only in use for short bursts. Why should I pay for downtime?

That said, we've actually had many people say they would prefer per month, as it is more predictable and they are worried it could spiral out of control.

I would be super interested to hear your thoughts.

I'm not sure that per-request would work; because the resources that a request takes can vary wildly in resources used / time taken. PiCloud (somewhat similar idea) used to charge based on processing time essentially (down to the millisecond I believe).

I personally think that is the correct kind of pricing for something like this; but monthly plans including X time/requests would likely be a good idea.

Different person, but I'd prefer per-request with N requests packaged for free and (N+1)th request charged if charging is enabled, or returning error if I want to stay free. (so there are no surprise charges for service spamming)

Reply on news.ycombinator.com