Have any of you picked a Galaxy competitor because of a lack of features?

deployment
21

This is kinda/sorta off topic, but a few quick corrections:

Optics did not come out of Kadira. Kadira was a totally separate purchase made to keep the leading Meteor based metrics solution alive, for the sake of the Meteor community and Galaxy customers. Optics was developed independently.

That being said, Optics was just shut down permanently last week. Apollo Engine is the replacement product.

Nope! :slight_smile: MDG is just as focused inside the app as outside the app. Apollo Engine is an important product for sure, but the company strongly believes its inside the app open source offerrings are just as important. Meteor, Apollo Client, React Apollo, Apollo Server, and countless other development tools/libraries/frameworks, are still being worked on happily.

Also, Apollo Engine isn’t just outside the app. That’s a common misconception that MDG is working on clearing up. It’s important to realize that Apollo Engine isn’t just an APM tool. Sure, it monitors GraphQL API performance, handles error tracking, graphs/charts trends, handles caching, etc. All important stuff for sure, but the unique nature of GraphQL opens up many more possibilities with regards to tying and leveraging Engine directly in your development process and tools. Take a look at Engine’s recently announced schema validation features for example. The feature name doesn’t really do the feature itself justice, so I definitely recommend reading that linked to blog post. In a nutshell, you can test application schema changes against the historical GraphQL query/mutation data Engine has stored for your application, so you can decide how to effectively/efficiently make changes to your data layer, without impacting your user base. You can also wire all of this up to run via GitHub on commit, so new incoming schema changes that are being commited are compared against historical data in Engine, to look for potential issues. If you’re removing a field from your schema for example, a change that you think is harmless, schema validation will automatically check to see if people are still relying on that field in their current queries, and if so flag the issue in GitHub (so essentially GraphQL CI).

Schema validation is just one example; there are some really cool new Engine features / dev tool integrations coming down the pipe soon, that definitely blew my mind when I saw them.

Nope again! :slight_smile: The team at MDG belives strongly in a world where a developer happiness focused company can be commercially viable, profitable, and a strong open source contributor/champion. We’re working hard to make this happen in many different areas - more details coming soon!

11 Likes
22

Thanks for clarity, my opinions can be dated/skewed, I’ve been around since 2013, so it’s tainted, but I appreciate you giving input.

I do too, and like I said, I’m happy with all that, and content with Meteor. I should use more colour words there. I also completely understand the complexity and density of work you guys need to deal with so I should make it clear given turning left or right, I think MDG has always made decisions with what’s best for their/our community.

Sorry, I didn’t mean to get off topic or turn this into any kind of flame war, but just to mention for some, there are competitors in hosting that work really well with Meteor because of how great MDG has made it.

Thanks, @hwillson <3

3 Likes
23

This is fantastic to read. Excited to what MDG will be announcing soon

4 Likes
24

I’m using GitHub - AdmitHub/meteor-buildpack-horse: Heroku buildpack for Meteor v1.0+. The horse one.

This could be a theoretical issue - but it has not been for me. I just updated the Meteor Candy staging site - which was bumped up from Meteor 1.5 to 1.7 in the process - and everything works fine. If anything, its very fast now, I am guessing thanks to some improvements in the new versions.

With that said, whenever I build for freelance customers, I put them on Galaxy. That way, neither them or I have any concerns about their deployment having problems in the long term.

2 Likes
25

Very interesting topic.

