This is a 5-part blog series. See part 1, part 2, and Part 3.
Fission is a Kubernetes-native, open-source framework for Serverless functions. With this free Function-as-a-Service (FaaS) solution, developers can easily code, deploy and operate Serverless applications that are production-ready from the get-go — without having to learn anything about Kubernetes. It also allows IT Ops to enable a Lambda-like experience (the Serverless service from AWS) in their own backyard — on any infrastructure, without risking lock-in or incurring additional cloud costs.
Built by Platform9 and other contributors in the Kubernetes community, fission focusses on developer productivity and accelerating time to value. Fission enables developers to write efficient, portable and high performance Serverless applications that instantly run on any Kubernetes cluster — on premises or in the cloud.
Serverless developer workflow:
- Developers easily write short-lived functions in any language
- Map them to triggers (message queues, timers, HTTP requests or other event triggers)
- The functions get deployed instantly to a Kubernetes cluster — no containers to build, no Docker registries to manage.
- When an event triggers the function, it’s instantiated along with the required underlying infrastructure.
- When the function has been idle for a (configurable) amount of time, resources are released.
Fission Architecture:
Fission Architecture
- Fission is designed as a set of microservices. A Controller keeps track of functions, HTTP routes, event triggers, and environment images. A Pool Manager (poolmgr) manages pools of idle environment containers, the loading of functions into these containers, and the killing of function instances when they’re idle. A Router receives HTTP requests and routes them to function instances, requesting an instance from the Pool Manager if necessary.
-
The controller serves the Fission API. All the other components watch the Controller for updates. The Router is exposed as a Kubernetes Service of the LoadBalancer or NodePort type, depending on where the Kubernetes cluster is hosted.When the router gets a request, it looks up a cache to see if this request already has a service it should be routed to. If not, it looks up the function to map the request to, and requests the poolmgr for an instance. The poolmgr has a pool of idle pods; it picks one, loads the function into it (by sending a request into a sidecar container in the pod), and returns the address of the pod to the router. The router proxies over the request to this pod. The pod is cached for subsequent requests, and if it’s been idle for a few minutes, it is killed.
- Fission enables the easy deployment of Serverless functions on any Kubernetes cluster.Functions execute logically discrete, short-life tasks and can be used to deploy simple applications.
- Developing more complex applications leveraging the Serverless paradigm requires the composition of interacting Serverless functions. This has typically been a complex and time-consuming process. Fission Workflows enable the easy orchestration of a sequence of Serverless functions to create an application — which significantly accelerates the creation of Serverless apps.
- Workflows present an elegant way for integrating and composing serverless functions together by defining a sequence of tasks, decisions, and loops. Functions can be composed either in sequence or in parallel. The output of a function can be sent to the inputs of another function, “if” statements, loops, and even functions that operate on other functions.
- Logging in Fission is supported via Fluentd and InfluxDB. Fission uses a Fluentd config that makes it source logs from any Fission pods and places them in a database — InfluxDB. Thanks to InfluxDB, users don’t need to install a whole ELK stack by default, and it is lightweight and simple to deploy. You can query logs from the Fission CLI, `fission function logs –name …`.
- Monitoring is supported via Prometheus, showing metrics for function call count, error count, call duration, (histogram) call overhead, response size, cold starts, function alive time, and more.
To learn more about fission and to install the open source framework to try it for yourself, visit https://fission.io/
In the last part of this series, we’ll review reference architectures for common types of serverless applications, and how to get started with some use cases that lend themselves well for Serverless functions.