Microsoft makes cheeky bid for MongoDB devs on Azure security grounds Microsoft is attempting to capitalise on a recent spate of ransom attacks on unsecured MongoDB instances by encouraging developers to switch to working with its own Azure-based DocumentDB system. The free version of MongoDB ships with the default TCP port 27017, and with so many administrators failing to run port to change it …
The problem is not taking security seriously enough to properly design and implement your system. MongoDB's defaults do not help but they are easily reconfigured if you bother to learn what you are doing. This is not different for any other db system; learn how to secure it and learn how properly sanitize data and most of the problems disappear.
Also, remember it is Slurp making the pitch who is a notorious data guzzler and also prone to security theater.
The problem is not taking security seriously enough to properly design and implement your system.
As if that were the only problem with the DB. But, hey, now you can connect the browser client directly with the server DB for better performance. If you're worried about security, you'll never be a hipster!
Have an up vote for the webscale reference. For anybody who has not seen it (NSFW): YouTube Link
I have to admit to having never liking the mongoDB approach... it seems so ill conceived to begin with. It is like "here is our great but should never be implemented ideas, implemented by half-brain dead monkeys", the thing I doubt is that Microsoft's DocumentDB is going to be any better a concept, tho will probably at least be more secure.
MongoDB might be insecure with its default settings, but there is no comparison to DocumentDB at present. Just ask anyone unlucky enough to have had to use DocumentDB for an extended period of time (case in point: me).
- No backup/restore
- Can't rename collections
- Can't rename databases
- No proper tooling, only way to interact with DocumentDB is through Microsoft's nightmarishly designed Azure Portal
- Incredibly expensive (and billed per collection!)
Recently, they added support for aggregate functions like SUM and COUNT, announced with great fanfare. Shame you need to pay them an obscene amount of money just to get decent throughput on aggregates though: I've seen 200 resource units being used in a single COUNT query, compared to 10-50 resource units for normal SELECT queries (which by the way are themselves slower if you select specific fields, rather than all fields). In addition, DocumentDB seems to give the wrong result if you do a COUNT of a whole collection when it gets larger than a certain size, and the result varies each time. This leads me to wonder what DocumentDB's internals are like!
Maybe come back in 5 years when DocumentDB is out of beta.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
