What valued features would make Meteor Cloud the default deployment destination for you?

deployment
21
  • Heroku has the easiest GitHub repo to deploy I’ve seen - I can just push to master branch and it deploys
  • Adding buildpacks to Heroku is easy (i.e. I need Puppeteer, etc) - not sure if/how Galaxy supports this
  • The UI is confusing for Galaxy (and there’s like 3-4 different apps - it should all be one app)
  • the hourly pricing is unclear to me - I just want to see what I’m going to pay monthly

One a side note, I find the round-ish font and purple/orange palette rather unprofessional for Galaxy. I want a cold and reliable product

–

The killer feature

I’d love to see RedisOplog (or something like it) brought into the core packages BUT it must continue to be open source or the whole point of Meteor being open source goes away.

Galaxy can then offer integrated Redis and MongoDB hosting for the easiest devops ever… but… here comes the killer feature: Meteor, MongoDB and Redis are communicating directly over Amazon Virtual Private Cloud so there is no latency between services as there would be if they’re communicating over internet :exploding_head:

Now, you don’t feel any vendor lock in, but you see great convenience and benefit in paying a few dollars extra compared to going through the pain of running all that yourself.

8 Likes
22

in your settings.json file…

'galaxy.meteor.com': {
    baseImage: {
      repository: 'meteor/galaxy-puppeteer',
      tag: 'latest'
    },
23

Well that’s a whole other point:

  • Galaxy should not be configurable through a settings.json file, rather, there should be a (nice) dedicated interface for managing everything.
    • For one client, we’ve had a situation where keeping settings.json in the GitHub repo is a security risk. For us, the best flow was to keep the settings in the Heroku environmental variables interface, and then simply have GitHub → Push to Deploy run everything.
    • Not only do we not have to expose the file, but it’s also much easier to make a change. If we need to change a setting, we can do it in Heroku and then just restart the instances in seconds (as opposed to waiting on a manual deploy).
  • The base image thing should display all the vendor-supported images if only to demonstrate the feature to developers. Then, an option for custom can be presented.

I’d also say that MONGO_URL and MONGO_OPLOG_URL should have dedicated inputs. It took me a while to figure out that Galaxy required these from settings.json, and my app was not using that yet. My deployments kept breaking, etc. By having these dedicated / required fields, you can really improve the UX for developers.

4 Likes
24

My biggest complaint is the cost to performance ratio. Idk what they’re doing under the hood but the performance of Meteor Cloud instances is so bad compared to running it yourself on AWS. In turn you need to pay for more hosts than you really should which makes it too expensive IMO.

4 Likes
25

I’m going to guess you’re dealing with low volume traffic. If that spikes, I think you’d rather be on Galaxy than trying to optimize the small things yourself.

26

Sure, but I’ve had low volume traffic for 3 years now and at some point the extra monthly costs of hosting begin to outweigh that theoretical benefit that I’ve yet to realize. Galaxy is a great service, it’s just really expensive for small to medium apps like mine. The performance you get out of the hosts is just terrible.

27

An observation, hopefully, without injecting any judgment: for those who are dissatisfied or have higher expectations, there is a lot of cost discussion, mostly around the value of Meteor Cloud as a basic hosting service vs. a managed service.

On the one hand, there are those who express that as a basic hosting service, Meteor Cloud is expensive relative to other options.

On the other hand, there are those who point out that as a managed service, Meteor Cloud doesn’t offer enough or its additional services are not as well developed as competitors to justify its cost.

Would that be a fair assessment on the cost dimension?

1 Like
28

I personally am happy with the services offered, although MontiAPM is just a better version of Meteor APM currently which I think is a big area for improvement. Adding more features or services wouldn’t fix the cost issue for me. It’s just that the amount and size of hosts needed for ~50 concurrent users on an app with basically no subscriptions or methods is crazy.

29

Overall I would say that is pretty good summary Alim.

Though here I would say that for what what already exists a bit more polish and unification (Galaxy & APM) could go a long way.

30

This is pretty much the case for me. Cost is not really a topic for me - even if it were $50 per month I’m happy to pay. I’m hoping my apps make much more than that, and even if Galaxy saves me an hour of work, it’s worth it.

The other thing is - Galaxy doesn’t really have anything that other hosts do not. You could even sell me on developer experience but I could not Galaxy has a great one.

1 Like
31

Well, not /really/. I just would like an option to support not one of the largest (and greedy) companies on the planet. If Meteor would roll their own, I would support that. Lacking that, the option, for instance, to support Red Hat Cloud for me would be a big plus.

1 Like
32

I think you can safely assume that Meteor will not be building its own physical infrastructure.

33

MongoDB hosting would be nice (I know there’s a free option, but a more official option would be nice). Currently we use Atlas but you must use a dedicated plan before you could use VPC peering, which isn’t ideal for smaller apps. Meteor Cloud with VPC peering setup by default would be great.

1 Like
34

So fa,r all paying Meteor projects I have done, had required server and db do be located in Germany (for legal reasons). For Projects that don’t pay it’s way too expensive to use.