Hacker News new | comments | show | ask | jobs | submit login

In my book, the innovation in Lambda is, above everything else, about the billing model. My company moved the work of 40 dedicated servers onto Lambda and in doing so decimated our costs. Paying for 1500 cores (our current AWS limit) in 100ms increments has been a game changer.

I'm sure there are upsides to adopting the same programming model with your own hardware or VMs, but the financial benefit of Lambda will not be there.

There is no disputing the financial model behind AWS Lambda is revolutionary. I know of a visitor NDA signing service that charges $5 per visitor. The backend runs entirely on AWS API Gateway and Lamdba and their cost per visitor transaction to AWS is $0.25. Think about how powerful this is! Now you can develop an app in your spare time and bring it to market for practically nothing. Once developed, your fix infrastructure costs are zero.

That said, there are financial benefits on premise too. Short lived processes that need 1 CPU and 512Mb memory are ideal candidates for oversubscription. If you had a server where CPU utilization never peaked beyond 60% and 15Gb memory was free then you could fit 20 Lambda functions in this 'slack capacity' without resource contention. Driving up utilization when the cost of the server is sunk is effectively capacity for free.

I'm struggling to imagine what about an NDA signing service would cost 25c per visitor. 25c buys you ~4 GB-hours in Lambda!

Isn't the cost significantly higher? Even with bulk pricing, lambda was more than 8x more expensive than ec2 for constant computing.

It depends on your traffic.

If you have a million 1ms transactions per second, you'll spend $500k/month, or $6m/year.


That pricing calculator isn't correct.

From the AWS Lambda pricing page:

    Duration is calculated from the time your code begins
    executing until it returns or otherwise terminates,
    rounded up to the nearest 100ms

So it would really be closed to $1 million per month.

That's only if you compare raw compute. When you create a VM on AWS it will get <10% utilization (many times close to 1%). Sometimes you need to factor in for varying utilization so you need to overprovision but if you have many services and the deployment unit is the VM then you end up having tons of VMs doing nothing. With containers the deployment model becomes more granular, hence you can share the VM and increase utilization, but you'll still pay for idle time. With hosted functions (like lambda) you don't pay idle time, so in many cases it's much more efficient.

Indeed, if you host your own "lambda" implementation, you may or may not have cost improvements. In this case it may be just a matter of operational efficiency.

It's highly dependent on your usage. If you want a crib job to run that isn't on your production server and it's to run every few hours. Great to schedule that on AWS lambda. EC2 would be more expensive.

Trying to process 1000s of requests on AWS lambda could end up hitting the limits of lambda and cost you more.

I use lambda to process exif data in images as they are uploaded to S3. Which is awesome because it doesn't require services running on the web server and costs me nothing because it comes into the free tier of AWS lambda.

Oh and AWS database access sucks balls. Because you cannot pool connections you must open/close db connections. If you fail to close you will exhaust the database connections quickly and kill your app until the connections expire.

Phillip - have you tried making your database connection in 'static' code? With container re-use (see https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...), you should see multiple invokes going to the same container, and you can use the same connection for all of them. That will only happen if your traffic is high enough.

I find it kinda strange, that in every official doc they talk about how not to rely on this, but every example I find relies on thsi.

I wonder why Google Compute charges a minimum of ten minutes to spin up an instance. I understand there is some setup cost, but ten minutes is $0.00056 for the cheapest (f1-micro) instance [1]. I know this sounds sort of cheap, but that's the cost just to deliver the interface (the VM) that is going to be used. That's a relatively large amount of money to spend on not having any work done at all yet. A diskless VM, which can just send data for storage to a database over HTTP, shouldn't require much setup work, as it really just is the execution of CPU instructions (with the OS being the CPU interface rather than JavaScript).

Couldn't someone write a virtualized VM that runs inside Lambda, thus providing zero (or Lambda-equivalent) startup costs for generic VMs? Then the VM would just be a function running inside Lambda, transforming incoming user data and then storing the result in a database, after which it would disappear.

Or maybe the OS just is the problem? One model of bypassing it is Lambda-like services, which would be the more centralized solution, while the more decentralized solution (of the two) would be bare metal/unikernels, which basically achieve the same thing: (close to) zero startup time/cost (~30 ms for a HaLVM unikernel).

[1] https://cloud.google.com/compute/pricing#billingmodel

I talk about cost being the main factor in this post about the benefits of Serverless. It's definitely the driving factor: https://www.iron.io/what-is-serverless-computing/

Wasn't this the very earliest billing model in multiuser computing? Give us a program to run on our big iron, we charge you for the CPU time it consumes?

This is how university supercomputers work currently. You don't get dedicated hosts; your project has a budget of CPU hours.

That's interesting - it's the first time I read about a 10x cost improvement.

Would you mind sharing a bit more details?

p.s. if you're in the Bay Area I wouldn't mind getting together over coffee/drinks for a deeper chat.

There are financial benefits to being able to very easily overcommit resources (although Lambda is just one way to do that).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact