7 ms·

I'm still wondering why Lambda simply doesn't support Docker containers? Would put an end to all this requests like "Please support $my_favorite_language on Lam

by leifg 9y ago

I'm still wondering why Lambda simply doesn't support Docker containers? Would put an end to all this requests like "Please support $my_favorite_language on Lambda"

owaislone 9y ago
You are looking for a different product. What you are looking for is ECS+Fargate. That does exactly this. The difference is that with ECS+Fargate you are in charge of building the entire application from scratch. With lambda you just implement 1 function, the "service" part of your app and all the plumbing to support different things like X-Ray, logging, handling errors, hot and cold boots, etc etc are handler by AWS.
otterley 9y ago
Because it’s a function execution system, not an application execution system. If you need the latter, you can use ECS or K8S.
- neom 9y ago
  This, also, is the direction the industry is going, regardless of cloud provider.
- cle 9y ago
  Fargate is probably the closest AWS offering.
benatkin 9y ago
It seems that they benefit from lock-in, whether it's deliberate or not.
- philliphaydon 9y ago
  There is no lock-in... you can write an agnostic function for both AWS lambda and azure function.
  - benatkin 9y ago
    I'm aware of tools like Serverless. They help remove the lock-in in some situations. That doesn't mean there's no lock-in to speak of at all.
    - philliphaydon 9y ago
      In regards to C# functions, there is no lock-in to AWS, it's a piece of code, you can run that function on AWS Lambda, or in ASP.NET Website, or Azure Function, or console app... It's literally a method which has a single parameter class, and a single class returned... Even if you're using node, java, golang, python. Other than the packaging. How is there any lock in?
      - hueving 9y ago
        Aren't you spending resources setting up your CI/CD pipeline /deployment tooling to talk to Amazon's APIs? Unless all of the providers have the same API to deploy functions, they are all trying to lock you in. So not lock-in at the code level (unless your serverless app talks to S3 or whatever Amazon services), but lock-in of your whole devops process.
        philliphaydon 9y ago
        So first it's all "Oh you're locked into IIS" and "You're locked into Windows", then "You're locked into AWS" now it's all "You're locked into your CI/CD pipeline" It sounds like, no matter what you do, you're locked in. Using Docker? Ah you're locked into Docker. Wrote your app in PHP, on you're locked into PHP now. I just don't understand this whole 'lock-in' mindset, it's just absurd now.
        Nullabillity 9y ago
        The vital difference being that Docker and PHP aren't subscription-based, and aren't controlled by a single corporation.
sudhirj 9y ago
Docker executes long running processes that communicate over HTTP/TCP. AWS has ECS, Fargate and has announced K8S support soon. Lambda is for executing individual functions, which implies that the execution environment must be language aware (could get away with JVM dynamic invoke or the .NET equivalent as well maybe). The way parameters are passed in, the concurrency model etc are all language specific.
- jdub 9y ago
  And yet, the golang runtime for Lambda is a long* running process that communicates over TCP. :-) It would be entirely possible to create a language agnostic Lambda runtime model, be it stdin/out/err, or TCP. * relatively so
  - sudhirj 9y ago
    That's already around https://github.com/apex/up https://github.com/apex/up
    - jdub 9y ago
      Not as a wrapper, but an official Lambda runtime model. This Go release points to a much more interesting way of doing so (RPC) than what I had previously imagined (stdin/out/err).
      - sudhirj 9y ago
        Yeah, the problem with RPC is that there's no one RPC to rule them all, like there is with JSON or HTTP. They'll have to build RPC wrappers for each language / VM, and choose the most popular RPC packager if there's isn't one in the stdlib.
        lmm 9y ago
        Couldn't they pick an existing, established cross-language RPC system like Thrift or gRPC?
