I must say Daniel Azuma did a really great job on the documentation / guides.
Awesome! Let’s hope other PaaS vendors follow suit.
Building a docker container to run on AWS Beanstalk or Azure AppService isn’t too hard, but it’s more effort than 4 lines of yaml:
env: flex runtime: gs://elixir-runtime/elixir.yaml runtime_config: release_app: appengine_example
I’m gonna try out that side of the savannah, I guess. I’m not enamored with what you get on AWS where it feels like most of Erlang distribution is prohibitively complicated (my impression from seeing leads/decisionmakers deal with it, nothing else) and everyone chooses to go with microservices + REST (ugh).
Also, as usual: Cool that Elixir is getting exposure. Being on the front page of HN is a double-edged sword, though. Lots of people get their opinions only from cursory glances there and it’s extremely easy for them to get misinformed.
This is really cool. I’m happy that Elixir is getting both the exposure and the different options for deployment. I will definitely give the Google ecosystem a go with my next Elixir project. As michallepicki mentions above, the documentation does actually seem to be pretty good (from a quick glance at least).
I’m pleased to see this, Deployment still seems like the biggest hurdle right now with Elixir.
I’m hopeful things like this help with a convergence on best practices/well understood deployment solutions.
Saw this on Hackernews today. It seems that Elixir is becoming more mainstream which is definitely a good thing, also to convince customers to use Elixir for upcoming projects.
But beside that, since I am closer to the AWS stack I am hoping that AWS also makes Elixir deployment easier soon (e.g. on Beanstalk, etc.).
It would be interesting to hear of anyone’s experiences when of deploying there.
I’ve been meaning to migrate my blog from Heroku to Gigalixir for a while. Whenever I get around to it I’ll definitely share.
Even though I’m on AWS, this is fantastic news. Next, Tensorflow bindings?
There is always Nanobox too
That would be nice
Gigalixir is happy to send you a pull request to help with the migration if your blog is open source. We can do closed source too, but you’ll have to add us as a GitHub collaborator. Just email firstname.lastname@example.org
Thank you but I’d actually want to do it myself. Want to know all the little moving parts.
After trying out google app engine I’m left disappointed that websockets are not supported.
For such an important feature of the Phoenix web framework the docs should have called out that the default transport configuration won’t work.
The heck? o.O
Gigalixir supports websockets so it’s not like all of Google Cloud Platform doesn’t support them. Probably just their more heroku-like portion. Which I think is app engine like you mentioned.
Yea, I was about to say the same. App Engine seems like the Google equivalent of Amazon’s Elastic Beanstalk…which is to say it exists but doesn’t seem like anything people really advocate for or are particularly proud to say they use.
Gigalixir seems to do a much better job of filling the automated infrastructure space for the Elixir crowd.
What has me more excited about GCP is the API code. Knowing that we can deploy on Compute Cloud VMs or Gigalixir and be able to count on easy API integration with the rest of the stack is a relief, especially for datastores.
FYI: It looks like Google Cloud Platform is adding WebSockets support to the App Engine (their PaaS). It’s currently in the Beta stage, but it really is good news. Lack of WebSockets support can be a deal breaker especially with Phoenix apps.
Fun fact: the issue requesting this feature will be soon 10 years old.