We have some exciting improvements to Galaxy that we’re releasing today. In line with our public Galaxy Roadmap, we’re releasing two major features that have been highly requested.
As of today, all Galaxy Professional users have access to:
Autoscaling - Make sure your app is running smoothly, automatically. Autoscaling spins up or spins down capacity for your application based on usage. No more paying for unused capacity or manually checking and upgrading your Galaxy account to support influxes in traffic.
API - Control your Galaxy account from afar with our new API. Extend features and functionality to your own internal dashboards or admin interfaces for more seamless maintenance of your Galaxy account.
These two features are only available to our Galaxy Professional applications so if you’re currently using Essentials, you can upgrade your account by going to the settings tab on your app. See full release notes here, or visit our docs for more details.
Thanks for being part of the community! More exciting things to come
@evolross - I was trying to find the same thing! Hopefully we’ll hear about official docs soon. Maybe you already found this, but for others with the same question, it looks like you can at least see the schema in GraphiQL: https://us-east-1.api.meteor.com/explorer
Hey! You can find API details in the GraphQL Explorer here, – check the Docs in the upper right corner.
This, along with our documentation here, should be enough. If you need help, please let us know (hello@meteor.com), and we can work to improve our documentation!
This is amazing! I’ve to say that I’m now very comfortable using and recommending Meteor/Galaxy combo to all entrepreneurs, I genuinely believe it is the best thing out there, especially for entrepreneurs.
With the the new changes, now Galaxy offers:
Fair pricing 7$ a month is a very good price for everyone who is serious about building something, it saves tons of devOps headache and yet it provides more control than things like Firebase and other backend providers, so it’s hitting this sweet spot.
Note that the price per month is $9. The annual price is for that instance is 12 x $7 = $84
Does it? Imo the headache mostly comes from, for example setting up Mup, but once you got it set up correctly, where’s the headache in doing deploys, and how often do you need to change something?
On-topic:
There are really awesome features for Galaxy
Is there any basic documentation on how the triggers work? I tried them just now to not so great results (my fault I’m sure - hence asking about documentation).
I set up one trigger to scale down if both memory and CPU usage were under a value of ‘30’ (min containers 1).
I set up another trigger to scale up containers if either CPU or Memory was over 70.
The app (at the time had a CPU usage of <20, a memory usage of approx 10 and with 420 connections) was running on 3 containers at the time and proceeded to scale down to 2 and then to 1 (all within 3 minutes of setting these triggers) and then the app crashed.
I’ve disabled the triggers for now but would love some guidance on usage - particularly what the advanced settings mean. If anyone has any idea what I messed up above or ideas on what I should try I’m all ears.
I think that is an extremely competitive price for what is being offered, the cheapest you can get after that is $5 DO but with 24$ annual difference you’re getting way more features and peace of mind (at least for my mind) therefore all my new cloud productions projects will go to Galaxy.
With that said, I do think there is still a slot for lower cost hobbyist tier, perhaps with limited connections or something.
I do use MUP and I sponsor, it’s great and it is growing fast, I need it for internally hosted servers, so it is essential for us and will continue sponsoring it. However the ability to edit the settings, autoscale, easy access to the logs (and trigger specific logs), slack notifications, and an API, ability to manage and deploy different versions, there is still tons of DevOps you need to do after deploying with MUP, that is why I think Galaxy is becoming very competitive, and if you are an entrepreneur just starting or a company in production, I think it’s better to put that energy on the actual problem you’re trying to solve and pay that little extra money.
Anyway let us keep the conversation focused on the new feature being discussed.
I’ve not tried the triggers yet, so Meteor Team can keep me honest here, but it looks like it is behaving as expected, you told it to scale down if CPU below 20% and it did, but then you can’t go that low because you’ll crash your servers (since you have that load), so I guess it is better to also keep the number of the connections in mind when you scaling down, so CPU < 30 and connection below something…if it didn’t crash, it’ll go to infinite loop, scaling down and up.
But again I’ve not tried it, just my quick thought on that.
Yup my thought process is similar but I feel there is more to it. In the case I mentioned, for example, the app runs fine on 2 containers (on current load - I have 3 as a redundancy, a redundancy I am hoping will not be needed with the right autoscaling rules in place).
And as I started typing more I found this: https://galaxy-guide.meteor.com/triggers.html - my wife would blame my having had a boy look! I’ll read through, watch the video and comment back on how I go. I’ll take another crack at setting up more triggers after business hours today.
Between the documentation here and the video by @filipenevolahere (thanks man! really appreciate it ) it’s a lot more clearer.
I think I messed up the frequency of the triggers (needed to have the scale down time be over a longer duration and have a longer interval). - I’ve got another set of triggers in place (currently disabled until end of workday today). We’ll see how it goes.
Every metric is extract from your containers, and then we calculate the simple average between all containers for every timestamp. For example, if you have 3 containers and you selected 3 metrics using 3 minutes series you are going to have 3 values that corresponds to the average of your containers 3 minutes ago, 6 minutes ago and 9 minutes ago.
A question about the bolded part (mine) - with the 3 values you have (from this example), do those values get averaged down again to determine if the trigger matches? Or does the rule look at min, max or something else?
So if I have an autoscale rule to scale down (from a starting point of 3 containers), with these parameters:
3 minute series
Metrics Quantity of 3
An action to ‘remove containers’
A rule that has CPU(%) below 30
Galaxy will look at the CPU% of each of the 3 containers, every 3 minutes, for the last 9 minutes. At this point let’s say it has 3 values (the average for all containers for each of the 3 timestamps) of 21, 13, 47 (87 being the most recent) - what happens then? Will the rule match?
I hope that isn’t a nonsensical question!
Update - to possibly answer my own question (but please confirm/correct this) - it looks at either the min or max, depending on the comparator. So my example above would fail because the value of 47 is what will be used to compare and not the average or minimum. I’m basing this on the logs generated. E.g.
So if any of the timestamps average values were above the threshold, then the match would not run.
That’s great if that is the case as it is the more conservative approach and prioritises availability. I.e. - Leans towards scaling up more liberally than scaling down.
Wow, thank you Galaxy/Meteor!
I was dying for autoscaling… and you delivered!
I tried it out this very moning, and my deployment scaled automatically!!!
You have a customer who will stay for much longer now
And the values are the average between all the containers for a specific point in time.
