I’ve Joined the NoSQL Movement…How About You?

Leave it to O'Rielly to give a great summary of NoSQL—and express what I have been telling other developers. NoSQL is not a technology. It's a different way of looking at large data sets and data-driven applications. I have been busy adding NoSQL to my developer's utility belt lately by introducing MongoDB into the projects that I am building. I have already referenced my BrainDonor.Mongo project in some of my other posts. I like to think of it as my formal announcement that I am a card-carrying member of the NoSQL movement. For me, the movement is about not putting all my data eggs in one basket. When it comes to development languages and platforms, I am a true polyglot programmer—and I must extend that further into data.

The primary reason I started looking at NoSQL do to it being an emerging trend. I've used 'alternative' data stores previously, such as memcached...but that was always in support of an RDBMS. All it took was the right project to come past my desk, and I knew I had to take a crack at it. I'm just finishing up a project at my day job geared towards event messaging. Without disclosing any real details (and I can't...sorry) I can say that the platform needs to be able to process high volume, have the ability to scale up, and even the ability to scale down. This platform is ASP.NET MVC3 on the front-end and MongoDB on the back-end.

Why MongoDB?
I've actually been following MongoDB since version 1.4 and playing around with its interactive shell and seen it grow considerably. The community of professionals using MongoDB has grown even more so. Best-practices in operations and architectures have been established and documented and the commercial company behind MongoDB, 10gen, is growing strong. What sealed the deal for me was the push to ensure that MongoDB was a dependable backend for almost any development language. Just take a peek at the Drivers page.

Enough of the soft reasons! Those just help me sell it to my partners in crime. Here are some of the features of MongoDB and why I find them valuable. If it's not listed, it's not that I don't care. All features are coming from the MongoDB website.

  • Document-Oriented Storage
    In my development, this feature is all about code-first. My domain objects are simply serialized and stored in MongoDB. I don't have to worry about updating tables, constraints or relationships. I've included the repository model I'm using in my BrainDonor.Mongo project.

  • Replication & High Availability
    For me, this feature is all about being able to scale both up and down quickly, and easily. A replication set can actually be entirely replaced without taking the databases offline. I'm also looking forward to trying out some of the WAN replication on AWS between different zones.

  • Fast In-Place Updates
    Updating a document can be done two different ways. You can update the entire document or you can update only a single field. Updating a document is not an atomic operation--but updating a single field is. The single field operation that caught my attention immediately was the increment operation and how I could use it in a data reporting application.

  • GridFS
    I want to build/use a CMS that uses this! Even better, I want to be able to sync everything with a CDN.

For what I am building right now, MongoDB is a great fit. And if trends continue, I'm confident that I will be using more NoSQL storage engines in the coming years. They are definitely not one-size-fits-all solutions.

Why ASP.NET MVC3?
I get asked this question a lot even without the addition of NoSQL. With all my experience with Open Source tools, why am I continuing to use C#?

  • Web Development is Polyglot Development
    Any rich web application will have JavaScript, HTML, and CSS regardless of the underlying platform. This is compounded when you start introducing tools such as SASS, LESS, CoffeeScript, etc. These applications are also not running in isolation. How many external services did your last application integrate with? There are countless reasons to integrate with social media, ecommerce, advertising and CRM systems. How many of those are well documented for the back-end language you are developing with?

  • ASP.NET Finally Understands Open Source
    With packages such as NuGet, I have a rich collection of libraries and utilities at my fingertips. Microsoft is also not reinventing the wheel with their MVC framework. It is very clear that the development team has been using and following other languages and MVC frameworks. I am constantly using new, open source utilities as I build applications.

  • I Am Not Locked In
    My application most definitely is locked into the Microsoft stack...but I am not. I have built and launched web applications in C#, Perl, PHP, Python, C++, C, and even an old Bash CGI powered site in my history. Java and Ruby aren't in that list...but how long would it take me to get up to speed building an MVC application with either of those? Java maps very closely to C# and Ruby maps very closely to Python. In fact, I have only had one job that used a single stack exclusively.

    Wait...is this a worthy business reason? Yes! I'm a firm believer that mono-culture web development teams are a recipe for disaster. Teams of polyglot developers aren't just agile with how they build a single application—they are agile in how they even think about building web applications. These teams will usually program in one stack at a time, but switching stacks is never off the table.

Back to coding with me!

Attachments:
February 10th, 2012