Soam VasaniandGitHub
e238776bf7
This changes the core fission function, environment and trigger types. It also changes Fission's storage to use ThirdPartyResources. - Functions are now specified by packages. Functions can also have both source and deployment packages. A package can be specified by a literal, or by a URL. - Environments have a build and runtime component. - Triggers reference functions by a FunctionReference. This is a layer of indirection between triggers and functions, and will allow things like incremental function upgrades in future releases. See Documentation/wip/env-v2.md for design discussion about points 1 and 2. Changes: * V2 Types All types now have a spec, following the pattern of K8s objects. Functions now have source and deployment packages. A Package can be specified by literal, or by URL. Environments now have a builder and runtime component. All triggers use a new FunctionReference to specify the function. This for now only uses a function name, but in the future can be extended to be more flexible. A new FunctionLoadRequest type is added for specialization requests to the environment runtime. * TPR types, TPR init code, and a "fission client" Implements TPR types using the spec types in fission/types.go. Adds code for adding creating TPR types, and convenient types for crud operations on each of our resource types. Adds code for connecting to K8s API and configuring a REST client with fission types set up. * Change old stateful controller into a thin apiserver This apiserver is now simply a stateless api layer on top of the TPR types. At the moment it doesn't do anything that couldn't be done by simply talking to the TPR types. In the future we can have better validation and potentially some higher level APIs (like versioning for example) in here. * Split controller client into files and update for v2 types. * Update CLI for v2 types. As far as possible we keep the CLI flags the same. We'll have to add flags for source/deploy packages and builder/runtime environments. That will come in the next change. * Update poolmgr and fetcher for v2 types. Also adds a poolmgr_test. * Update router for new types. Also adds a function reference resolver, which separates out the job of resolving a FunctionReference to a function. * Update kubewatcher and timer for v2 types. * Update Message Queue trigger type for v2 types. * Minor odds and ends. * Fission bundle CLI updates Remove controllerUrl flag, since we don't need it any more. * Remove etcd deployment (replaced by storing state in TPR) Also update the poolmgr commandline, and use an env var for the fetcher image URL. * Explicit ChecksumType and consts * Clarify separation of environment interface types
Fission: Serverless Functions for Kubernetes
Fission is a fast serverless framework for Kubernetes with a focus on developer productivity and high performance.
Fission operates on just the code: Docker and Kubernetes are abstracted away under normal operation, though you can use both to extend Fission if you want to.
Fission is extensible to any language; the core is written in Go, and language-specific parts are isolated in something called environments (more below). Fission currently supports NodeJS and Python, with more languages coming soon.
Performance: 100msec cold start
Fission maintains a pool of "warm" containers that each contain a small dynamic loader. When a function is first called, i.e. "cold-started", a running container is chosen and the function is loaded. This pool is what makes Fission fast: cold-start latencies are typically about 100msec.
Kubernetes is the right place for Serverless
We're built on Kubernetes because we think any non-trivial app will use a combination of serverless functions and more conventional microservices, and Kubernetes is a great framework to bring these together seamlessly.
Building on Kubernetes also means that anything you do for operations on your Kubernetes cluster — such as monitoring or log aggregation — also helps with ops on your Fission deployment.
Fission Concepts
A function is a piece of code that follows the fission function interface.
An environment contains the language- and runtime-specific parts of running a function. Fission comes with NodeJS and Python environments; you can also extend environments or create entirely new ones if you want. (An environment is essentially just a container with a webserver and dynamic loader.)
A trigger is something that maps an event to a function; Fission supports HTTP routes as triggers today, with upcoming support for other types of event triggers, such as timers and Kubernetes events.
Usage
# Add the stock NodeJS env to your Fission deployment
$ fission env create --name nodejs --image fission/node-env
# A javascript one-liner that prints "hello world"
$ curl https://raw.githubusercontent.com/fission/fission/master/examples/nodejs/hello.js > hello.js
# Upload your function code to fission
$ fission function create --name hello --env nodejs --code hello.js
# Map GET /hello to your new function
$ fission route create --method GET --url /hello --function hello
# Run the function. This takes about 100msec the first time.
$ curl http://$FISSION_ROUTER/hello
Hello, world!
See the examples directory for more.
Running Fission on your Cluster
See the installation guide.
Compiling Fission
See the compilation guide.
Status
Fission is in early alpha. It's not suitable for production use just yet.
We're looking for early developer feedback -- if you do use Fission, we'd love to hear how it's working for you, what parts in particular you'd like to see improved, and so on. Talk to us on slack or twitter.