> 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)
You should time it then, it's incredibly slow these days
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:
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)