So I noticed that Heroku is suggested solution for hosting for things like Phoenix but I feel like a PaaS like this might actually cause Elixir/Phoenix to lose some its power. Let me explain…
When ever you deploy to Heroku a new instance is spun up, if no errors are giving during spin up the internal routing is moved from the old instance to the new instance. Correct me if I am wrong but it seems like anything that you may have in mailboxes or stored in ETS would no longer exist. So this seems like a poor solution for something that should be fault tolerant or hot code swappable.
This is correct under most uses of Heroku. The instances don’t talk to each other or know about each other (can’t, in fact, as heroku won’t route to a private IP from another instance). This is why there’s a Redis PubSub adapter with phoenix, which will let you communicate about stuff like channel notifications but isn’t great for normal distributed BEAM uses, AFAIK. Ets, mnesia and friends are out.
The caveat is that Heroku Private Spaces will let you do the networking you need to make distributed BEAM work, at least as I understand it. However, its only available as part of the enterprise offerings and is quite expensive, so I haven’t tried it yet, though I do have an elixir app on heroku right now. Plans are to move it to AWS in the fall.
So should this be something that Phoenix points out on their site? OR should the developer learn this the hard way? I know there are a lot of packages that use genserver or ETS for a lot of things and losing that mailbox or anything stored in ETS could have a huge impact on their application. Granted understanding how OTP and ETS work are very important, there is still a lot of growth happing in the elixir community, personally I would hate to see someone learn a very hard lesson from this.
FYI:: My way around this is, instead of relying on the builtin mailbox I have a pool (poolboy) of workers that build their own connections to RabbitMQ. This allows for any worker to fail without effecting any other part of the system and when updates are pushed the system will just keep working.
I agree, its important to know how your tools work. Heroku probably deserves a “Caveats” section on the guide given how many things are different about it from traditional hosting, but that’s true of any PaaS vendor. But I have to say I have a hard time seeing how a developer is going to get bitten by this completely unawares in an app that’s been through even the lightest of development cycles—I can’t imagine someone is going to be both so new to the pros and cons of heroku, and capable of getting an app completely right on the first try, and doing zero testing through a restart… Just seems unlikely to me.
So I thinking along the lines of you have a huge processing queue,during dev that queue may be very small or non existent. So someone goes balls to the wall with their system and haven’t considered this, put updates and blam their whole queue is dead. I dont see this happening often but, I’m not sure a lot of people will consider this especially coming from other programming paradigms where the concepts of messaging and queues are not the norm.
You raise a good point, and as I said, I think a caveats section would probably be a good add. I’m still gut-checking instincts on Elixir, but I imagine the core team would look kindly on such a PR to the guides…
The issues you brought up are the exact reason I built gigalixir.com! Instances are designed to be long-lived and we support hot upgrades. We also support clustering and remote console/observer. And It’s free to try without a credit card!
I’d love your feedback even if you aren’t in the market right now.
