Comment by stephenr | Hacker News Reader

Comment by stephenr | Hacker News Reader

Tech, to Business: So, hear me out guys. With the power of "The Cloud", we can break our compute workload down to the function level, and have them run as a service for us, rather than say an entire VM, or even an entire container.

And because it's a "Cloud" service, we pay for what we use, so if there's no workload for the functions to service, there's no cost. We just pay for the time the tiny little container is active.

Business: Ok, that sounds like it can save us money, and you seem confident in the technology, let's go with that.

1 Month Later:

Business: Why do all these actions take so much longer to complete? They used to load instantly with a "Done" message, now they're measurably delayed to respond.

Tech: Well, you see the containers that run our functions stop running once they've finished their work and it looks like theres nothing more for them to do, so when new work comes in theres a delay while the container starts.

Business: You mean like how my Dell takes 5 minutes to boot up?

Tech: Well, kind of, but its much quicker than that obviously, and it's not a whole operating system, it's just some processes in a process namespace...

Business: <visibly zoning out>

Tech: Ok, well tell you what we can solve this, we can setup something to periodically ping the system so the containers running our functions don't ever get de-activated, and that way they'll be ready to service requests immediately, all the time.

Business: OK great that sounds like what we want.

1 Month Later:

Finance: Why did our bill for "functions" suddenly spike in the last month, compared to when we started using it?

Tech: Well you see now we have to keep the function containers running 24x7 so they're quick to respond, because $Business complained they're too slow to start up from inactive state.

Tech Onlookers: ..... <blink>.... Wat... Why... Why would you do that?

(Edited to add:)

Tech Entrepreneur: I can outsource that process of keeping your function containers active for you, for just $1/container/month!

There's also a parallel universe where Tech Entrepreneur#2 sits in darkness for a few months while building a competing product with Rails or another comparable stack and gets everything up and running 10x faster on a single server and it ends up costing less per month.

My takeaway is that lambdas are pointless if you’re latency sensitive.

If you’re not latency sensitive, such as queue to queue lambdas, then go for it.

Yes. It is pretty much useless for web servers as even the scale out from 1 vm container to 2 will require a cold start. In hindsight, this is kind of obvious as you don't expect them to keep a bunch of containers loaded with your dependencies ready to serve requests. They might offer something like that eventually, but at that point your setup is basically the same as ec2 servers loaded with your service in autoscaling groups so why not just use that?

Pretty sketchy marketing in my opinion.

> you don't expect them to keep a bunch of containers loaded with your dependencies ready to serve requests

I think you would expect them to at least use swap for density and always keep one extra instance running and ready to serve requests. It's not like people generate functions on the fly, so it shouldn't even cost anything extra. Swap will help with unnecessary things kept in memory.

1: I've created a lot of experement functions that I hardly ever use and have ones that are no longer used so that would be expensive.

2. The last company I worked for isolated functions to vms on a customer level. That way, if someone hacked their way past the function container, they would then still have to hack their way past the VM container to access another customers data which is what you would have to do anyways on the public VM offering.

That's all plausible except the price issue. Say, you keep 10 containers alive, so you make 10x 100ms calls every 5 minutes. That's gonna be $0.20 per month. 20 cents.

Internal math at my org says that lambdas cost about 20% more than an equivalent amount of EC2 power at full utilization. Now hitting full utilization is very hard, but the point is that lambas are only cheaper compared to underutilized EC2 hosts.

If you don't scale up at 80% usage you either have extremely non-volatile workloads (in which case, yes, of course, use EC2s), or you're doing it wrong.

Any many people (like me), think Kubernetes is a better way to increase utilization compared to Lambdas. Especially with things like autoscaling, you can keep a kubernetes cluster pretty highly utilized, and no cold startup dance.

I'll pay 20% more for a system that I don't have to manage - the cost of patching and general EC2 maintenance is easily higher than that to me.

That's ultimately the misuse 9f the technology though right. Unless it's a freak, business changing, spike in usage due to exposure or whatever that lambda are not critical path suitable and don't seem to have been implemented with that intent.

For example if your sign up process is lambda you did you got your cost benefit analysis wrong on anything other than a prototype or mvp, but if your 'change your profile photo', something that maybe happens a handful of times across a month on average per user at best, and you implemented that as your lambda to reduce load and delay scaling needs on your core infrastructure then that feels like you did it right.

This assumes AWS will never reach a point where they decide to stop subsidising this behaviour by keeping the instances alive.

More like:

Business: OK great that sounds like what we want.

1 Month Later:

Business: We were really successful with hundreds of requests a minute, but for some reason the delay came back!

Tech: Oh...warming up doesn't scale. Scratches head and walks away.

The ping costs on AWS to keep VMs warm are literally just pennies.

Reply on news.ycombinator.com