Explore Serverless with Fission – DevOps Series, Part 19

Welcome back to our on-going series about hands-on with serverless, hope you are enjoying it! For our post today we will explore yet another interesting FaaS runtime engine: Fission.

Let’s get started by installing fission in its own namespace

kubectl create namespace fission
helm install --namespace fission --name-template fission \
https://github.com/fission/fission/releases/download/1.9.0/fission-all-1.9.0.tgz

The output will show you how to install the fission client CLI. For example with OSX:

curl -Lo fission https://github.com/fission/fission/releases/download/1.9.0/fission-cli-osx && chmod +x fission && sudo mv fission /usr/local/bin/

You will find 3 different namespaces created for fission:

fission
fission-builder
fission-function

kubectl get namespace

The fission namespace includes all the different pods deployed for the framework itself:

kubectl get pods -n fission

The other 2 namespaces are empty for now as there are no functions deployed yet.

Now that the fission environment is completely set up you are now ready to start working on your first function. We will start by creating a new environment for the specific programming language you would like to use in your function. For our example we will use NodeJS:

fission env create --name nodejs --image fission/node-env

You may now take a look at the fission-function namespace and see now it includes 3 pods for that new environment you just deployed.

$ kubectl get pods -n fission-function
NAME READY STATUS RESTARTS AGE
poolmgr-nodejs-default-144232726-5579665886-bwkxc 2/2 Running 0 3m27s
poolmgr-nodejs-default-144232726-5579665886-qctgh 2/2 Running 0 3m27s
poolmgr-nodejs-default-144232726-5579665886-qxdmw 2/2 Running 0 3m27s

Wait a minute! … I have not deployed any code yet, and there are already pods running in the system!?

Yep, that’s an important difference when comparing fission with other FaaS engines: it pre-deploys a number of pods for a warm start-up when code needs to be executed.

Let’s download a simple hello-world javascript app we can use for our demo, and save it to a local file called hello.js

curl https://raw.githubusercontent.com/fission/fission/master/examples/nodejs/hello.js > hello.js

Take a look at its content and you will see it is as simple as returning a “hello, world!” message. We will use it to create a new function in the already deployed nodejs environment. In fission that means registering the function with the available nodejs environment (–env nodejs).

fission function create --name hello --env nodejs --code hello.js

You will see no changes in the fission-function namespace, as the environment pods were already deployed, but now your app code has been included there.

You may list the deployed functions with:

$ fission function list
NAME ENV EXECUTORTYPE MINSCALE MAXSCALE MINCPU MAXCPU MINMEMORY MAXMEMORY TARGETCPU SECRETS CONFIGMAPS
hello nodejs poolmgr 0 0 0 0 0 0 0

You can now invoke your function by running:

$ fission function test --name hello
hello, world!

It works fine!

In order to access this function via a HTTP endpoint let’s take a look at the externally reachable IP address assigned to the router LoadBalancer service:

$ kubectl get svc router -n fission
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
router LoadBalancer 10.31.240.5 104.155.113.47 80:30668/TCP 25m

But before accessing the endpoint we need to accommodate another requirement for fission: triggers. Functions in fission are invoked only when an event happens, and that’s what they call a trigger. Before being able to access that new function you need to create a trigger. In our case we will create a trigger that invokes the hello function when the URL path /hello is accessed.

$ fission route create --method GET --url /hello --function hello
trigger '027634d8-44a6-4eba-9354-cd28e55beb69' created

You may now access the URL path where the function resides:

$ curl http://104.155.113.47/hello
hello, world!

It works, well done!

By now you should have a good understanding on how to get started with several different FaaS engines over kubernetes, so please keep exploring! Remember: serverless is here to stay and nobody likes lock-in!

Any questions or comments please let me know in the comments section below, Twitter or LinkedIn.