I hate to say it, @debergalis, but Meteor’s track record as being an a la carte platform is just not what it’s known for. MDG hasn’t paved the way to alternate databases or an asteroid.js-like client-only bring-your-own-DDP approach, so its a hard sell I think to say it’s now an advantage to host your database in a separate data center, over network hops, recieving a separate bill for it, and only get middle tier style DevOps for $595/mth.
I just don’t see awareness growing at the rate it’s needed for me to believe that, in Chicago IL, you’ll have more than 5 Galaxy customers by Q3 next year. So maybe you’re not priced aggressively enough, I don’t know. But it’s not easy for me to evaluate Galaxy, and the 1-year lock at first further ensures it’s easy to postpone the $7200 decision a little longer, ensuring it will only be a hit with True Believers, of which I just don’t see enough yet, and I don’t see how this pricing will help me make any new Converts.
It may not convert people over now, but when it successfully helps Meteor applications scale up and businesses buy into it, it can lead to more adoption through case studies from other larger companies.
@deanius, I really have to disagree with you here. Most of the DB providers now have links to most datacenters and you can pick that when setting up with places like Compose.
Galaxy is targeted at people with different scaling issues than startups. While I, and most others on this forum, are dealing with very typical scaling issues around Oplog write load issues, perhaps others aren’t at a much higher level? I only have one enterprise app customer and they are self-hosted for security issues, but they lack Oplog support and only have 1k users hitting the system. That is a much different load from the 200 constant concurrent users and nearly constant barrage of google bots I am trying to contend with on Crater.
We already know they have over 10 customers for launch due to a nice find by someone in the Meteor Club slack chat. I think MDG can double that in early days.
I also think it will be great to have MDG dealing with support issues that have plagued all of us for so long in devops long. Maybe we will start to see fixes trickle out in the form of 1.2.2 or some such?
In the long run, this will be better. Just maybe sucks to feel out in the cold (with pricing) for a short bit, right now.
You can’t prove that and I would argue that it is untrue at this point. MDG has hosted very few large apps outside of Percolate and outside of the 10 they have on Galaxy. This will be a trial by fire and they will learn quick, but the first 10-20 customers will pay the price.
as opposed to the price these customers would pay doing themselves?
Consider what it takes to scale a Meteor app. In the old app days, you just do a round-robin and maintain statelessness. With Meteor things change due to the constant connection. Now consider who is the best team to build a mechanism that can connect / reconnect clients on the fly. Then consider who is the best team to debug it when it goes wrong. Maybe you could use meteor-cluster if you fancy your chances, but I know where my I would bet my money and even if they still have some lessons to learn, I still think that the MDG are the best devops guys around for Meteor apps, unless you know someone better?
We were accepted into the Galaxy early access program, and paid an invoice for 1 year at $495 monthly. We are not a well-funded startup. We’re bootstrapping it, but we’ve had Meteor applications in production for two-and-a-half years already. Today we’re running 5 production apps (hosted on Modulus and Heroku) and also we spin up staging and testing servos when needed.
A single servo on modulus.io costs around $30, but you want to run on at least 2 servos to reduce downtime. So with 4-5 apps running on two servos you are over $200 per month on Modulus.io. You could host on Galaxy for $495 and it would cost twice as much, but you’d also have spare containers to grow into. Also (we hope) there will be better support and less downtime than with Modulus.io. (We’ve wasted way too much dealing with Modulus.io downtime and performance issues.)
Personally I wish Modulus.io had been more on the ball regarding the Meteor opportunity. They had a Meteor hosting solution years before Galaxy, but I feel they dropped the ball as I wrote about elsewhere.
If you are an individual developer, just stay with MUP, Modulus.io or whatever you are using and wait for Galaxy Individual Developer Plans to be announced.
My biggest criticism of Galaxy is that 1) I wish pricing was more a la carte. I don’t want to pay for 10 containers at $500 if I only need one or two containers. 2) metrics only show me the last few minutes. I should be able to see larger periods of time. We’d also like to see more stats baked into Galaxy. It’s very basic. 3) logs are purged on re-deploy so we lose the history. Also it would be nice to have some tools for searching the logs.
The price they would pay hosting with people that have experience.
Nginx and Haproxy can do this out of the box pretty easily without much effort. Network routing has been solved long ago by many other people. There is no real magic here. Places like Modulus have grown to the point where they have custom routers written in Go to deal with all the traffic they push. There is no doubt in my mind that Galaxy is using Haproxy to cover the bit you are talking about here.
Having websocket load balancing using HAproxy is one thing, and it’s totally different to have a client connection jump to another container because the first container failed. All the current load balancing mechanisms I know for Meteor require sticky sessions because they can’t handle this case.
Luckily, I don’t have to worry my little head about these details because I would rather trust the MDG deal with this stuff in Galaxy whilst I eat macaroons. That was and remains to be my point!
Again, not true. Haproxy can monitor an upstream server and pull it from the rotation. It will toss a 502 or 504 on the previous websocket and the client will reconnect. Basic Haproxy 101 here.
I get that you don’t want to learn it and that is what you are advocating for here. But this stuff isn’t that hard to learn.
As others, I also think this pricing is kind a great. Specially, when you have better support. With other cloud hosting providers, support is not that great and Meteor specific.
So, this is a good deal. From my experience, I think 1GB containers are pretty big for Meteor, because Meteor has the CPU bottleneck. So, It would be better we’ve a 512MB containers as well.
I hope this is just the beginning, Galaxy will be great and one stop place for Meteor hosting.
Totally agree here @arunoda. @samhatoum actually made a similar point in Meteor Club slack chat today, Galaxy is cheaper for 1gb boxes at 10 boxes. We just need to break up the container sizing options to make it accessible to others.
The choice to keep it at 10 containers is purely to lightening the sign up/support load, imo.
How do you see Kadira (the monitoring app, not the larger organization) interacting with Galaxy? Are they complementary? Incompatible? The section of the Galaxy announcement ‘Tracking connected clients’ sounds similar in ways. It would be cool if they worked in tandem.
Always go for 