add front content to nav and update roadmap (#109)

Author: berndtj

docs/_config.yml

@@ -37,7 +37,25 @@ collections:
   guides:
     output: true
     nav: Guides
+  front:
+    output: true
 
+defaults:
+  - scope:
+      path: ""
+      type: specs
+    values:
+      layout: default
+  - scope:
+      path: ""
+      type: guides
+    values:
+      layout: default
+  - scope:
+      path: ""
+      type: front
+    values:
+      layout: default
 # Exclude from processing.
 # The following items will not be processed, by default. Create a custom list
 # to override the default setting.

docs/roadmap.md renamed to docs/_front/roadmap.md

@@ -1,3 +1,5 @@
+---
+---
 Dispatch Project Roadmap
 ========================
 
@@ -34,10 +36,10 @@ This will start a more in depth discussion.
 
 ## 1.1 Users and Authentication
 
-Currently Dispatch does not contain a user database.  Although there is support for a login action against an IDP (GitHub),
-this effectively only ensures that the user has a GitHub account.  Authentication and authorization is a big value
-proposition for Dispatch, and the first step is to maintain a database of users.  This is a precursor to full blown
-roles and authorization which are also on the roadmap.
+Currently Dispatch does not contain a user database.  Although there is support for a login action against an IDP
+(GitHub), this effectively only ensures that the user has a GitHub account.  Authentication and authorization is a big
+value proposition for Dispatch, and the first step is to maintain a database of users.  This is a precursor to full
+blown roles and authorization which are also on the roadmap.
 
 An initial implementation should simply support a database and APIs for managing users.  Then the authorization check
 should simply ensure that the entity making an API request is included in that user database.  Additionally, the user
@@ -47,4 +49,29 @@ metadata should be propogated through the system (associated with the request or
 
 ## 1.3 Applications or Groups
 
+Dispatch requires a grouping mechanism in order to better structure resources such as functions and API endpoints.
+The suggested name for this grouping is "application", though that is subject to change.  Application is itself a
+first class resource, belonging to an organization.  Application should be a required property of the following
+resources:
+
+* Function
+* API
+* Secret
+* Subscription (may be implied through function)
+
+Base-images and images may remain tied to an organization.  It's possible that they may optionally be tied to an
+application.
+
+Applications should additionally enable per-application hostname (domains?) and certificates on the API gateway.
+
 ## 1.4 Image Management
+
+Currently the image support in Dispatch is simply pass-through. See the [image manager spec](image-manager.md) for
+feature description.
+
+## 1.5 Multi-Organization Support
+
+Dispatch is a multi-tenant serverless framework.  The top unit of tenancy is "organization".  Because, Dispatch only
+supports a single IDP per installation, organization is akin to a business unit with a larger enterprise.  Currently,
+a single organization is hard-coded at installation time, however organization is expected to become a configurable
+resource.

docs/_layouts/default.html

@@ -37,7 +37,14 @@
           <nav>
           {% for section in site.collections %}
           {% if section.docs.size > 0 %}
-          <h4>{{ section.nav }}</h4>
+          <!-- front section is top level and has no label -->
+          {% if section.label != "front" %}
+            {% if section.nav %}
+            <h4>{{ section.nav }}</h4>
+            {% else %}
+            <h4>{{ section.label | capitalize }}</h4>
+            {% endif %}
+          {% endif %}
           <ul>
             {% for doc in section.docs %}
             {% if doc.url == page.url %}
@@ -53,7 +60,9 @@ <h4>{{ section.nav }}</h4>
         </div>
       </header>
       <section>
-
+      <div class="section-header">
+        <a href="{{ site.baseurl }}/">Dispatch Home</a> &raquo; {{ page.title }}
+      </div>
       {{ content }}
 
       </section>

docs/assets/css/style.scss

@@ -5,7 +5,8 @@
 
 nav h4 { margin-bottom: 3px; }
 nav ul { padding-left: 0px; list-style: none; background: initial; border: initial; height: initial; }
-nav ul li { float: none; margin-left: 20px; white-space: nowrap; border: initial; height: initial; }
+nav ul li { float: none; margin-left: 0px; white-space: nowrap; border: initial; height: initial; }
 nav ul li a { color: #267CB9; display: initial; height: initial; font-size: 14px; }
 nav ul li a:hover, a:focus a:active { color: #069; font-weight: bold; background-color: initial;}
-.page-link.selected { color: #069; font-weight: bold; }
+.page-link.selected { color: #069; font-weight: bold; }
+.section-header { padding-bottom: 20px; font-size: 16px; }

docs/index.md

@@ -4,3 +4,59 @@
 # See: https://jekyllrb.com/docs/themes/#overriding-theme-defaults
 layout: default
 ---
+
+# Dispatch - more than Functions
+
+Building, deploying and administering serverless applications requires more than just a function scheduler and executor.
+Dispatch brings features and services together to easily manage production-caliber applications and services which are
+built upon functions.
+
+## A flexible FaaS
+
+Dispatch itself is not a function scheduler and executor.  Since there are several open source FaaS implementations, the
+Dispatch team decided two things early on.  First, we would not create yet another open source FaaS.  Second, the space
+is too young and immature to predict with any certainty that one FaaS would be the dominant player over others.
+
+Instead, Dispatch abstracts the FaaS implementation via a driver interface allowing integration with one or more
+existing or future FaaS implementations. The initial Dispatch release includes drivers for OpenFaaS and Riff.  Future
+drivers could include support for additional FaaS implementations, including public cloud offerings such as AWS Lambda.
+The flexibility to integrate multiple FaaS implementations is more than just future proofing, it also opens the door to
+interesting scenarios where the same function can be executed on one or more different environments based on criteria
+such as locality, compute resources (GPU) or burst scaling onto the public cloud.
+
+## A secure FaaS
+
+Giving developers direct access to VMs and containers can be problematic.  IT can quickly lose control over the
+production environment, with no knowledge of what software is actually running in their data center.  On the other hand,
+if developers have no direct access to VMs and containers this causes bottlenecks in IT and developer frustration.
+
+Function based deployments can alleviate much of this concern.  Dispatch provides an environment where everything up to
+the actual function code can be managed and inspected.  Pivotal Container Service (PKS) from VMware provides a secure
+and up-to-date Kubernetes service. Dispatch manages function runtimes and artifacts (containers) built on the latest
+Photon OS.
+
+## A multi-tenant FaaS
+
+Dispatch is designed to work in a multi-user and multi-organization environment.  Dispatch will integrate with existing
+Oauth2 compatible identity providers such as github or Active Directory.  Administrators will be able to create roles
+and permissions to ensure tight access control around the full Dispatch API.
+
+## A proper API gateway
+
+Whether building a simple web-hook or a richer web-service in order to trigger the functions that make up a deployment,
+an API gateway is required.  The API gateway provides routing and security.  Dispatch integrates the open source Kong
+API gateway to provide a production quality solution for applications built on Dispatch.  Simply define a route and bind
+it to a function to create a secure HTTPS endpoint.
+
+## Plays well with others
+
+Integration with external services and events is critical for any serverless solution.  Dispatch includes an external
+services interface that allows extending Dispatch to work with just about any other service.  These services could be
+databases to provide state to applications, or event sources which provide triggers to functions.  Included in the
+preview release is a vCenter driver which ingests vCenter events which functions can now subscribe to.  The interface is
+flexible and extensible.
+
+## Join the Dispatch team
+
+You can find Dispatch on Github. Many features are still a work in progress, but we encourage the curious to start
+building and imagining with us.