I work in the enterprise and we spend tens of millions a year with AWS.
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.
This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in?
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.
If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possible that the incremental cost for adding it to AWS was cheaper.
My point is that those support functions' lack of understanding of realms outside of AWS shouldn't be the sole motivator for not using a technology.
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?
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%.
I certainly don’t disagree with you on principle. It’s just a bad example in this specific case because A is roughly equivalent to B in this case.
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.
They're roughly equivalent, but what if B costs a tenth of A?
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?
Does Google have a reputation for killing Enterprise products? I thought it was just consumer products that they offer for "free" that are subject to getting the axe.
Unfortunately that’s typical in enterprises. Procurement staffers are typically not technologists, rather they are contract wranglers, responsible for setting terms with vendors that have longevity, references, willing to negotiate, approved by security, are provably better than at least two comparable competitors, etc. If you want to sell to enterprises you have to bend the knee to their procurement team.
