What’s New in MongoDB 3.6. Part 4 — Avoid Lock-In, Run Anywhere

Published in

MongoDB

6 min readDec 28, 2017

Welcome to part 4 of our MongoDB 3.6 blog series.

In part 1 we took a look at the new capabilities designed specifically to help developers build apps faster, including change streams, retryable writes, developer tools, and fully expressive array manipulation
In part 2, we dived into the world of DevOps and distributed systems management, exploring Ops Manager, schema governance, and compression
In part 3 we covered what’s new for developers, data scientists, and business analysts with the new SQL-based Connector for BI, richer in-database analytics and aggregations, and the new recommended driver for R
In our final part 4, we’ll look at all of the new goodness in our MongoDB Atlas fully managed database service available on AWS, Azure, and GCP, including Cross-region replication for globally distributed clusters, auto-scaling, and more.

If you want to get the detail now on everything the new release offers, download the Guide to What’s New in MongoDB 3.6.

Run Anywhere

Many organizations are turning to the cloud to accelerate the speed of application development, deployment, and data discovery. Replatforming to the cloud gives them the ability to enable self-service IT, to elastically scale resources on demand, and to align costs to actual consumption. But they are also concerned about exposing the business to deeper levels of lock-in — this time from the APIs and services of the cloud providers themselves.

Increasingly, users are demanding the freedom to run anywhere: private clouds in their own data center, in the public cloud, or in a hybrid model that combines the two. This flexibility is not available when they build on a cloud-proprietary database from a single vendor. Alternatively, the platform independence provided by MongoDB gives them the ability to respond to business or regulatory changes without incurring the complexity, risk, and time that comes from expensive database migrations whenever they need or want to transition to a new platform.

MongoDB Atlas

As a fully managed database service, MongoDB Atlas is the best way to run MongoDB in the public cloud. 2017 has already seen major evolutions in the Atlas service, with key highlights including:

Expansion beyond Amazon Web Services (AWS) to offer Atlas on Google Cloud Platform (GCP) and Microsoft Azure.
Achieving SOC2 Type 1 compliance.
The launch of managed database clusters on a shared architecture, including the free M0 instances, and the M2s and M5s, which allow customers to jumpstart their projects for a low and predictable price.
A live migration facility to move data from an existing MongoDB replica set into an Atlas cluster with minimal application impact.
The addition of the Data Explorer and Real Time Performance Panel, now coming to Ops Manager, as discussed above.

MongoDB 3.6 is available as a fully managed service on Atlas, along with important new features to support global applications, and with automated scalability and performance optimizations.

Turnkey Global Distribution of Clusters with Cross-Region Replication

MongoDB Atlas clusters can now span multiple regions offered by a cloud provider. This enables developers to build apps that maintain continuous availability in the event of geographic outages, and improve customer experience by locating data closer to users.

When creating a cluster or modifying its configuration, two options are now available:

Teams can now deploy a single MongoDB database across multiple regions supported by a cloud provider for improved availability guarantees. Reads and writes will default to a “preferred region” assuming that there are no active failure or failover conditions. The nearest read preference, discussed below, can be used to route queries to local replicas in a globally distributed cluster. Replica set members in additional regions will participate in the automated election and failover process if the primary member is affected by a local outage, and can become a primary in the unlikely event that the preferred region is offline.
Read-only replica set members can be deployed in multiple regions, allowing teams to optimize their deployments to achieve reduced read latency for a global audience. Read preference — providing a mechanism to control how MongoDB routes read operations across members of a replica set — can be configured using the drivers. For example, the nearest read preference routes queries to replicas with the lowest network latency from the client, thus providing session locality by minimizing the effects of geographic latency. As the name suggests, read-only replica set members will not participate in the automated election and failover process, and can never be become a primary.

Teams can activate both of the options outlined above in a single database to provide continuous availability and an optimal experience for their users.

Figure 1: Globally distributed MongoDB Atlas cluster, providing resilience to regional outages and lower latency experiences for global apps

Auto-Scaling Storage and Performance Optimization

MongoDB Atlas now supports automatic scaling for the storage associated with a cluster, making it easier for you to manage capacity. Enabled by default, auto-scaling for storage detects when your disks hit 90% utilization and provisions additional storage such that your cluster reaches a disk utilization of 70% on AWS & GCP, or a maximum of 70% utilization on Azure. This automated process occurs without impact to your database or application availability.

In addition to auto-storage scaling, the new Performance Advisor discussed earlier for Ops Manager is also available in MongoDB Atlas, providing you with always-on, data-driven insights into query behavior and index recommendations.

A Cloud Database Platform for Development & Testing

New enhancements to MongoDB Atlas make it the optimal cloud database for spinning up and running test and development environments efficiently.

You can now pause your MongoDB Atlas cluster, perfect for use cases where only intermittent access to your data is required, such as development during business hours or temporary testing. While your database instances are stopped, you are charged for provisioned storage and backup storage, but not for instance hours. You can restart your MongoDB Atlas cluster at any time on demand; your cluster configuration will be the same as when you stopped it and public DNS hostnames are retained so no modifications to your connection string are required. MongoDB Atlas clusters can be stopped for up to 7 days. If you do not start your cluster after 7 days, Atlas will automatically start your cluster. Pausing and restarting your MongoDB clusters can be triggered in the MongoDB Atlas UI or via the REST API.
Cross-project restores, introduced with Ops Manager 3.6, are also available in MongoDB Atlas, allowing users to restore to different MongoDB Atlas projects than the backup snapshot source.

Next Steps

That wraps up the final part of our what’s new blog series. I hope I’ve helped demonstrate how MongoDB 3.6 helps you move at the speed of your data. It enables new digital initiatives and modernized applications to be delivered to market faster, running reliably and securely at scale, and unlocking insights and intelligence ahead of your competitors.

Change streams, retryable writes, causal consistency, greater query and update expressivity, and Compass Community help developers move faster.
Ops Manager, schema validation, enhanced security, end to end compression, and user session management help operations teams scale faster.
The MongoDB aggregation pipeline, Connector for BI, and the recommended R driver help analysts and data scientists unlock insights faster.

And you have the freedom to run MongoDB anywhere — on-premises, public cloud, and as a service with MongoDB Atlas available on AWS, Azure, and GCP.