Clarify which runtimes are supported and expected to work OOTB

[mjg123]

We officially support 5 FDKs:

• Python
• Go
• JavaScript
• Java
• Ruby

So I propose that these should be the only ones which are supported by fn init --runtime=xxx - the other runtimes in the CLI currently are in a poor state (either not working, out of date or untested). Supported here means tested and guaranteed to work OOTB using whichever format: is the current default.

Specifically this should be implemented in terms of init-images (see #369). So that the fn init --runtime=xxx would be implemented internally as fn init --init-image=yyy. Where there are multiple versions of a runtime I think we should pick one for first-class treatment. The mapping from runtime to init-image would be something like this:

Runtime	init-image
python	fnproject/python3-init *
go	fnproject/go-init
javascript	fnproject/js-init
java	fnproject/java8-init *
ruby	fnproject/ruby-init

(* exact versions are up for debate but I think there should be a single supported version, and using the most-recently released LTS version makes sense)

We can still produce and release support for other runtimes (and other versions of the main runtimes) as init-images by releasing them to dockerhub and documenting them (as indeed anyone else can). But by not hard-coding them in the CLI we are being clear about what we consider a first-class supported runtime.

As a side-benefit this would:

• allow us to remove all the LanguageHelper code from the CLI (making it smaller and easier to test)
• break some circular dependencies between CLI and FDKs
• Reduce the testing matrix for runtimes in the CLI.
• decouple FDK and CLI versioning which would allow users to select different (older or newer) versions of a runtime, rather than relying on what's hard-coded in whichever version of the CLI they happen to have.

[delabassee]

Why is Kotlin not officialy supported?

Related issue https://github.com/fnproject/dockers/issues/16

[mjg123]

Several months ago we had a whole-team meeting in Bristol where we decided on those 5, and it's been in our publicity (on https://deck.fnproject.io) ever since. There are currently 16 runtimes mentioned in fn init --help and there are open PRs for at least 2 more. This isn't sustainable. I am in principle open to having the core list extended but the question ought to be the other way around:

Why should we add $SOME_LANGUAGE to the list of first-class supported languages ?

There is a testing and maintenance burden here and it has to be justified by some measure of usefulness to our users I think - I don't know how many Kotlinners there are but I suspect it's orders-of-mangnitude less than Java or gophers. Remember will be totally possible to support kotlin (and any other language) by keeping the init-image up to date with the CLI - without having its name hard-coded in the CLI.

In other words, a language not in that list doesn't mean we don't support it at all, just that keeping it up to date (how many of us knows the Kotlin FDK in enough detail to do that?) shouldn't block a CLI release.

[mjg123]

@shaunsmith and @sachin-pikle, @denismakogon, @rdallman what are your thoughts?

[rikgibson]

In that original Bristol meeting we sketched out ideas for different grades of FDK/language/runtime support - e.g. Gold, Silver & Bronze. I later sketched out some notes whilst on a flight after the Stockholm meetup outlining what these might mean (and actually came up with four rather than three)

"This issue proposes four levels of support for various languages - Platinum, Gold, Silver and Bronze.

Boilerplate generation will stop being hardcoded strings in the CLI, and will be produced by the CLI running an "init-image" container built by the appropriate FDK.

Platinum - Java: Function initialisation Build Image Overridable & Parameterisable Boilerplate generation Data Bindings xUnit Testing Support STDIO + FDK** protocol support OOTB

** FDK Protocol == TBD - one of [HTTP || JSON || CloudEvent]

Gold - Node, Go, Python, Ruby: Function initialisation Build Image Overridable Boilerplate generation*** STDIO + FDK** protocol support OOTB

Silver - Kotlin, Rust: Function initialisation Build Image Overridable Boilerplate generation STDIO Protocol only OOTB. Function dev can implement FDK protocol if desired.

Bronze - .NET Core, PHP, Lambda Node 4, Lambda Node JS 4.3, [Scala, Clojure]: Function initialisation User-supplied*** Boilerplate generation

*** fn init --init-image=<path-to-some-image>"

So there's a few things here that are being worked on across different issues - externalisation of build images into FDKs, externalisation of boilerplate using --init-image etc. The issue of a single function container protocol is still not resolved.

My interpretation of "officially supported" is that there is a proper FDK available that is always maintained by "us". There's nothing stopping someone producing a new FDK - e.g. Clojure - but that doesn't mean the creator of that FDK is committing to keeping it maintained over time. Similarly, "Silver" and "Bronze" above imply no core FDK, so the onus would be on the function developer to implement the container protocol themselves.

Specifically regarding Kotlin, whilst there's no FDK for it at the moment I'm assuming it would very likely be able to use the Java FDK? Similarly Scala?

[delabassee]

Indeed, Kotlin is simply using the Java FDK, see https://medium.com/fnproject/kotlin-and-the-java-fdk-ffcf1778c74a

[delabassee]

Flow should IMHO also be factored in that features matrix.

[rikgibson]

It would seem silly to duplicate the Java FDK to create a Kotlin FDK, maybe the Java FDK just produces an additional Kotlin init-image? So creating a Kotlin function becomes fn init --init-image fnproject/kotlin-init instead of fn init --runtime kotlin.

[mjg123]

In light of Rik's notes above, this proposal can be re-worded to:

fn init --runtime=xxx should support one version of each of the platinum and gold FDKs. Other runtimes and non-latest versions of the platinuim/gold runtimes can be made available as init-images. This will reduce our testing and upgrade burden, make the cli less confusing for new users, remove broken code and allow improvements to be made to FDKs without code-change in the CLI.

[rikgibson]

Random thought: maybe --runtime=xxx should be --fdk=xxx?

[rdallman]

• allow us to remove all the LanguageHelper code from the CLI (making it smaller and easier to test)
• break some circular dependencies between CLI and FDKs
• Reduce the testing matrix for runtimes in the CLI.
• decouple FDK and CLI versioning which would allow users to select different (older or newer) versions of a runtime, rather than relying on what's hard-coded in whichever version of the CLI they happen to have.

yuge. #369 is great, long discussed! yes, it would be great to stick to our guns on having great support for our official set and to make everything else more loosely supported. in the same vein as @rikgibson's comment, we need some graduation of these to 'official' and ideally, some metric of usage (or approximation) maybe, in addition to some notion of feature-completeness (as outlined by the various levels of precious metals). in any case, I don't think we have to be militant about only supporting very few things if it's as easy as pointing --runtime xyz to a specific docker image that is well maintained, either by us or a/the community. as things are implemented currently, I agree it's horrendous to try to support all 16. we do need to gauge how well maintained things may be if it's a 'community' image, this may just be a case by case basis. there's a general ticket to hash out this process for various things https://github.com/fnproject/fn/issues/725 it's a concern for a number of things I guess.

there was an effort to make https://github.com/fnproject/fdk-testkit which we could relatively easily use something like that to verify 'feature-completeness' I would think, it would need some love of course. I think we could have a docker image we can run to point at an init image that could set up a simple function and test for feature compatibility, then e.g. init images could be tested in CI and it would be easy for a community supported image to know when things break or what else needs to be done to get full feature support. I am a little skeptical of graduating projects across various levels, considering that an fdk is a for loop with a json parser primarily it seems like a little much -- we do need some way to say that a certain runtime is 'official' / 'community supported but perfect' / 'experimental' / etc but I think that'd be a simple checklist that things either pass or they don't -- by way of moving them into fnproject/xxx-init they are blessed as 'official', we just need to define metrics around when we should do that (I think). if there's additional features above that, great, but it kind of shames certain languages if we define support levels based on really wide feature sets when for some languages certain features may not make sense either. to me, it either supports what is needed for fn or not and things such as: Overridable & Parameterisable Boilerplate generation, Data Bindings, xUnit Testing Support -- are just nice but above and beyond. in this case imo it just makes it look like we only really care about java and everything else is kinda meh, and I don't think that's really the case!

[mjg123]

Thanks for the reply @rdallman - completely agree with most, especially the last bit. Couple of points where I think we differ:

• I don't wanna be militant about what runtimes we support, but it is more complicated than pointing at a suitable init-image. Runtimes available as a --runtime=... are still considered part of the CLI. If we make a change to the CLI and they stop working, the CLI is broken and we can't release that change. Other runtimes have a looser contract with us and can be updated quickly, but wouldn't block a release of CLI. So there's a testing and compatibility burden on us for anything that has a --runtime. For example #383 will be hard with a lot of runtimes to deal with.
• I am especially wary of hard-coding --runtime=... to mean --init-image=xyz-init where xyz-init is community-maintained. Seems like too easy a way for someone to inject malicious code into our users' workflows.

[rdallman]

yeah, agree about that. I guess to keep it short, the hope is that soon(tm) the contract doesn't change a whole lot and hopefully we have decent CI to make sure CLI changes don't break the init images. right now the pain is more acute because we don't have any testing (at least, I think that's the main reason)