With interest in serverless computing increasing rapidly, the question of which technology solutions will win is receiving much interest. Although there is significant industrial activity relating to serverless – driven primarily by the AWS Lambda ecosystem – there is a clear need for solutions which are not premised on lock-in to a single provider and which can work across clouds. OpenWhisk and Knative are two technologies which focus on this space – here we consider the relative positioning of these technologies based on our experience working with them.
OpenWhisk is of interest as – in our view – it was one of the first Open Source serverless platforms which offered a holistic view of the serverless paradigm. Knative is serverless hype du jour, mostly driven by intense activity within the Kubernetes community; for this reason, it is likely to claim some space in the serverless landgrab.
What was not entirely clear to us at first and what we’re reporting on here is how these two technologies relate to each other with a view to understanding how they can evolve and, in particular, if either will be more dominant.
In previous posts, we showed how to set up OpenWhisk and to create some basic services which use its event mechanisms. It is worth noting that this was all operating on top of Kubernetes. Our primary conclusion was that while the vision of OpenWhisk is compelling, the current Open Source implementation is not so easy to work with and significant effort is needed to turn it into a full fledged serverless platform. For example, basic database integration requires effort, adding external feeds which trigger events is non trivial and serving static content is more difficult than it needs to be. Of course, some of these issues are addressed in commercial OpenWhisk offerings.
At the most basic level, the lingua franca of OpenWhisk is clearly serverless functions – actions in OpenWhisk terminology. Configuring an action is as simple as wsk action create with the source code. OpenWhisk also has high level abstractions of events and trigger mechanisms, with events having clear naming conventions and quite arbitrary rules which can enable one or more actions to be triggered on occurence of an event. Further, OpenWhisk supports sequences of actions in which the output of one action is fed to a subsequent action as an input.
Knative, on the other hand, is much closer to the Kubernetes world: Knative talks yaml with diverse kind‘s and makes liberal use of kubectl apply. Knative provides mechanisms by which code in a git repo can be converted to a Knative compatible container which can be deployed and scaled dynamically – as such, the code running in the function is one step removed from working with the Knative tools. In this sense, Knative does not feel as though it offers a serverless solution per se.
For example, the following file yaml file can be used to deploy a so-called Knative service once Knative has been set up on a kubernetes cluster.
apiVersion: serving.Knative.dev/v1alpha1 # Current version of Knative
kind: Service
metadata:
name: helloworld-go # The name of the app
namespace: default # The namespace the app will use
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: gcr.io/Knative-samples/helloworld-go # The URL to the image of the app
env:
- name: TARGET # The environment variable printed out by the sample app
value: "Go Sample v1"
To be fair, Knative does not specifically consider itself a serverless platform – rather a platform to ‘build, deploy and manage serverless workloads’ and proffers that it can sit beneath different serverless platforms – OpenFaaS, fn and others.
Despite this significant difference in how to work with the systems, there is also significant overlap between these two technologies. Fundamentally, all work executes in docker containers in both cases. Further, both OpenWhisk and Knative provide a solution for building containers; both provide solutions for deploying and scaling containers and both provide event integration mechanisms. Given this significant overlap, it is natural to ask if one will dominate or how they can evolve.
As is clear from above, the current feature set of Knative does not fit with the base requirements of a serverless platform. To meet such requirements, it would likely have to add an extra layer which is one step removed from the kubernetes tool chain. Given the current stated aim of Knative, it is unlikely to do this in the near term. Of course this may change.
OpenWhisk, on the other hand, generally meets the requirements of a serverless platform: given that there is overlap between it and Knative, it needs to determine whether it will disembowel itself to leverage Knative and instead focus on higher level aspects of a serverless platform (eg good test and debugging supports, higher level usage analytics, easier event integration etc) or whether it will ignore Knative developments and continue maintaining its own kubernetes integration as both OpenWhisk and kubernetes evolve.
This is certainly a non trivial issue for OpenWhisk as it would require a significant shift in focus. Arguably, it would be worthwhile as it would enable OpenWhisk to focus more on providing value to developer communities even if it comes at the cost of alienating some of the contributors to today’s OpenWhisk. It could make it easier, for example, to develop domain specific variants of OpenWhisk which easily integrate specific data sources and data formats and are aware of primary tools and workflows within specific industries. Some efforts in this direction have already been started but it remains to be seen if they will get traction.
Today, both of these technologies are tightly coupled to the container ecosystem. However, it is likely that alternative runtimes will be more suited to serverless – unikernels and web assembly are interesting technologies worth exploring in this regard. Even within container systems themselves, there is significant scope for optimization eg bespoke containers for serverless have been proposed.
It is still very early days for serverless technology with the key benefits of serverless solutions only partially understood. Further, although it is interesting and important to consider key technologies for today and tomorrow, the technology leaders at this early stage of the race are likely to look quite different as the serverless world matures.
Lots of serverless fun ahead!