Diego, the underlying scheduler for Cloud Foundry, has a concept of pre-defined one-off tasks. It'll eventually show up in the rest of the platform.
However, it'll be in the middle of the range for startup times, as some agents are sideloaded. Latency is around a second. The initial target is tasks like database migrations and batch jobs, so the ~1s delay isn't an issue.
One of my colleagues in NYC spiked on using one-off tasks for a FaaS and concluded it's not a slam dunk fit.
If I was to shimmy FaaS-style stuff into Cloud Foundry, I think it'd be easier to have standing apps with an array of functions already running, then push the magic into route services. I suspect this is how AWS already does it, given the vast difference in spinup times between Node and JVM requests -- Node makes hot-patching a list of functions easy, the JVM is less hot-patch friendly and really expects you to provide all the JARs at launch time.
Disclaimer: I work for Pivotal, we donate the majority of engineering to Cloud Foundry.
However, it'll be in the middle of the range for startup times, as some agents are sideloaded. Latency is around a second. The initial target is tasks like database migrations and batch jobs, so the ~1s delay isn't an issue.
One of my colleagues in NYC spiked on using one-off tasks for a FaaS and concluded it's not a slam dunk fit.
If I was to shimmy FaaS-style stuff into Cloud Foundry, I think it'd be easier to have standing apps with an array of functions already running, then push the magic into route services. I suspect this is how AWS already does it, given the vast difference in spinup times between Node and JVM requests -- Node makes hot-patching a list of functions easy, the JVM is less hot-patch friendly and really expects you to provide all the JARs at launch time.
Disclaimer: I work for Pivotal, we donate the majority of engineering to Cloud Foundry.