Over the last few months I’ve been diving into various Serverless/FaaS architectures that can run on Kubernetes. To say this space has exploded would be a severe understatement. The number of amazing developers working in this space is remarkable. Much less the number of them integrating with Kubernetes.
I’m not going to talk about wrappers around Lambda (which there are a TON of). I’m talking about true FaaS capabilities that can at least demonstrate they run on Kubernetes.
As it turns out there are a fair number of them.
I’ve worked with several of these now but I’ll point out the ones I’ve not as we go along. In most circumstances I was able to reduce the number of candidates to explore simply by reviewing their architectures to understand their pros and cons.
I’ve also come across what I believe will be some key indicators we may want to be aware of before taking on one of these capabilities.
- Language support
- Performance and Scalability (how quickly can a basic function execute)
- Asynchronous/Synchronous support
- Monitoring
- Architecture
OpenWhisk
OpenWhisk was built and designed by IBM. Seems to be gaining a fair amount of traction in this space and has a good reputation. An excellent overview of the OpenWhisk Architecture can be written by Markus Thömmes , an OpenWhisk contributor at medium.com.
Language Support – OpenWhisk has full language support for just about anything. It even has integrations with Swift, Cloudant, Slack and YouTube.
Performance and Scalability – I found performance of OpenWhisk to be somewhat sluggish out of the box. But Mark provides some pretty good ways to increase performance here. Scalability is quite good as all components including the controllers can be scaled out.
Asynchronous/Synchronous – Asynchronous Only. Sounds like there are some plans for (semi?) synchronous support.
Monitoring – IBM does have Dashboard that can be use with IBM Bluemix and the CLI can be used for gaining insights as well but built-in capabilities with open source monitoring platforms are non-existent.
Architecture –
CouchDB and Kafka are in direct line of the execution for any function. CouchDB being for both authentication and action retrieval. Personally I couldn’t see us requiring Authentication through OpenWhisk and I would imagine most others have their own Auth capabilities that support far more than what are offered here. Kafka because all requests are Asynchronous (at this time).
Primary problem the with the above is availability. The more stateful (semi or otherwise) services required to be available, the more opportunity for failure however you’ll find this is fairly common in FaaS. Some sort of message queue and some sort of storage for holding code. This tends to limit the number of languages (and/or versions) supported but IBM have done a good job here. Basically any container can be an invoker as long as it conforms to a few specifics.
Notes for OpenWhisk on Kubernetes:
- No use of Kubernetes scheduling.
- OpenWhisk controller talks directly with the Docker API on the host, thus limiting scalability to what that host can handle. Also not going to work for availability.
Recap: Overall OpenWhisk is a platform that’s been around for a little bit now. It largely resembles Lambda in its capability but open to the masses. I could see OpenWhisk being used in very large FaaS implementations but its number of dependencies in the critical path scare me. Its performance could use some enhancing out of the box. But for a FaaS that relies on injecting functions into containers, its language support is stellar and it has some pretty cool direct integrations.
Bottom Line: I can’t recommend this platform if running Kubernetes at this time.
Kubeless
Kubeless is almost a brand new project. As of the time of this writing, Kubeless has only been committed to in any earnest for the last 5 months. They are truly Kubernetes native and plug right in to the Serverless project. I did not get the chance to really test out this platform but I’m aiming to get a handle on it in the next few weeks.
Language Support – Python and NodeJS
Performance and Scalability – I just don’t know yet
Asynchronous/Synchronous – Both
Monitoring – Baked in monitoring with Prometheus.
Architecture –
Kubeless relies heavily on built-in Kubernetes capabilities such as ThirdPartyResources (or Custom Definitions depending on version of Kubernetes) and takes advantage of the built-in API server. Everything to run a function exists in the ThirdPartyResource. As a result however, the Kubeless team has to provide support by language/version for functions to run. My hope is they will make this a bit more generic to allow customer runtimes? Otherwise I fear they won’t be able to keep up.
Correction: Executions with Kubeless are through http or triggered events. Thank You @sebgoa for pointing this out.
Notes: Kubeless has an easily consumable UI and directly plugs in to the Serverless Framework.
Kubeless runs on vanilla Kubernetes, OpenShift and hooks seamlessless into Kubernetes-RBAC for security.
Recap: Really cool new up and coming project integrating deeply with Kubernetes. Could be a heavy contender in the future.
Bottom Line: Not yet unless you are solely Python and NodeJS based.
IronFunctions
IronFunctions are the current unsung heroes in my mind. Under heavy development starting in July of 2016, this is an easily consumable open source project that integrates well with Kubernetes while having the unique ability to run Lambda style functions as well. So for all you Lambda junkies wanting to break your addiction, this might be a pretty damn good option.
Language Support – Only limited by the docker containers you can dream up.
Performance and Scalability – Only limited by the infrastructure its running on. I quite easily executed it in several languages both locally and on a full cluster in the 200-250ms range for Synch requests and 300ish for Asynch. I don’t see any scalability issues at this time. If a ceiling was hit, it would be quite easy to simply spin up a new IronFunctions capability in a different namespace in Kubernetes.
Asynchronous/Synchronous – Both
Monitoring – Logs
Architecture –
IronFunctions are a truly well built platform that I’m hesitant to say could serve many different use cases. There are a few basic components to running IronFunctions.
- IronFunctions – Essentially the controller/API that manages incoming requests and starts up resources/container to fulfill said request.
- Database – for configuration only. Not in the critical request path.
- Message Queue – For Asynchronous requests.
Notes: Has a usable UI for managing functions. HotFunctions are pretty awesome. The CLI is very easy to use.
All in all, IronFunctions was the dark horse that surprised me by a long shot. I would love to see Prometheus monitoring make it in as I’m not terribly excited about Logging being the metrics collection point. Overall, minor gripe.
Recap: I was noticeably surprised by its scalability, performance and maturity for a project I just happen to run across. It has all the makings of a truly scalable, production capable FaaS offering. With Synchronous, Asynchronous AND HotFunction capabilities, I was very impressed. Combine that with ease of use, just enough integration with Kubernetes and I’m pretty much sold. Keep up the good work.
Bottom Line: Of the ones I’ve reviewed so far, a definite Yes. Just get me some metrics into Prometheus. 😉
In a future post I’ll have a look at Fission, Funktion and maybe an up and comer by alexellis called faas-netes.
@devoperandi