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)
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.
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.
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…