27 ms·

Missed opportunity to just support one runtime to rule them all: Docker containers.

by mychael 8y ago

Stefan-H 8y ago
https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/ They don't tend to miss an opportunity.
- mychael 8y ago
  You're aware thats an entirely different service right? We're talking about Serverless and Lambda.
  - Stefan-H 8y ago
    Whoops, need this as well https://aws.amazon.com/fargate/ https://aws.amazon.com/fargate/
  - bootlooped 8y ago
    I've always found "You're aware... right?" and its close cousin "You do realize... right?" to sound pretty condescending.
talawahdotnet 8y ago
I think over time Lambda and Fargate[1] will get closer and closer to each other in terms of functionality and deployment speed. 1. https://aws.amazon.com/blogs/aws/aws-fargate/ https://aws.amazon.com/blogs/aws/aws-fargate/
- ralmeida 8y ago
  The key distinction for me is that Lambda is event driven. If you have a microservice/function which is seldomly called, in Fargate you would pay 24x7 just to be listening for calls.
  - talawahdotnet 8y ago
    Fargate tasks can now be initiated by CloudWatch Events as well[1]. Lambda will always be at the extreme end of "serverless", but over time I expect the lines to blur more especially since Fargate will now be based on Firecraker[2] which has 125ms startup times for container workloads. 1. https://aws.amazon.com/about-aws/whats-new/2018/08/aws-fargate-now-supports-time-and-event-based-task-scheduling/ https://aws.amazon.com/about-aws/whats-new/2018/08/aws-farga... 2. https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/
    - mcintyre1994 8y ago
      Firecracker is behind Lambda as well as Fargate, so that points toward the lines blurring too.
jedberg 8y ago
That’s what Fargate is.
- mychael 8y ago
  Fargate is a great service, but it's not a serverless solution not by any mainstream definition of the term (although Amazon seems to be intent on stretching the definition lately). Create a simple ping/pong HTTP service in both and you'll quickly see difference in everything from billing to startup time.
  - jedberg 8y ago
    I like how both you and the sibling comment tried to educate me on the difference between containers and event-driven compute. I'm well aware of the difference. My point, which maybe I didn't make so clear since both of you missed it, was that you can make fargate spin up a container for an event, but it would be too slow for any useful event driven computing. If you're gonna use containers, use containers. If you want someone else to manage the container for you, use Lambda.
    - mychael 8y ago
      In one moment you're saying "Thats what Fargate is" as if Fargate == Running Serverless Containers. On the other you're saying "you can make fargate spin up a container for an event, but it would be too slow for any useful event driven computing", which is the truth, but it contradicts your initial comment.
- ralmeida 8y ago
  Sort of. Lambda is event-driven and on-demand, Fargate is "task-based". As mentioned in the sibling comment, if you build a "ping" HTTP endpoint in both, in Lambda you will have just a function which is called when necessary, in Fargate you will need to build a mini-webserver to keep listening for requests (as well as pay just to be listening instead of pay just when running).
  - 8y ago
derefr 8y ago
Docker doesn’t let you take the union of separately-authored base images together as a runtime image for your app. Lambda (apparently) does. That’s the only major difference I can see, though. The rest is convention/standardization on what’s put into the image (an executable that speaks HTTP over its stdio; separately-namespaced projects under /opt rather than use of the global namespace; etc.)
- manigandham 8y ago
  Why wouldn't Docker layers work the same way? More work but possible by stacking base images.
- tlrobinson 8y ago
  Technically Dockerfiles don't let you do that (they used to https://github.com/moby/moby/issues/13026 https://github.com/moby/moby/issues/13026) but in theory it should be possible to construct a Docker image from multiple base images (e.x. https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images)
