The Serverless Start-Up – Down with Servers | Hacker News Reader

The Serverless Start-Up – Down with Servers

highscalability.com

22 pointsdsr125 comments

I'm wondering what they're doing that they're estimating is 1 MB of data uploaded for data in, and 10 MB of data downloaded based off the following:

| We guess that such a client uses 1000 API calls per month (that's editing only), requires therefore 1GB of data in, and needs about 10 GB of traffic-related data out.

I agree with Sgoettschkes regarding Heroku, I've been using it in production for over a year without any issues at all and found it to be the lowest level of entry for scaling apps.

For example, I just spun up some new analytics software I wrote last week in golang and it peaks around 50k req/min, averages around 23k req/min, I'm using 4 nodes which realistically could probably handle 100k req/min without issue since in peak it's consuming about 50% of available resources to us as it is right now, but $100/mo is well worth it for the piece of mind, then combined with a $20/mo percona mysql server on digitalocean that averages around 4% cpu load, we're paying $120/mo to handle on the low end 927,360,000 http requests/month and all I have to do is a git push and the code automatically sets up the DB structure and DB indexes when booting the app up.

It's cool that they're using all these new technologies, but based on their numbers for me to have this software running on their setup it could realistically cost millions of dollars a month, and that's still removing the costs of cloudfront and s3 since it's not relevant in my case. Maybe on paper meshing a bunch of AWS technologies that big named companies use sounds great, but it seems like a high price to pay for the ability to say you're using these services.

If you are running on Heroku or Google App Engine, you don't have a server as well. AWS Lambda abstracts the concept of a server even more, but yeah...

I also think the costs are pretty high. Of course I have no idea how much traffic and requests where calculated, so I am just guessing. As cloudfront and S3 do the heavy lifting, a cheap server or two for actual editing of the content should be enough. And they don't need to scale on the same level as there won't be that much changing for customers, so paying more than 10,000$ for that with 100.000 customers seems pretty high.

But I get what the idea behind it was, and it seems to work pretty good. Also nice to have really low costs in the beginning :)

If you would have the same setup, but with EC2 instead of lambda, you would still have the same CloudFront pricing, so you should compare the $410 lambda costs for 100.000 customers with the costs of some EC2 servers plus ELB. Of course, then, you will miss the benefits of 1. no server-maintenance, 2. no down-time or scaling issues and 3. initial startup costs - without customers.

For all the German fellows: I'll give a talk about "exactly" this topic including a hands-on sample at the "Monster on Rails" Meetup this week in Münster - http://www.meetup.com/Monster-on-Rails-Web-Development-Meetu...

Now, all you need is a nice open-source Framework :) http://www.serverless.com

Reply on news.ycombinator.com