Galaxy Developer Edition pricing is just absurd!

deployment Galaxy
85

Ruben - I think that’s one of the sources of confusion. I stated that Galaxy (the service overall) is production-ready, not that the Developer Edition is the best option for production-class apps (especially compared to the Team/Business/Enterprise editions of Galaxy, which was the point of the emails I’ve sent to our current commercial customers like Max).

Should Meteor developers run meaningful apps on Galaxy Developer Edition? Yes. Will many of these apps be considered “production” apps? Perhaps, depending on your definition and expectations. But if you have truly mission-critical app requirements yet no budget for something like Team Edition, it seems like a decision and tradeoff you’re going to need to make, no different than any other part of your business.

We’ve priced the Developer Edition to allow almost anyone to at least try it to see if it works for your needs/budgets; no amount of marketing or walls of text on this forum can convince you better that than actual experience with the product itself. And we will learn from ongoing customer usage and feedback much like we’ve learned from our earliest Galaxy customers. As I’ve stated before, it’s our goal to win your business. There are a number of other popular hosting solutions in the market. For MDG to be successful long-term, we’ll need to deliver competitive solutions at fair prices that deliver an awesome experience for as many developers and customers as possible.

5 Likes
86

I think I understand what you are saying. It’s not that $500 is not in the budget, it’s just that there are far cheaper options than 500 that are production ready for a project of my size. But those options advertise their uptime/dependability/etc. I understand that that is probably hard to do on a brand new product. I’ll give it a shot when I get the invite!

1 Like
87

Hello Mark, if the Developer Edition is only spot instances rather than a scale up from an on-demand and if those spot instances aren’t diversified as Amazon outlines then it is entirely possible that your container(s) get shutdown.

I believe that if there is any chance at all to show off an app to the world, there should be no inherit possibility that your app will not be available when requested no matter what the price point is.

A car for non-professional non-critical purposes should still reliably take you from point A to B without needing a restart on the way. It should work, for sure, always.

Amazon tends to market spot instances and spot fleets as part of an auto-scaling solution. If you guys had a similar thing at a price point in-between Developer and Team, that could prove to be quite a cost effective solution for most who are perhaps in-between something with thousands of non-stop concurrent users and just a few here and there.

As for censorship, unless someone is being belligerent and/or violating forums rules (i.e., community destructive forms of forums advertising) it seems unnecessary.

8 Likes
88

What a trainwreck…

89

Let me address the technical points.

Developer containers are totally fine for production workloads. They use the same container orchestration technology and the same custom scheduler and proxy software as all our containers. They run on the same class of AWS machines. They have all the same Meteor-specific devops baked in. We monitor all of that infrastructure 24/7/365 and respond immediately to any issue. You can scale your app on developer by using multiple containers, and if you do use multiple containers you also get the same coordinated zero-downtime updates that Galaxy pro plans have always had.

(This is different from the free meteor deploy servers, which aren’t designed to the same standards, aren’t monitored the same way, and don’t allow more than one process per app. We do not recommend the free deploy servers for production use.)

There’s this particular question about these “spot containers”. I didn’t explain this clearly enough in the blog post. So I’ll take the what point for that. I’ll post more on spot down the line as we roll Galaxy out.

Briefly, the idea is that Galaxy may occasionally reschedule developer containers as a cost-optimization measure. These techniques are what let us offer the low $0.035/GB/hour price, metered down to the second. For example, under certain conditions Galaxy may move developer containers to spot instances for a length of time. Or it may rebalance developer containers to machines with extra capacity depending on Galaxy’s overall system load. In all these cases, Galaxy always schedules your requested number of containers, automatically and without your intervention.

Babak had it about right here:

Our professional plans (Team, Business, Enterprise) have a different container policy which optimizes for the uptime of each individual container (instead of price) and minimizes the frequency of container restarts. The Business and Enterprise tiers go even further and guarantee that app containers and client proxies will be diversely scheduled across multiple availability zones to survive even the failure of a whole AZ. And of course these pro plans come with our advanced container performance metrics and commitment to a critical incident response time.

So as far as “production-ready”, it really depends on what you need. If you’re focused on the capability of the underlying bare metal containers and want to minimize your bill, the developer plan is great. If you have a business-critical app, I’d recommend the pro plans.

30 Likes
90

Thanks Matt, this clears up all the questions I had about how those really worked. It seems like a great tier to get started on. :thumbsup:

Also a side note, Modulus actually shuts down your app for a few seconds when deploying… this alone will cause your outage metrics to be thrown away. I’m willing to bet that Galaxy developer instances will have less downtime per year.

2 Likes
91

What an epic flip-flop! A few days ago you guys were saying “we don’t recommend Developer Edition for production applications”, your own blog posts says it’s for “personal apps” which don’t need scale, high-availability. and critical support. Now you tell us it’s not only ready for production apps, but it’s the same, same, same and you’ll respond immediately to any issue.

