From the article:<p>> To optimize cold start overheads, Fission keeps a running pool of containers for each environment. When a request for a function comes in, Fission doesn't have to deploy a new container -- it just chooses one that's already running, copies the function into the container, loads it dynamically, and routes the request to that instance. The overhead of this process takes on the order of 100msec for NodeJS and Python functions.<p>100 ms of overhead is pretty steep. Google recommends a limit of twice that for the entire server response (<a href="https://developers.google.com/speed/docs/insights/Server#recommendations" rel="nofollow">https://developers.google.com/speed/docs/insights/Server#rec...</a>):<p>> You should reduce your server response time under 200ms<p>Still, I've heard that AWS Lambda may run around 200 ms, so perhaps Fission is doing OK here.<p>But with modern progress in fast-starting compiled languages like Go and Rust, I'd love to have some easy way to supply small static binaries instead of source code. With compiled web server frameworks, it's feasible to handle over 250,000 (very simple) requests per second, or thousands of requests while Fission is trying to figure out where to send your source code. It doesn't always make sense to pay for interpreter startup overhead on every request (EDIT: this is not the case according to the Fission developers), especially not now that compiled code is so easy.
Zappa author here, very excited by this project!<p>We've been planning on supporting other DIY/non-AWS offerings in this space - particularly IBM's OpenWhisk[1]. If the Fission authors are here - can I ask how the two stack up? OpenWhisk's ability to write your own custom even sources seems like a leg up, as does their wider language support, but Fissions's Kubernetes foundation seems preferable. Curious how the two compare!<p>[0] <a href="https://github.com/Miserlou/Zappa" rel="nofollow">https://github.com/Miserlou/Zappa</a>
[1] <a href="https://developer.ibm.com/openwhisk/" rel="nofollow">https://developer.ibm.com/openwhisk/</a>
It might be the case that docker was just some enabling technology to go back to static binaries even with dynamic languages that IMHO expect a more complicated runtime setup.<p>So if one goes with statically compiled web services written in e.g. Go, Rust, Haskell or any other language supporting static binaries (most languages support this actually, but not all of them encourage you to do it), the only thing missing is a deployment framework that distributes your binaries to your (potentially virtual) machines. So am I correct that this is the point where Kubernetes comes in?<p>So how to use Docker in production is a controversial topic and the consensus seems to change rapidly, but in my opinion is mostly used as a weapon against dependency hell, but this problem is mostly solved using static binaries. Other use it for sandboxing, but I am not sure what security guarantees one can expect here.<p>If one compares static binaries with Docker containers how do they compare from a security point of view if one is hyperparanoid that the code executed may harm the host?
I'm relatively new to the Serverless/FaaS space. Or to be more precise: I missed AWS Lambda and only heard about it when OpenWhisk was donated to Apache.<p>I have a couple of questions, maybe someone here has answers for me:<p>1) In particular I'm wondering about expensive one-time/setup operations (e.g. opening a database connection) that are usually done once at startup of a service. But that doesn't really apply here. How are these things handled?<p>2) As a Java guy I also wonder which of these tools support Java and how they deal with dependencies and JVM startup times etc.<p>3) And my last question: How do these integrate into development workflows? Continuous integration? Run this offline/local etc. Will I need a Kubernetes instance on my machine?
I think it feels like a competition for celery. It fits into those tasks that are too heavy to run on the primary web server, but too small to set up the dedicated deployment/replicaset.<p>On slightly different note, I am still looking for a good job pattern for my use case. I run jobs on very custom docker images (including deep learning and computer vision stuff). I currently use redis queue with todo items, each pod in deployment picks up items from the queue in the loop, but I dislike some things about it. Fission is not the good fit, but I am wondering if HN community would have some suggestions. I thought about kubernetes jobs, but they have some things I don't like.
Kubeless from Skippbox is another open source serverless offering for Kubernetes <a href="https://github.com/skippbox/kubeless" rel="nofollow">https://github.com/skippbox/kubeless</a>
Your article mentions the reason you chose client code vs docker images, which I understand and can agree with. However, is there any plan to support docker images in place of client code?<p>What you're suggesting [initially] is very similar to what the folks at iron.io did but I'd really want to ship containers all around, not pieces of code. Iron.io addressed that a little too late in my opinion and their feature set around docker leaves a lot to be desired.<p>IMO, AWS Lambda and Google Cloud Functions are going to support docker in the near future, they have to if they want their ecosystem to be adoptable by all.
Isn't one of the big benefits of serverless functions being able to scale transparently? Can a kubernetes cluster give you anywhere near the elasticity of something like lambda?
I've spent some time on a PoC FaaS project with Docker Swarm primitives and Docker 1.13 features - exploring things like auto-scaling.<p><a href="http://blog.alexellis.io/functions-as-a-service/" rel="nofollow">http://blog.alexellis.io/functions-as-a-service/</a><p>Long version:<p>> FaaS is a platform for building serverless functions on Docker Swarm with first class metrics. Any UNIX process can be packaged as a function.<p>> Enabling you to consume a range of web events without repetitive coding.
Please see: <a href="https://github.com/stackvana/microcule" rel="nofollow">https://github.com/stackvana/microcule</a><p>We've got better functionality, streams ( not a buffered context ), more language support, and better response times.
I'm a long time software developer, have recently implemented a series of web application servers on Heroku using Node.js, and I have no clue what this article is about. My suggestion is a better introduction might broaden it's readability.
This popped up a few days ago and it seems worth it to compare: <a href="https://github.com/alexellis/funker-dispatch/" rel="nofollow">https://github.com/alexellis/funker-dispatch/</a>
How does this compare against funktion (<a href="https://funktion.fabric8.io/" rel="nofollow">https://funktion.fabric8.io/</a>)? Both projects seem very similar.