Open source products are often equated with technologies that are used for the internet age and for internet-based business models. And that’s particularly true of the NoSQL database market, which is currently filled with a bunch of companies that are scrapping to come out on top as the most profitable, most widely used database company of the future.
But when a product is essentially free, how do you grow a company beyond providing support to customers? Whilst providing support will bring in revenues, it doesn’t provide the profitability of enterprise tech sales in years gone by and that which the market is accustomed to.
MongoDB, pretty much the leader in NoSQL, is taking on this challenge head on. We’ve written about how it has launched a new consulting arm to take on the likes of Oracle (and MongoDB has a pretty solid reputation for having a very aggressive sales culture). But it also thinks that it is doing something different in terms of its approach, which it hopes will make its business profitable and sustainable for the long term.
I got the chance to sit down with MongoDB’s VP of Strategy, Kelly Stirman, at the company’s annual customer event in London this week. Stirman is a very interesting guy and was happy to delve into how the company is hoping to differentiate itself in an open source market. He said:
It’s actually pretty interesting topic, how to build a high growth sustainable business around open source technology? The solution for that is not obvious. The way that Red Hat did it, does not work today. It is essentially table stakes to be open source and disrupt this kind of market. Or you have to be a SaaS product. The traditional proprietary product and very expensive price point, that model, you cannot disrupt a market like this anymore.
What you see in the market are companies, for example in the Hadoop space, that are open source and essentially have the same go to market model, which is selling consulting, training and support. That’s their main revenue stream. They do well, because Hadoop is so complicated that there is a lot of demand for training, consulting and support.
Amazon has a portfolio of database products that are also aimed at disrupting this market, which are entirely a SaaS play. So you may never talk to someone from Amazon and the convenience is overwhelmingly appealing and you’re willing to give up a lot of control to get that convenience. That’s the other thing that’s potentially viable in terms of potentially disrupting the market.
I wholeheartedly agree with this latter point. Talking to customers across a number of industries, we very rarely hear them getting excited about a new cumbersome piece of tech that’s going to cost them X million dollars and 3 years to implement. That’s the old model.
It’s all about ‘-as-a-service’ delivery models, open source implementations and the redesign of services. The companies thinking this way are the ones that are setting themselves up for a digitally-enabled future.
But what does that mean for MongoDB? How is it planning to monetise? Stirman believes that the company is taking a different approach to others in the market. He explained:
In my opinion we are breaking new ground and doing something that no-one else is doing. We have a traditional enterprise sales play, where we have an open source core product, but we have proprietary differentiated products around it and when we sell a subscription, the buyer is buying not just support, but they’re also buying access to these proprietary tools. Tools that make using MongoDB easier and safer.
We have this traditional enterprise arm of the business. But the other core strategy that we have in play is a cloud play. Where we have a suite of management technologies as a cloud service, that is geared for people that we are never going to talk to and it’s at a very attractive price point - $39 a server, a month. It allows us to go after this long tail of the market that isn’t Fortune 500 companies, necessarily. So we can do both of those in parallel.
That’s a very different go to market business strategy and model around open source. It doesn’t guarantee that it’s the recipe for everyone going forward, but what you see is that we are growing faster and outperforming other open source vendors in the market. Partially because of this two phase attack, but also partially because of execution.
How do you stay interesting?
The other question I had for Stirman, which was closely linked to the above discussion about remaining profitable, was around how MongoDB can stop itself from becoming a commodity. Partly playing devil’s advocate, I suggested to Stirman that NoSQL and Mongo are very interesting and disruptive to the market at the moment because they are a strong alternative when compared to going out and buying a database from Oracle, for example.
But how do you stop from becoming a commodity? It’s not too hard to imagine a world 10 years down the line where NoSQL is the de facto choice for database implementations and everything is very standardised. How does MongoDB stay interesting?
Stirman’s response was solid, in that he believes whilst MongoDB has the potential to become ‘just a database’, the company’s investments in improving developer and operations performance should keep it interesting in years to come. He said:
This is the innovators dilemma. I would love to have that problem in 20 years - Mongo not interesting anymore and everybody is just using it. At a certain point everyone can be just like Mongo. You can actually see that already happening. Seven years ago we had a vision that a document data model could really transform the way that people build applications. The jury is still out to a certain extent, but it’s overwhelmingly positive so far. People really do believe that this is a fundamentally different approach that has big advantages over the way that we have been building applications for 30 plus years.
The reality today is that if you look at projects from 30 years ago and you look at the total cost of taking an idea and putting it into production for your business, the overwhelming majority of the cost was in infrastructure. It was in servers and storage. And now if you look at the same project with 10X the data volume, the cost of the infrastructure is less than 2%. The overwhelming cost is the people. It’s the developers you are paying a fortune to develop the applications and the operations people to keep the projects alive.
One of the huge appeals of MongoDB is, what are we going to do to make those people more productive? That’s what keeps people coming back to MongoDB. They move faster and more effectively. The database was always the bottleneck for folks. Every other layer of the stack has evolved, but the database. This is why people get absolutely hooked, it’s a number of things in MongoDB coming together.
We have to stay ahead though. I think the really interesting direction we are moving in is
continuing to push on innovation in the management on the operation side of things. Now we have a cloud product for managing MongoDB deployments, we have tens of thousands of users on that. We know a lot about MongoDB. You can think about that like a pile of big data about operating on MongoDB, where we can look at that data to get insights into indicators that predict if something is going to go terribly wrong with your system. We can build that intelligence into the application and basically say if something was going to go wrong, even if you didn’t know it was. Click here and we will fix them for you without impacting your application. It’s a prescriptive management capability that helps you keep the system healthy before it’s too late.
Ah, so linking MongoDB very closely to the performance of the application itself. Automating that process, rather than relying on the know-how of your dev/ops team, and reducing costs for the customer. Makes sense.
Finally, I was keen to hear from Stirman about how (if at all) customers are changing in their use of MongoDB. I wanted to understand whether or not customers are moving beyond side projects with the database towards rip and replace. Stirman admitted that this isn’t always the easiest sell and that MongoDB has work to do to ensure it makes those rip and replace projects as easy as possible for customers. He said:
The other challenge is, I like to think about data as having inertia. Once it is in motion it stays in motion, and when it is at rest it stays at rest. People don’t change their database platforms lightly. It’s not a decision you make on a whim. There is sort of a re-platforming cycle in a seven, eight, nine year cadence.
What you see right now in the market is that people are overwhelmingly using MongoDB for their new applications. I guess in a way what I’m saying is that the size of the market opportunity continues to grow, but there is a kind of friction just because of the inertia of the data. It’s already somewhere and it’s hard for people to move it from one platform to another. We have work to do to make that transition easier.
Part of that includes introducing tools that make MongoDB a more realistic option for mission critical apps. In other words, if Mongo was to replace an Oracle database, useful things wouldn’t be lost. The latest 3.2 release, which was out this week, goes some way to address that. But Stirman admits there is still a way to go. He said:
One of the things in the product in this release, is the connecter for BI. So we can go to the business that’s using tools like Tableau and say to them that they can keep using those tools and have access to their modern data. It’s one of those things that makes it easier for people to move those things to MongoDB.
The trend is that people do the first five or six projects with MongoDB. Then they’re looking at how do they manage an estate of dozens or hundreds of applications running on MongoDB? The trend is from the initial courtship of these projects that may be important, but not absolutely critical to the business. As the confidence develops and the history of success develops, it sort of becomes irresistible and you move mission critical things onto MongoDB.
We still have a lot to do in terms of building and instilling confidence that this is the right technology for mission critical apps. But you can see in these earlier adopters that they’re there. If you look at our last three releases, there is a lot there around mission criticality. Things around security, around operations and management. The connector for BI. Things that aren’t necessarily sexy or shiny features, but they’re core requirements for any real database.