Galaxy performance vs AWS

deployment
41

Hi @sabativi that is my point, it’s hard to compare as they are different things, of course are machines have more than 1 vCPU but we are running multiple containers there.

From your response time analysis on APM, where do you see more time being spent? What is the difference between the stack trace on Galaxy and outside Galaxy? That could provide more insights about where we could optimize more.

If you start to increase your container, in which one do you have a similar response time?

We are always investigating new ways to improve our services, for example, in the last 2 weeks we are running some experiments with different instance types as host machines. AWS provides many instances families and sizes and they are always releasing new types so it’s a continuous process.

We even have regular calls with AWS team to understand new options and optimizations.

2 Likes
42

About these last messages in general:

First, I believe many messages here are off-topic as they are focusing on cost and the thread here was focusing on performance. The performance discussion is great and we, Meteor Software, want these types of discussions as they open doors for feedback, new ideas and improvements. That is excellent for us. We are very transparent and open to discuss improvements and problems (see my previous reply as an example).

Now talking about the off-topic (costs) because I don’t like to “hide” from these types of discussions:

At Meteor Cloud we are not selling a hosting service. At Meteor Cloud we are selling hosting + time saving (no DevOps) + APM + Auto scaling + Security layers + Proxy layers + Rollback features + Alerts + Notifications + Custom app protection layer + Automatic Security updates + Expert support (from people with experience scaling Meteor apps to huge volumes) + all the other things listed here.

So every time that you compare Meteor Cloud full-featured solution with Digital Ocean Droplets or AWS EC2 or any other Hosting provider you are just comparing two different things and of course they are going to have a different cost.

It’s that simple: they have different costs because they are different things.

It’s also weird to see someone saying: “Galaxy is a bad deal”. Meteor Cloud is growing since the acquisition by Tiny and even comparing with previous years before Tiny acquisition we are in our best moment on every important metric. So clearly Galaxy (or Meteor Cloud) is a great deal for thousands of companies and Meteor apps.

Is Meteor Cloud the best option for everybody? No, I don’t believe any production or solution is the BEST option to EVERYBODY. But I can ensure you all that Galaxy is great for many and many companies building great businesses with Meteor.

I’m talking with different Meteor Cloud customers at least twice a week. So I know what I’m talking here. Trust me.

And the best part, we are always working to provide better services and we hear our clients a lot. We know what they think about us and why they are running with us.

Soon we are going to add one more feature that will reduce even more the work to deploy Meteor apps. Our goal is to improve every day the experience of people running businesses with Meteor. This is our focus.

So if you want to run your app in production with confidence, deploy to Galaxy, ask all your questions to our support and I’m sure you are not going to regret.

12 Likes
43

Hey @filipenevola, I upgrade to double size container and it looks the same as I mentionned ealier.
For me it is fine right now, it was just unclear at start, because I thought that with a standard size I will get the same performance.

I have two more questions to :

  • About APM, I love monti APM dashboard, especially because I have REST API and they add this + a new Insight and System feature in beta.
    Is there any link between galaxy APM and monti APM ?

  • Security layers + Proxy layers, would you recommend it for any app ?

Also I do agree that most things after are off topic ( interesting but another topic should be opened )

2 Likes
44

Our app scaled quickly in 2020 and 2021. We went from spending $1000 per month in Galaxy to now about $5000 per month.

Our app is highly optimized too. Been working on optimization steadily since 2015 when we started on Meteor (search the forums for evidence of that).

You definitely pay a lot more on Galaxy to get the same horsepower. We’ve been wanting to get a test instance up on AWS for a long time.

I agree with @vikr00001 - Yes, this sounds so easy! Nothing really to do at all. Just setup and maintain ten new AWS services! :crazy_face:

We stick with Galaxy for now because it easily loads Meteor APM, it easily rolls back deployment, the Domains & Encryption functionality is essential to our business because we white-label our app for various URLs and apply SSL (which Let’s Encrypt makes easy). Not even sure how to do that in AWS. Would need to look into setting all this up. Plus everything else.

Though, we do use S3, Route 56, and CloudFront already with Meteor. So perhaps we already have a headstart.

I look at those $5K bills each month and we’re still not really at the performance we need. We need even more horsepower but it’s too expensive. It only gets bad in peak periods of use. We do “events” so we have those crazy bursts of users.

1 Like
45

Thanks for this answer ! Really impressive 5000$ but I guess revenue should be correlated.
We have the same use case : white-label apps and on this galaxy is perfect.

1 Like
46

Invest $1000 and a good AWS certified DevOp can set it all up for you in 1 week, including having everything nicely documented in Terraform (IaaS).

You know, if I’d propose Google cloud or even Azure and the alternative is Galaxy (which runs on AWS), I could understand your arguments to a certain amount.

But it’s AWS vs a 3rd party running on AWS.

The middleman needs to make money at scale to pay those resources, their training and get a nice ROI to satisfy the investors.

So by all means, stay on Galaxy so Tiny keeps on investing in Meteor and people like Filipe.

But if a Frontend developer can learn all these skills over the weekend by reading docs and articles, it can be done.

But the fact that you don’t even know it’s not called Route 56 or how AWS handles domains and encryption just shows you didn’t even look into it properly.

So with that little knowledge you can indeed not estimate how big a task it is to do all this on AWS only.

Besides, I just reset my commit in Git and CodePipeline does a quick and smooth rollback of deployments if despite all tests there’s an error.

Nothing that you describe isn’t available in AWS.

Did you ever look at DataDog’s APM? But just go with MontiAPM, adding it was a single line of code.

1 Like
47

Route 56 was just forgetting the name. I’m adept at several AWS services. We run our DNS in Route 53, Meteor caching in CloudFront, static site hosting and app image-uploading in S3 (thanks to Slingshot), so I know all about some of it. Manual hosting, not so much.

