3 results

Making sense of increased database choice

Gartner estimates that by 2015, 25 percent of new databases deployed will be of technologies supporting alternative data types and non-traditional data structures. This is great news, as these new database choices, many of them NoSQL, are generally better tuned to modern application requirements. The downside to this end to the “30-year old freeze,” to quote Redmonk analyst James Governor , is that with all these new options comes the risk of complicating a hitherto somewhat simple choice: which database to use? DB-Engines, after all, lists and ranks 92 different database systems , which doesn’t even include all of the NoSQL variants . Good luck to the CIO who tries to deploy all of those within her enterprise. The key, then, is to figure out how to standardize on a core of database technologies. Most companies will want to retain their legacy relational database for applications tuned to an RDBMS, or perhaps require complex transactions. But for most new applications, NoSQL databases like MongoDB will be be the optimal solution. But which one? There are currently at least 150 different NoSQL databases, split into different camps: document, columnar, key-value, graph, and others. One of my favorite guides for differentiating between these different options is Pramod Sadalage and Martin Fowler’s NoSQL Distilled . It does a great job of making NoSQL approachable, and also offers some guidance on which type of database to apply to specific types of problems. This is critical: which database is best largely depends on a particular use case. There is no shortage of guidance as to whether an enterprise should use NoSQL or stick with RDBMS or, if NoSQL, which to use ( here’s just one of many sites offering guidance). Unfortunately, this still doesn’t cut down on the number of choices presented to a developer interested in selecting a database for her application. I’m sure much of the advice is good, but it could end up solving a point problem (which database to use for a particular application) but exacerbate the meta problem (which databases to standardize on throughout the enterprise). This should be top-of-mind for every CIO, as shadow IT is already bringing NoSQL databases into the enterprise. This trend is only going to accelerate, as InfoWorld’ s Bob Lewis notes . The reasons NoSQL technologies are being adopted into the enterprise are somewhat similar to the reasons shadow IT is embracing the public cloud: speed of development, ease of development, and suitability for modern applications, as a recent Forrester survey found : Hence, savvy CIOs will select a few, broadly applicable databases that can tackle the vast majority of enterprise needs, while simultaneously satiating developers’ needs for databases that help them get their work done. But, again, which ones? Most enterprises already have RDBMS preferences, standardizing on two and possibly three SQL databases. Part of the reason that these databases have served so many for so long is that they are general purpose databases. They might not be the absolute perfect solution to a particular application requirement, but they do the job well enough and help the enterprise focus its resources. When choosing a NoSQL database, and every enterprise is going to need to do this, it’s important to opt for NoSQL databases that solve a wide variety of problems, rather than addressing niche requirements with a narrowly-applicable database. Document data stores like MongoDB tend to be the most broadly applicable, able to tackle a wide array of workloads. But there are other NoSQL databases that while not as generally useful, do a few things really well and should be considered. Other things to consider in settling on database standards are political and cultural issues, compatibility with existing applications or applications on the near- and long-term roadmap, and the momentum behind a particular NoSQL database. With 150-plus NoSQL databases to choose from, picking a fashionable but ephemeral database is a recipe for frustration and failure. As I’ve written, MongoDB’s community size and momentum , among other things, suggests it will be around for a long, long time. But there are other NoSQL communities that also demonstrate staying power. No enterprise wants to be managing dozens of databases, or even 10. Ideally, enterprises will settle on a few. Perhaps five, at most. In so doing, they should look to augment their RDBMS standards with NoSQL databases that are general purpose in nature, and broadly adopted. Considered in this light, NoSQL database standardization becomes much more manageable. — Posted by Matt Asay, vice president of Corporate Strategy . Tagged with: MongoDB, NoSQL, RDBMS, choice, database, relational database, Forrester, standardization, InfoWorld, shadow IT, Matt Asay

December 19, 2012

App development too slow? Fire your infrastructure

