Kelly Stirman of MongoDB isn’t your typical VP of Marketing and Strategy. You see, he has a database research obsession, which makes him a prime
victim candidate for one of my on-site podcasts. Last week at MongoDB Palo Alto, I taped an informal podcast with Stirman on database upheavals and MongoDB security in the headlines.
Stirman explained why it bugs him when MongoDB is lumped into the NoSQL database category. Our wide-ranging discussion wrapped with a couple of teasers from the upcoming MongoDB World in June, which (spoiler alert!) They Might Be Giants fans may find of particular interest.
You can download the podcast or check it in the player below, but for your browsing I’ve picked some highlights, including streaming data, the impact of containers (Docker etc.), and cloud databases crossing the Rubicon. Stirman also had newsworthy thoughts on how MongoDB views graph databases.
Last but not least, Stirman agreed to address a couple of recent “ripped from the headlines” news items about security breaches that involved online MongoDB systems. Here’s some highlights from our thirty-minute podcast.
Stirman: don’t lump MongoDB into NoSQL
Stirman doesn’t like the NoSQL monicker for MongoDB. He views it as a lump category that diminishes some relational database virtues:
Unfortunately, NoSQL became the “other” bucket. Lots of things went into it that had very little in common with one another. The way I think about MongoDB is that there are all these wonderful things about relational databases… There are great things like the notion of expressive query language and secondary indexes, strong consistency, and integrations with all those enterprise tools and standards that have been evolving over the past several decades.
He wants MongoDB to pull in the best relational and NoSQL attributes:
People started building different kinds of databases about ten years ago, mostly because they were running this limitations with relational database and they started focusing on flexibility of data model and scalability and performance… [we] preserve the virtues of relational database but give you the scalability and flexibility and always on the abilities of things.
Four database trends Stirman is tracking
After that MongoDB clarification/plug, we moved onto database trends Stirman thinks you should be tracking.
1. Streaming data – Stirman pointed to Kafka, the Apache data streaming tech developed by LinkedIn, as one example of the streaming data trend:
While MnngoDB puts food on the table for me and my family, it’s just a piece of the larger story. It’s a very interesting and quickly evolving story about how people are capturing and leveraging data for insight in their business and competitive advantage – to connect everything together. That means all the different types of systems that create data, all the types of systems that consume data, and all the different ways you might want to analyze the data. It’s not one single thing that does that for you.
Today, what people are working towards is lots of smaller independent components that are working together in concert to achieve some larger goal… I have been spending a fair bit of time looking at Kafka for example, which connects different systems and reliably moves the data between those systems – conditionally moving it from one place to another based on certain rules – even giving you some insight into the data maybe before it lands in any kind of database. I think that is really interesting.
During the podcast, we went deeper into why streaming data tech matters to business. Nutshell: businesses might be making flawed decisions because the chance to act on insight disappears before the data can be surfaced appropriately. “Time is of the essence” use cases are increasing beyond the obvious threat detection, fraud detection and recommendation engines.
2. Graph databases – Stirman is bullish on graph databases and sees a role for MongoDB. I asked him if graph databases are overhyped:
I think there is some hype, but I there’s a lot there. Frankly, I find the learning curve on the graph model and graph queries – and using these systems – is fairly steep. But once you get into it, I think it’s extremely powerful… We’ve started to view graph as fairly narrow in it’s applicability, and we view it as something we’d like to see as a capability of MongoDB.
I joked with Stirman I was breaking news that MongoDB was changing to a graph database, but err – not so fast:
We are not going to rewrite our database as a graph database, but we can give graph operators, and certain new types of indexes that will allow you to get most of the way there… graph is an important part of what we are going to do in the future.
Stirman says MongoDB’s pursuit of graph database functions is directly impacted by customer feedback:
This is not us being an ivory tower. We are hearing enough from users in different sorts of industries like healthcare, where the analytics you can perform with these graph models gives you some capabilities you just can’t get otherwise.
(The podcast gets further into graph database industry use cases, and the importance of data visualization).
3. The impact of containers – Stirman believes MongoDB has a responsibility to be compatible with a range of virtualization and container options. Docker has set the standard for containers, which Stirman credits to their developer user experience and APIs. He sees orchestration as the unsolved puzzle piece:
Docker has won this container standard debate, but the wars right now are the orchestration options for managing all these containers. MongoDB is distributed, so the way you run MongoDB needs to fit into how you are going to run all these different containers with your orchestration tool. That’s an interesting thing that we are working on right now.
4. Cloud data has crossed the Rubicon – The easy climbing in the database rankings is over for MongoDB. DB-Engines.com has them ranked number four in popularity now, and the top three will not be easy to displace. But Stirman thinks MongoDB is very well positioned in the cloud database movement. This led to a discussion on the levels of cloud database adoption and which types of systems companies are moving to the cloud. Stirman thinks cloud databases have “crossed the Rubicon”:
People download MongoDB over 20,000 times a day just from our website. We don’t know what they are doing with it, but we have some insight based on our cloud management tools into where people are running and what kinds of environments, what sorts of operating systems, machine instance types, all those good things. The numbers are just overwhelming in how much usage there is in the cloud.
We have crossed the Rubicon; the greater proportion of workload will be in the Cloud. It’s irresistible, but I think there will always be some amount of on-premises usage also.
There is nuance in which data projects work better on-premises and in the cloud. But Stirman sees a fundamental shift. Speaking of provisioning databases for testing and Q/A, he says:
[When IT tells you], “It should be about eight weeks, and we can have your servers up and ready for you,” people don’t tolerate that anymore. In just a couple of seconds, I can get all the servers I want on AWS or Azure.
MongoDB in the security news – Stirman responds
Cloud databases the security questions we would expect, often with sensationalist hype. Stirman and I talked turkey on database security, including two recent incidents (one and two), both of which involved a MongoDB database that the companies in question had not configured properly from a security standpoint.
Responding to the headlines, Stirman said:
We take the security very, very seriously. It’s been a core part of the product for a number of years, and every release, we have added more and more security features into the product. This is not just in our paid version of MongoDB. In the open source version of MongoDB, you have everything you need to secure the system in a variety of different ways. What you have in these examples are people that have deployed MongoDB with all the security disabled. We treat users like adults and they have the option of enabling or disabling security.
We talked about the “lock your front door” analogy, which is simplistic but not inaccurate:
I think the analogy is very appropriate in terms of your front door or locking your car. Having the security on is less convenient, so I think what happens is people turn it off for the sake of convenience, and then they just put these things in the cloud, and forget to turn the security back on. Most of the data we believe is just test data where they don’t really care. The vulnerability is there, but they are not concerned about any significant data loss. Certainly that that’s not true for all of these, and some people are not taking precautions that they should be taking.
Stirman went on to talk about the security resources MongoDB provides to all who download. We then talked about the vigilance that security requires on all sides. Many databases, whether its Couchbase or Cassandra or MongoDB or fill-in-name here, require attention to proper security configuration – and are therefore vulnerable to the same breaches if security is lax or improper. Stirman then acknowledged:
Some people might view this as reflecting negatively on MongoDB, but stepping back from that for a moment, awareness is going to go up. Hopefully as an outcome from this, we have people being more careful about their security in MongoDB, and other systems as well.
I also got Stirman to weigh in on the Apple-versus-FBI dispute (that’s what you call a teaser folks). The final comments in the podcast are about MongoDB World, which has a “giant ideas” theme that works well with the They Might Be Giants concert. Some fanboys and fangirls from the old school will be over the moon about that.
Image credit - Digital safety blue concept © Sergey Nivens - Fotolia.com
Disclosure - I covered my own expenses to meet with MongoDB in Palo Alto (I was already in the San Francisco area at the Influitive Advocamp event). Diginomica has no financial ties to MongoDB. I hope to attend MongoDB World in June, but that plan been confirmed on either side.