Amazon is gaining a reputation for shooting its business partners in the back. After deciding to ditch databases from Oracle (more competitor now than partner) for its own services, Amazon is now looking to replace MongoDB with its own “compatible” version called DocumentDB. What’s interesting is that while the Oracle announcement came on the heels of Oracle CEO Larry Ellison boasting that AWS and Salesforce run on Oracle databases, this one came right after MongoDB changed its licensing terms. What’s even more interesting is the fact that MongoDB changed its licensing terms specifically to prevent this sort of thing from happening, though they seem to be worse off for having done it.
The MongoDB Server Side Public License essentially mandates any cloud provider offering MongoDB as a service must open source all the code related to that service offering. This is not something that any cloud provider would readily agree to so it isn’t surprising AWS has found a way around it. Given that DocumentDB is designed to work with version 3.6 which was released before that license went into effect, the SSPL doesn’t appear to apply to DocumentDB. Additionally, Amazon’s new offering is basically just a set of compatible APIs that sit on its own database, so it’s not actually using any MongoDB code.
Considering AWS is by far the biggest public cloud and the mere announcement of DocumentDB caused MongoDB shares to plummet, the fact that DocumentDB only supports MongoDB 3.6 could be a serious problem. If AWS’s new service gains popularity, MongoDB has little choice but to either open source its latest offerings or risk stagnation. This is why licensing is like open source suicide and not only did the new license not protect MongoDB from big bad wolves like AWS, it’s even gotten them a lot of flak from the open source community. In response to the SSPL, both Debian and RedHat have decided to not include MongoDB with their latest offerings deeming it contrary to the spirit of open source.
In their latest announcement, AWS describes DocumentDB as “a fast, scalable, highly available, and fully managed document database service that supports MongoDB workloads.” While this implies MongoDB out of the box can’t handle workloads at scale, it also implies AWS is not selling MongoDB, but rather its own core competencies that are performance, scalability, and availability. AWS also said in an accompanying statement that organizations rarely take advantage of a fraction of the capabilities the MongoDB APIs and find it challenging to scale to multiple terabytes and hundreds of thousands of reads and writes per second because of the complexity of setting up and managing MongoDB clusters.
AWS doesn’t sell software, it sells convenience, and while MongoDB gave its customers the tools to do the job, AWS is giving them what they really want, someone else to do the job for them. Getting performance, scalability and availability upgrades without having to manage the underlying infrastructure is what every organization wants and that’s what has made AWS so successful in the first place. To make things even more convenient, users can use MongoDB application code, drivers and tools for workloads on Amazon DocumentDB and with the help of AWS Database Migration Service (AWS DMS), can perform live migrations from MongoDB without any downtime.
Amazon DocumentDB uses an SSD-based storage layer, with 6x replication across three separate Availability Zones which not only means DocumentDB can failover from a primary to a replica within 30 seconds, but also that it supports MongoDB replica set emulation as well. It also features automatic provisioning and setup, monitoring, metrics, and automatic software patching as part of its “fully managed” offering. Additionally, DocumentDB storage can be scaled from 10 GB up to 64 TB in increments of 10 GB and reduces database I/O by writing only database changes to the storage layer. It is also claimed to achieve twice the throughput of currently available MongoDB solutions.
This is probably because with Amazon DocumentDB architecture, storage and compute are decoupled from each other, allowing each to scale independently. This means developers can add up to 15 low latency replicas in minutes, increasing the read capacity to millions of requests per second, regardless of data size. Apart from speed, scalability, and availability, DocumentDB also focuses on security in a big way and runs in Amazon VPC, which allows you to isolate your cluster in your own virtual network. It’s also integrated with AWS Identity and Access Management (IAM) and allows you to encrypt your databases using keys you create and control through AWS Key Management Service (KMS).
The folks at MongoDB can’t be too happy, but CEO Dev Ittycheria was quoted stating “Imitation is the sincerest form of flattery, so it’s not surprising that Amazon would try to capitalize on the popularity and momentum of MongoDB’s document model.” He then goes on to call DocumentDB a poor imitation, while a company spokesperson pointed out that it’s based on a 2-year-old version that’s missing out on new features like ACID pay, global clusters and mobile sync. While the MongoDB stock plunge following the AWS announcement no doubt illustrates the kind of muscle AWS, MongoDB’s stock has risen 200 percent in the past year so it’s definitely too early to count them out.
MongoDB offers its own managed version of the open-source database through a product called MongoDB Atlas which is based on the newest version of MongoDB, 4.0. In a recent blog post, company CTO Eliot Horowitz compares the two services and points out that DocumentDB is actually about 6 years behind and based closer to version 2.4 rather than 3.6. He also numbers a bunch of trade-offs that come with AWS’s promise of performance, scalability, and availability, including the fact that all DocumentDB clusters are limited to residing in a single region unlike Atlas, which allows replica sets to span the globe and provide low latency.
In conclusion, it’s sort of a Catch-22 situation, where you don’t really know whether you should sympathize with MongoDB or support AWS’s decision to blatantly steal from the open source community. From the AWS point of view, they’re not selling MongoDB, they’re just providing a service that enterprises value and if it wasn’t MongoDB, it would be whatever other database their customers were using or wanting help with. One example is Redis database, which is under a permissive license so AWS’s version is always up to date. While this is great for development, it doesn’t help Redis Labs make any money, which is probably why it changed the licensing on its add on modules.
It’s definitely got to be painful to watch one of the richest companies in the world profit off your hard work and it’s difficult not to feel bad for companies like Redis and MongoDB. The other side of that coin, however, is the fact that their popularity is probably because they were both open source in the first place and there will always be a market for “managed” open source services. Whether this means AWS continues to take what it wants from the open source community at will, or licensing laws change to protect companies like MongoDB, only the future will tell.
Featured image: Pixabay
Microsoft has pumped up Office 365 Advanced Threat Protection with a new feature, Automated Incident Response. Here’s what you need…
What will be in your living room or on your wrist this year? It may very likely be one of…
As virtualization becomes a major part of organizations’ infrastructure, these SD-WAN technologies provide faster and more reliable networking solutions.
In this blog post, we are going over a simple script that can be used as an Azure runbook to…