jitl 9y ago
I think Lambda should do this. Lambda seems like its a more managed version of the concepts in inetd + CGI: Like inetd, Lambda will start a server, if needed, to handle a new connection, and like CGI, Lambda passes request data to user application code in a standardized way. You could implement a Lambda-like service using inetd + CGI to run functions in Docker containers, and then destroy the container once you get the result. Spawning a process in a container is expensive. Not only do you need to wait for the container to init and mount its filesystems, but you then need to wait for the inner application to boot on every request, on top of that. So, allow containers to linger with applications booted, like Lambda does to save on those starts. Since we aren't launching a new process for every call, we can't use CGI with its environment variables, etc, so we'll have to describe a new protocol for calling your functions, like... HTTP! The interface could be POST /call with JSON params. I'm not sure how this model would differ semantically from the fully-managed, in-process system that Lambda uses. The management system can always kill containers that go over their memory limits or seem to be doing suspicious amounts of system calls when they're not executing a function. AWS can still go about providing in-process libraries for "supported" languages that implement these protocols, but if they also describe these protocols, then the community can go ahead and develop libraries for other languages that could eventually be adopted and officially supported. In fact, the community is already producing libraries that use AWS's supported languages to allow hosting lambdas in other languages, via a CGI-like model! Just look at https://github.com/apex/apex https://github.com/apex/apex - a NodeJS shim will spawn a command in the language of your choice, and then return the result back to Lambda.
- lobster_johnson 9y ago
  Why would a container be slow to create? It's effectively a fork with namespacing options. The overlay file system is just a product of one or more layers that are already computed; there's not much complexity to its mounting compared to something like ext4 or NFS. I haven't timed it, but containers seem damn fast to start with Docker and Kubernetes.
  - TheDong 9y ago
    > I haven't timed it, but containers seem damn fast to start with Docker and Kubernetes. You should time it then, it's incredibly slow these days $ time docker run busybox /bin/true .388s total $ time docker run --net=none busybox /bin/true .310s total The above times, of over 300ms, are with docker 17.06 and the overlay2 driver on a powerful computer with an ssd. It's horrifically slow because the entire docker codebase is disgustingly bloated. It has to fork something like 10 processes and synchronize between them (for everything from network initialization to runc hooks). It has to make ipc calls from docker-cli to dockerd to containerd and back again, allocating and freeing large chunks of memory for grpc along the way. It's incredibly slow. On the other hand, just forking and running something with namespacing options is effectively instant: $ dir=$(mktemp -d) $ docker run --name bbexport busybox /bin/true $ cd $dir $ docker export bbexport | tar x $ time nsenter --root=$dir /bin/true 0.000s total This is the reason they don't let you use arbitrary docker containers; docker containers are a ton more than a fork and some options. They're a bloated moving target. What lambda does allows them to optmize much more. In fact, lambda doesn't even have to fork a process sometimes because they can keep the e.g. javascript runtime running and then just add a new request into the existing process directly. They can freeze and thaw environments from known good states for request processing. But most importantly, by not being compatible in any way with docker, they don't have to deal with the bloated mess that is docker and the ecosystem around it. They don't have to load 3 daemons measuring 50MB into memory to run 100kb of javascript (which they can currently run more quickly than docker can even start the simpleist container)
lackbeard 9y ago
Isn't that what Fargate is, basically?
zitterbewegung 9y ago
The architecture of lambda may prevent this.
- chimeracoder 9y ago
  > The architecture of lambda may prevent this. It doesn't; you've always been able to use any language you want, by embedding it within the runtime of a supported language. This is just announcing proper, official support for it instead of having to rely on a workaround.
  - inopinatus 9y ago
    Lambda's execution model is language-specific runtimes being fed events off a queue through a single well-defined RPC or RPC-like entry point, with the process frozen or discarded upon queue exhaustion. So the architecture of Lambda may indeed be a severe mismatch for running arbitrary containers.
chimeracoder 9y ago
> I'm still wondering why Lambda simply doesn't support Docker containers? Would put an end to all this requests like "Please support $my_favorite_language on Lambda" Because they can present that as a separate service (Fargate) and bill more for it. Fargate isn't exactly what you're describing, but it's a close match. It's in Amazon's best interests to charge people based on the amount of "DIY" they're willing to put up with, and that's why they offer a number of overlapping services at different price points.
- hamandcheese 9y ago
  Amazon does not launch a brand new container for every invocation of lambda, only cold starts. Supporting arbitrary Docker containers is definitely more costly.
jdub 9y ago
"simply" is one of those words that makes people twitch... See, the packaging format is not the problem. The protocol is where it gets tricky. I previously imagined Go support would arrive with a JSON on stdin/out/err protocol. Instead, your binary runs as a service with RPC endpoints. Unfortunately, it's a bit Go-oriented, so you'd have to implement some Go things (go/rpc, gobs) in your language/framework of choice to use it. But, you get a (much) lower warm function startup cost because it's just an RPC call, all of which is neatly abstracted away for the Go programmer in the runtime library. Great for Go, bit of a bummer for those of us hoping for something more agnostic. Yes, Lambda could support "Docker containers", but the more interesting problem to solve is the runtime model and protocol.
- sudhirj 9y ago
  > bit of a bummer for those of us hoping for something more agnostic. If you can imitate the go/rpc protocol, you an run any binary from any language on this, including LLVM based systems. A version of this is already in play in https://github.com/apex/up https://github.com/apex/up
joaofs 9y ago
Like many people stated here, Fargate will give you this. Lambda is actually under the hood a container system.
jdc0589 9y ago
I don't know about the internals, but my guess is one of the following: 1) there's something about the lambda platform that just doesn't lend itself well to customer provided containers. a lot of people would AT LEAST have issues keeping image size reasonable. 2) they plan to add this. AWS is already investing in serverless container services, take a look at Fargate.

