Even wider language support in Fn with init-images
One of the neat features of Fn is that you define your functions as container images. Fn isn’t prescriptive about what goes into the container as long as you can read requests and write responses — anything you package in a container that can read from STDIN and write to STDOUT can be a function. This flexibility sets Fn apart from other FaaS platforms which typically only offer a small set of supported languages.
Fn encourages you to use whichever language you are most productive in, and to help get you started, the Fn CLI can generate a function template — usually a HelloWorld — for a few different languages. Try it at home:
fn init --runtime=go my-first-go-function
This is a popular feature. So popular in fact that we enthusiastically added support for a lot of different languages. As Fn became more popular, and runtimes at different versions started to be requested (Java 8 as well as Java 10, for example),… well, we ended up with 16 supported runtimes in the CLI, with PRs arriving every couple of weeks for new ones.
We decided that: a) this was adding too much responsibility to the CLI, b) the testing matrix was getting out of hand, and — most important, c) we wanted to make it easier for people to add their own function templates. So, since release 0.4.148, the Fn CLI now supports a feature we call init-images.
What is an init-image? It’s a way to package up the creation of a function, or implement a new runtime — as a container image.
Here’s an example:
fn init --init-image=mjg123/java-init
This command pulls and runs my
java-init image, and the output is used to create the new function (see the init-image how-to to learn how it works). These init images can be written by anyone and hosted anywhere, so it gives us and our users a way to create and share new function runtimes without changing the CLI. Companies can create their own private init-images — people can create and share init-images for any language they choose — and of course, being containers themselves, the init-images can be implemented in any way you can think of.
Supported runtimes aren’t going away, though —
fn init --runtime=go is still going to work (although internally it’ll be just another init-image). Now you also have a neat and flexible way to define and share function templates. Hope you like it, and if you create an init-image which you like, let us know and we’ll share it with the world.