A Comparison of Serverless Frameworks for Kubernetes: OpenFaas, OpenWhisk, Fission, Kubeless, and more
AWS Lambda has become synonymous with Serverless. But there are two benefits to separating from AWS: it avoids some restrictions and is more flexible.
Serverless is actually a pseudonym; it is actually a set of technologies that completely abstracts the underlying hardware technologies. Obviously, these functions or functions are actually still running on a server somewhere, but let’s not worry about that. The developer simply needs to provide a code function that is then consumed or called through some interface: typically REST, but also through messaging-based technologies (such as Kafka, Kinesis, Nats, SQS, etc.).
The following compares the Serverless framework for Kubernetes platform and provides some suggestions:
Comparing the results
The table below is a comparison of the K8S non-service frameworks in terms of popularity, stability, tools, technology, and ease of use.
The problem with ideas like popularity is hard to quantify, so we have to resort to metrics. For example, I’d really like to know how many people are using the framework every day, but it’s hard to find an exact number, so we use metrics like Github Stars or Google Trends to indicate “popularity.” More information on popularity can be found here: Open Source Metrics.
Note that many of these metrics are rough estimates. So it may look like a framework is better or worse than it really is. Read the whole picture.
| Dimension/frame | OpenFaas | OpenWhisk | Kubeless | Fission | IronFunctions | Fn |
|---|---|---|---|---|---|---|
| (Popularity)Github Stars |
 |
 |
 |
 |
 |
 |
| (Popularity)Google Trends (100 means most popular) | 37 | 58 | 24 | N/A(conflicts with fission) | N/A | 3 |
| (Popularity) Stability (contributor) |
 |
 |
 |
 |
 |
 |