by leifg 9y ago

I'm still wondering why Lambda simply doesn't support Docker containers? Would put an end to all this requests like "Please support $my_favorite_language on Lambda"

owaislone 9y ago

You are looking for a different product. What you are looking for is ECS+Fargate. That does exactly this. The difference is that with ECS+Fargate you are in charge of building the entire application from scratch. With lambda you just implement 1 function, the "service" part of your app and all the plumbing to support different things like X-Ray, logging, handling errors, hot and cold boots, etc etc are handler by AWS.

otterley 9y ago

Because it’s a function execution system, not an application execution system. If you need the latter, you can use ECS or K8S.

neom 9y ago
This, also, is the direction the industry is going, regardless of cloud provider.
cle 9y ago
Fargate is probably the closest AWS offering.

benatkin 9y ago

It seems that they benefit from lock-in, whether it's deliberate or not.

philliphaydon 9y ago
There is no lock-in... you can write an agnostic function for both AWS lambda and azure function.
- benatkin 9y ago
  I'm aware of tools like Serverless. They help remove the lock-in in some situations. That doesn't mean there's no lock-in to speak of at all.
  - philliphaydon 9y ago
    In regards to C# functions, there is no lock-in to AWS, it's a piece of code, you can run that function on AWS Lambda, or in ASP.NET Website, or Azure Function, or console app... It's literally a method which has a single parameter class, and a single class returned... Even if you're using node, java, golang, python. Other than the packaging. How is there any lock in?
    - hueving 9y ago
      Aren't you spending resources setting up your CI/CD pipeline /deployment tooling to talk to Amazon's APIs? Unless all of the providers have the same API to deploy functions, they are all trying to lock you in. So not lock-in at the code level (unless your serverless app talks to S3 or whatever Amazon services), but lock-in of your whole devops process.
      - philliphaydon 9y ago
        So first it's all "Oh you're locked into IIS" and "You're locked into Windows", then "You're locked into AWS" now it's all "You're locked into your CI/CD pipeline" It sounds like, no matter what you do, you're locked in. Using Docker? Ah you're locked into Docker. Wrote your app in PHP, on you're locked into PHP now. I just don't understand this whole 'lock-in' mindset, it's just absurd now.
        Nullabillity 9y ago
        The vital difference being that Docker and PHP aren't subscription-based, and aren't controlled by a single corporation.

sudhirj 9y ago

Docker executes long running processes that communicate over HTTP/TCP. AWS has ECS, Fargate and has announced K8S support soon. Lambda is for executing individual functions, which implies that the execution environment must be language aware (could get away with JVM dynamic invoke or the .NET equivalent as well maybe). The way parameters are passed in, the concurrency model etc are all language specific.

jdub 9y ago
And yet, the golang runtime for Lambda is a long* running process that communicates over TCP. :-) It would be entirely possible to create a language agnostic Lambda runtime model, be it stdin/out/err, or TCP. * relatively so
- sudhirj 9y ago
  That's already around https://github.com/apex/up https://github.com/apex/up
  - jdub 9y ago
    Not as a wrapper, but an official Lambda runtime model. This Go release points to a much more interesting way of doing so (RPC) than what I had previously imagined (stdin/out/err).
    - sudhirj 9y ago
      Yeah, the problem with RPC is that there's no one RPC to rule them all, like there is with JSON or HTTP. They'll have to build RPC wrappers for each language / VM, and choose the most popular RPC packager if there's isn't one in the stdlib.
      - lmm 9y ago
        Couldn't they pick an existing, established cross-language RPC system like Thrift or gRPC?

jitl 9y ago

I think Lambda should do this. Lambda seems like its a more managed version of the concepts in inetd + CGI: Like inetd, Lambda will start a server, if needed, to handle a new connection, and like CGI, Lambda passes request data to user application code in a standardized way. You could implement a Lambda-like service using inetd + CGI to run functions in Docker containers, and then destroy the container once you get the result. Spawning a process in a container is expensive. Not only do you need to wait for the container to init and mount its filesystems, but you then need to wait for the inner application to boot on every request, on top of that. So, allow containers to linger with applications booted, like Lambda does to save on those starts. Since we aren't launching a new process for every call, we can't use CGI with its environment variables, etc, so we'll have to describe a new protocol for calling your functions, like... HTTP! The interface could be POST /call with JSON params. I'm not sure how this model would differ semantically from the fully-managed, in-process system that Lambda uses. The management system can always kill containers that go over their memory limits or seem to be doing suspicious amounts of system calls when they're not executing a function. AWS can still go about providing in-process libraries for "supported" languages that implement these protocols, but if they also describe these protocols, then the community can go ahead and develop libraries for other languages that could eventually be adopted and officially supported. In fact, the community is already producing libraries that use AWS's supported languages to allow hosting lambdas in other languages, via a CGI-like model! Just look at https://github.com/apex/apex https://github.com/apex/apex - a NodeJS shim will spawn a command in the language of your choice, and then return the result back to Lambda.

