NoSql vs. Ldap

During my time with Pearson Education I had the opportunity to work with the NoSql developers on the task of integrating Puppet infrastructure in the cloud. As in any new project using a new technology their was not only a learning-curve with everyone on the team, but each contributor had a different master skill set that was needed to gel the whole new plan together. It was decided early on that MongoDB would be used to host data, such as online-classes, student records, etc. This involved everyone on the team not already experienced with Mongo getting up real-quick. On line classes on Mongo were held that the team attended. After all & done I still felt some pieces were missing. Where's the nice web or at-least GUI user & admin interface? You may laugh and say "We don't need no stink'in gui", but be aware, not everyone on the admin team or off-shore team are necessarily capable of supporting or managing Mongo. Don't get me wrong, I think NoSql via Mongo is fine. But I think we forget about a service that's widely in use on hundreds of thousands of servers and desktops around the world, Ldap. (AKA. Active Directory)

So you're thinking, "Great, old-school". Yup! And it's all matured, bugs ironed out, good collection of utilities/tools, and even well supported, both via the community and commercial. Ldap and I go back to the iPlanet days of Ldap, then the Sun One Directory server, along with the redhat directory server (note: both sun one & redhat got a piece of netscape (previously iPlanet) and that included their ldap. Sun rewrote the whole smash in java & redhat just rebranded it) and now finally 389-ds. Never liked openldap. (I'll save that for another day).

So, why use Ldap?:

• • Capable of wan replication (multimasters). If we're talking cloud, I'd put a master in each zone, two to be safe.

  • Levels of replication can be fine-tuned. We can replicate to hubs, which feed to consumers (read-only). This is how we scale. Ldap was optimized for few writes, many reads.

    • of course if the app is write intensive (i.e. 50% write, 50% read), then look at Mongo....or....is this something we could put on Gluster??

    • ... and if it's okay for slow async replication, then I'd go the bittorrent approach and roll-out btsync. (directory replicator)

  • tools galore! I like jexplorer. The old crusty crowd reading this may remember back in the Netscape days, the browser had a built-in Ldap browser! It was Nice!

  • simple to extend. Modifying the schema can be done online. And the 389-ds console tool makes it very simple to create new objects and attributes. I used that when I configured puppet with an Ldap ENC and stored all the node configurations in Ldap.