Is it possible to run kernel in functions with enterprise gateway?

[Jeffwan]

I am curious any community member explore the possibility to extend remote kernel to compute resources like functions?
Currently it's session based and kernel on FaaS may against the jupyter design pattern. We are trying to figure out the technical blockers and found two major ones.

1. Kernel use ZeroMQ protocol between enterprise gateway..Most function provider doesn't allow user to connect ip:port. Instead, they provide the endpoint and use gateway to forward the request. unluckily, most of them do not support TCP as well. However, we have internal function offering and we might be able to make the change.
2. It's hard to persist the intermediate state/variables. Once a cell execution is finished, the kernel is clean up and next cell can not use the variable from last cell. This seems breaks the design of jupyter.

Can someone give some insight whether these problems can be resolved? Thanks!

[kevin-bates]

EG uses the jupyter stack, same as jupyter server, to launch and manage kernels - the only difference is that it has the ability to manage kernels launched into resource-managed clusters. This functionality is now available to the rest of the framework in general in the form of kernel provisioners and which EG will be adopting in its next major release (4.0).

It sounds like FaaS takes aaS to the extreme and if the kernel's state is required to virtually persist between calls (and distinct kernel instances), you'll need to figure out that aspect of things first.

For your first item above, you might be able to use a lighter-weight server like Jupyter Kernel Gateway (and Gateway Provisioners) to essentially use a web server for each kernel - that is, a JKG server is launched for each kernel request and it manages exactly one kernel.

However, again, the harder part is capturing the state, getting it into a shared location, and re-hydrating a new/different kernel with that retrieved state. Since EG's (and Gateway Provisioner's) kernels use a "sibling launcher" they may be able to capture and send that state back to the server where it persisted. Then, somehow, a kernel startup will need to know that it needs to have its state re-hydrated and we could introduce a new communication message to the "sibling launcher" that, somehow, injects that state into the managed kernel.

Since this message appears related to your culling question, it seems like what you really want is a "sleep"/"wakeup" mechanism where those messages can be sent to different kernel instances to capture and re-hydrate state respectively. I'm not sure culling is the way to accomplish this.

Sorry for the ramble. This is kind of an interesting scenario.