1 Like
92

MDG aren’t the government; it’s moderation, not censorship :wink:

94

I also think that what is written in private email ( if there is non-disclosure specified or agreed in advance ) is sacred and should not be publicly copy-pasted around the internet.
If you do it to me, I would remove it too. And if you keep adding it than there will be ban on my services. No refunds.
Simple as that.

95

I’m sure the developer edition is fine. It sounds like they are just saying “this is our lowest plan and we don’t expect a company who just raised a $10M series B to have their app hosted on this tier”.

I think the issue is with the “mission critical” word. From what I can tell, this is just a dev buzzword with ambiguous meaning. Whether you’re a small company working out of the garage or the company who just raised $10M, it’s likely you would consider your app “critical to your mission”. Of course one of these companies could probably swing being on the $13 a month tier, while the other it might not make sense for.

Also, everyone seems to be ignoring the fact the MDG said they’d be adding more options in the coming weeks/months. So it sounds like this huge gap between $13 and $650 dollars will be getting filled in shortly… so I’m confused why everyone is up in arms over a situation that will be different in a month.

7 Likes
96

Because internet comments.

3 Likes
97

Well to be fair, until Matt’s post a few hours ago, the official story was that Developer Edition was for “personal apps” and testing. Not for production apps. So I think people went from feel very happy about the price, to feeling very disappointed that it appeared to be only a sandbox. So it makes sense to me.

I too look forward to hear the new pricing next month!

1 Like
98

Yeah I agree with you.

I find the dev community uses a lot of ambiguous words… “mission critical apps” “production apps”. Again, the startup working out of their garage probably considers their app “mission critical” and a “production app” but chances are they can get away with hosting on the developer edition. MDG (and devs in general) should probably get away from these buzzwords or at least expand further when using them.

6 Likes
99

yes until Matt’s reply it was difficult for people like @rubenpa to make a decision

3 Likes
100

Hey Max, I empathize and can appreciate your situation.

I provided a car analogy above. Some people drive sport model Audis and some people drive Hondas. Some people need F350s. They all work.

If someone had F350 but that could manage with a little hatchback, making multiple trips, I’d wonder how often they carried that load and if the fees collected from their respective customers could cover that.

Maybe contact MDG with clarity in what you want and see if they can make a one time exception given the situation at hand. To be fair, paying upfront for a lower cost means someone is clear about what they want. In return for the lower cost the business gets to secure a known income. Perhaps you can retroactively pay $650 per month, the month-to-month rate, then apply the balance as credit to a different solution that you’ll be happy with.

A few years ago we clipped an ad from a hosting company that offered unlimited storage, unlimited domains, and unlimited bandwidth for $1 per month. We used to joke with the guys at our ISP/data-center that they should outsource all their workload to that hosting company to save major cash.

As for the pricing difference, I’d suggest the read on the different kinds of spot-fleet distributions and the informative video with @debergalis. MDG is clear about their underlying AWS technology. 10 * $13 containers = 130 per month. A total of 5gb not 10gb. Look over the pricing difference between stable spot-fleets and cost savings fleets as well as the difference in available memory at AWS. You may find that MDG has priced the TEAM product competitively for someone who needs it.

1 Like
101

@debergalis, please help me understand, as half of the technical words you are using are unknown for me.
Does this mean that with developer edition, an online client could see the app sometimes “reload” (like a hot code push ?). Or that for time to time, the site could be unreachable ?

102

I feel like people keep talking about 1 container temporary unavailability as if it was application downtime, instead of just comparing it to longer node crash.

But it would be nice to know that if I would have that 5 containers app there, what is the worst case scenario - 2 down, 1 down, all down ? I believe even with live re-balancing there should be some rule how to distribute containers - like every 1 of them in separate logical group and never migrating 2 logical groups at same time.
Something like HDD shelf distribution in storage arrays that data are spread over different shelves and in the case of 1 shelf power failure some copies would be still available

103

maybe the best solution is to just run your app on >1 instance, monitor the downtime with pingdom-like tools and see if it’s acceptable. But you’ll have to wait until Developer Edition exists (or you could get started with Bluemix right now)

1 Like
104

What about elasticSearch ? Same thing i guess.
Mh, I feel like I will have trouble putting my app into production.

105

Same. It’s actually easier this way. You just copy/paste the URI that compose gives you into your enviroment variable: MONGO_URL and you’re done. Elastic search would be similar depending on how you’re consuming it.

By letting a company who specializes in databases manage your database, you get better service, reliability, and better tooling (web GUI for example).

It also makes it easier to move your app to different hosts. Switching from Heroku to Modulus to Galaxy is simple when using a separate DB host.

4 Likes