As ZDNet’s Natalie Gagliordi reports this morning, MongoDB announces general availability of a new multi-cloud cluster expansion of its successful Atlas database as a service offer. Once Natalie reviews the details, we just want to summarize that the new capability takes advantage of the simplicity that DBaaS is supposed to be: it buries all the complexities of multi-cloud deployment under the hood.
It includes the complexity of federated user identity across different clouds, and any changes in external applications are just that: extrinsic to the database. So if your operational instance of MongoDB is running in AWS, but you want to take advantage of the AI features of the Google Cloud AI platform, you can change the configuration to have operational nodes in the original cloud and read-only secondary running analytics elsewhere. Atlas takes care of data replication under the hood.
As we noticed in a previous post, there are valid usage cases to run a database across multiple clouds, but they are very few: If there is a regulatory reason to ensure that your workloads are not vulnerable to errors from a single cloud provider (such as MongoDB listed, Australian banks ), or if cloud providers do not have sufficient (or no presence) in your country or sovereign zone. We believe that the latter case is certainly valid today, but a solution that resolves when cloud providers expand their global footprint over time.
MongoDB rightly points out another use case: when a company performs M&A and wants to rationalize cloud installations – but this is more relevant for database migration rather than multi-cloud operation. The good news is that the multi-cloud Atlas configuration settings can enable this.
Cut to the pursuit: We wonder if MongoDB is communicating too ambitious 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 charge data output fees from their clouds. It also involves with performance: there are network latencies to consider, especially that most cloud providers do not have special high-speed connections between rivals – and why would they? This is a case where Microsoft Azure-Oracle Public Cloud dedicated link is clearly the exception to the rule. Yes, you can mitigate it if it’s a region that has all three major cloud providers within the same metro area, as is the case in Northern Virginia. MongoDB responded to us that you can prioritize consistency or performance – this is also common balancing with NoSQL database with multiple clusters in the same provider’s cloud.
By the way, we were not alone in our concerns about multi-cloud, as there has been a setback this summer from people like Matt asay, Corey Quinnand Gardener. Admittedly, most of their concern is directed at IT organizations seeking to roll out their own multi-cloud applications and databases by going the Kubernetes route.
Admittedly, Atlas multi-cloud evens out most of the interruptions, such as dealing with different cloud management plans, selection of computational and storage instances, load balancers, authentication, access control, etc. And it skips the questions that those who want to do this themselves know to create their own Kubernetes clusters, on which the aforementioned peoples largely wrinkle. It’s good and good.
In an analysis by analysts, MongoDB said 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 to your analytical instance, both of which work with the same underlying dataset. Ultimately, this is a case of trying to get the best out of both worlds, where gravity determines where your operational database is, but the desire for unique functionality requires a different cloud. What is interesting is included Google BigQuery Omni, where Google supports the running of a satellite BigQuery instance on an Anthos cluster in an alien cloud, the impending idea is just to expand the performance data to improve conditions. Whether or not you continuously replicate from Cloud A to Cloud B, these data output charges will add up. Maybe MongoDB could get creative by pricing some discounts here.
As we maintained in our previous post, we believe that multi-cloud for most organizations is really about having the freedom to choose cloud. MongoDB quotes customer requests for cross-cloud access, so if a database is running in Cloud A that they can take advantage of differentiated services in Cloud B. That would be fine for occasional usage cases, but as mentioned above doing so on a regular basis can become expensive. And that’s not to mention network latency, especially if those cloud centers are hundreds of miles apart. And do not even think about running these services in the other cloud close to real time.
MongoDB also talks about the superiority of dev teams – and of course it is dev teams, not CIOs, who originally put MongoDB on the map. But we have to be adults here, the local demands from dev teams can cause costs and administration costs to rise if their wishes are not controlled.
By and large, it’s much easier to migrate data and instances of Atlas from one cloud to another a very useful feature for organizations that need to keep their cloud settings open. And in a metro area, yes, maybe it makes sense, as long as you are willing to pay for the privilege of constantly issuing data.
Of all these options, we embrace the issues of data sovereignty, cloud migration, and disaster recovery (where absolutely required by regulation) as the most compelling utility cases for multi-cloud clusters. And that is the message that we wished MongoDB had emphasized.