I feel that this question directly implies several additional questions:
- how does meteor scale
- what options do I have to scale
Indeed, with the sudden retirement of the author/maintainer of both Cluster and mup/mupx one may have additional concerns when even asked about initial production deployments.
The offerings were always somewhat implicitly pointing towards the need for the community to step-up and create solutions.
The documentation suggests a vanilla node js deployment with solutions from that ecosystem for keeping the application running upon system restart or crash.
We had the free Meteor hosting platform until a year ago or so available with an easy “meteor deploy” CLI
We have Galaxy taking on the enterprise side (worth noting that one needs an external Mongo provider and features like IP Whitelisting, such as Atlas offers, are still not supported) also providing similar ease in deployment and scaling with a dial (turn it up for more) and no downtime
(can anyone confirm no downtime with either scaling or code deploys?)
We have unmaintained mup and mupx solutions, which have forked in many directions due to differences in production best-practice ideals and the inevitabilities of SSL/TLS, load-balancing, and reverse proxies.
Cluster integrates with these to some extent.
Docker having been added into the mix has proven controversial, to say the least.
Missing dependencies and the lack of general Docker foo universally, have resulted in mysterious docker image fetishization… (blame should also lie with Node, it’s versioning and breaking changes, and the great leap forward we took with the last meteor version in node and mongo versioning…)
We have pm2 based solutions, but this basically papers over a vanilla node install IIRC…
The agnostic front that MDG seeks to maintain regarding deployment and scaling options is often misinterpreted for a happy conflict of interest in which users are funneled towards Galaxy… (all the magic of the platform and build tool = lots of stuff going on under the hood)
I may be paraphrasing very badly here: feel free to correct as appropriate:
The general issue with mere horizontal scaling is shared state solved by “sticky sessions” “session affinity” and other means of keeping people on the particular box they were on, whilst sharing the load as best as possible.
Cluster was a breath of fresh air, and now…
I haven’t been able to use it in production except for worker auto scaling, due to issues I experience with DNS load-balancing and removal of any of the cluster nodes from DNS resulting in total system failure etc… I’m probably being dumb and not noticing some quorum even/odd issue, but the support isn’t there and the community will move on, as it never really was an active participant but was rather handed a magical gift by a really smart guy who has since moved on…
A project is more than just code. Code doesn’t die or go away. Projects do, as people route around them and their relevance fades (He’s also a flow-router co-author, pun intended)
Brilliance is often succeeded by relevant mediocrity. It’s unfortunate. It’s life.
What I really wish to ask is:
What are some clear paths to deploying and scaling an app with minimal downtime, expenditure, and hair-pulling?