MongoDB on Azure: VM or Worker role?

Question

I am interested in hosting a mongoDB on Azure. I believe I have a few options for exactly how I host the db on Azure: a virtual machine or a worker role. What are the pro and cons in each option? More specifically, how does each approach differ in maintenance, configuration, scalability, ease to work with from .net, and cost. Is it easy to switch to the other option later?

Some details on what I am creating (though I would love to hear general pro/cons of the options based on varying circumstances): The db will be accessed by an Azure website. This website will be an ASP.net MVC Web API site rest service. I don't expect traffic to the service, and thus the db, to be over 100 resource requests per minute, at least to start. The database will be relatively small, well under 10,000 records in the foreseeable future.

Answer 1

Well... MongoDB is easier to set up in Virtual Machines, as you can get things configured exactly how you want them, without dealing with startup scripts to set things up.

Since you'll have your website on Azure Web Sites, you can either expose the endpoint(s) publicly or create a virtual network between website and virtual machine (now supported).

If you're deploying a standalone server, the difference between Virtual Machine and worker role deployment won't matter that much. But... once you get into replica sets and shards, that's where you'll find Virtual Machines to be easier to work with. And if you want to run Linux instead of Windows, you'll have no choice but to go with Virtual Machines.

Regarding the ease of working with MongoDB from .net: That shouldn't matter at all.

Scaling-wise: It's not often you'll change your VM sizes or VM count. VM size changes should be the same experience for either setup. Scale-out to more VMs (e.g. expanding a replica set) is probably more manageable with Virtual Machines, as you'll be in total control of each node. This is probably more important when scaling in (removing a node), since worker role instance scale-in doesn't let you specify which instance to get rid of.

EDIT July 2015 - this answer is 2 years old. I cleaned up a few things. A quick update:

• VM sizes are significantly larger than previously mentioned (up to 448GB 32-core, plenty for MongoDB), along with SSD-attached storage for some of the VM sizes
• Aside from manual configuration, the new Azure Resource Manager can be used to automate cluster spin-up on Virtual Machines.

One final thought: While you're pondering the options, you might consider a hosted MongoDB solution such as MongoLab. You can set up a free (500MB) or paid database either through the Azure Store or directly through MongoLab's website. It only takes a minute to set up...