The Gorilla Guide to Serverless on Kubernetes, Chapter 4: What is Fission?

Fission: Open Source, Kubernetes-Native Serverless Framework

Fission is an open source, Kubernetes-native serverless functions framework with support for public, private, and hybrid clouds. Support for Kubernetes enables the portability of Fission functions with the ability to create once and deploy anywhere for consistency in code development. This accelerates your software delivery pipeline without sacrificing quality.

Fission is made up of three core concepts:

1. Functions

2. Environments 

3. Triggers

These are illustrated below.

Functions

A function is something that Fission executes. It's the code a developer has written; for instance, a piece of business logic. It adheres to certain technical characteristics commonly found in event-driven programming.

Here's a simple example of a "Hello, world!" function written in NodeJS:

module.exports = async function(context) { return {

status: 200,

body: "Hello, world!\n" };

}

Functions are generally written in an asynchronous way, so they can run in parallel for easy horizontal scaling. They're also stateless by nature, assuming anything in memory on local disks can be deleted. Any persistence is stored externally to the function, in a file system, object store or database.

Environment

Environments are the language-specific parts of Fission. An environment contains just enough software to build and run the function. It consists of a container with the language runtime, a web server, and Fission-specific parts that allow functions to dynamically load.

Fission supports many languages out of the box. A new language, or customization of an existing language environment, is as easy as creating or modifying the underlying containers.

Supported languages include:

• Node.js
• Python
• Go
• Ruby
• Java
• C# / .NET
• Binary (for executables or scripts)
• Perl
• PHP
• And more

Trigger

Functions are invoked on the occurrence of an event; a Trigger is what configures Fission to use that event to invoke a function. In other words, a trigger is a binding of events to function invocations. There are a number of types of triggers supported by Fission:

1. HTTP (specific URL or endpoint)
2. Time (cron)
3. Message Queue (based on queue topic subscription)
4. Kubernetes Watch (watches for changes in Kubernetes objects)

For HTTP requests, the Fission router handles the mapping of triggers to functions, keeps track of which actual containers run a given function, and forwards requests (and sends responses back) to and from functions.

Technical Overview

You've seen the functional concepts of Fission; now let's look under the hood. Fission is made up of a set of microservices running on Kubernetes.

Fission provides CLI tools for generating these specification files, validating them, and applying them to a Fission installation. Note that running apply more than once is equivalent to running it once: if the desired state as defined in the configuration is reached, it won't change.

Fission Services

Fission consists of various services, each running in containers:

• Controller. This is the brains of Fission, and it keeps track of functions, HTTP routes, event triggers, and environment images. It serves the Fission API to the client.
• Pool Manager and other executors. It manages pools of idle environment containers, manages the loading of functions into these containers dynamically, and kills idle function instances. The second type of executor enables automatic horizontal scaling of functions.
• Router, which handles requests and routes them to function instances. It has a cache of request and service mappings to route traffic to an existing container, or request an instance from the Pool Manager where needed.
• The Fission CLI. This is the user interface, used to interact with the fission system. It uses a declarative, file-based approach for Fission objects, like functions and environments. This way, you can track the Fission specifications along with the source code in the version control system. This allows Fission to be integrated seamlessly into the developer workflow and existing (CI/CD) pipelines.

Getting Started With Fission

Getting started with Fission is easy, needing just a couple of Helm or kubectl commands to deploy it on a laptop, in an on-premises Kubernetes cluster or in a cloud service.

The installation steps can be found on the project website, and don't require any in-depth knowledge of Kubernetes.

Learn more and install Fission.

On the next posts, we'll dive deeper into what makes serverless and Kubernetes such ideal companions, and key use cases for real-world </em> applications.

To learn more about </em>, download the Gorilla Guide: Serverless on Kubernetes.