Choosing The Right Cloud Provider For Your MongoDB Database

Filed in Cloud Industry Insights by J.R. Arredondo | December 5, 2013 12:01 pm

In yesterday’s post I considered some of the limitations of running MongoDB on the public cloud[1]. In the event that you decide to host MongoDB with a cloud provider, below are some thoughts on how to choose the right one. The framework is actually applicable to many other data services, but we will continue to use MongoDB for the discussion.

The choice of a cloud provider affects how you will be able to apply your development and operation resources for a given application. In a world of limited resources, any effort applied to the management of the database engine is not necessarily being applied to the development of your application.

Let’s discuss four progressively sophisticated levels:

  1. Do-it-yourself database
  2. Provisioned database
  3. Automated database
  4. Managed database service

In the graphic below we see those four levels. I also show a number of database related tasks (from architecture, to management and administration). In the top half of the chart (in green), we see activities that are managed by the MongoDB service provider FOR the developer, while in the bottom half of the chart (in red) we see the activities that have to be performed BY the developer. As we move to the right in the chart, we see that the MongoDB service is providing more capabilities to you as a development team. Clearly, the less “database management time” that you have to invest in, the more “application development time” that is available towards your business goal.

Let’s now discuss each level.

Level 1 (Do-it-yourself database)

At this level, you are able to procure a generic hosted server from the MongoDB cloud provider. You are free to select the specifications of the hardware, but you are also burdened by that decision. The architecture can be difficult to scale later on. Additionally, you must install and configure MongoDB, and are also required to implement backups, compacting, sharding, monitoring and all other maintenance activities to keep MongoDB running. Achieving availability and performance on the cloud is also something that you must develop from scratch. All of these activities take resources away from developing the actual application. This level may be well suited for your development or testing needs because of its initial low cost.

Level 2 (Provisioned database)

This level is better than Level 1. The cloud provider makes available to you some standard choices for hardware and automatically installs MongoDB, typically on another IaaS hosting provider. The level of sophistication is not great, but this level may be initially attractive because of the speed of provisioning, but obviously you realize the consequences that that choice has for production workloads. You must live with the hardware choices and their effect on the performance and scale of MongoDB. Maintenance and administration may still fall back on you, along with other complex responsibilities such as clustering and cluster management, which have a big impact on availability, scale and performance. Some MongoDB hosting startups fall within this level.

Level 3 (Automated database)

This level represents a significant improvement. Here, the MongoDB provider delivers a set of automation features, on top of provisioning and configuration choices. Backups are scheduled, monitoring runs automatically and other maintenance activities such as version upgrades are performed. While the level of automation may vary, you start to feel that you can outsource many management tasks to the automation suite. In a perfect world, this would be sufficient. But in reality, you are still in charge of “dealing with the database,” particularly as the application grows and the initial architecture starts showing signs of stress under the new level of load, affecting the performance and scalability of the application.

Level 4 (Managed database service)

Cloud vendors who deliver Level 4 capabilities offer a key important benefit over Level 3: you no longer deal with the database engine from a management perspective, and instead see the database engine as a service that just works. You connect to a hostname and port, consume a data service that requires virtually no maintenance and ideally never need to consider what’s sitting behind it (other than to build the application itself). What drives that service is an architecture that is fundamentally different than that available in previous levels, one that places scale, performance and availability at the core of the engineering choices. In the case of MongoDB, the architecture should deal with sharding transparently, for example, for vertical and horizontal scaling. It should also place particular emphasis on performance across the stack, from the network, to the storage choices and MongoDB configuration. Finally, it should take care of the complexities of achieving uptime by, for example, automatically allocating instances across hardware in a way to ensure redundancy and avoid single points of failure. Vendors at this level may also offer an enhanced level of analytics and tooling that helps you optimize your application in a proactive way. As examples, profiling and I/O and query analytics can help tune your application, or background tasks such as shard balancing or defragmentation are done not just automatically but also scheduled at appropriate times to reduce impact to production. Clearly, there are always some tasks that cannot be automated, but these should be application-specific, such as migrations or integrations with other systems.

THE ROLE OF OPERATIONAL EXPERTISE

A MongoDB cloud provider should deliver technical expertise to help you architect the best application possible. This kind of operational expertise should help your developer and application experts and bring them into a collaborative partnership across all phases of development—from data migration to production and code refreshes.

FINAL THOUGHTS

Obviously, non-technical issues are also important considerations when choosing a provider. Pricing and financial terms, the technical and operational reputation of the provider, compliance and regulatory restrictions as well as SLAs should not be overlooked.

As with any other platform choice, the decision of a MongoDB provider should not be taken lightly, particularly when a company’s main application depends squarely on MongoDB for its data tier. Development teams need a vendor with the flexibility to offer solutions to fit the different app needs and stages of the development lifecycle. Discuss your data design strategy early and often with the MongoDB experts of your cloud vendor. The strength of that expertise—not just the quality of the infrastructure—will be a key factor in any evaluation of a cloud provider, as your application will surely evolve and grow over time, and require that level of technical partnership for your application.

At Rackspace, our Data Service for MongoDB, ObjectRocket[2], was built as a Level 4 MongoDB managed service from the ground up: a unique architecture to make MongoDB perform fast, with high availability and scale. Let us know how we can help make your next MongoDB app deployment a success.

Endnotes:
  1. limitations of running MongoDB on the public cloud: http://www.rackspace.com/blog/3-limitations-of-diy-mongodb-on-the-public-cloud/
  2. ObjectRocket: http://objectrocket.com/

Source URL: http://www.rackspace.com/blog/choosing-the-right-cloud-provider-for-your-mongodb-database/