otterley 8y ago
I suspect cold-start performance of arbitrary Docker containers would be intolerable for most customers in light of the sizes and number of layers of many of the images seen in the wild. Most people aren't building "FROM scratch" images yet, if they ever will. Single binaries, or scripting languages with well-defined runtime environments, are far easier to meet customer-demanded SLOs when building a serverless platform. (Disclaimer: I work for AWS, but this is strictly my personal opinion/observation.)
- jacques_chester 8y ago
  This is in part what Cloud Native Buildpacks is working to solve. Can you come find us (https://buildpacks.io https://buildpacks.io)? I think it would be really helpful to have CNB supported in/as Layers.
- CMCDragonkai 8y ago
  Nix allows you to easily create from scratch containers.
munns 8y ago
Docker isn't a runtime, its a packaging technology. The Runtime API is a simple standard interface that will allow you to run even Docker containers if you so desired.
manigandham 8y ago
Yes, it's strange they didn't do this. Azure and GCP are headed that way, and there are smaller vendors doing the same thing. Per-event invocation of a docker container instead of a specific bundle of code seems much more flexible, especially with the Firecracker tech they announced.
7ewis 8y ago
They said they didn't do this for security reasons, they wanted hardware virtualisation to separate Lambdas - not container separation.

Missed opportunity to just support one runtime to rule them all: Docker containers.

Stefan-H 8y ago

https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/ They don't tend to miss an opportunity.

mychael 8y ago
You're aware thats an entirely different service right? We're talking about Serverless and Lambda.
- Stefan-H 8y ago
  Whoops, need this as well https://aws.amazon.com/fargate/ https://aws.amazon.com/fargate/
- bootlooped 8y ago
  I've always found "You're aware... right?" and its close cousin "You do realize... right?" to sound pretty condescending.

talawahdotnet 8y ago

I think over time Lambda and Fargate[1] will get closer and closer to each other in terms of functionality and deployment speed. 1. https://aws.amazon.com/blogs/aws/aws-fargate/ https://aws.amazon.com/blogs/aws/aws-fargate/

ralmeida 8y ago
The key distinction for me is that Lambda is event driven. If you have a microservice/function which is seldomly called, in Fargate you would pay 24x7 just to be listening for calls.
- talawahdotnet 8y ago
  Fargate tasks can now be initiated by CloudWatch Events as well[1]. Lambda will always be at the extreme end of "serverless", but over time I expect the lines to blur more especially since Fargate will now be based on Firecraker[2] which has 125ms startup times for container workloads. 1. https://aws.amazon.com/about-aws/whats-new/2018/08/aws-fargate-now-supports-time-and-event-based-task-scheduling/ https://aws.amazon.com/about-aws/whats-new/2018/08/aws-farga... 2. https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/
  - mcintyre1994 8y ago
    Firecracker is behind Lambda as well as Fargate, so that points toward the lines blurring too.

jedberg 8y ago

That’s what Fargate is.

mychael 8y ago
Fargate is a great service, but it's not a serverless solution not by any mainstream definition of the term (although Amazon seems to be intent on stretching the definition lately). Create a simple ping/pong HTTP service in both and you'll quickly see difference in everything from billing to startup time.
- jedberg 8y ago
  I like how both you and the sibling comment tried to educate me on the difference between containers and event-driven compute. I'm well aware of the difference. My point, which maybe I didn't make so clear since both of you missed it, was that you can make fargate spin up a container for an event, but it would be too slow for any useful event driven computing. If you're gonna use containers, use containers. If you want someone else to manage the container for you, use Lambda.
  - mychael 8y ago
    In one moment you're saying "Thats what Fargate is" as if Fargate == Running Serverless Containers. On the other you're saying "you can make fargate spin up a container for an event, but it would be too slow for any useful event driven computing", which is the truth, but it contradicts your initial comment.
ralmeida 8y ago
Sort of. Lambda is event-driven and on-demand, Fargate is "task-based". As mentioned in the sibling comment, if you build a "ping" HTTP endpoint in both, in Lambda you will have just a function which is called when necessary, in Fargate you will need to build a mini-webserver to keep listening for requests (as well as pay just to be listening instead of pay just when running).
- 8y ago

derefr 8y ago

Docker doesn’t let you take the union of separately-authored base images together as a runtime image for your app. Lambda (apparently) does. That’s the only major difference I can see, though. The rest is convention/standardization on what’s put into the image (an executable that speaks HTTP over its stdio; separately-namespaced projects under /opt rather than use of the global namespace; etc.)

manigandham 8y ago
Why wouldn't Docker layers work the same way? More work but possible by stacking base images.
tlrobinson 8y ago
Technically Dockerfiles don't let you do that (they used to https://github.com/moby/moby/issues/13026 https://github.com/moby/moby/issues/13026) but in theory it should be possible to construct a Docker image from multiple base images (e.x. https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images)

otterley 8y ago

I suspect cold-start performance of arbitrary Docker containers would be intolerable for most customers in light of the sizes and number of layers of many of the images seen in the wild. Most people aren't building "FROM scratch" images yet, if they ever will. Single binaries, or scripting languages with well-defined runtime environments, are far easier to meet customer-demanded SLOs when building a serverless platform. (Disclaimer: I work for AWS, but this is strictly my personal opinion/observation.)

jacques_chester 8y ago
This is in part what Cloud Native Buildpacks is working to solve. Can you come find us (https://buildpacks.io https://buildpacks.io)? I think it would be really helpful to have CNB supported in/as Layers.
CMCDragonkai 8y ago
Nix allows you to easily create from scratch containers.

munns 8y ago

Docker isn't a runtime, its a packaging technology. The Runtime API is a simple standard interface that will allow you to run even Docker containers if you so desired.

manigandham 8y ago

Yes, it's strange they didn't do this. Azure and GCP are headed that way, and there are smaller vendors doing the same thing. Per-event invocation of a docker container instead of a specific bundle of code seems much more flexible, especially with the Firecracker tech they announced.

7ewis 8y ago

They said they didn't do this for security reasons, they wanted hardware virtualisation to separate Lambdas - not container separation.