You’re right @a4xrbj1 , it is a bit of FUD. I’ve never taken the time to really research it. Seems there’s so many options like you say:

AWS, MUP, EC2 and ELBs, Beanstalk, CloudFormation, Fargate, etc. etc. Private Cloud. Google, etc.

And with growing users and revenue, app features have been the priority. We never bothered fixing something that wasn’t broken (Galaxy).

It would be nice to get a 5x or 10x increase in scalability for the same (or less) money though. I’ll have to track down your video.

And yes @sabativi, the revenue is there to support $5K and $2K a month for Galaxy and Atlas respectively. Otherwise, we would have been forced to switch some time ago.

One way to look at it is $5K x 12 months = $60K a year. That’s a damn cheap DevOps engineer and includes the hosting cost. That’s the value of Galaxy, which is fair. It just doesn’t deliver on muscle for the price by any stretch. Other features, yes.

2 Likes
48

One way to look at it is $5K x 12 months = $60K a year. That’s a damn cheap DevOps engineer and includes the hosting cost. That’s the value of Galaxy, which is fair. It just doesn’t deliver on muscle for the price by any stretch. Other features, yes.

You don’t need the devops guy fulltime, especially not after it’s setup. In our company we (as in the programmers) set it up ourselves. I can’t say exactly how much time it took in total but in an average month we don’t generally make any changes to it. It’s still important to know how to make those changes or know where to look when there’s an issue though. That said services like ELB are already reasonably high level, not quite PaaS level but certainly easy for non sysadmins to work with without reading any manuals.

1 Like
49

They’re both forks of the original kadira but AFAIK zodern has been a lot more active improving it. I haven’t seen galaxy in a while so not sure if they’ve made any updates.

50

For discussion purposes only… when there’s an issue, it may be something that is taking your servers offline. This may not be a good time to be reaching out to an independent developer to see if they are available and have time to spare on an emergency basis to recover.

51

I hope to be able to save you all some money…

Roll back: sudo cp -r bundle bundle_backup when you scp your build - it’s a one line command. then untar the build tarball and run (cd programs/server && npm install) go into a screen instance and restart it node main.js (or use forever) it’s done - run nginx as your loadbalancer with meteor as the backend you don’t need extra stuff.

Mongo comes with free monitoring: https://docs.mongodb.com/manual/administration/free-monitoring/

Monit.d is a free open source library that I have been using in production for over a decade now, you can set rules to monitor any processes and make it send you alerts its very powerful and customizable, has fault tolerance and many neat features built in: Monit Manual

Like wise RRD Tool and Cacti provides free graphing for all of your disks and network interfaces: https://www.cacti.net

I have a custom display a bit like a stock trader would have price charts for all my disks and I/O await and logs etc so I can keep a good eye across the network and what’s going on. I find alerts a little irritating so I have it setup to try and be resilient.

For scaling I just ask the admin at my datacenter to spin up another server for me, I login and run my shell script to provision it then add the IP to my load balancer it takes about 30 minutes in all. If I need to issue commands across several ssh connections I use tmux another free tool.

To maximize profit I have always tried to run as simple a setup as possible and so the biggest bill is bandwidth. When you setup a dedicated network in a datacenter you will have to pay a setup fee upfront but afterwards it is significantly cheaper and the tools are all free and very simple to configure. Hope that helps you make more bread man

1 Like
52

That certainly wouldn’t be ideal, no :laughing:
I’d imagine though that if you were depending entirely on this external person you’d have some sort of contract with them where they monitor alerts and are on call for emergencies.
In our case there are two of us who know how it all works and we just never go on holiday at the same time. Not ideal either but workable

53

Yes man I’ve been there - I’ve been contracted on and off since my early teens to be the on-call admin, there’s a website pagerduty.com which will ping me when one of my clients services goes down. It’s a good job if you need to grind money because I charged per event and weekend was double time at $150 per hour so that’s why I took it. Obviously it’s trenches work and when you are out with friends and pagerduty pings it is a nightmare so I don’t recommend it for long term.

One thing is using monit so that there are rules so you can keep fishing and not have to go and sit infront of the laptop for a few hours fixing stuff. If you were stupid enough you could just milk the money in this position, which I am sure many lesser morally inclined admins do, I value my free time so I just used it to accumulate capital and build as robust a web service as possible. Setting the kernels ulimits, back tracing with dmesg, and setting up cacti for your phones screen and monit are your best friends for that and means you can enjoy your weekend without being called in to work.

3 Likes
54

We have plans to APM, as we help many clients scaling with Meteor daily we have some improvements in our backlog so it’s going to better in the future as well. It’s already good enough for the main uses cases, like optimizing publications and methods but we want to go further in next releases.

@zodern is doing a great work in MontiAPM but we don’t have any direct relationship with MontiAPM besides the fact that we bought Kadira and open-sourced it.

Zodern is a great Meteor partner in many ways, in many things we work together with him and his work on MontiAPM it also good to push us to improve our APM as well.

Sure, Meteor apps are special as they use Websockets more often than other apps so our Galaxy custom layers are tailored for Meteor apps.

Some layers are always on when you use Galaxy, others you need to run on Professional plan.

We are always improving those layers based on our customers feedbacks so you have 6 years of improvements there.

2 Likes
55

I enjoyed reading the comments shared and getting the different perspectives.

With that said, I wanted to share a video presented by one of the Co-Founders of Meteor, Matt DeBergalis - see below. This video outlines the architecture and thought process behind the creation of Meteor Galaxy and the use of Amazon ECS, Elastic Load Balancing, AWS CloudFormation, etc.

All the Best!

5 Likes
56

Never know such talk existed, thanks for sharing it :+1:

2 Likes