dazuma

I have Opinions about Rails or Rails-like frameworks on FaaS.

But that said, now that Google has a full-fledged Ruby runtime, it might be interesting to see if Jets can be rebased on Google Cloud Functions, maybe some adapter layer that can be swapped in for different underlying cloud vendors to help applications avoid lock-in to any vendor's product.

Procs can be used anywhere a block can.

    my_proc = proc { |request| "Hello, world!" }
    FunctionsFramework.http("hello", &my_proc)

Yeah, splitting up google-api-client was long overdue. I was really glad to have a window to do it over the holiday.

If you have feedback on Cloud Functions, feel free to open issues on the GoogleCloudPlatform/functions-framework-ruby repo on GitHub, which is where the open source side of the runtime is housed.

That's a good question. It comes down to how much you want to control the devops vs how much you want someone else to handle it for you.

App Engine is a platform-as-a-service (PaaS) which generally means a lot of things are done for you. You give App Engine the code, and App Engine builds it, deploys it, scales it, monitors it, applies OS patches, and generally provides a bunch of related services for you.

Compute Engine is more infrastructure-as-a-service (IaaS) which means the service gives you VMs, and you handle installation, build, deployment, and setting up load balancing, scaling, monitoring, etc. the way you want.

There are also hybrid products that fall somewhere in the middle. Kubernetes Engine is an example. Indeed, you can locate most hosting platforms somewhere on this spectrum.

Note also that there are trade-offs specific to Elixir as well. PaaSes generally have to be opinionated about application architecture. Most PaaSes assume a stateless web application well suited for container-based deployment, which runs somewhat counter to Erlang's stateful services and hot code swapping. If you're writing a typical web app (say, using Phoenix) then a PaaS like App Engine will often work very well. But if you are doing something different and managing persistent nodes and processes, you may need to control deployment yourself, which makes a lower level service like Compute Engine more useful.

We're not doing anything special to help set up distributed Erlang at the moment. It would probably be difficult with App Engine because it's designed to manage stateless containers. But I could imagine setting up such a network with Kubernetes Engine, or definitely with Compute Engine VMs.