posted

0 Comments

By Berndt Jung, Senior Manager of Engineering, Serverless, Cloud-Native Apps BU

 

Dispatch started as an xLabs project to explore serverless computing for VMware. This year-long program resulted in the Dispatch Framework, an enterprise take on open-source Functions as a Service (FaaS). The team graduated from xLabs in August and joined the VMware Cloud-Native Applications business unit(CNABU). With this move, the Dispatch team has more resources to enable functions-based workloads for VMware customers. This move also coincided with another big event within the serverless ecosystem, the introduction of Knative.

 

What is Knative

Knative provides a set of Kubernetes native primitives for building serverless applications. The Knative project is broken up into three main components: build, serving, and eventing. These components map directly to functionality that underlies Dispatch.

 

In addition to functionality, Knative brings with it a community that now includes VMware. Although Knative remains a Google project, it has already achieved considerable industry support by many significant Kubernetes vendors and contributors.

 

The introduction of Knative was a significant event for the Dispatch project and team. The overlap of functionality between Dispatch and Knative was validating and shows that we understand the problems that a serverless framework addresses. Additionally, the value proposition for Dispatch remains, because Knative provides a control plane that can be fully leveraged while the Dispatch API and higher-level functionality is unchanged. However, Knative is not yet production ready and is still developing rapidly.

 

The Dispatch Roadmap

 

There are three efforts going on within Dispatch. Each of these efforts represents a separate branch within the open-source Dispatch repository:

  • Dispatch — the original project, installable on Kubernetes and flexible with regards to FaaS backends.
  • Dispatch-Solo — a spinoff of Dispatch that  removes all dependencies (including Kubernetes) except Docker. This spinoff is intended as a way to explore Dispatch and FaaS with as little fuss as possible.
  • Dispatch-Knative — a replatforming of the original project onto Knative building blocks. By fully leveraging Knative components, Dispatch can be thinner and focused on enterprise features and usability.

 

What Happens with Dispatch v0.1.x?

 

Dispatch v0.1 is deprecated. Releases will be produced on-demand and based on bug fixes. Although the feature set of Dispatch v1.0 should be comparable with v0.1, there will be breaking changes to the API and CLI. There is no future for Dispatch on Kubernetes without Knative. Dispatch remains largely for demonstration purposes, at least until Dispatch-Solo is feature complete.

 

Dispatch-Solo

 

Dispatch introduced “local mode” with v0.1.21. Dispatch could now be run as a single binary, locally, without Kubernetes. The goals were simple:

  1. Easy to develop locally
  2. Easy to get started for evaluation
  3. Easy to distribute

Dispatch-Solo is a branch of Dispatch that only supports local mode. It will be a leaner Dispatch that removes support for Kubernetes and focuses on lowering the barrier to entry to use Dispatch.

Because Dispatch and serverless is still in its infancy, understanding use cases is the highest priority. It therefore makes sense to continue to focus on getting Dispatch in as many hands as possible and making it as easy as possible to get started exploring its usage. Dispatch-Solo will also focus on packaging. In addition to releasing binaries for macOS and Linux, minimal configuration machine images will be released to make getting started in a non-Kubernetes environment quick and predictable.

Kubernetes (with Knative) will continue to be the future for production deployments of Dispatch; however, there may remain a need for Dispatch-Solo. There may be a time where getting a managed Kubernetes cluster is as simple as provisioning a virtual machine today, but we are not there today. Once Dispatch-Knative is feature and API-compatible with Dispatch-Solo, it’s possible that the Dispatch-Solo images may package up Kubernetes as well as Knative with Dispatch-Knative.

Dispatch-Knative

 

Dispatch-Knative is a branch of Dispatch that is a replatforming on top of the Knative primitives (build, serving, and eventing). Dispatch-Knative leverages all three of these building blocks to provide the same feature set as Dispatch while significantly reducing the footprint and complexity of Dispatch code. The following dependencies are replaced with functionality included within the Kubernetes and the Knative building blocks:

  • Postgres — state is captured in Knative and Kubernetes Custom Resource Definitions (CRDs)
  • Kong — API gateway functionality is provided by Istio
  • FaaS (OpenFaaS/riff/Kubeless) — Knative serving handles function scheduling and execution. Each FaaS also has a set of dependencies that will no longer be required.
  • ZooKeeper — Kubernetes CRDs and controllers manage concurrent access to resources

Knative eventing will still require a persistent queue; therefore, Kafka or RabbitMQ will likely remain a dependency.

The medium-term goal is functional compatibility with Dispatch v0.1 and API compatibility between Dispatch-Knative and Dispatch-Solo. Knative is a very young and evolving project. It is expected that changes in Knative will affect Dispatch as it develops.

 

Long-Term Dispatch: v1.0 and Beyond

 

Dispatch 1.0 represents several milestones:

  • Dispatch v0.1.x is EOL
  • Single API between Dispatch-Solo and Dispatch-Knative
  • Common client, UI, and CLI across Dispatch servers (Dispatch-Knative or Dispatch-Solo)

By converging on a single API, any clients (libraries, CLI, and UI) can all be made common. Additionally, CI tests should run against both environments with minimal differences to make maintaining two servers considerably easier.

Another goal is to maximize the common code. The servers should be thin, and plugin-like, where the interface is now the Dispatch API as opposed to lower-level plugins specific to each service. Dispatch is more opinionated now, with two supported implementations (Dispatch-Solo and Dispatch-Knative) instead of the matrix of different FaaS deployments and Queues.

It might also make sense to replace the “local mode” Dispatch packaged within Dispatch-Solo with Dispatch-Knative at this point. This decision will largely be based on the ability to easily package Kubernetes and Knative into the Dispatch-Solo image. However, it’s too early to tell when this will be a viable option.

Further details and dates are TBD and will be dictated by learnings from both Dispatch-Solo and Dispatch-Knative in addition to the evolution of the Knative project.

 

 

Got it. What can I do?

 

What we need now more than anything is feedback. Dispatch-Solo will soon be available for anyone to download and try out. Once available, give it a try and let us know what you think.  This is everyone’s chance to shape the future of serverless at VMware.

 

We are also always looking for contributors. If you want to get started contributing to Dispatch, check out the Dispatch repository and reach out to us on the #dispatch slack channel.