Galaxy performance vs AWS

deployment
1

Hello,

I am a wavehosting user for years, but I do not trust for a long term vision ( support respond is inexistant ).
I want to go to galaxy ( good way to give back to meteor ), I have setup a staging env on it with exactly the same configuration as the prod I have :

  • Same EC2 instance ( 1Go RAM, 1CPU )
  • Same clusters on atlas with same database ( copy of prod )
  • Same region on AWS and galaxy
  • Cloudfront distrubution on both app

I see clearly that the app is slower on Galaxy than AWS ( I have monti APM setup for both apps so that I can compare graphs ), it’s not always the same difference in time response but what I can see is that DBTime is more important on galaxy.

Are there any explanations on that ?

2 Likes
2

Galaxy is using AWS. Not sure why you want to use an extra layer at additional cost and no benefit. Not even speaking about less flexibility and features.

If you want to support Meteor, I’m sure there are other ways (eg. helping with the core or other packages under the community).

2 Likes
3

Putting in a good word for Galaxy here – for me it’s great to use Galaxy because I don’t have to hassle with any devops. :slight_smile:

4 Likes
4

I’m using AWS and I don’t have to hassle with any Devops either. Because AWS does it for me (auto-scaling, security, patches etc.).

Are you guys aware how little DevOps you need to know and do when you use AWS?

I’ll give you an example, I’m using DataDog to monitor the infrastructure and also for my logs. Setting it up is very easy if I follow DataDog’s recommendation to use CloudFormation (AWS own Infrastructure as Code service). I just paste a link to an S3 object that is managed by DataDog into the CloudFormation and let it create the new stack. That’s with all the right IAM and policies and what else needs to be configured.

That’s it.

I think you guys should give it a try to handle AWS on your own and see how little DevOps is necessary.

Please don’t see that as an Anti Tiny post here. Their business model is Galaxy and providing managed services. You guys should make an informed decision. If using AWS directly isn’t for you, then by all means use Galaxy as the next best alternative.

I just want to let you know there’s a lot of FUD around DevOps on AWS :wink:

1 Like
5

Hey, great to hear about this. Did you have to make a custom deploy script, using mup or are you using deploy based on a github repository ? If so which of their hosting services are you using, simple EC2 with own config, or AWS beanstalk ?
Thanks for your feedback, any guide, setup info, or more detailed info would be welcome.

1 Like
6

Hi Ivo,

I gave a Meteor talk just a couple of weeks ago. The video is hosted somewhere here (not exactly sure where) where I also talk about the infrastructure that I use.

But a quick answer is AWS Fargate, one instance each for frontend and backend. ELB, VPC, S3, Lambda (for CPU intense functions), CloudFront, CloudFormation and CodePipeline for CD/CI

3 Likes
7

That sounds like a lot of devops to some people (including me) ! :slight_smile:

4 Likes
8

No, not as long as we have wonderful people here like @abernix who build a Docker image with Meteor and everything else you need!

I think it’s actually easier than getting Meteor to run on Windows :wink:

Not sure what you mean by DevOps. There’s no one awake the whole time checking that servers are running healthy, applying updates and patches, watching incoming traffic for potential malicious attacks, starting new servers on higher load and reducing them on lower one.

Even deploying a new version is just a commit in Sourcetree which then runs through our CI/CD and upgrades users seamlessly.

The only bit of a problem is Electron but that has nothing to do with AWS but all to do with Meteor-Desktop package.

9

I’ve looked up DevOps on Wikipedia and found the following 7 toolchains:

image
image1170Ă—2074 359 KB

1-3 is normal task for all of us, 4 is provided by the Docker image and Fargate. 5 is just a commit to the git and CodePipeline, 6 is a one-off exercise on AWS and 7 is DataDog via AWS CloudWatch in our case.

I still don’t see anything complicated there but if you find 4, 5 and 6 challenging I suggest you look into a training video or start reading some articles/docs about the AWS tools I mention.

It’s really not rocket science and if I as a CEO can run all this, so you can too.

1 Like
10

Hi @sabativi as we discussed in the ticket Galaxy is running on AWS so you need to be sure you are comparing the same thing.

Maybe you have more ECUs than the container size that you choose. AWS metric to compare CPU resources is ECUs and not CPUs.

Besides that I don’t see any other reason for having a slower performance on Galaxy. Galaxy is running your app in a container inside EC2 Machines.

We provided more hints to you in the ticket and we can continue discussing here after your finds.

1 Like
11

Hi @a4xrbj1 using Galaxy is so much more than just using AWS and creating everything from scratch using your time and money. Also you need to keep everything running and up-to-date. Pager Duty setup, people on-call, etc. We do all this for you and much more.

In Galaxy we offer a service built from the ground up thinking about Meteor apps.

Custom proxy, custom loading balance, custom scheduler (orchestrate your app versions, scale options and deploys), custom auto scaling (tailored for Meteor apps where you can scale up and down in a very flexible way saving a ton of money), Meteor experts to help you in any issue in 24 hours or less (usually a lot less), custom app protection, etc.

We have scaled many Meteor apps to dozens of thousands simultaneous users so with us you don’t need to worry about how your infrastructure is going to scale with your business. We have your back. Focus on your app.

We are a headache free approach.

We offer much more than hosting and we are always improving our services, for example, soon you are going to be able to deploy directly from GitHub repository saving money on CI or specific machines for deploys.

We offer migration discount if you are coming from a different provider as well Migrate to Cloud and Save: 30% off the first 6-months of any Meteor Cloud plan.

Just open a ticket at support@meteor.com and we will explain what you need to send in order to get this discount.

