@raragao Does running a Docker container improve performance over running directly on a server / VPS?
What do you mean by “better” hardware? From what I’ve seen, the pricing between Lightsail/Linode/DO/UpCloud/etc. is fairly similar for the same spec of hardware (memory, cpu, storage, transfer)? Is there something I’m missing?
Docker doesn’t improve performance, but allow you scaling vertical and horizontally your system when you need. With VPS or a VM, you can’t or you need a lot of work to do (and slow work). This is very simple when you use a Swarm, per example.
When I told better hardware I mean about quality and performance of hardware, not sizing. I want to tell that performance of hardware of UpCloud is better than others cloud with same size. I did this comparation with same sizing (RAM, CPU and I/O).
I can test it and compare with others (DO, Heroku, AWS, etc).
@wildhart. Hmm, I must’ve got confused somewhere. I will look into using MUP for my deployments.
I have not tried graphLookup aggregation, but I will try to use that instead. I currently use Grapher React for pub/sub and createQuery so I will try to implement aggregation in there - thanks for the suggestion!
@raragao Hmm okay, so theoretically, I could spin up a docker container/node for each tenant/client?
Each container/node could run either an instance of the Meteor application or an instance of the Meteor application & DB?
And I could then use the swarm manager(s) to distribute traffic to the appropriate node for each tenant?
Or, use each node for all traffic and spin up extra nodes when necessary?
I guess it may be true that with a VM / VPS scaling up / out can be difficult or even impossible; but if that’s the case, the reason is always incompetence, or, to put it in a nicer way, lack of expertise.
To make it perfectly clear: If you have the required knowledge, scaling up or scaling out a Meteor app in a VM / VPS environment should not be difficult at all.
A final word about VPS: don’t go there, it’s a bad choice. In case of a VPS you’re getting just nominal resources in terms of number and power of CPUs, amount of RAM and network throughput / latency, because that’s how a VPS works: you’re on a hardware shared with other clients, and you have zero guarantee over what those other folks do and how many they are. It is of course perfectly ok if your app has zero or just marginal importance, maybe because it’s just for a quick demo or a proof of concept or similar. It is a bad idea to use a VPS with a real-life app, especially if it’s commercially relevant.
A VM is like a VPS, except that all resources are dedicated to you, nothing is shared with any other client. AWS EC2 instances are for example real VMs, as are those that one can commission for themselves on a rented physical root server.
Yes, you can use a container for each tenant/client, or more than one container (scaled horizontally) when you need more throughput.
Container by concept should to run one unique service. To databases, create other container.
Yes, swarm can distribute traffic to specific container, but to web app or service, my advice is use some container with a reverse proxy (Apache, Nginx, Traefik).
Really, you have many options. You need to know if you have need to do every manually or use some IaaS or PaaS to host your apps. I already use Galaxy, Scalingo and Nodechef. For now I create my own cluster in UpCloud IaaS.
Let me just chip in by saying that for me, mup has served me really well. zodern has been doing a great job on it. Yes, using alternatives to Galaxy might eat into Tiny’s revenue a bit. No arguing there. But having an easy way to deploy projects on any cloud provider in any region provides some important peace of mind that is also a non-insignificant factor in driving adoption for a framework like Meteor. So I would not see these deployment options as competitors per se.
If you use mup (or monti for that matter) and feel the same, then do consider making a small monthly contribution to him using Github’s sponsoring feature here like I and some other have.
@peterfkruger Would you also suggest using a managed database service like Atlas? Or would a dedicated VM for DB be okay to start?
I understand the benefits of a managed database, but I am trying to as cost effective as possible early on.
I don’t use Atlas; in fact, I don’t use any managed service at all (except Google Cloud services where unavoidable). While I do recognize that many of the managed services are undoubtedly great and come with huge benefits, I have a few reasons to host and manage all services for myself:
Deployment is a big time headache for meteor apps.
The most valuable comment of the year
I have one more reason to host Meteor on my own server: I don’t trust startups when it comes to managed services. MDG was practically gone overnight, Tiny took over, including Galaxy. It was not written in the stars that it had to happen this way. Maybe the venture capital firm pulled the plug, and they – or shall I say we — were lucky enough to find another startup to jump in.
At best, one in ten startups prevail, nine die. Do I want to host my app with a company whose fate is so uncertain?
What if I host my commercially relevant app with them, and then when I wake up on a Tuesday morning, my systems are unavailable, and Galaxy is down for good? To make things worse, in this scenario, I wouldn’t have acquired the required skills to deploy my app somewhere else in due time; I would just start to look around in panic for alternatives.
Exactly the same reason I’m here looking for solutions of deployment. I stopped using Blaze because I didn’t know its future.
Who hosted google, amazon anyway.
Galaxy has been up and running because it is a revenue generating product, regardless of who owns it. And it is money generating product because it adds value and not everyone here agrees with what you said.
You got to support the people who create products you use one way or another.
It was me in the first place in one of my previous comments who drew the attention to the fact that for Tiny to survive people need to host with Galaxy, and that using hosting alternatives jeopardizes Tiny, and, by extension, Meteor as a product.
Secondly, it is not enough for a service like Galaxy to be sustainable to add value and to generate revenue. Enough revenue needs to be generated not just to offset the costs, but also to allow the investor to make a profit. My point was that Galaxy’s price model is not good: the price is too high. I don’t know if I’m right, I have only expressed an opinion.
Sorry I missed that part.
It is generating enough and growing appeartantly, it was funding Meteor and Apollo development for the last few years. From the Meteor’s impact conference, this month has been the best month for Galaxy since its inception, for the price, I agree, but they are bringing the free tier back, so 9$ for production does make sense given the extra value Galaxy provides for meteor apps, you really don’t need DevOps at all with Galaxy.
But I can’t speak officially for Galaxy since I’m just another community member, I’ve only expressed an opinion as well 
To make it perfectly clear, I never said that Galaxy was a bad or faulty product. I did argue for using it, and I do recognize its value. I don’t use it, and it’s not just, or primarily, because of its high price, as I explained in another comment. MDG’s sudden disappearance reminded me once more how fragile startups are.
Indeed, startups are fragile, especially in Open Source but startups are the reason we’ve Meteor in the first place. I’m personally grateful that Meteor still thriving after a decade given how fragile the JS ecosystem is in general.
I am thankful for Meteor to all engineers, visionaries and investors who created it, and also to all who maintain it. It’s a great product! I never said otherwise.
I guess you is right, but I think that VM use a lot of resources when you need create many VMs to host same app. Containers to this case are better using less resources. But ever you will have pains. As VMs have good and bad things, containers have too.
For me, container have a great advantage, mobility. If I need change of server/VM, is very simple and quick.
A real case: in a customer project, they don’t use containers, only VMs (VMWare). They have 3 big servers (bare metal) with VMWare installed managing VMs. When they some problem or any need to shutdown the servers, they need move VMs to others servers. This is simples, but depends on size of VM, they can stay by hours to move VMs. Now we started with Docker Swarm, then the Swarm when lost a host Node, move all containers to others server, completely transparent to admin and with downtime almost 0. Obvious that you need to prepare all environment to this, but I think this is better than VMs.