FYI Clever-cloud ( https://www.clever-cloud.com/en/ ) supports Meteor apps. very cheap pricing, vertical and horizontal scaling possibilities, free 500mb MongoDb and just as for Heroku you just have to link your git repository and any time you push to master it is live updated. 0 configuration, almost no down time… I am a big fan personnally.

From what I just checked it also supports 2FA.

For me it’s very similar to Heroku, generally cheaper and very responsive support team.

26

Do you find that the Galaxy servers are about equal to the Heroku servers in terms of speed?

27

I have no idea. Unfortunately, I have not getting to the stage of having to care about that.

28

The changing schema example you mentioned sounds fantastic! Looking forward to it.

Getting back on track with Galaxy - These kinds of ‘upcoming’ features/tools etc are exactly the kind of thing that are entirely lacking on Galaxy - other than integrating Kadira when Arunoda shut it down, I can’t remember any significant update to Galaxy since I started using them 2-3 years ago.

Of course, this is MDG’s prerogative as I imagine the team prefers to work on the newer and way more exciting tech such as GraphQL vs spending time on their hosting platform - I just want the explicit clarity that the lack of a roadmap and any kind of upcoming announcement is because there is nothing upcoming with no intention to improve Galaxy’s offering beyond what it currently is?

2 Likes
29

Agreed! This looks amazing.

Well I have to defend them on that count. They did add whitelisting (available in Pro containers) and also the abiltiy to revert to a previous build (which has saved my ass a few times) and a few controls with health checks which are useful. When they do something it’s generally done very well, but just a shame they don’t allocate more resources to it. I see the new Apollo engine has Slack Alerts, if they could port that over to Galaxy it would be great :grinning:

Fingers crossed the annoucement that @hwillson alluded to will have something for us Galaxy users.

1 Like
30

Yes, as a matter of factor we are moving just now. I just turned off both of our Galaxy servers just hours ago.

Reasons:

  1. no auto scaling and hence going against the purpose of a managed service

  2. customer service is really bad (compared to other companies we work with, eg MongoDb). Long wait time, answer is usually it’s your problem or problem of some other company (eg Mongo). Had several tickets and we went through the same kind of “not our fault” replied every single time.

Another example is that issues are not fixed or even attended. See the reported bug with Meteor 1.7.1.x and cursor lost.

  1. Logging, alarms

Logging is very limited, can’t filter for last x time period, very unresponsive with a production system. Alarms? Non existent

  1. Lack or any development or even resources it seems

All seems to go to other developments yet while other companies bring out new features (see Zeit.now) MDG does nothing.

As to where we are now. We use a Terraform script (IaaS) to handle our whole infrastructure ourselves on AWS. Thus we’re cutting MDG as an unnecessary middleman who adds no value and we get a bunch of more features from the endless features that AWS offers.

Eg: We’re using Fargate but we also use many others like CloudWatch, Lambda, CodeStar, the whole CI/CD all in one company that has a responsive CS that helps on every ticket.

Andreas
Co-Founder and CEO of Numero Pte Ltd
Author of Your DNA family

PS: We will launch to the general public end of September and demand is huge. We have over 500 people for our private beta waiting (to test scaling). That will be a huge revenue opportunity lost for MDG but I hope this thread is a wake up call for them

2 Likes
31

Yes, sounds like Fargate or Kubernetes. It’s not milliseconds to come alive again and obviously depends on the size of the image. But it’s still fast enough for their users I guess (you accept that for the price advantage they give)

32

“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.”

Cannot be lambda as it has a 5 minute limit. Hence I believe it’s AWS Fargate or Google Kubernetes

33

Well I have to defend them on that count. They did add whitelisting (available in Pro containers)

You’re right - I’ve got my dates mixed up as it has been so long. But looking at when exactly this was, it is an example. Whitelisting is a great feature to have, and the most recent one released… all the way back in Feb 2017! Perhaps 18 months is a normal amount of time for a platform to stagnate but when so many things are lacking, and the demand for them is so high, I would have thought there would have at least been a lot of time saved on wondering/mapping out what to build.

34

Throughout my exp. with Meteor I’ve tried many options like deploying directly to AWS through docker-compose, Zeit platform(it doesn’t manage DB though), Meteor’s Galaxy.

If I were to chose now, I’d probably hack into a combination of Galaxy + Atlas(because, indeed Mongo team is currently rocking hard with their support(though, who knows how long it will last, because they weren’t always like this) since 4.0 announce or so).
Logs can be streamed just fine too.

I use Zeit platform a lot for smaller/pet projects though it doesn’t provide enough flexibility to use it for meteor. One option I’m considering right at this moment is a combination of Zeit paired with NextJS as client platform and separate server for Meteor(galaxy or AWS custom). As recent Apollo-camp development drives me crazy and Meteor just shines as Server framework.

As for auto-scaling, once you delegate heavy tasks(image processing for ex.) to AWS-Lambda/cloudinary/etc. and implement basic application degradation it is safe to assume that auto-scaling may be overkill and may probably result in additional expenses, as predictions of auto-scaling fall apart under short, but heavy load(image processing mentioned before).

1 Like
35

Yeah, those seems more likely. We’ll definitely be investing a bit of time soon to try out Zeit again.

36

Did anybody already mention Scalingo? I’m pretty happy with it although there are still features like auto scaling missing. But they told me it’s on their roadmap. But it’s super easy to use and for that it also have nice pricing.

1 Like
37

@rjdavid And anyone else who rolls their own hosting on AWS with zodern:meteor-up or otherwise… how does horizontal scaling work? This is the major thing I love about Galaxy and fear losing. Simply clicking to add more servers or change server types. All active users get handled and managed.

Is it as seamless when rolling your own on AWS?

38

In AWS, autoscaling depends on the trigger that you set e.g. a server instance hits 70% cpu load in a 5-minute period, AWS automatically initiates building another instance. Since I am using a gitlab runner, the runner creates a build waiting to be downloaded. I created a startup script for new instances to automatically download the build from the gitlab runner then install. AWS handles connecting the new instance to the load balancer.

Require 3 scripts:

  1. Gitlab CI/CD to create the build
  2. Startup script to download and install build in new server instance
  3. Terraform script to replace the instances when a new build is created
1 Like
39

I am thinking to try https://captainduckduck.com/ with https://app.montiapm.com/

40

Had never heard of those - interested in hearing how you go…