Hacker News Reader

Comment by SwellJoe | Hacker News Reader

AWS Lambda is cool and all, but aren't people doing the math on this? Lambda seems like a really expensive way to deliver almost anything. Likewise, the AWS API Gateway is expensive, but at least provides some additional capabilities. Lambda seems like its profitable niche would be very small; limited computing environment, very high cost (relative to almost every other way to host an API), and having to learn a whole bunch of new APIs and processes to make it all spin.

Am I missing something?

View on HN

I've found Lambda to be really ridiculously fucking cheap. We moved image resizing onto it and saved thousands a month.

Don't compare the cost of Lambda per 100ms to the cost of a virtual machine per month since Lambda only charges as you use it. You'd have to have the CPU pegged at 100% usage to make that a fair comparison. Mind you even if you took the cost of Lambda per 100ms and multiplied that out for a monthly cost it's still about the same as an EC2 instance of the same capacity. (Eg. if I had a 1GB Lambda running for a total of 1 month compute time in the uswest2 region it'd cost $32).

Oh and the cost of API gateway is $3.50 per million requests and the bandwidth cost is completely negligible for us (we redirect to the resized image hosted on S3, fronted by cloudfront). We get 3 million image resizing requests a day. That's over 30 per second. It would take a lot of VMs to handle that (image resizing isn't trivial). Or we could just pay the whole $11.50.

I have to ask have you done the math? Lambda beats everything in cost except for some funky solutions using unreliable and less scalable lowendbox.com services.

I would say that it strongly depends on the type of requests you are handling.

Saying that you can run a 1GB lambda for 1 month nonstop for $32 does not impress me, and its kind of strange that it impresses you.

You could run a t2.micro with the same RAM for $6/mo if you reserve it for a year. And if you want to give that t2.micro a workload where it only has to respond to 1 request at a time, the same terms we are affording the lambda system, then it's no comparison.

Now, for responding to disparate requests every once in a while? Lambda is ideal. You can spin it up and you don't have to pay when it is isn't processing requests. But continuous requests? Hard no.

We can argue that the cost overhead at full load is worth it for the ability to "infinitely" scale with no effort. Alright, that's fine. But let's not pretend that it is "cheaper".

I don't have a strong opinion one way or the other, but I'd like to point out that micro instances also have diminished networking (besides processing/memory). Depending on what you're doing, this could be a factor.

We can afford a t2.medium or an m3.medium at the price he quoted, which will have better RAM, processing capability, and probably equivalent networking capability, so that isn't really the takeaway point.

The point is, his lambda setup has vastly better capability than your instance, should he need it. Unless you're able to bring instances up fast enough to address your need, which clearly doesn't put you in the same ballpark as him.

You can't compare it to a t2.micro because that's not what you're getting with lambda. t2.micro is a single, weak piece of hardware meant to handle 30 requests per second? I forsee issues there. For the same traffic would be called in parallel when the spikes require it, which is something you would not get without scaling the t2 micro and programming concurrency. And that is ultimately where the comparison comes in. Because hardware needs to be able to accommodate unpredictable traffic, it is running all the time, and it is beefier than it needs to be. The performance buffer to account for unpredictable traffic is completely eradicated when using FaaS.

I still use dedicated hardware where I deem it appropriate, but the proof is in the pudding. For the right services, pulling them out into lambdas is proving to be a huge savings and performance boost for countless architectures.

Whenever I've looked half-seriously at any cloud offering, I've come to the conclusion that it's the data transfer/bandwidth that kills vis-a-vis dedicated services. If you don't need ~10TB/month, then sure - it doesn't really matter. If you do then you need to get a lot of reduced ops work for your effort.

I suppose that if while testing/starting out you use little bandwidth, and any additional bandwidth/users comes with income - it doesn't really matter that a chunk of that goes to AWS, and not to your business.

For those that actually do run non-trivial things on AWS (or other clouds) - do feel this is an accurate assessment? That bandwidth is still really expensive in the cloud?

What makes you say Lambda is more expensive than things like EC2?

Obviously lambda is a hammer, not a swiss army knife - you shouldn't shoehorn it into your app just because it's the new tech on the block. But the use case isn't niche at all.

We're using lambda for our service to ingest and process Hearthstone replays. An HTTP POST is sent to the API gateway, this triggers a lambda which parses a 0.5-2MB file, scrapes the data in it and stores data in the db + converts it to another format. The whole process takes 3-6 seconds. Lambda lets us easily scale to dozens of requests per second without having to worry about anything other than the DB server. Our frontend/app servers don't need to be touched.

The alternative would be to provision and manage a lot of EC2 instances to handle the load. We'd have to worry about provisioning them dynamically so that it's economically viable. We'd have to manage the load balancing ourselves. Lambda's been a huge time saver.

PS: Let it be known that Lambda only supports python 2.7, not python 3, and that really frickin sucks. Get your shit together, Amazon.

"Let it be known that Lambda only supports python 2.7, not python 3, and that really frickin sucks. Get your shit together, Amazon."