And last but not least you can save 20% by prepaying for the year.

More data

A little bit more data to back my explanation above, Galaxy is growing strong Month over Month since the acquisition of Meteor and Galaxy in 2019 by Tiny Capital.

Our churn MoM is also basically zero, this means that our customers usually stick around for years and people only stick around for a long time with solutions that are providing a lot of value to them.

As we are not only a hosting service, as explained above, so it is expected that we are going to charge more than just hosting.

Usually companies prefer to have the peace of mind that they have Meteor experts handling their apps so they don’t need to worry about DevOps at all. This provides more time for companies to focus in their apps. It’s basically the same idea of Meteor, to provide you all the necessary configurations and packages so you can focus in your app code and not building and configuring everything. With Galaxy we bring the same experience to your production environment as well.

Talking as a customer since day 0

As you all know I work for Meteor Software, ok.

But I’m also a Galaxy customer since day 0. Before the creation of Galaxy I’ve created a “Galaxy” for my previous company but it was too much work and hard to achieve all the features that Galaxy provide out-of-the-box.

When Galaxy was released we migrated right away and so far the experience has been great.

Try Galaxy

As my final message I would say to people reading here to try Galaxy and let me know :slight_smile: We have many Meteor users migrating away from other solutions to Galaxy and they are not regretting it.

I have calls with Galaxy customers at least twice a week and the feedback is always great. It is great to work with Meteor and Galaxy and our amazing community.

Also, as a customer, you can always open tickets at support@meteor.com and we are going to help you, even with Meteor questions not related to Galaxy :wink: As we have thousands of clients usually we can answer your questions very fast and appropriately because usually the questions are familiar to us.

6 Likes
12

Of course you have to make advertisement for Galaxy, which is ok. But we’ve discussed that via PM before, at least for my use case there’s no benefit and the advantage is with AWS directly (which offers superb CS as well and you deal with the experts, I mean, they have access to all the insights and tools, like MongoDb Atlas is just the best when it comes to MongoDb as it’s their product).

Anyways, I wanted to make it clear that it’s not such a big issue as most people think. We don’t have any headache either and I don’t need to employ someone to run around with a pager. It just works

1 Like
13

Sure, it’s ok to run on your own but there are different tradeoffs involved.

We don’t want to force everybody to run on Galaxy. It’s great for our community to have different options so there is not a lock-in. This makes Meteor even stronger but we also need to point out the differences and benefits of Galaxy :wink:

Galaxy is very important for Meteor. And also Meteor is very important for Galaxy. It’s a win-win.

4 Likes
14

We’re also looking to move away from Waves, but our preferred option is MUP + ELB plugin.

From what I recall when we switched away from Galaxy the performance gain was massive using like for like configurations. Not sure if that is still the case but even our users commented on the speed boost and in Monti we could see a drop in response times for everything.

In Galaxy’s defence it had a great and very mobile friendly dashboard which I still miss :smiley:

2 Likes
15

Personally I don’t want to do ops myself. It’s not because I don’t think I can figure out how to get a couple environments set up with autoscaling servers and a db in AWS. It’s because there’s a big difference between knowing how to set something up while following a tutorial, and knowing how to debug and fix something when you’ve got a production issue impacting thousands of customers. I’ve been there and it’s some of the worst anxiety I’ve ever had. I’d much rather have professional support who I can get help from. When I pay for Galaxy (or any managed infrastructure) I’m paying for the comfort of knowing that hundreds of other companies are using the same setup as me and that it’s maintained by a team of ppl who know much more about ops than I do. That peace of mind is worth quite a bit to me, and the cost of Galaxy is sooooo much cheaper than hiring a dev ops contractor to rely on for production support.

That said, I do wish Galaxy had better performance for the hardware it’s on. There seems to be an overhead that makes it worse than just using EC2 directly.

5 Likes
16

Which is why I can pay AWS and its best engineers to help me on their products. I’ve written it before, why do you think that a service provider can deliver better PS than the one who build the products?

Whenever there is a problem, you can start paying the most qualified engineers to solve your problem at AWS. That’s piece of mind. BTW, they also work 24x7, when I was a paying customer of Galaxy I can’t say the same. With AWS, you can always reach someone. It’s a one of the largest companies in the world that’s behind AWS :wink:

17

This is exactly my point, Galaxy has some sort of overhead that leads to worse performance that just raw AWS. It seems that a 9$ EC2 is like 8 times cheaper than a galaxy container with same performance.

There are big advantages of galaxy, one has to choose.

1 Like
18

Maybe someone with more knowledge of this can confirm but I believe the overhead is Kubernetes. I would not have expected it to have such a big impact however so there’s probably more to it.

19

I would love to.

To give some illustrations here is a monti APM dashboard after moving from Wavehosting to Galaxy
I add an arrow what I did it, we can notice an increase in response times !

Screenshot 2021-07-19 at 10.03.16
Screenshot 2021-07-19 at 10.03.163514Ă—1930 404 KB

20
  • Same EC2 instance ( 1Go RAM, 1CPU )

I believe the difference is probably around here.

What do you mean by “same EC2 instance”? What EC2 instance are you using?

I’m sure you are not using the same EC2 instance as Galaxy, Galaxy is running EC2 instances to host containers, you are probably running EC2 instances running your app directly on them, no?

If you are also comparing CPUs with ECUs you are mixing different metrics.

If you get 1 CPU (it’s impossible to know how many ECUs without the instance type) and compare with 1 ECU of course your response time is going to increase as usually 1 CPU is more than 1 ECU.

We would need more data to compare fairly.