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.
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.
@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 ?
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
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)
What about elasticSearch ? Same thing i guess.
Mh, I feel like I will have trouble putting my app into production.
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.
If you don’t want to rely on a $13/month container and MDG support just build your own infrastructure. Problem solved.
That’s the most relevant question. If you have only one container does it’s replacement get started before it goes down? MDG controls the routing layer so they should be able to re-route the websocket connection to the new container, in which case I think the client just re-subscribes to all the publications without any visible reloading.
I can’t see why this should be a problem as long as the new container is available before the old one goes down.
in which case I think the client just re-subscribes to all the publications without any visible reloading.
I believe a resubscription would cause visible reloading, at least in terms of the old subscription getting teared down (no data) and new one getting established (new data loading)
And that may be undesirable depending on the use case.
I don’t think that’s the case - the old data intentionally sticks around until the new subscription is ready.
Hm, that’s an interesting surprize. I don’t know if it is a good or a bad one, though.
The underlying publication changing without the subcribing client noticing that change can be a good thing, but may also hurt if the new publication is actually a new version.
I don’t know, haven’t given this enough thought, but I think it deserves some exploration.
Yeah it’s the default that we thought made the most sense to avoid exactly the situation you’re talking about.
I don’t think this is possible because the client would reload in the case of new server code, right?
the client would reload in the case of new server code, right?
Even though there is no change to the client code?
can we pay with bitcoin or some crypto-currency here in nepal Credit card doesn’t support online payment gateway
In that case your new publications must not have changed much since the old client code will work with them, so there is also no problem. If you want to talk most in depth we can start a new thread?
your new publications must not have changed much since the old client code will work with them
this is a huge understatement 
But thank you for taking the time, a new thread is not necessary, I was just thinking of ways this could be exploited for the better or worse. Nice to know how it is designed to work.
can we pay with bitcoin or some crypto-currency
I would not actually trust my sensitive business data to an “enterprise” service who accepts bitcoins as payment form.
Paypal would be nice, though.
I’ve had credit cards and banks giving me headaches with online international payments. The banks are almost exclusively and deliberately unhelpful about explaining why they decline payment with their card, let alone mitigating issue. They also seem to have this rather random and chaotic blacklists…
yeah but the problem for us here will be i cannot purchase from credit card lol and it sucks …