I’ve been using Galaxy for a while as I have a SaaS in closed beta. Mostly, it’s been a huge headache-saver as far as “set it and forget it,” and uptime has been quite good.
The only pain point for me has been how maintenance periods are handled. There are a few issues, some more serious than others:
- An update to a container causes the app to refresh. So if the user is busy doing something, they will experience a page reload unexpectedly. I believe there might be a workaround to this, which is to catch the reload (or “migrate” process as Meteor calls it) with a hook and simply disallow automatic reloads.
- The above doesn’t address the server side of the restart, unfortunately. Container restarts are causing me some minor grief with only about 80 beta testers (imagine 1000+ users!). My SaaS relies on REST API calls submitted by AWS Lambda, to report certain processes being completed. When Galaxy restarts my container, there’s an interruption and in some cases users will see stuck processes in the UI because Lambda failed to talk to my Meteor app.
- So taking the above two things into consideration, the only thing I can think of doing is to put my SaaS in maintenance mode during the container upgrade/restart period. The problem is, these maintenance periods (for US servers, I might add) are not necessarily during off-peak times. Not so long ago there was a maintenance period that started at around 5pm PDT, and now theres’ another coming up on the 21st that will run from 7pm to 11pm PDT. IMO, this is unacceptable. I can’t just shut my app down for three hours, but I also can’t leave it open and accessible because of points #1 and #2 above. Container restarts occurring after midnight would be much better, I think.
I’d like to hear what MDG has to say about these points. I’m seriously considering not using Galaxy when I launch and just doing a self-service setup on AWS EC2. It might be more painful to set up and ensure uptime, but at least I have full control over when restarts happen.