Blogroll

How does Knative project compare to Dapr?

How does Knative project compare to Dapr?

Both Dapr and Knative projects help create and run cloud-native applications on Kubernetes, but differ in important aspects. I thought I'd quickly share where these projects overlap and complement each other from a user point of view. If you prefer, you can read this post as a twitter thread too.

Dapr vs Knative

Dapr vs Knative

TLDR:
Knative extends Kubernetes with serverless containers (scaling to and from 0) and helps you connect applications declaratively. Dapr helps developers implement reliable connected distributed applications quickly. 

Community

Knative originated from Google, whereas Dapr from Microsoft. Today both projects are incubating at CNCF. Both projects have growing communities and are within top 20 active CNCF projects (Dapr #10 and Knative #17)

Knative vs Dapr community statistics
Community statistics

See the full CNCF project statistics here.

Primary focus area

➤Knative extends Kubernetes with serverless containers by taking care of runtine networking (sync/async), autoscaling (to/from zero), and app revision tracking.

➤Dapr helps developers create reliable connected distributed applications quickly. It doesn’t manage the lifecycle of the application, instead it runs next to the applications.

Target user

➤Knative serving can be used by Ops to auto-scale and release apps (with traffic splitting). Knative eventing and functions can be used by devs to build, deploy apps, and connect external systems and event-driven containers. 

➤Dapr is toolkit designed primarily for developers. Developers use APIs & SDKs to interact with Dapr and offload responsibilities such as: pub/sub, state access, stateful service invocation, resiliency, etc. There are design time and runtime benefits for architects and operations teams respectively as described here.

Supported platforms

➤Knative runs only on top of Kubernetes and a network layer such as Kourier, Istio, Contour.

➤Dapr can run on Kubernetes, as well as on-premises and edge devices (such as the International Space Station).

For local dev, Knative requires Kubernetes, whereas Dapr can also run on Docker, or as a single binary only.

Deployment model

Both projects have operator, helm chats, CLI that help with installation and operating the control planes on Kubernetes. 

➤On the data plane side, Dapr is a sidecar that gets injected into the application pod. The application interacts with Dapr over well-defined APIs...

➤Knative dictates how the application is defined and run on Kubernetes by creating deployments, pods, configmaps, and networking configurations. It injects a transparent sidecar into every pod to measure network activity. And has an activator to hold off requests while scaling from zero.

Developer experience

➤Knative uses Kubernetes CRDs for defining an app (called Knative Service) composed of container, configuration, revision. It also offers CRDs that can define how events (CloudEvents) flow between these services, subscribe to a broker. And functions-centric CLI.

➤Dapr offers HTTP and gRPC APIs for Service invocation, Pub/Sub, State, Workflows, Bindings, Configuration, Secrets, Distributed lock, called building blocks. Devs use an HTTP/gRPC client, or SDKs for 8+ languages to interact with the above APIs.

Operational experience

➤Knative serving helps Ops with releasing, auto-scaling, configuring services. Knative eventing with abstracting the broker. 

➤Dapr helps Ops with monitoring, securing, and increasing resiliency of services, as well as cloud infrastructure abstraction.

Top features

➤Knative Scale to 0 Autoscaling Traffic splitting App definition Pub/sub Connectors Function CLI

➤Dapr Pub/sub Service-to-service interaction with resiliency, key/value access, Actors, Connectors, Security (mTLS, Auth), Config/Secrets, Workflows, Distributed Lock APIs.

Feature overlap

The primary overlap is around pub/sub capabilities. Both projects offer async interactions between applications by abstracting the broker & using CloudEvents format. Both projects have connectors and ability to subscribe apps to the broker. 

➤Knative defines these w/ CRDs & over HTTP. 

➤Dapr supports HTTP/gRPC, using CRDs and code.

Sweet spot

➤Knative: autoscaling containers (to and from zero).
➤Dapr: event-driven and stateful service interactions.

Upcoming hot feature: 

➤Knative: function development. 
➤Dapr: workflows based orchestration.

Summary

Those are the key differences between Dapr and Knative I'm aware of.  If you know other differences, share those on the twitter thread. We @diagridio are actively working on both projects and exploring how they complement each other and integrate with the greater CNCF ecosystem.

About Me