[sudhirj]

What this is allows, and I'm hoping a full fledged service will be announced on Thursday or Friday, is running containers as Lambdas. i.e. if you application starts fast enough, you can just set a container to start and run as a request comes in. It can also shut down when it's done running.

This allows things like per second billing for container runs, serverless containers (there's no container running 24/7, only when there's traffic), etc.

[Twirrim]

Why run a container? What value does that abstraction provide here?

To my mind this completely negates any value proposition of the container. The only thing missing, at face value, is something as straightforward as the Dockerfile for building base images. I imagine that shouldn't be hard using things like guestfish etc in guestfstools.

[sudhirj]

Want to run Ruby on Rails on Lambda, with no changes from the servers I run on my laptop. Or maybe I want to run Crystal. Or maybe I’m writing my own language. Doesn’t really matter.

Lambda works great as a deployment and execution model. This allows anything to run on Lambda, not just specially prepared runtimes.

[Twirrim]

It's a VM, right? So whatever you put in the base image will be available, just like with a container. It's just fast to provision and small.

[sudhirj]

In this case the base image is then a packaging format, which takes us back to building special AMIs for this. Used to do EC2 deployments like this in the early days, using Packer.io.

Prefer containers because build once run anywhere, as opposed to build for each deployment target.

[lilcorey10]

So essentially pairing Firecracker with Lambda will reduce Lambda down to a simple trigger that can spin up one of these VMs where before Lambda ran the code?

[sudhirj]

Yes, and the fact that each Lambda executor is a VM allows the execution of any code in any language using any server.

[nine_k]

Your container = your environment.

When your container is not running (say, 99% of time), other customers' containers are running. No need to ever boot the kernel, etc.

One might say that an unikernel has advantages over it. But it also has a higher barrier to entry.

[Twirrim]

It's a KVM microinstance. Your image = your environment. Same as with a container.

[woogley]

I'm expecting/hoping for this as well. GCP already has something like this in alpha - https://services.google.com/fb/forms/serverlesscontainers/ More info on it here in "Serverless containers" section: "https://cloud.google.com/blog/products/gcp/cloud-functions-s...

[nazka]

On its website in the FAQ they say that it can't run Docker and others, yet. I hope this is coming soon too!

[discodave]

> containers as Lambdas.

How similar is AWS Fargate to what you're describing?

[sudhirj]

I need to run 1+ Fargate containers 24/7, which is useless and wasteful.

With Fargate-Lambda crossover I wouldn't be running anything 24/7, and it would be a lot less resource intensive than one Lambda-Container per request as well.

Google's App Engine gets / got this right when they first launched, but to make it work they had to demand apps be written for their sandbox (like AWS Lambda), because of which the model isn't as general purpose. Firecracker would allow regular containers to be used this way, making a Firecracker service the first service to allow general purpose servers to be started and stopped (all the way to zero) based on incoming traffic.

[sciurus]

I think with the App Engine Standard generation 2 runtimes you don't have to write to their sandbox anymore. It still has to be one of their supported languages though, instead of any arbitrary server.

https://cloud.google.com/blog/products/gcp/introducing-app-e...

[thesandlord]

Serverless Container support is coming to GCP: https://services.google.com/fb/forms/serverlesscontainers/

[chrisbroadfoot]

Very easy to exec() into an arbitrary binary from these 2nd generation runtimes.

(and, as thesandlord notes below, arbitrary containers is the idea behind g.co/serverlesscontainers)

Disclaimer: I work on GCP.

[tybit]

Another missing piece in addition to the billing aspect mentioned elsewhere, is all the existing event based integrations lambda provides. E.g. react to kinesis, sqs, sns etc. events. having aws manage the event plumbing in addition to start/pause/stop is really nice.

[xmly]

Pricing model is not serverless. The basic serverless principle is no-use-no-pay.

[talawahtech]

Theoretically, if container start up times are around 125ms it should be possible to achieve this with Fargate + Knative's "scale to zero" functionality[1]. AWS is already working on improving Fargate/Kubernetes integration.

[1] https://cloud.google.com/knative/

[coder543]

Doesn't a Kubernetes master on Fargate cost a significantly non-zero amount of money? Pretty sure it does.

[talawahdotnet]

Sure, but if you already have one then there is no incremental cost.

It would be great if they announced that they were gonna remove EKS master costs altogether. Technically Firecracker should make it possible for them to run that infrastructure more efficiently :)

[sitkack]

Only dev instances should see zero traffic, any production site will have > 0 load at all times.

[coder543]

That's not completely accurate.

- If we're talking about a business that provides a service to local companies, there are quite a few hours during the week where everyone is either asleep or enjoying their weekend. Not every company has millions of users spread across every time zone; some companies provide a niche service to a small number of high paying users.

- Lots of developers have small hobby projects that are inactive for most of the day/week.

Scale to zero can be convenient, but it's not usually a make-or-break thing.

[xmly]

Yep, if with KNative, it is possible.