Meteor opens up a lot of opportunities for software development, and I’ve been especially interested in using it to deploy single instances of an app to end users as it’s easier to build and scale. I’ve been thinking of how Galaxy can empower this style of distribution, and I think a good way to go about it would be to build something like “Stripe for deployments”.
Here’s the first case where it could work: lets say somebody builds something like WordPress and wants to offer seamless set up to their customers. Ideally - they’d just ping Galaxy to set up an application, configure it to a certain domain, and pass the results back to the end user. This could be big for enterprise too.
The other opportunity is if somebody forks Meteor and repackages into another framework - lets say it drops the front-end, swaps support for Mongo in favor of SQL and becomes positioned as a back-end for iOS applications. The people who would be marketing this solution to the iOS community can easily set up deployment infrastructure while keeping the money pouring into MDG.
It can also lead to the creation of a market. For example, if John create the ultimate todo’s app for businesses, they could be sold through a consumer-facing Galaxy Store where a customer can subscribe for $X and have their own cluster.
Easier said then done - but perhaps it can lead to a conversation of the market’s hopes and dreams for Galaxy.
Good thoughts. What we really need is some form of Galaxy to try out soon.
May be we could give more feedback, rather building it for in-house for a long time and publish at once.
I’m also genuinely interested in this idea of a platform to distribute meteor applications, especially for business consumers. I’m currently working on that for LibreBoard (the project will be renamed). Currently @arunoda’s docker image seems to be the easiest way to bundle a meteor application in a generic package – but you still need to provide a mongodb database externally. There is also a lot of stuff related to image orchestration and containers updates that are still not super-easy to manage for a business consumer. Platforms like sandstorm or similar might also be viable alternatives.
The possibilities that could be unleashed here are almost scary One man start-ups have never seemed closer to reality
This idea hit me from this: I had an idea of building a co-working space application where you basically bill your members, let them book rooms, chat, etc. It would be dead simple to build with Meteor, and provide tremendous value to the space, but deployments/etc because less clean.
I figured if Galaxy gave me an easy way to do it- and say it gets 100 customers at $100/mo - it wouldn’t be the biggest waste of my time I’d build it an open source MVP, but right now I have other priorities. Overall though, this kind of thing could be insanely disruptive for SAAS products.
I think Sandstorm is pretty cool, and the team is awesome - but I never fully understood what they’re trying to do. It looks like they’re unbundling the app installer from a “CPanel” type application (if you recall from the PHP days)
PS: been thinking of this all morning, I’ll shift gears to your thread later today
That’s probably the highest priority item - and maybe that’s what v1 of Galaxy will be. Ultimately though, imagine meteor deploy taking care of everything from database & app servers to integration and scaling. The next generation of coder’s won’t even have to know what a server is
Lots of people get oplog tailing on modulus by hosting their mongo instance at Compose.io (and probably their are other places too). Even if you didn’t care about oplog, it appears to be much more stable.
Modulus is very limited though, so galaxy feels like something could open up a huge number of options why still requiring little ops effort to get going. Hard to say though, since we don’t yet know much about it.
@andylash Livequery is likely to be the first thing to bottleneck when scaling a well written app. From the link:
The main way that Livequery scaling differs from traditional database scaling is that increased database write load will result in increased CPU usage on all application servers with livequeries outstanding against that database. That's because Livequery, running on each application server, must read the replication log (or other stream of update messages) from the database, and even parsing an update message from the database takes a certain amount of CPU.
Currently, each server observes the oplog individually. If you have like 10k operations a second (that was a random number), it could eat up all the CPU power on your servers.
btw we started using Mongol here last week. great tool! we really love it, but can’t use it for some objects which hold a reference to their parent. Any place to put up a code bounty to get this fixed?
Even galaxy came, I don’t think it will have native MongoDB support. Even if it does, Compose willl be a better tool since it’s a managed service with support.
@arunoda What’s your take on people that want to host their database (and don’t want to use compose.io or any delegated solution)? How do you think they will host their application in the future? Do you think having a set of docker images (one per micro-service and one for the database) and orchestrating their deployment (and updates) will be democratized in the coming years? Or maybe the way to go is a more integrated system, inspired for instance by what you did by putting a load balancer and a DDP endpoint in the same “unit”?
If I was going to invest $11M into MDG and Galaxy will be their only product, I’d want something like msavin’s cradle-to-grave solution as a sufficiently differentiated service offering vs. DIY with Docker containers, Mongo providers, etc. “Don’t worry we’ll take care of everything and give you all the support and scale you need” including a strong SLA would be worth paying a significant premium for, and anything much less than that might not be worth paying anything for not only later this year but already right now.
Having everything “just work” with no more than meteor deploy including the data, transparent sharding on geography/user accounts, mobile to desktop with hot code refresh…that story would get the $11M. And explain the stealth.
It’s tricky because we all want MDG to be profitable so the platform grows, but none of us want excessive vendor lock-in where if they have problems delivering a high QoS we’re stuck with them. So they may open source enough of Galaxy on a specific license that lets us use it ourselves but not resell it as a commercial service or something.
But I think they have to do the data management to make significant money. It’s the greatest responsibility and thus the biggest profit opportunity. Those are the eggs and who’s holding the basket.
Yeah! hosting databases on their own is a good idea for few reasons.
not for a production app
if you know how to manage a Mongo deployment
Deploy with a tool like mongodb MMS and their support
Managing a DB is harder than an app. App is stateless and we can deploy as many as we need.
But DB is not. We need to create replicas and shard.
So, if someone thinks linking a DB container into their app solves his DB issue. That’s a myth.
I think no one knows a better way to use Docker with DBs. We’ve some questions?
Are we going to store data inside the container
Are we going to use a local volume
How do we manage data when containers are moving
How do we replicate?
If we replicate can we use container linking?
So, if Galaxy does Mongo hosting it needs to come up with a good set of tools to monitor it and may be with support.
May be MDG is doing something with PathomDB acquisition. (Or they can link up with MongoDB)
I think when we heard about Galaxy, Docker was not around the corner. (or at infant stage).
Docker storms into the deployment space like a storm with some other tools like CoreOS, Kubernates.
I think that’s the delay for Galaxy. (MDG may had change some plans)
One man start-ups have never seemed closer to reality