“MongoDB is as easy to operate at scale as it is to develop with.” From the very beginning of MongoDB, I’ve envisioned making that bold claim. Until today, it’s been a dream.

We just brought it firmly into the realm of the realistic. Today we rolled out a completely revamped MMS built atop Automation, our cloud service for deploying and running MongoDB. Automation works with any infrastructure, from AWS to private cloud to bare metal. It deploys brand new replica sets, adds new shards to clusters, adds replica set members, deploys version upgrades… all at the push of a button. Monitoring and Backups are maintained seamlessly via Automation as well. It also makes julienne fries.¹

You can read about the new MMS on the MongoDB blog, or visit mms.mongodb.com to check it out for yourself. What I would like to explain here is the road that led to this point, which began with our mission to create a database that enabled the greatest possible productivity and horizontal scale.

The Consequences of Horizontal Scale

There are many possible designs for horizontally scaling data stores. As with all development, every design choice incurs trade-offs. Sometimes developer productivity comes at a cost of operational complexity. Moreover, MongoDB’s chosen mechanism for horizontal scaling results in an infrastructure where maintenance tasks must be performed in a specific order. We understood the consequences to these choices, and envisioned a layer of tooling above the raw MongoDB processes that would offer an operator a robust yet simple mechanism for maintenance.

The trouble is, no tool existed which could serve as that layer.

Existing Provisioning Tools

General purpose provisioning tools are not designed to manage non-homogenous, distributed resources for which ordering of maintenance operations matters. Every resource is treated as a stand-alone system, so operations which require ordering of events require complex and error-prone custom code. One example of this is upgrading a sharded cluster. The process is to upgrade the mongos processes (possible in parallel), then the config servers (serially), and then all the replica sets (sets in parallel, nodes within sets serially). While it is technically possible to express this within the frameworks of today’s provisioning tools, it is far from easy, and the tools do not provide primitives to address the problem domain. An operator with these needs is essentially on their own.

We’ve said all along that the complexities of operating a MongoDB cluster could and would be handled with tooling, but unfortunately, several years after MongoDB became by far the most popular non-relational database, that tooling still did not exist… until today.

MMS is not meant to replace provisioning tools like Chef, or Puppet… in fact many people will deploy the MMS automation agent via these tools, after provisioning and configuring their VMs with those same tools. Rather, it is meant to take over where they leave off.

MongoDB ♥ Ops

This is a love letter to operators everywhere. Our new MMS is a huge step forward for running MongoDB infrastructures, making even the most tedious and risk-fraught tasks simple.

Our mission is to take things that are overly complicated and make them simple, even enjoyable. First we did it with data storage programming, and now we’ve done it with our own infrastructure. We hope you enjoy this new chapter of MongoDB. Now go forth and deploy!