Some interesting articles on AWS Lambda: https://mikhail.io/serverless/coldstarts/aws/ https://filia-aleks.medium.com/aws-lambda-battle-2021-performance-comparison-for-all-languages-c1b441005fd1 It looks like it would be worth checking out what you are paying for running in a container - Docker is much the worst cold start in the first article. Big discrepancy between the JVM cold start times between the two - having looked at the source code I suspect the second is using JVM libs that do lots of reflection at startup, whereas the first just responds to a request with a response. My intuition is that the JVM’s primary issue is the way JVM developers have learnt to code over the last 20 years - big, heavy, reflection based libs for things like JSON parsing & generation. Otherwise why would the JVM be particularly worse than Node? Both runtimes are a VM needing to translate to machine code.

I don't know OpenFaaS, but we're using Kotlin with Azure Functions and … it's fine, overall. 🤷‍♂️ Just as you wrote, the key is having enough throughput, so that your JVM doesn't get shut down; for example, data mapping for an IoT project works very well as an Azure Function, because there's constant data ingress. Doing stuff based on user interaction doesn't work so well, because your function will probably be shutdown in between. What I really disagree with is your argumentation, that a setup like this is not elastic anymore (it is, just not down to zero) and therefore not serverless and therefore not FaaS. For example, if you're monitoring cars, you have two traffic (literal and data 🙂) spikes per day - when most people go to work and return home. During these times, your FaaS environment will spin up a few more JVMs, but you don't have to pay them all day. That's elastic enough for me. What's 10 JVM startups a day for handling millions of messages? Heck, even if you don't use the elasticity at all (Azure can keep your environment running, but you're essentially paying for a VM then), FaaS still provides the benefit of smaller code size, deployment units, independent of the runtime. FaaS is of course not a silver bullet – it is a new tool and you have to know, what this tool is good for. Saying it shouldn't be used with the JVM at all is way too generic to be correct.

Saying it shouldn’t be used with the JVM at all is way too generic to be correct.

if you use it for short-lived functions, then what’s the benefit?

if you use it for short-lived functions, then what’s the benefit?

Using a language that’s standard to your org (and that hopefully you enjoy using), which translates to developer productivity (and hopefully happiness). It seems like you’re also making some assumptions here that will not be true in all cases: • FaaS calls must always be fast (for some definition of “fast”) • Running bytecode through the JVM is intolerably slow • “Elastic” requires scaling down to zero • The function will not be called often enough to stay warm

Using a language that’s standard to your org

i agree with you on that