How Knative Can Unite Kubernetes and Serverless
Kubernetes and serverless are two of the hottest buzzwords in tech today — and yet they’re not often part of the same conversation. Typically, Kubernetes is used to orchestrate containerized applications, while serverless computing offers a different type of deployment model. When most people think of serverless, their first thoughts still go to AWS Lambda, Azure Functions and other cloud-based serverless frameworks that brought serverless into the mainstream a few years ago.
But the ecosystems surrounding Kubernetes and serverless are increasingly intersecting, due to the release of serverless frameworks that rely on Kubernetes. DevOps teams looking to build a serverless environment today no longer have to limit themselves to hosted serverless frameworks from public cloud vendors.
In this post, we look at Kubernetes-based serverless frameworks available today. We cover all the major offerings, but most of all, we give special attention to Knative.
Indeed, it is Knative that stands to make the biggest splash and play the largest role in attracting DevOps teams away from Lambda and the like and toward Kubernetes-based serverless environments.
Kubeless
Kubeless is an open source Kubernetes-native framework that allows you to deploy bits of code and not worry about the underlying infrastructure. It uses Kubernetes under the covers to offer API routing, autoscaling, monitoring, troubleshooting, etc. Kubeless was only created as an initial effort to give people a glimpse of what it would be like to run serverless workloads on top of Kubernetes. Upon its release, Kubeless would not be the only serverless framework to be based on Kubernetes.
Fission
Platform9, a company whose primary offering is a managed-Kubernetes service, saw the need for a serverless solution apart from Lambda. It released Fission, an open source serverless framework. Its goal was to provide an easy way for users to get started and manage their applications without having to do any of the plumbing related to containers. Fission is based on native Kubernetes.
This helpful comparison by Pete Johnson on the Cisco blog shows that Fission is somewhere in the middle between Lambda and Kubernetes. However, the need of the hour is to have a solution that is closer to Kubernetes than Lambda — both in terms of having no vendor lock-in and by being based on Kubernetes, which is the platform all cloud platforms are consolidating around today. Fission is being offered commercially by Platform9, but it hasn’t quite enjoyed the kind of industry-wide adoption that Kubernetes has. However, there’s now a contender for that spot, however: Knative.
Knative
Knative is not a complete serverless solution on its own. Rather, it is a platform to build serverless solutions on top of. In that sense, Knative would more likely be used by vendors or operators to build serverless solutions on top of Kubernetes. Dan Lorenc, a software engineering manager at Google Cloud and contributor to the Knative project, explains that “Knative acts as the layer between Kubernetes and the serverless framework. So, if you write your application to target the Knative APIs you can run it anywhere that Kubernetes runs.”
Collaborative Approach of Vendors
Knative’s key motive is to define vendor-agnostic standards for serverless computing.
The first sign of this is that Knative was created by a consortium of the leading cloud organizations like Google, Pivotal and others. Commenting on the collaborative approach to creating Knative, Jason Polites, a product manager with Google Cloud, says: “We believe that customers benefit the most from consistency across providers, and both open source and community collaboration is the best way to achieve this. We’ve seen this happen with Kubernetes, and Knative takes a similar approach. The end goal according to Jason is that “you get portability not just at the container level, but at the serverless platform level.”
For example, you can move your entire serverless platform and all the apps that run on it from your data center to a cloud platform as and when you’re ready to.
Serverless as an Adjective
Polites makes an interesting point about treating “serverless” as an adjective instead of as a noun. For the grammatically challenged, this simply means that you’re not looking to become serverless — rather, you realize that to run your app you need serverless compute, serverless memory and so on. Once you see things with that perspective, Polites explains that “you can now choose the abstraction that suits you the best without being forced into, or out of the benefits of serverless.” With Knative, you have the flexibility to architect your dream serverless platform that works perfectly for your organization’s needs. You can pick and choose which parts of your entire stack you want to manage serverlessly, and leave the others untouched.
Build, Serve, Event
Knative involves three major components: build, serve and event.
- Build: Once a piece of code is written, it needs to be packaged in a container. This is the build part of the pipeline that’s typically handled by a CI tool like Jenkins. Once the container image is built, it is uploaded to a container registry. From there, it can be deployed using YAML files to create simple or complex deployments. Knative abstracts all these steps into a single manifest file. The build part of Knative handles all container orchestration duties;
- Serve: This is the part of Knative that handles scaling of underlying instances from zero to large scale, and back to zero when the service is no longer in use. It also leverages Istio to handle routing of requests between multiple revisions or snapshots.
- Events: This part of Knative allows you to set up and define triggers for your functions. It helps build automation at any single step, or across a complex process using pipelines. This part of the project is still a work in progress.
Ease of Use
Knative also makes a lot of sense from an operational efficiency standpoint as it is really simple to use. Dan comments: “If you want to try Knative on top of Google Cloud platform, you can very easily today. With a single command, you can get Kubernetes with Knative running inside of it.” He says, “if you want to run your own serverless framework inside of a Kubernetes cluster, Knative is the best option.” And the best part is that you can have the same ease of use in your data center — in short, anywhere you can run Kubernetes, you can run Knative and all your serverless apps, too.
Running containers serverlessly is where the entire Kubernetes ecosystem is headed. As Lorenc teases: “We will have some announcements soon about how these two efforts (containers and serverless) are related in the context of Knative.” The first glimpse of this is the Knative GKE add-on, which was the first-ever commercial Knative offering. Will we see something like AWS Fargate, or something completely new? We’ll have to wait and watch.
Apart from Google’s efforts, there’s Pivotal Function Service, which is also based on Knative. Another interesting startup is TriggerMesh, which was started by the creator of Kubeless, Sebastien Goasguen.
Kubernetes-Based Serverless or Lambda?
About a year ago, if you were trying to decide whether to use a cloud-based serverless framework like Lambda or a Kubernetes-based one, the answer to this question would be the former, hands down.
Today, however, Knative has changed the landscape, giving us a capable, and even superior alternative to Lambda. If you’re just getting started with serverless, I would recommend opting for one of the Knative solutions like the GKE add-on, Pivotal Function Service or TriggerMesh. And if you’re already running apps on a serverless platform like Lambda, I’d suggest waiting it out for a few months till the Knative solutions are released, vetted with initial customers, and the reviews come pouring in. My guess is that the reviews are going to be unanimous that Knative is the way of the future — the point of intersection between Kubernetes and serverless.
