Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firecracker – Lightweight Virtualization for Serverless Computing

aws.amazon.com

Post reply on HN
Print view View original

51–60 of 114 posts

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#51

Post by cddotdotslash »

vdfs wrote: post #48
cddotdotslash wrote: post #40

Earlier quoted context omitted.

We got around this with a bit of a hack - use a CloudWatch event to trigger a dummy invocation of your function every five minutes. This keeps the container "hot" and reduces the start time (and is negligible cost-wise). This won't fix the cold starts when the function scales up, but it does reduce latency for 99% of our API requests.

Isn't using a server better in this case? Or Lambda have some benefits in this setup?

It's still insanely cheap. You could have millions of executions per month and only pay $0.50. But if you needed to, it could scale up to billions of invocation nearly instantly, something a standard server would have trouble doing as easily as Lambda does.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#52

Post by cbzbc »

ex-aws-now-goog wrote: post #50
fapjacks wrote: post #43

Earlier quoted context omitted.

Right. In the end, AWS saw containerization as an existential threat, and serverless is its response to the commoditization of AWS (and other specialized cloud vendors) by containerization technology. Serverless helps AWS re-couple your application back into the specialized AWS vendor environment, once more requiring you to keep specialized and costly AWS-specific knowledge on-hand in order to build and deploy your a…

Having worked at AWS, I have to disagree with you. No-one that I worked with saw containerization as a threat. And why would they? At the VM level you can already paper over differences between cloud providers and I don't think that anyone at any of the large cloud providers lies awake at night worried about this. I also don't understand why serverless would couple you to a particular cloud provider. All the big clou…

The point is that each serverless implementation is different enough that even if you are using the same feature, the cruft around that is different enough to provide an certain amount of lock in.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#54

Post by ex-aws-now-goog »

cbzbc wrote: post #52
ex-aws-now-goog wrote: post #50

Earlier quoted context omitted.

Having worked at AWS, I have to disagree with you. No-one that I worked with saw containerization as a threat. And why would they? At the VM level you can already paper over differences between cloud providers and I don't think that anyone at any of the large cloud providers lies awake at night worried about this. I also don't understand why serverless would couple you to a particular cloud provider. All the big clou…

The point is that each serverless implementation is different enough that even if you are using the same feature, the cruft around that is different enough to provide an certain amount of lock in.

Sure and this is to be expected. It costs time and money to align yourself with someone else's implementation and unless your customers demand alignment (e.g. S3-compatible storage interfaces), you're probably not going bother.

Again, this comes down to cost-benefit calculations. If some companies find that proprietary feature X from cloud Y provides a bigger (perceived) return on investment than not using feature X, then they are likely to use it. If company X later shafts them, they have to swallow more costs to migrate away but hopefully (for them) they took this possibility into consideration when they made their original decision.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#55

Post by tanilama »

fapjacks wrote: post #43
dm3 wrote: post #36

Earlier quoted context omitted.

Pushing the adoption of "serverless" - benefits Amazon ultimately as it's the largest provider.

Right. In the end, AWS saw containerization as an existential threat, and serverless is its response to the commoditization of AWS (and other specialized cloud vendors) by containerization technology. Serverless helps AWS re-couple your application back into the specialized AWS vendor environment, once more requiring you to keep specialized and costly AWS-specific knowledge on-hand in order to build and deploy your a…

S3 is the bigget coupling, or data storage. Why do you think containerization threatens AWS? It doesn't. Vendor lockin happens naturally, IAM are a vendor lock in feature, and I didn't see a lot people even mention about it. Migration off those sruff is incredibly hard and things can easily go wrong.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#56

Post by markonen »

cddotdotslash wrote: post #51
vdfs wrote: post #48

Earlier quoted context omitted.

Isn't using a server better in this case? Or Lambda have some benefits in this setup?

It's still insanely cheap. You could have millions of executions per month and only pay $0.50. But if you needed to, it could scale up to billions of invocation nearly instantly, something a standard server would have trouble doing as easily as Lambda does.

Then again, you are doing the hacks you describe because it is not scaling up nearly instantly. The cold start delays are not only an issue when scaling from zero to one, they hit you whenever you scale the capacity up.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#57

Post by justincormack »

Aissen wrote: post #41
talawahtech wrote: post #12

This is huge! It basically removes the VM as the security boundary for something like Fargate [1]. This should lead to a significant reduction in pricing since Fargate will no longer need to over provision in the background because VMs were being used even for tiny Fargate launch types. It should hopefully eliminate the cost disparity between using Fargate vs running your own instances. Should also mean much faster s…

Indeed, this seems very similar to kata+runv+kvmtool(lkvm). I'm curious why they don't provide a comparison. Here's what I gathered: - it seems to boot faster (how ?) - it does not provide a pluggable container runtime (yet) - a single tool/binary does both the VMM and the API server, in a single language. Can anyone else chime in ?

From memory the original version of Intel Clear Containers had its own kvm based vmm but they moved back to qemu (or a more minimal patched version they maintain). They are working on containerd support so should be similar to Kata soon.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#58

Post by aspyker »

markonen wrote: post #56
cddotdotslash wrote: post #51

Earlier quoted context omitted.

It's still insanely cheap. You could have millions of executions per month and only pay $0.50. But if you needed to, it could scale up to billions of invocation nearly instantly, something a standard server would have trouble doing as easily as Lambda does.

Then again, you are doing the hacks you describe because it is not scaling up nearly instantly. The cold start delays are not only an issue when scaling from zero to one, they hit you whenever you scale the capacity up.

This. I continue to hear about hacks of people running ping to keep a single instance warm. But that doesn't cover periodic changes in capacity needs nor spikes. I would think to avoid cold starts all together you'd need a pinger that sent exactly the load difference between peak load and current load. I would love to hear if anyone is keeping Lambdas warm at more than n=1 capacity.

Re: Firecracker – Lightweight Virtualization for Serverless Computing

#60

Post by Touche »

cbzbc wrote: post #52
ex-aws-now-goog wrote: post #50

Earlier quoted context omitted.

Having worked at AWS, I have to disagree with you. No-one that I worked with saw containerization as a threat. And why would they? At the VM level you can already paper over differences between cloud providers and I don't think that anyone at any of the large cloud providers lies awake at night worried about this. I also don't understand why serverless would couple you to a particular cloud provider. All the big clou…

The point is that each serverless implementation is different enough that even if you are using the same feature, the cruft around that is different enough to provide an certain amount of lock in.

I mean, the arguments and return values are different. Seems like a couple hours of work to convert from one to another, at most.
Post reply on HN