Are you sure it’s fair to compare Galaxy’s Developer Plan to Heroku and Modulus?
MDG tells me "We do not recommend using Developer Edition for production apps for a number of reasons, including:
Smaller container sizes: Developer Edition is limited to using 512MB containers (up to 5 initially). Current production editions of Galaxy use 1GB containers and may support other container sizes in the future.
Less stability: Developer Edition containers run on spot instances vs. the stable instances that power the production-class Galaxy containers. Spot instances may force random restarts of your app as the underlying cloud computing resources aren’t always available.
No critical support: Developer Edition only offers non-critical support with 1 business day response times.
Limited performance metrics and logging: Developer Edition performance metrics and logging is very limited compared to the 30-day analytics available in the production editions of Galaxy."
Does Galaxy include a database?
Galaxy does not provide the database layer. You can run your own MongoDB server inside AWS, or create a database through any number of MongoDB hosting providers.
I don’t really see the need for them to become monogodb hosting specialists. There are already a number of companies (Compose, Mongolab) with sophisticated mongodb hosting capabilities. What’s the real value in hosting your database with MDG? Modulus does have mongodb hosting but it’s very limited compared to the metrics and features provided elsewhere. in fact, “The Modulus shared MongoDB databases do not currently provide access to the oplog.”
For me, expecting MDG to be a mongodb host is like expecting them to also get into the cloud storage and CDN business. Apps often need to store files sometimes, so should a persistent bucket be included “in the box”, or should developers just use any of the existing storage providers, such as Amazon S3?
I was always convinced the MDG was selling the ideal of outsourcing DevOps 100% (at least, before Galaxy came out). It’s not just the application layer that scales. You need to know how to make your database fault-tolerant. That means configuring MongoDB with sharding and replica sets. Now it’s on you to do that due diligence and find a provider that can gives you a HA database. I’m not sure about S3 – a safe assumption most production applications need a way to store and serve files, yes? – now that’s another monthly bill for your technical infrastructure. While I agree that these aren’t huge gaping holes, and that MDG’s services currently stand to offer a lot of value-- since load balancing sticky sessions with websockets across multiple application instances is tricky. But Galaxy would certainly be an even more attractive offering if it were an end-to-end solution. I bet there is a market of people out there with great app ideas who care not at all about DevOps, but want millions of users. They just want to build apps with top notch UX that work great on cross-platform. Getting to market is more important than anything, so paying a premium for DevOps is well worth the cost for those individuals.
All good but it’s still a matter of integration. If their goal is to be the most pervasive, approachable and flexible JS platform, they need pretty seamless integration with the most pervasive solutions for what they don’t intend to offer. Guides and conventions outlining (best) practices are fine to begin with, but people (will) expect wide, deep integration through plug-and-play solutions from a platform, I think. A centralized place for managing pretty much anything to do with (stat-/dynamic) content, whether it’s storage, packaging, distribution, etc, no matter where or what it is, etc.
I suppose you might want to deploy to a server to allow other shareholders (prospective customers, other team members like designers, marketing and customer support) to test and give feedback. You might also deploy in order to stress test with third-party online tools (Blitz, Loadimpact). Or you could just be a maverick and soft launch on the cheap to determine market fit before upgrading to proper hosting.
I wouldn’t recommend Modulus.io for production either. They had a poor record for keep things up and available when I was using.
I’m not sure the argument for a soft launch on the cheap holds up because you could also do a soft launch on AWS’s free tier. Though that does require a little more work, so I guess that’s where the cheap could come in at.
I would hope that this initial release of GDE is just a trial run and that there will soon be multiple tiers between this and Galaxy’s current offerings.
I also hope that MDG makes Galaxy’s packages more flexible. A package without support would be cheaper than with it. Packages with less RAM / size than current offerings. Or just make all tiers (not just GDE) usage based.
Wow I didn’t read about that. Interesting. I wonder if the Developer Edition is as unstable as the free Galaxy? I’ve had several calls about our ‘demo site’ being down when it was being used.
I guess the best way to start out is to use Mup + DO until you can scale up to afford $500 a month in hosting (using one instance at $500 is a bit steep )
Can someone from MDG explain the spot instance a bit more? How often do these restarts happen and would it be the entire cluster or just one instance? (say if you’re running 3 instances).
for $13 a month with a Galaxy Developer Plan, who has time to monkey around creating a new fake account on AWS for each application to take advantage of a limited free tier – “if you stop and start an Amazon EC2 instance three times in a single hour, you use up three hours of your monthly allotment.”
Bigger question is probably: why are so many Meteor developers absolutely adverse to spending any money to bring a product to market? You gotta break eggs to make an omelet. With all the constant discuss on these forums about low-cost hosting, I really wonder why more developers here don’t have enough confidence in their business ideas to put a little money into making them happen!
All the hours you spend learning deployment/devOps so you can host your own low-cost server for pennies per day is hours you could have used to develop your business ideas, figure out your market fit, and gain traction.
Oh I wasn’t talking about the price, just the stability. It seems like it’s worthless if it’s labeled to be unstable from the beginning. I just meant that DO might be the most stable solution for starting out.
The price is amazing! 10 years ago you had to lease a server which was really a big deal to get started and get a product into the market
I’m guessing Developer will be stable enough for a startup to run their app reliably enough to gain some customers and test market fit and hopefully gain enough revenue to afford Galaxy Enterprise.
We ran a production app on the free tier for over a year, and the uptime was great. We used a pinger to keep-alive the server. Here’s a downtime report for 12 months on the free tier!
The instance will be cut off when the Spot price increases and exceeds the customer’s bid. As long as the customer doesn’t cancel his bid, the instance will be reactivated when the price falls again. Instances may also be terminated when the customer’s bid price equals the market price. This can happen when demand for capacity rises or when supply fluctuates.
I hope they’re overbidding enough! It seems like Modulus might be more reliable for this entry point. I wouldn’t even mind paying $25-35 an instance if it was reliable.
Demand for Spot instances can vary significantly from moment to moment, and the availability of Spot instances can also vary significantly depending on how many unused EC2 instances are available. In addition, no matter how high you bid, it is still possible that your Spot instance will be interrupted. Therefore, you must ensure that your application is prepared for a Spot instance interruption. We strongly recommend that you do not use Spot instances for applications that can’t be interrupted.
)
