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.

Ah yes, good point. I neglected to cover that. Well, in a nutshell:

* FunctionsFramework allows us to open-source the parts of the runtime not tied to the Google Cloud Functions hosting environment itself, meaning it should be possible to port it to other hosting, such as Kubernetes, Google Cloud Run, even FaaS products from other vendors.

* Procs work, but they're just objects. We'd still need some kind of interface to name them, load them, etc. Otherwise we'd be limited to, e.g., setting a special constant or global variable to the proc, which is messy, makes testing harder, etc.

* Speaking of which, a FunctionsFramework library gives us a place to put the unit testing library, tools to spin up a functions server locally for testing, and whatever tools developers might find useful in the future.

For reasons such as these, Google's overall Cloud Functions team decided to produce framework libraries for all supported languages. There's a contract and everything that our Ruby gem follows. (https://github.com/GoogleCloudPlatform/functions-framework)

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.

Hey all! I'm one of the engineers who worked on this. If anyone has questions or wants to get involved, feel free to open an issue on the github repos.

* Elixir clients for Google APIs: https://github.com/GoogleCloudPlatform/elixir-google-api

* Elixir runtime for App Engine: https://github.com/GoogleCloudPlatform/elixir-runtime

* Elixir examples: https://github.com/GoogleCloudPlatform/elixir-samples