I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake.
They really need to come up with a per mb per hour option.
I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake.
They really need to come up with a per mb per hour option.
I evaluated DocumentDB and price wasn’t the issue (at our scale, the price is OK).
Main blocker is that it’s locked at Mongo 3.4 API compatibility, which is several major versions behind. But worse, their implementation of the 3.4 API is incomplete, so while they advertise “Mongo Compatible”, it really isn’t a drop in replacement.
Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product.
With a managed MongoDB (even though it's on AWS) you need to get buy in from dozens of people and go a vendor comparison to get through Procurement. It's why for many companies AWS dominates and in the future could well end up owning everything under the application layer.
There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of processes".
We had a large local bank choose not to pursue a good opportunity because "our procurement process takes too long". This instead of investing in fixing the procurement process.
What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?
Also, Amazon doesn’t have the same reputation as Google for killing products, so it’s a pretty safe bet. And AWS will be around for quite a long time. The financial stability of MongoDB (the company) isn’t as guaranteed.
Maybe the parent’s company’s processes did work in this case.
It's not about the safety of the bet, because from an OSS perspective, the issue seems to be that many are moving away from MongoDB to something even more opaque. I don't follow AWS, but do they publish a roadmap of planned changes in their document DB?
In a .gov environment, we literally paid 5x more for certain services because the contract terms demanded were too costly or onerous for OEMs to handle. So everything funneled through middlemen of dubious value, who basically borrowed money, pushed paper and carried insurance for a vig that pushed up the price.
The procurement people were very happy, because they got their three bids that varied less than 1%.