As ZDNet’s Natalie Gagliordi reports this morning, MongoDB is announcing general availability of a new multi-cloud clusters extension of its successful Atlas database as a service offering. As Natalie reviews the details, we’ll just summarize that the new capability capitalizes the simplicity that DBaaS is supposed to be: it buries all the complexities of multi-cloud deployment under the hood.
That encompasses the complexities of federated user identities across different clouds, and any changes in external applications are just that: extrinsic to the database. So, if your operational instance of MongoDB runs in AWS but you want to take advantage of the AI capabilities in Google Cloud AI Platform, you can alter the configuration to have operational nodes in the original cloud and read-only secondaries running analytics elsewhere. Atlas takes care of data replication under the hood.
As we noted in a previous post, there are valid use cases for running one database over multiple clouds, but they are far and few: If there is a regulatory reason for ensuring that your workloads won’t be vulnerable to failure from a single cloud provider (such as, as MongoDB stated, Australian banks), or if cloud providers do not have adequate (or any presence) in your country or sovereign zone. We believe that the latter case is definitely valid today, but one that will resolve as cloud providers expand their global footprints over time.
MongoDB rightly points out another use case: when a company conducts M&A and wants to rationalize cloud deployments – however this more relevant for database migration rather than multi-cloud operation. The good news is that the configuration settings for multi-cloud Atlas could enable this.
Cut to the chase: we’re wondering if MongoDB is communicating too aspirational a message.
In our post, we cited the difficulties of running a single database across different cloud providers. It starts with cost: most cloud providers impose charges for data egress from their clouds. It also involves with performance: there are network latencies that must be factored in, especially that most cloud providers do not have special high-speed links between rivals – and why would they? This is a case where the Microsoft Azure-Oracle Public Cloud dedicated link is clearly the exception to the rule. Yes, you can mitigate that if it’s a region that has all three major cloud providers within the same metro area, such as the case in Northern Virginia. MongoDB responded to us that you can prioritize consistency or performance – that’s also common tradeoff with NoSQL database with multiple clusters in the same provider’s cloud.
By the way, we weren’t alone in our concerns about multi-cloud, as there’s been a backlash this summer from folks like Matt Asay, Corey Quinn, and Gartner. Admittedly, most of their concern is directed at IT organizations seeking to roll their own multi-cloud applications and databases by going the Kubernetes route.
Admittedly, Atlas multi-cloud smooths over most of the disconnects, like dealing with different cloud control planes, compute and storage instance choices, load balancers, authentication, access control, and so on. And it skips the issues that those wishing to do this themselves through setting up their own Kubernetes clusters that the aforementioned folks were largely frowning on. That’s all well and good.
In an analyst prebrief, MongoDB stated that this gives organizations the flexibility to choose where their data is stored and where to run their databases and applications. Or more specifically, Cloud A to run your operational database and Cloud B for your analytics instance, with both working with the same underlying data set. Ultimately, this is a case of trying to get the best of both worlds, where data gravity determines where your operational database is, but desire for unique functionality demands a different cloud. What’s interesting is with Google BigQuery Omni, where Google will support the running of a satellite BigQuery instance on an Anthos cluster in a foreign cloud, the going notion is to just egress the results data to ameliorate matters. Regardless, if you’re going to be replicating from Cloud A to Cloud B on an ongoing basis, those data egress charges are going to add up. Maybe MongoDB could get creative by pricing in some discounts here.
As we maintained in our previous post, we believe that for most organizations, multi-cloud is really going to be about having freedom of cloud choice. MongoDB cites customer requests for cross-cloud access so that if a database runs in Cloud A, that they can take advantage of differentiated services in Cloud B. That would be fine for the occasional use case, but as noted above, doing this on a regular basis could get expensive. And that’s not to mention network latency, especially if those cloud centers are hundreds of miles apart. And don’t even think of running those services in the second cloud in close to real time.
MongoDB also speaks of the primacy of dev teams – and of course, it’s dev teams, not CIOs, who originally put MongoDB on the map. But we need to be adults here, the localized demands of dev teams could cause costs and management overhead to soar if their wishes go unchecked.
By and large, making it simpler to migrate data and instances of Atlas from one cloud to another is a very useful feature for organizations that need to keep their cloud options open. And in a metro area, yes, maybe this makes sense as long as you’re willing to pay for the privilege of constantly egressing data.
Of all these options, we embrace the issues of data sovereignty, cloud migration, and disaster recovery (where absolutely called for by regulation) as the most convincing use cases for multi-cloud clusters. And that’s the message that we wished MongoDB had emphasized.
