Hosting software remains a pain-point, though. It's never quite as easy as people want it to be. Perhaps that’s because developers now have so many options for establishing basic server tasks — and the foundation of our applications can change fairly quickly. A software framework typically has pretty specific ways of getting things done, and that legacy may span years or decades. On the server side, often you’ll see many different ways of doing the same thing. Most custom server approaches tend to be somewhat different from one another — , depending on the individual experience of the team or individual building it.
Successful Drupal hosting platforms Acquia and Pantheon may serve to highlight this point. Each features a starkly different backend implementation (Pantheon uses Docker; Acquia uses typical VMs) and user interface driving the backend. Each platform leverages completely different philosophies on how things should be done. As a user, it makes you wish you could elect to use the best aspects – and forego the weaker characteristics – of each. That said, the Project Ricochet team recommends both services and use them heavily to deploy Drupal sites.
For many developers, the new dedicated framework hosting options can indeed make projects easier. But if your app has exceptions, services are cost-prohibitive, or there are unique security concerns, tasks can quickly regress from easy to complicated.
When it comes to Meteor, you’ve actually got a lot of options. First, there’s Modulus and Galaxy (which is Meteor’s all-in-one solution for production deployment). You could also opt to “roll your own” (write the core code yourself). Yet still, with dedicated platforms there are three potential problems:
- If you’re a development shop or a company with several apps, pricing can vary from unattractive to quite challenging. Providers seem to want to charge per container — and when you’ve got 10-20 apps in development (or more), you’re rarely leveraging the resources behind the ones you’ve committed to. So, paying for this larger digital footprint seems like a waste of budget dollars.
- If your client is a bank, health care provider, or other large company with highly sensitive data, then a cloud service like Amazon or Rackspace, may just be out of the question. Situations like these often force developers to use a solution that allows you to use your own infrastructure.
- Many of the plug-and-play services don’t provide a database layer. So you’re forced to add another SaaS service on top of the hosting provider.
When none of the prepackaged solutions seem appropriate — you may just need to “roll your own.” Writing your own code from the ground up may seem a bit scary — and frankly it should be if you can’t justify why you’re making that choice. But new tools like Docker and DCHQ do enable you to launch complex architecture on an easy-to-use platform. DHCQ makes deploying containers easier, in part, because it helps you simplify the complex network mapping between hosts on your cluster.
Discover how to “containerize” Meteor apps on Docker and DCHQ
- Use a hosted version like compose.io
- Run dedicated Mongo servers and setup a cluster of VMs each running Mongo
- Spin up a cluster on Mongo containers on DCHQ.io
If you’re more familiar with Docker, you might consider learning how to launch a Mongo cluster across Docker, since this can offer a fair amount of flexibility going forward. DCHQ provides a Mongo Replica Set Cluster that supports service discovery for typical scale in/out scenarios while rebalancing the replica set. An official blog will be available very soon. Here's the template:
A closer look at the details
How to build your Meteor Application Docker image for deployment
How to load balance your Meteor app
Essentially you’ll define the Load Balancer instance and also run a plugin that keeps the nginx config up-to-date with recent nodes jumping in or out.
Here’s the example Meteor app definition:
If, like most developers, you’re new to Docker, you could also perhaps focus on scaling your Meteor app node processes and use something like compose.io in the meantime. Using Docker on something that has persistent storage typically requires a bit more planning.