| StackOverflow.com number of posts | 21 | 359 | 15 | 2 | 5 | 9 |
| (Popularity) Contributors with more than 10 submissions | 10 | 33 | 7 | 6 | 9 | 19 |
| (Stability) Sponsoring company | VMWare | IBM(Apache Foundation) | Bitnami | Plaform9 | Iron.io | Oracle |
| (Stability) Time of first release | 2016/12 | 2016/02 | 2016/11 | 2016/08 | 2016/02 | 2016/05 |
| (Stability) Development language | Go | Scala | Go | Go | Go | Go |
| (tools) Package tools | Docker container | Docker container | Docker container | Docke container | Docker | Docker |
| (Tool) K8S deployment mode | Customize yamL Manifest | Customize yamL Manifest | Manifest | Customize yamL Manifest | User related | User related |
| (Tool) passserverlessThe deployment? | YES(WIP) | YES | YES | NO | NO | YES |
| (tools) Basic technology | Alertmanager / Prometheus, Nats | CouchDB, Kafka, Nginx, Redis, Zookeeper | None (Nats or Kafka optional) | Fluentd (also available with Nats) | Postgres, Redis | DB (sqlite3, PostgreSQL, MySQL), MQ (Bolt, Redis), Prometheus |
| (Ease of use) Out of the box | YES | YES | NO(failed through Serverless deployment) | YES(but there’s a problem) | There is no try | There is no try |
| (Ease of use) Document quality | Good | Good | Average (slightly less organized) | Poor (poor organization, missing documentation) | Average (slightly less organized) | Good |
| (Ease of use) Whether Slack channel exists | Yes (via email) | There are | There are (slack.k8s.io) | There are | There are | There are |
Recommendations for the Serverless framework
Based on the comparison in the above table, I suggest:
- Use Serverless Framwork as the SDK
- Use OpenFaas or OpenWhisk on K8S to manage functions
- OpenFaas is mature, easy to use, and extensible, but it has fewer active developers on core projects than OpenWhisk and is less popular. (Based on my definition of active developer and popularity)
- OpenWhisk is mature, popular and supported by many active developers, but also complex. It is written in Scala and is supported by IBM/Apache (for better or worse, depending on your point of view)
So the resulting technology stack might look something like this:
As an additional tip, Serverless FramWork allows developers to deploy functions to Lambda or other k8S unserviced platforms. If you already have functions deployed on Lambda, this is very helpful in migrating functions.
An introduction to various frameworks
Severless Framework
Serverless Framwork will be mentioned several times later in this article, so it’s worth mentioning what it is first.
It’s not a platform, but it can run any function. It is an SDK without services. In fact, it’s essentially just a layer of packaging. But best of all, with Serverless FramWork packaged with Functions, you can deploy the same code to Lambda, Google Functions, Azure Functions, OpenWhisk, OpenFaas, Kubeless or Fn.
Such convenient features are attractive, setting standards that developers follow to build their code, and allowing developers to analyze and decide where to deploy them in terms of standards, cost, features, or usability.
In addition, it helps us not to worry about “which framework should be used”. I like the Kubeless implementation, but it’s not mature enough. If we were based on the Serverless Framework, we could build our function code on OpenFaas and Lambda, which could be easily ported to Kubeless later.
The only downside is that the name is a bit awkward and misleading. There are also limited languages currently supported, but other than that, I think this is the safest choice.
OpenWhisk
OpenWhisk is a mature no-service framework supported by the Apache Foundation and IBM. IBM cloud function services are also built on OpenWhisk. The main submitters were IBM employees.
OpenWhisk takes advantage of CouchDB, Kafka, Nginx, Redis, and Zookeeper, and has many underlying components, so it adds some complexity. The advantage is that developers can clearly focus on scalable and elastic services, the disadvantage is that both developers and users need to have knowledge and learn how to use these tools, and the other disadvantage is that it duplicates some features that already exist in Kubernetes (such as automatic scaling). The function will eventually run in the Docker container with the framework.
OpenWhisk can be installed using Helm Chart, but some steps still need to be done manually. Functional applications can be deployed using CLI tools or serverless Framework. Prometheus Metrics (used to monitor function performance Metrics) is available out of the box.
OpenFaas
OpenFaas is a popular and easy-to-use no-service framework (although not as good as OpenWhisk in the table above). But it’s not as popular as OpenWhisk, and code submission is done on an individual basis. In addition to the contributions of individual developers in their spare time, VMWare employs a team to maintain OpenFaas full-time. A company called OpenFaas is now incorporated in the UK, but it is unclear how this is related to the OpenFaas project.
The architecture of OpenFaas is relatively simple. API gateways can be invoked via Kafka, SNS, CloudEvents, CRON, or other synchronous/asynchronous triggers, where asynchronous calls are handled by NATS Streaming. Elastic scaling of the service is done using Prometheus and Prometheus Alertmanager, but replacement with Kubernetes’ HorizontalPodAutoscaler is also supported.
Complete Kubernetes installation support is available through Helm or Kubectl, including CRD operators (such as fetching functions via Kubectl). There is another Kubernetes Operator WIP that works well: openfaas-operator.
Function applications can be deployed using CLI tools or serverless Framework. There is also a “Funtion Store” that provides many of the features used on OpenFaas. Prometheus Metrics, which monitors the performance of functions, is also available out of the box.
Kubeless
I am very interested in Kubeless because it is based on native Kubernetes. It works by adding a CRD of custom resources called “functions” to native Kubernetes. Except that the implementation is very clever, which also means that it turns Kubernetes into a function runner, rather than adding all sorts of complicated features like messaging mechanisms that other frameworks do.
I like to manage functions like standard Kubernetes objects, meaning that all the usual Kubernetes goodies are available out of the box (Helm, Ark, etc.).
The interaction is done through standard Kubectl, so there are no additional tools and no service support is built in.
It sounds perfect, but…
Unfortunately, it’s not mature enough for user production. The community is also not large enough and not fully documented (having to rely on other articles or posts). And the no-service support is buggy, which means it can’t be used in Amazon EKS,
On a positive note, I believe Kubeless will become the “Kubernetes Serverless Framework” in the next 6 months.
Fission
Fission is interesting because it’s between Kubeless and OpenWhisk. It relies heavily on many features of Kubernetes, but is not fully integrated. The advantage of this approach is that it can take advantage of Kubernetes’ strengths (such as automatic elastic scaling), but get better performance when you need to do something different. For example, it has a fairly sophisticated cold start pool mechanism.
Fission is supported by Platform9 and can be installed via Helm. Influxdb is used to handle state, and FluentD is provided to collect logs for out-of-the-box use. Nats is used for messaging and Redis is used for caching. As you can see, no other framework provides caching and logging out of the box, although it’s easy to add them manually.
A very good extension of Fission is Fission Workflows. It is a tool that allows developers to write functions using functional transformations. It’s a very interesting direction, and I’d love to see what we can do with it.
However, Fission has very few users (only two related questions on StackOverflow, but does that mean it’s easy to use?). . The core contributors were also very small, with only six contributors contributing more than 10 times. There are a few other drawbacks, but mostly due to the lack of users and developers, and the lack of documentation. This makes it hard for developers to understand how the framework works, and I don’t know how the code templates and launches the Pods, which may have some implications for the future. On the whole, I’m very confused about Fission’s construction. “I don’t know anything. I’m afraid to ask.”
Also, the name Fission is hard to search for.
Fn
The name Fn sounds a little awkward. It is open source, but the major contributors are from Oracle. In use, it mainly relies on Fn CLI, and the function runs in Docker container. There is some information about the CLI in this blog post, which is documented here. Some components of the framework can be deployed using Helm. There is also a new feature called Fn Flow that can be used to orchestrate multiple functions, similar to OpenWhisk.
But the most important difference is the way it works. The Fn’s emphasis on ease of use and novelty makes it seem self-righteous. It provides hot deployment of functions (which other frameworks also provide), as well as “flow functions” (which is unique, but it’s not clear how this works with other frameworks).
The Fn project was started in 2016, so it’s about the same age as OpenWhisk and has a certain number of contributors. However, there were some features that conflicted with Kubernetes and I was held back by them (you can’t deploy AFAICT via Kubernetes, for example). But it was my appeal, so I stopped using it. However, it is compatible with the Serverless Framework, which provides some relief.
IronFunctions
Iron Functions is backed by a company of the same name. So there’s a bit of a glitch here, and on the Readme on Github you click on “documentation” and you’re actually redirected to Iron’s home page. Then you click on “docs” and it’s not about Iron Functions. The actual documents are in the docs directory of the repository…
Like the other frameworks, it is docker-based. One interesting feature is that it has some special support for AWS Lambda. You can take code from Lambda and run it directly on Iron Functions. This is very migration friendly.
Unfortunately, it does not support deployment to Kubernetes via manifest as natively as Fn does, nor does it support the Serverless Framework. Because of these disadvantages, I stopped trying to use it. It wasn’t popular enough to appear on Google Trends.
Funktion
Funktion is a defunct solution for RedHat.
Pay attention to [IVWEB community] public number to get the latest weekly articles, leading to the top of life!