I just went through this thread: Meteor Galaxy Auto-Scaling Package for the umpteenth time. Was in the midst of replying to it but figured that the final question I was posing in my comment might make a new thread a better fit:
I think @msavin has hit the nail on the head here - no point spending resources on a feature that may reduce the amount of money Galaxy makes -> This referring to auto-scaling as a feature in Galaxy.
Of course, the wider view would be that there is lost revenue by way of potential clients choosing alternatives because of a lack of certain features in Galaxy. Existing paying clients who ask for such features will get ignored as their actions (continuing to pay and use Galaxy) speaks louder than anything else.
So my question to the community is (is there a way to add polls here?) - have any of you moved away from Galaxy/avoided it entirely (thereby actually having a monetary loss to MDG) because of missing features/lack of development within Galaxy? If so, what service are you using instead and what is the feature in question?
Final Note - This isn’t meant as an attack on MDG. I love Meteor and Galaxy, for the features it does have, is a joy to use. I just have a vision of how much greater it could be and am hoping that a thread like this might motivate further development to make it that much better.
We use Galaxy for our production app just because, in my experience, it’s the easiest deployment solution to use. “Using” meaning deploying, updating, viewing logs, Meteor APM, adding containers on the fly, adding domains in the settings (which we use a lot), changing container types, MDG manages all the server images for you (e.g. they set you up with the correct and most optimal version of Node and many other tools in their deployment images - this alone would be a major headache), etc. It’s also, I assume, the priciest. So that ease-of-use comes with a price. At the moment for us, it makes sense.
I agree with your points in that I don’t really get why MDG doesn’t give Galaxy more love. They’ve added a few things over the years (e.g. Meteor APM, IP whitelisting, etc.) but they spend much more time on Meteor and other projects. I would think with Galaxy being their main source of revenue that they would add features like notifications (especially since Kadira - from which Meteor APM is forked - had notifications??? ) and auto-scaling based on metrics (e.g. connections, CPU, memory, etc.). I assume MDG makes good money from those pricy monthly/yearly support contracts but I would think Galaxy revenue would outweigh that.
As far as other solutions - interesting to hear that Zeit’s Now with meteor-now is a solution. I didn’t know about this. That’s @arunoda right? If he’s involved you know it’s good. There’s also two package’s by the same author: meteor-up (which I think is originally forked from once-again @arunoda’s mup-x project) and mup-aws-beanstalk (which has auto-scaling, but also problems I’ve read).
There’s a few other node.js cloud providers out there that can also run your Meteor app and provide closer to what Galaxy’s provides. I forget what they are at the moment but if you search around the forums or Google you’ll find them. I think if I recall they were cheaper than Galaxy but didn’t have the same feature-set.
Running my app now on Google Kubernetes service (GKE). Haven’t looked back. Has autoscaling, alerts, 2FA and a whole lot more. Bit of work to get it setup but the ongoing costs savings are great.
We’ve used Galaxy for about two years now. It works, it’s stable (our containers very rarely die these days) and it’s easy to use.
We also run a few environments on AWS which have been kind of a pain to deal with without dedicated devops, but it’s necessary for VPC, 2FA and other requirements. If Galaxy would offer those kind of enterprise features I doubt we’d need to run them.
In general I think Galaxy is fine for most business uses. It does its job (frees you up from most devops stuff) as it is.
Right, there’s Google Compute Engine, Microsoft Azure, Amazon Web Services, Digital Ocean, and plenty of other cloud providers if you want to “roll your own” deployments with meteor-up or otherwise.
Wow, I took the last hour to review ZEIT and meteor-now… this looks interesting! I posted a few questions to the above announce thread. But holy cow the pricing. For $50 a month you get 25 instances across unlimited deployments. With this you could go wild with micro-services, start your own Meteor APM, etc. With each instance having 1GB of RAM and “1 CPU” of CPU (which I’m assuming is 1 ECU) that’s a really sweet deal if it all works. 25GB of RAM and 25 ECUs is nuts for $50 a month.
A Standard Pro (1GB 1ECU) container on Galaxy is $79 a month! My app currently runs 3 Standard Pro containers (one part of the app) and 3 Double Pro containers (another part of the app) - that’s about $725 a month.
One of my favorite things about Heroku is how you can connect your GitHub repositories to it. Whenever you push to master, it starts a new deployment. It actually beats the ease of meteor deploy because you do not have to wait for the whole bundle to build, upload, and etc, every time.
For me the key to making a true Galaxy replacement is Kubernetes which does all the heavy lifting of self-healing, autoscaling. It’s also extensible so I can add other components that I need inside of it. With Galaxy I’d need to have a seperate hosting environment for those.
re: ZEIT - If it sounds too good to be true then probably is. I’m skeptical that you can get a Ferrari for the price of a Ford Focus. Will be interested to see benchmarks.
I just watched this ZEIT DAY 2018 Keynote and their product seems pretty sweet. Sounds like Kubernetes a little.
From what I understand, they scale-down and ultimately freeze your app if you don’t have any traffic. They have some fancy tech to unfreeze it in a matter of milliseconds upon a new request. So with this algorithm they probably save a ton of server usage on lot on under-visited apps and services.
But according to their docs, you can set the scaling to always maintain a set amount of instances up to your limit. So if you want, you can keep the horsepower turned up… from what I understand.
NodeChef is a popular choice for meteor app hosting. Somewhere in 2017, a user benchmarked three platforms and found NodeChef to be the best in terms of performance. Over the years we have addressed all the Cons the user identified and have even added more features that users have requested. Auto-scaling of app containers based on rules and auto scaling of databases are just basic features on NodeChef now. More features which make running meteor apps easy are listed on pricing page.
You’re correct… After signing up for ZEIT’s chat channel on Spectrum (some new Slack-ish chat/discussion platform), the very first email notification I got was:
If you haven’t read the ZEIT docs, it basically means on their bad-ass new cloud platform, they don’t let you set the minimum number of instances for a deployment to anything above zero. So with lack of activity all deployments (e.g apps, API servers, APMs, etc.) will eventually scale down to shutting off completely (even though they claim they can be unfrozen in a matter of milliseconds).
The docs, however, say you can set up a deployment to have a minimum number of instances set to your max number of instances so you would then get that “Ferrari” power full-time. But the thread says that’s only for the v1 (old version) of their cloud.
So… to complete the analogy, yes it sounds like you get a Ferrari for the price of a Ford Focus, but the second you stop driving it around, someone else runs over, grabs the keys, and takes it out for a spin (albeit they can also somehow magically return your Ferrari in a few milliseconds). Hence their pricing. It makes sense actually, and seems really clever to me.
@knana Right, NodeChef was what I was trying to think of above. It’s much closer to Galaxy than a DIY cloud provider.
Hey, thanks for starting this @hemalr87. Really interested to hear how others are deploying their Meteor apps of late. We’re currently using Galaxy and whilst the system works and is reliable I must say we’re quite frustrated with the lack of development - things like Alerts & TFA are a must have these days. It’s a great product and could be so much better with a little TLC. We were so excited when MDG took Kadira under their wings and had high hopes but it’s not been developed at all. We’ve since switched to using Monti-APM and are also looking at options for deployment.
What we would love to be able to do is deploy a version to our staging, test it and then, when we’re happy, promote it to production (which would also require changing the settings.json). Currently we have to launch a whole new build process to launch to a different app in galaxy. Galaxy also lacks the ability to update the settings in situ.
Another thing that would be great is ssh access to the server so we can use the production shell and profiler from Qualia. Actually, it would be great to know what Qualia use for their deployments @veered ?
Zeit does seem pretty cool but never convinced us as there a bit opaque with the resources you receive. I was led to believe they are leveraging AWS Lambda under the hood but haven’t investigated much.
@hexsprite - Do you have any links on setting up with Kubernetes ?
@msavin, how about with Heroku ? We currently use Codeship which will initiate a deploy to galaxy when we push to bitbucket. Sounds like we could forego Codeship using Heroku? I’m always happy to have less moving parts
@marklynch I had no idea that you can’t SSH into a Galaxy server! I have a modified version of https://github.com/qualialabs/web-shell/ that I haven’t published which allows you to securely open a Meteor shell over the browser (and could potentially let you SSH in I suppose). I’m not confident enough in my security chops to advertise it though.
We use Rancher hosted in AWS for running in production. My Meteor talk from a couple years ago gives a bit more information on our production infrastructure: https://www.youtube.com/watch?v=Iguedyg2cOI
Yea, it’s really hard to compete with Heroku’s offerings.
Rather than focus on features that make my life easier as a developer (File uploads to S3, Forms, asset generation - icons, etc etc). They’ve focused on the rat race that is hosting, with enterprise offerings and pivoted to Optics via buying out Kadira. I’ve said it before and I’ll say it again, I’ll happily pay for things that make my life easier as a developer. It feels like MDG took the focus from inside the app to outside the app and landing in the middle. It seems like they’ve settled on being a data-middleware with graphql. I’m happy with all that, I’m content with Meteor.
@msavin, I don’t have a lot of devops experience yet. Last time I looked at Heroku was probably a year ago. At the time I was concerned that the Heroku buildpacks for Meteor were not supported by Heroku, and could potentially get out of date, develop bugs, etc. What Meteor buildpack do you use for Meteor, and how has your experience been with it?
You just need one buildpack, lots of people maintain forks https://github.com/AdmitHub/meteor-buildpack-horse/network but it’s very stable as it only needs to do a few things like grab meteor and build the application. A nice thing about buildpacks though is you can layer them with other buildpacks, for instance if you wanted to use ruby buildpack for something or need a binary like imagemagick or etc. They can be a bit of a annoying to debug, but you really shouldn’t need to unless you’re going way off the rails but any devops work can be painful to debug. Generally speaking you should be fine.
This comment is really relevant. Why MDG went to the hosting provision is a very good question. That being said, how a billing model will work for all the things OP wants is also a really good question.
I guess MDG bit the bullet and went with the pricing model which made the most sense for both them and their investors, so cannot whinge too much.
Yeah - i’m quite content with MDG too. Meteor is a good product.
) and auto-scaling based on metrics (e.g. connections, CPU, memory, etc.). I assume MDG makes good money from those pricy monthly/yearly support contracts but I would think Galaxy revenue would outweigh that.
Hence their pricing. It makes sense actually, and seems really clever to me.