lobster_johnson 9y ago
Why would a container be slow to create? It's effectively a fork with namespacing options. The overlay file system is just a product of one or more layers that are already computed; there's not much complexity to its mounting compared to something like ext4 or NFS. I haven't timed it, but containers seem damn fast to start with Docker and Kubernetes.
- TheDong 9y ago
  > I haven't timed it, but containers seem damn fast to start with Docker and Kubernetes. You should time it then, it's incredibly slow these days $ time docker run busybox /bin/true .388s total $ time docker run --net=none busybox /bin/true .310s total The above times, of over 300ms, are with docker 17.06 and the overlay2 driver on a powerful computer with an ssd. It's horrifically slow because the entire docker codebase is disgustingly bloated. It has to fork something like 10 processes and synchronize between them (for everything from network initialization to runc hooks). It has to make ipc calls from docker-cli to dockerd to containerd and back again, allocating and freeing large chunks of memory for grpc along the way. It's incredibly slow. On the other hand, just forking and running something with namespacing options is effectively instant: $ dir=$(mktemp -d) $ docker run --name bbexport busybox /bin/true $ cd $dir $ docker export bbexport | tar x $ time nsenter --root=$dir /bin/true 0.000s total This is the reason they don't let you use arbitrary docker containers; docker containers are a ton more than a fork and some options. They're a bloated moving target. What lambda does allows them to optmize much more. In fact, lambda doesn't even have to fork a process sometimes because they can keep the e.g. javascript runtime running and then just add a new request into the existing process directly. They can freeze and thaw environments from known good states for request processing. But most importantly, by not being compatible in any way with docker, they don't have to deal with the bloated mess that is docker and the ecosystem around it. They don't have to load 3 daemons measuring 50MB into memory to run 100kb of javascript (which they can currently run more quickly than docker can even start the simpleist container)

lackbeard 9y ago

Isn't that what Fargate is, basically?

zitterbewegung 9y ago

The architecture of lambda may prevent this.

chimeracoder 9y ago
> The architecture of lambda may prevent this. It doesn't; you've always been able to use any language you want, by embedding it within the runtime of a supported language. This is just announcing proper, official support for it instead of having to rely on a workaround.
- inopinatus 9y ago
  Lambda's execution model is language-specific runtimes being fed events off a queue through a single well-defined RPC or RPC-like entry point, with the process frozen or discarded upon queue exhaustion. So the architecture of Lambda may indeed be a severe mismatch for running arbitrary containers.

chimeracoder 9y ago

> I'm still wondering why Lambda simply doesn't support Docker containers? Would put an end to all this requests like "Please support $my_favorite_language on Lambda" Because they can present that as a separate service (Fargate) and bill more for it. Fargate isn't exactly what you're describing, but it's a close match. It's in Amazon's best interests to charge people based on the amount of "DIY" they're willing to put up with, and that's why they offer a number of overlapping services at different price points.

hamandcheese 9y ago
Amazon does not launch a brand new container for every invocation of lambda, only cold starts. Supporting arbitrary Docker containers is definitely more costly.

jdub 9y ago

"simply" is one of those words that makes people twitch... See, the packaging format is not the problem. The protocol is where it gets tricky. I previously imagined Go support would arrive with a JSON on stdin/out/err protocol. Instead, your binary runs as a service with RPC endpoints. Unfortunately, it's a bit Go-oriented, so you'd have to implement some Go things (go/rpc, gobs) in your language/framework of choice to use it. But, you get a (much) lower warm function startup cost because it's just an RPC call, all of which is neatly abstracted away for the Go programmer in the runtime library. Great for Go, bit of a bummer for those of us hoping for something more agnostic. Yes, Lambda could support "Docker containers", but the more interesting problem to solve is the runtime model and protocol.

sudhirj 9y ago
> bit of a bummer for those of us hoping for something more agnostic. If you can imitate the go/rpc protocol, you an run any binary from any language on this, including LLVM based systems. A version of this is already in play in https://github.com/apex/up https://github.com/apex/up

joaofs 9y ago

Like many people stated here, Fargate will give you this. Lambda is actually under the hood a container system.

jdc0589 9y ago

I don't know about the internals, but my guess is one of the following: 1) there's something about the lambda platform that just doesn't lend itself well to customer provided containers. a lot of people would AT LEAST have issues keeping image size reasonable. 2) they plan to add this. AWS is already investing in serverless container services, take a look at Fargate.