You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 16, 2020. It is now read-only.
Copy file name to clipboardExpand all lines: docs/_front/overview.md
+32-21Lines changed: 32 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,20 +11,9 @@ Building, deploying and administering serverless applications requires more than
11
11
Dispatch brings features and services together to easily manage production-caliber applications and services which are
12
12
built upon functions.
13
13
14
-
## A flexible FaaS
14
+
## Features
15
15
16
-
Dispatch itself is not a function scheduler and executor. Since there are several open source FaaS implementations, the
17
-
Dispatch team decided two things early on. First, we would not create yet another open source FaaS. Second, the space
18
-
is too young and immature to predict with any certainty that one FaaS would be the dominant player over others.
19
-
20
-
Instead, Dispatch abstracts the FaaS implementation via a driver interface allowing integration with one or more
21
-
existing or future FaaS implementations. The initial Dispatch release includes drivers for OpenFaaS and Riff. Future
22
-
drivers could include support for additional FaaS implementations, including public cloud offerings such as AWS Lambda.
23
-
The flexibility to integrate multiple FaaS implementations is more than just future proofing, it also opens the door to
24
-
interesting scenarios where the same function can be executed on one or more different environments based on criteria
25
-
such as locality, compute resources (GPU) or burst scaling onto the public cloud.
26
-
27
-
## A secure FaaS
16
+
### A secure FaaS
28
17
29
18
Giving developers direct access to VMs and containers can be problematic. IT can quickly lose control over the
30
19
production environment, with no knowledge of what software is actually running in their data center. On the other hand,
@@ -35,26 +24,48 @@ the actual function code can be managed and inspected. Pivotal Container Servic
35
24
and up-to-date Kubernetes service. Dispatch manages function runtimes and artifacts (containers) built on the latest
36
25
Photon OS.
37
26
38
-
## A multi-tenant FaaS
27
+
###A multi-tenant FaaS
39
28
40
29
Dispatch is designed to work in a multi-user and multi-organization environment. Dispatch will integrate with existing
41
30
Oauth2 compatible identity providers such as github or Active Directory. Administrators will be able to create roles
42
31
and permissions to ensure tight access control around the full Dispatch API.
43
32
44
-
##A proper API gateway
33
+
### An integrated API gateway
45
34
46
35
Whether building a simple web-hook or a richer web-service in order to trigger the functions that make up a deployment,
47
-
an API gateway is required. The API gateway provides routing and security. Dispatch integrates the open source Kong
48
-
API gateway to provide a production quality solution for applications built on Dispatch. Simply define a route and bind
36
+
an API gateway is required. The API gateway provides routing and security. Dispatch integrates an
37
+
API gateway to provide a solution for applications built on Dispatch. Simply define a route and bind
49
38
it to a function to create a secure HTTPS endpoint.
50
39
51
-
## Plays well with others
40
+
###Plays well with others
52
41
53
42
Integration with external services and events is critical for any serverless solution. Dispatch includes an external
54
43
services interface that allows extending Dispatch to work with just about any other service. These services could be
55
-
databases to provide state to applications, or event sources which provide triggers to functions. Included in the
56
-
preview release is a vCenter driver which ingests vCenter events which functions can now subscribe to. The interface is
57
-
flexible and extensible.
44
+
databases to provide state to applications, or event sources which provide triggers to functions. The interface is flexible and extensible.
45
+
46
+
## Versions
47
+
48
+
The Dispatch project consists of two versions or branches:
49
+
50
+
*[Dispatch-Solo](#dispatch-solo) (solo branch) - Minimal dependencies and convenient packaging for evaluation
51
+
*[Dispatch-Knative](#dispatch-knative) (master branch) - Production ready, built upon Kubernetes and Knative
52
+
53
+
## Dispatch-Solo
54
+
55
+
Dispatch-Solo is a branch of Dispatch which is intended to offer the full functionality and user experience of Dispatch
56
+
while requiring very few dependencies. Additionally, Dispatch-Solo is packaged as a VM appliance making it as easy as
57
+
possible to get a functioning Dispatch environment in seconds.
58
+
59
+
There are of course limitations:
60
+
* Scale - Dispatch-Solo is a single binary and not designed to scale beyond that.
61
+
* IAM/Tenancy - Dispatch-Solo is intended to be single-user.
62
+
* Services - Dispatch relies on the Kubernetes service catalog to bring services integration. Dispatch-Solo does not include Kubernetes and therefore the service catalog.
63
+
* Persistence - Dispatch-Solo relies on a simple embeded database (BoltDB)
64
+
65
+
## Dispatch-Knative
66
+
67
+
Dispatch-Knative is the long-term production version of Dispatch. This version of Dispatch is dependent on Kubernetes
68
+
and [Knative](https://knative.dev). It is currently under heavy development.
0 commit comments