Forrester analyst Mike Gualtieri has argued (PDF) that “Many CIOs are on the hot seat to innovate by delivering increasingly critical applications more quickly,” yet don’t know how to do this. Part of the problem stems a shortage of staff that can keep up with requests for new applications. But perhaps a bigger problem is the crufty data infrastructure that makes it difficult to develop and improve applications. Solving this second problem (infrastructure/tools) may be the key to solving the first (personnel shortage). Throwing more bodies into an inefficient system doesn’t make it more efficient. It’s not surprising, therefore, that after interviewing a range of CIOs, Gualtieri concludes: Traditional application development platforms such as Java and .NET are not necessarily the fastest approaches to develop applications. CIOs should investigate application development productivity platforms that make application development professionals more productive. This parallels something my colleague, Jared Rosoff, said recently to me: The key to rapid development is looking at the whole stack of tools and processes that deliver software. You need to throw out the things that further a ‘design it, build it, ship it’ mentality and switch to things that encourage an ‘iterate it’ mentality. This means thinking of continuous deployment instead of shipping code, dynamic schemas instead of rigid schemas, and so on.” Unfortunately for the CIO, her enterprise is not going to sit around waiting for her to solve this. Cloud has changed expectations for business users, who have learned from Salesforce and its peers that robust business functionality doesn’t need to wait on IT to provision servers or install software. Nor are the advantages of cloud lost on IT. DevOps is but one example of IT buying into this “magic layer,” as Wipro vice president K.D. Singh terms it , enabling developers to “scrunch[] development cycles and improv[e] quality by fusing development and operations activities (and integrating testing between the two functions).” Increasingly such developers also turn to a new breed of development languages like Ruby, or application frameworks like Django or new market entrant Meteor . They’re writing less code and getting more done. And they’re asking the CIO for forgiveness, not permission. …Unless, of course, they’re shackled to 20th Century database technology. The traditional data infrastructure layer is a primary inhibitor to application flexibility. Relational databases served us well for many years, and still play a critical role for a certain class of application, but they’re a poor fit for modern application development. Take, for example, The Guardian , one of the UK’s leading newspapers. As the world has moved online, The Guardian was looking for ways to maximize user engagement, given its positive impact on revenue. It needed a new user identity system that could be tweaked and improved, and a traditional RDBMS just didn’t fit, as Philip Wills, software architect at, highlights : Relational databases have a sound approach, but that doesn't necessarily match the way we see our data. MongoDB gave us the flexibility to store data in the way that we understand it as opposed to somebody's theoretical view. Importantly, this wasn’t a one-time decision on the data model. Wills continues: ...MongoDB allows us to create a system that we can shape ourselves, with a view to the future of new ways for users to interact that we may not even know yet.” The reality is that most applications today, and the kinds of information they gather and deploy, depend upon a flexible data model that doesn’t constrain a developer unnecessarily. We’re entering a more rational world where the database structure is more fluid, changing as needs change. This is the world of NoSQL. NoSQL databases like MongoDB are not necessarily “schema-less,” but rather offer a great deal of flexibility around schema design, which in turn allows developers to change their schemas to reflect changes in their applications and the kind of information they’re trying to capture or exploit. In other words, they’re a great way to future-proof application development within the enterprise. This isn’t to suggest that most enterprises should rip out their existing data infrastructure. Yes, at 10gen we see organizations do just that (sometimes very large organizations for mission-critical applications), but this generally won’t be the preferred path for developers or their CIOs. They’ll want to maintain what they have while building for the future. As such, we’re seeing new app development gravitating to the platforms and processes that enable choice, rather than lessen it. We’re in the early days of NoSQL, but the momentum is already big and accelerating. So, want to speed up your company’s ability to deliver applications faster? That’s easy. Fire your data infrastructure and build flexibility and choice into your next-generation application development. Building on MongoDB is a great way to accomplish this. <b>Posted by Matt Asay, vice president of Corporate Strategy</b> Tagged with: CIO, DevOps, MongoDB, app development, Forrester, Mike Gualtieri, django, ruby, Meteor, The Guardian

October 26, 2012