Node 4 support came, what, a month ago? It's pretty ridiculous.

I specifically don't understand the Python 3 situation. They support Python 2, it can't be that complicated to have a separate Python 3 runtime.

There is no significant benefit to python 3 over python 2.

Except that it is the way forward and many people choose to write python3 compatible code.

You're wrong, and it's irrelevant anyway. Our app is in Python 3. Having to support Python 2 just because lambda doesn't support 3.x is a pain.

Unicode....?

I mean, that's reason enough. Python 2's string processing suuuuuuucks.

Asyncio?

https://docs.python.org/3/library/asyncio.html

Do you leave your database server publicly open (but password protected obviously), or can you use IAM policies for this as well?

A quick google search of more 3-letter-acronyms than there are in the US government yields this:

- https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds.html

- https://docs.aws.amazon.com/lambda/latest/dg/access-control-...

I've got (virtual) servers all over the place. I run my tiny little "needs a minute" tasks on one or more of those. It's nice, I guess to make it a wholly isolated thing, but I rarely actually want to go to the trouble to design it to be isolated. My little jobs often need at least some of the rest of my production environment to be available (database, logs, libs, something). Making a Lambda thing just for those things seems like something I'd rarely want to go to extra effort for.

But, if building on a very large scale with strict isolation requirements for your individual tasks it would make sense. Which is the niche I'm talking about; maybe it's just bigger than I assume it is.

I think the appeal of Lambda is that most services get zero-to-low usage, and so something which is "pay only for usage" may be a net win over dedicated computing resources if you use it for the right parts.

I've had a number of startup ideas that went nowhere, and it would've been handy to test & demo them without springing for the full $17/month for an EC2 t2.micro instance. Usually they have some key aspect that's prevented me from running them on Lambda (eg. you can't exactly run a hacked Node.js binary on Lambda, and sending push notifications from it requires going through SNS and adopting its API), but if I could run arbitrary code & third-party packages and pay for only the computing time I use, it's an attractive proposition.

In general you use AWS for convenience anyway - if you're concerned about minimizing costs, you can sometimes get 10x price/performance ratios by moving to dedicated hosting.

Really $17 for a micro? Baby gce machine is $4.

Yup. AWS prices suck, in general. If it weren't for the large (multi-terabyte) dataset I need for my current project that they're hosting for free on aws-publicdatasets, I'd probably switch to Google Cloud. I may yet switch, which illustrates the danger of relying on proprietary APIs like Lambda.

    google micro (1 cpu, 0.6GB ram): $0.006/hr
    amazon nano  (1 cpu, 0.5GB ram): $0.0065/hour
    
    https://cloud.google.com/compute/pricing
    https://aws.amazon.com/ec2/pricing/
    in both cases, +disk, +traffic

Not exactly a crippling difference.

Except google gives you a discount just for using the instance. Amazon requires prepayment

Swings and roundabouts. AWS gets flak for having expensive data transfer costs; Google's data transfer costs are even higher (both listed at same links above).

My point is that when you compare apples to apples, it's really not all that different.

Oh interesting...are nano instances new? Didn't see them last time I was looking for a "just throw up a demo" machine.

They've been around for a few months, but like all new AWS things, they're being slowly rolled out across regions, so may not be available everywhere. Flick through the 'region' dropdown in that pricing link to see if they're available where you want them.

The micro went from 0.6G to 1G ram in the 't2' generation, and the nano fills the need people have for the old micro size. I use them for bastion/nat boxes :)

As already mentioned, $4-$5 gets you a tiny instance all month. But, for me, I just run my small jobs on my existing virtual machines, generally speaking. I have a bunch of servers, they already have my necessary libraries, files, and database information and caching and such setup. Running a cronjob, or something triggered or pulled from a queue, is trivial and practically free.

My feeling on this is that if the job is small enough and infrequent enough, I don't care about its impact on other services so I can run it anywhere (and it's effectively free in such a case), and if it's large enough and frequent enough then setting up for it in Lambda every time is wasteful and I probably want a system (even if a small one) dedicated to the job, for probably less money. There's probably a sweet spot in there somewhere...but, it's not high on my list of things to integrate into my infrastructure.

Yes, you're missing the fact that you don't have to run servers all the time.

Unless your CPUs are constantly at 100% utilization, there is some slack in your infrastructure. Lambda you literally only pay for the compute time you actually use.

I migrated a smallish app to Lambda from EC2 and shaved my AWS bill from >$100/m to <$5/m.

AFAIK Lambda is the only way to react to events on S3 buckets. A lot of what I've seen it used for is as a mechanism for kicking off a workflow off of a new item in S3.

SNS can be consumed from anywhere not just Lambda.

you can push S3 events to SQS and then consume it anywhere (eg we had file converters running on Heroku, listening to S3 events through SQS)

Likewise, Lambda can execute events from SNS, Cloudwatch Events, Dynamo and a lot more, including the Amazon workflow system.

Reply on news.ycombinator.com