Kubeless vs Fission: The Kubernetes Serverless match up
If you are reading this article, you are probably looking into implementing some sort of serverless framework in your Kubernetes cluster…and why not? both Kubernetes and Serverless are the next big thing, and both of these offer a variety of benefits for modern enterprise applications.
But why Serverless on Kubernetes? Take a look at what a typical development-ops process of micro-service on k8s vs using serverless looks like:
With traditional microservices, you have to manage much of the underlying “Ops” such as writing the dockerfile, and relevant k8s yamls. Serverless abstracts that out, so you can focus on what matters: development
For a serverless framework there are few contenders, but today I want to compare Kubeless and Fission two of the more popular options. So, which one should you choose? Kubeless? or Fission? let’s compare the two.
As you can see with the exception of Binary and Ballerina, both frameworks support most of the popular languages. I do have to point out one thing here though: Kubeless supports Python 2.7 natively, whereas Fission only has support for Python 3 out of the box.
Now that we know what languages we can use to develop, how can we execute each framework?
Both Fission and Kubeless supports most common use cases for Serverless: http trigger via k8s ingress. Pub-sub, and time-based trigger (cron). The only difference is some specifics like kafka and Kinesis.
Features / Architecture: Fission.
When it comes to features, Fission wins hands down. Though I do have to give credit when its due to Kubeless for its kubeless-ui, a really cool component that allows you to edit and deploy Kubeless functions in real-time (very similar to the AWS lambda console).
Fission also has something similar called Fission-ui, though it isn’t as UX friendly as Kubeless-ui, but it is by far more feature rich by providing bit more benchmarking and logging built-in.
However, I didn’t put much emphasis on the UI components because the likeliness of this UI feature being used in production grade enterprise applications would be slim (CI/CD anyone?). So as great as it is, using this feature would completely bypass CI/CD gates like unit tests, code reviews and version control.
Speaking of CI/CD, another thing I want to point out as a Pro for Kubeless is its integration with the serverless.io framework, which has an addon for Kubeless.
Fission Workflow
However, one of the more production ready points has to be given to Fission, with its fission-workflow, which Kubeless currently has no answer to.
Fission-workflow is basically Fissions implementation of AWS step functions. For the uninitiated, Fission workflow allows you to create a workflow of Fission functions to complete tasks with a specific order: I.e. You can have an output of one function, be the input to another, so on and so on, in sequential order.
Kubeless…the Faux Serverless
Another reason I gave the feature/architecture win for Fission over Kubeless is for what I consider to be Kubeless’ “faux” serverless. What many people assume to be serverless is undoubtedly the same architecture AWS Lambda functions use: Ephemeral, on demand and short-lived executions. Kubeless however (as of this post), creates one pod per function and scales them as needed. If you had two Kubeless functions, it would create 2 pods, and 2 deployments.
Whereas Fission stays true to serverless ephemeral nature, and executes your function in a environment pool-manager, whether you have 1 function, or 100 functions. Fission by default deploys your functions in pool-manager
Pool-manager is simply a “pool” of environments you create for each of your runtimes for your functions. Suppose you have 1 nodejs function that needs to be executed, you would create a nodejs environment as such:
we can see the pools by running `fission env list`, and the number of pods as well
So theoretically in Kubeless if your node crashes just before a request comes in, that request will wait until a K8s creates a new pod for you. Whereas in Fission due to pool-manager, even if a node crashes your function can still execute in the remaining environment pods.
Another thing to keep in mind is that in an enterprise application, you will probably have hundreds of functions, which means in Kubeless case, it would create 100+ pods, and 100+ deployments, breaking the principle: “on demand, pay for what you use.”
Popularity: Kubeless.
Even though Fission (3.4K ) has more stars than Kubeless(3K), and more “watchers” (132 vs 119), in the popularity sense (though I would venture and say it is somewhat of a meaningless statistic), Kubeless by far is more popular than fission. Hell, the only reason I found out about Fission was because of Kubeless.
Kubeless (probably because of its namesake) gets talked about, written about, and generally better “PR” than fission…In fact I’m willing to bet you came to this story because of Kubeless. Though popularity should never be the sole reason we pick a tech-stack over features, as developers we want to use technologies that will be supported for a long time. And popularity is a big driving factor of that.
Winner: Fission.
It shouldn’t have been too much of a shocker…but the clear winner in my opinion is Fission. Though both Fission and Kubeless has a long way to go before it truly competes with the likes of AWS Lambda functions, Fission embodies everything serverless is: its easy to set up, and get started and more importantly, much more feature rich than Kubeless. I can’t reiterate enough that I find Kubeless to be a faux serverless (at least until they get a pool-manager implemented), and would only recommend using it if you have a specific use case where only Kubeless is available (like if you need to use kafka or kinesis)
To Summarize:
Fission:
- Supports most modern languages
- Supports most use cases for triggers (like http, cron, MQ)
- Truly serverless
- Can create a workflow
What are your thoughts? are my assumptions correct? Did I miss anything? Let me know!
