Documentation Revamp (#496)
Added a new documentation structure with details of concepts, tutorials and examples
This commit is contained in:
Vishal
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Fission Concepts"
|
||||
chapter: true
|
||||
draft: false
|
||||
weight: 30
|
||||
---
|
||||
|
||||
# Fission Concepts
|
||||
|
||||
#### Understanding Fission terminology and concepts
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Environment"
|
||||
draft: false
|
||||
weight: 32
|
||||
---
|
||||
|
||||
An environment contains the language and runtime specific parts of a function. An environment is essentially a container with a webserver and a dynamic loader for the function code.
|
||||
|
||||
The following pre-built environments are currently available for use in Fission:
|
||||
|
||||
| Environment | Image |
|
||||
| ------------------------------------ | ------------------------- |
|
||||
| Binary (for executables or scripts) | `fission/binary-env` |
|
||||
| Go | `fission/go-env` |
|
||||
| .NET | `fission/dotnet-env` |
|
||||
| .NET 2.0 | `fission/dotnet20-env` |
|
||||
| NodeJS (Alpine) | `fission/node-env` |
|
||||
| NodeJS (Debian) | `fission/node-env-debian` |
|
||||
| Perl | `fission/perl-env` |
|
||||
| PHP 7 | `fission/php-env` |
|
||||
| Python 3 | `fission/python-env` |
|
||||
| Ruby | `fission/ruby-env` |
|
||||
|
||||
To create custom environments you can extend one of the environments in the list or create your own environment from scratch.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Controlling Function Execution"
|
||||
draft: false
|
||||
weight: 33
|
||||
---
|
||||
# Executors
|
||||
|
||||
When you create a function, you can specify an executor for a function. An executor controls how function pods are created and what capabilities are available for that executor type.
|
||||
|
||||
## Pool-based executor
|
||||
|
||||
A pool based executor (Refered to as poolmgr) creates a pool of generic environment pods as soon as you create an environment. The pool size of initial "warm" containers can be configured based on user needs. These warm containers contain a small dynamic loader for loading the function. Resource requirements are specified at environment level and are inherited by specialized function pods.
|
||||
|
||||
Once you create a function and invoke it, one of pods from the pool is taken out and "specialized" and used for execution. This pod is used for subseqnent requests for that function. If there are no more requests for a certain idle duration, then this pod is cleaned up. If a new requests come after the earlier specialized pod was cleaned up, then a new pod is specialised from the pool and used for execution.
|
||||
|
||||
Poolmgr executortype is great for functions where lower latency is a requirement. Poolmgr executortype has certain limitations: for example, you can not autoscale them based on demand.
|
||||
|
||||
|
||||
## New-deployment executor
|
||||
|
||||
New-Deployment executor (Newdeploy) creates a Kubernetes Deployment along with a Service and HorizontalPodAutoscaler for function execution. This enables autoscaling of function pods and load balancing the requests between pods. In future additional capabilities will be added for newdeploy executortype such as support for volume etc. In the new-deploy executor, resource requirements can be specified at the function level. These requirements override those specified in the environment.
|
||||
|
||||
Newdeploy executortype can be used for requests with no particular low-latency requirements, such as those invoked asynchronously, minscale can be set to zero. In this case the Kubernetes deployment and other objects will be created on first invocation of the function. Subsequent requests can be served by the same deployment. If there are no requests for certain duration then the idle objects are cleaned up. This mechanism ensures resource consumption only on demand and is a good fit for asynchronous requests.
|
||||
|
||||
For requests where latency requirements are stringent, a minscale greater than zero can be set. This essentially keeps a minscale number of pods ready when you create a function. When the function is invoked, there is no delay since the pod is already created. Also minscale ensures that the pods are not cleaned up even if the function is idle. This is great for functions where lower latency is more important than saving resource consumption when functions are idle.
|
||||
|
||||
### The latency vs. idle-cost tradeoff
|
||||
|
||||
The executors allow you as a user to decide between latency and a small idle cost tradeoff. Depending on the need you can choose one of the combinations which is optimal for your use case. In future, a more intelligent dispatch mechanism will enable more complex combinations of executors.
|
||||
|
||||
| Executor Type | Min Scale| Latency | Idle cost |
|
||||
|:---------|:---------:|:---------:|:---------|
|
||||
|Newdeploy|0|High|Very low - pods get cleaned up after idlle time|
|
||||
|Newdeploy|>0|Low|Medium, Min Scale number of pods are always up|
|
||||
|Poolmgr|0|Low|Low, pool of pods are always up|
|
||||
|
||||
### Autoscaling
|
||||
|
||||
The new deployment based executor provides autoscaling for functions based on CPU usage. In future custom metrics will be also supported for scaling the functions. You can set the intial and maximum CPU for a function and target CPU at which autoscaling will be trigerred. Autoscaling is useful for workloads where you expect intermittant spikes in workloads. It also enables optimal usage of resources to execute functions, by using a baseline capacity with minimum scale and ability to burst up to maximum scale based on spikes in demand.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Function"
|
||||
draft: true
|
||||
weight: 31
|
||||
---
|
||||
A function is a piece of code that will be invoked based on a [trigger](../trigger). The code follows the Fission interface. In practice, the function is only an entry point for execution and it can be backed by a larger program or module.
|
||||
|
||||
A function is registered with Fission through a CLI and associated with a trigger. A function can be created based on a single source file or a source archive or a deployment archive.
|
||||
|
||||
It is possible to associate and use Kubernetes secrets and configmaps with a function.
|
||||
|
||||
Functions also accept minimum and maximum CPU and memory to be assigned, the behaviour of which varies based on executor types which are discussed in greater detail [here](../executor)
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Builder and Packages"
|
||||
draft: false
|
||||
weight: 36
|
||||
---
|
||||
|
||||
Most real world applications are more than a single file of code and typically have dependencies on libraries etc. Packages in fission solve three distinct problems:
|
||||
|
||||
1) Enable a mechanism to store more than one file as a single unit and use them with functions. This is done through a combination of deployment archive builder environment associated with the environment.
|
||||
|
||||
2) Provide a mechanism to build from source code and dependencies into a binary based on a build command and store it as an object. User should be able to use this built artifact with a function. This is achieved with a source archive and a builder environment.
|
||||
|
||||
3) Decouple the execution logic from the functions and thus enable reuse of same logic for multiple functions. This will enable user to run same logic with different functions having different runtime charateristics and executor types.
|
||||
|
||||
When you create a function with a single source file, fission internally creates a package and links it to a function. Creating a package explicitly gives more flexibility in some use cases as explained above.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Trigger"
|
||||
draft: false
|
||||
weight: 34
|
||||
---
|
||||
|
||||
Triggers are events that can invoke a [function](../function). Fission has three kinds of triggers that can be used to invoke functions.
|
||||
|
||||
## Http Trigger
|
||||
|
||||
HTTP triggers enable calling functions with HTTP requests. Supported methods are GET, POST, PUT, DELETE, HEAD and by default GET is used. URL pattern follow the gorilla/mux supported patterns.
|
||||
|
||||
## Time Trigger
|
||||
|
||||
If you want a function to be called at a periodic frequency then the time triggers are perfect for the use case. Time triggers follow cron like specifications and are invoked based on the cron schedule.
|
||||
|
||||
Time trigger based invocations are great for running scheduled jobs, periodic cleanup jobs, periodic polling based invocations etc.
|
||||
|
||||
## MQ Trigger
|
||||
|
||||
Message queue based trigger enables ability to listen on a topic and invoke a function for each message. You can optinally send a response to another topic. By default it is assumed that the messages in queue are in application/json format but you can specify otherwise while creating the trigger. Currently `nats-streaming` and `azure-storage-queue` are supported message queues supported.
|
||||
|
||||
MQ triggers are great for integrating various systems in a decoupled and asynchronous manner.
|
||||
Reference in New Issue
Block a user