Ravi Mayuram is the CTO and SVP of Engineering at Couchbase, a NoSQL vendor responsible for the Couchbase Server, an open source, NoSQL, document-oriented database. In this episode, Ravi discusses how an entrepreneur may successfully orient themselves around the problem they’re solving.

Couchbase
Transcript

Intro

Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we talk to the leaders of successful open source companies about the business model that powers their growth.

This week, we’re excited to have Ravi Mayuram, CTO of Couchbase. In the interest of full disclosure, Couchbase is the latest database supported by the Gluu server.

We’ve been super impressed with the technology, their level of engagement with customers, and their flexibility to find ways to work with us.

Ravi gives a pretty good technical and business overview, so let’s just dive into it.

Ravi, thank you so much for joining us.

Ravi Mayuram: Thank you for inviting me.

Michael Schwartz: So, how’d you get involved with Couchbase?

Ravi Mayuram: That was a good number of years ago.

In the early stages of the Couchbase, there was a lot of exciting stuff going on here. And my own experience with some databases had led me to thinking – with all this innovation that is going on, with the new way of development paradigms and the new way of the data being more flexible, what should be the answer?

Some of us were thinking in terms of how to get going on that, and Couchbase was doing some of the stuff, so I started to talk to some of the people here, and that excited me to sort of jump in and get the journey going to where we are right now.

What Is Couchbase?

Michael Schwartz: This isn’t a tech talk, but maybe just to help our listeners, could you explain a little bit about what makes Couchbase different than other databases?

Ravi Mayuram: The fundamental question we were sort of asking ourselves when we began this journey was – many of the assumptions that we had to make when the relational databases were built are no longer true, memory is a way cheaper, network is a way faster.

And the entire application development paradigm had completely changed. There was no object-oriented programming, back in the day when the relational systems were built.

So, every paradigm around the database has changed. But the databases that we were still using, the relational ones, which were predominantly the ones that used technology that was developed some 40 years ago, in the late ‘70s and early ‘80s, whereas every other piece that we talked about has completely changed since then.

So, in this new landscape – what assumptions would you make, and how would you build a new database? So, that is the fundamental premise.

And what are those pieces that are worth keeping? One of the lessons that we had learned – from the relational work – what would you like to keep, and what would you really like to change or design differently?

If we look at it from that perspective, we would like the databases to be a little bit more memory-friendly, and network-friendly. These were the two assumptions you could make earlier, so it was very disc-oriented.

Also, a single system, if you will, a single-node system is where relational systems work, because you could never rely on the network back then.

So a distributed database, which is memory and network-centric, would be one element of it, from the standpoint of how infrastructure and how the bottom-half of the database need to look at the problem. And on the top-half was all this change to the object-oriented programming paradigm.

So, in this paradigm, there is already this object-relational impedance, as we call it. And how do we basically solve that, how do we make databases that much more natively plug into the application development paradigm now, which is object-oriented, and the World Wide Web is here, JSON has become this lingua franca of the web.

In this circumstance, where any endpoint that you talk to is describing and consuming JSON, in this object-oriented world, what would be the database’s role? How can it become easier and a help to the application developers, as opposed to being the friction point between an application, developer, and finally, when you want to roll something out, to production.

How do we solve these problems?

In a manner, which takes databases forward, it’s not worrying about whether it is SQL or NoSQL, but how do databases need to move forward. And what would be those foundational changes that we have to make, and what are those good lessons that we’ve learned from databases that we must keep.

And so evolved the journey at Couchbase, in building the new data platform, which is based on the NoSQL technologies, and the lessons learned from there as well.

Why Open Source?

Michael Schwartz: So, where does open source fit in the strategy?

Ravi Mayuram: A very good question. One of the lessons in the last 40 years of software has been to move from what we used to call monolithic stacks to open systems, open source.

And that movement has been basically lead because of this reason that, no matter how friendly, or how much APIs that you have there to integrate into systems, you always needed to make that little tweak or a change.

You didn’t want that to be hidden behind some proprietary wall, where you couldn’t see how the software is actually going to run. So, integrating multiple components into one place, that has always been a huge pain, because it’s not, you know, “I can take bridge at A and consume bridge at B.” It’s not that clean. You always have to do some last-mile programming, if you will, before two components will talk to each other.

And you need to understand how these components work. And so, having the facility to observe under the hood, and so the open source movement began. That also gives you the ability to help within a community around how we are building, which is very important for adoption of a technology.

These two elements of sort of having a community as well as an ability for that community to feel that they can own a piece and move that forward, which will both solve their problems as well as move the consumer software forward, is generally the motivations behind the open source.

And a platform, like a database, or a data platform like ours, requires the community to come together and consume this move, this forward, and benefit from that, as well as the company that’s doing this benefit.

The lesson learned is to start with an open source sort of a paradigm and ethos, and cultivate that community. That way you get to be closer to your users, you learn from them, you adapt to changes faster. Instead of doing the classic full-on cycle of focus groups and everything, you can basically go faster by interacting with this community.

It’s a win-win on both sides, and that is always one of the motivations for the open source-based companies like ours, which want the community, as well as monetize on the back side when the deployments are serious enough.

The Couchbase Community

Michael Schwartz: Can you just describe the community?

Ravi Mayuram: The community is a set of developers who are building applications on top of platform like Couchbase.

In this case, our community is those developers who take Couchbase, and build applications, the modern applications which are the ones that require flexible data model, performance, scale, what are all the other requirements that they have, which the older relational databases could not service those needs.

That generally becomes our community, the community of web and mobile developers, and perhaps even beyond, in terms of the types of applications that are getting built on Couchbase.

What Features Are Open Source?

Michael Schwartz: Couchbase has a very nuanced feature matrix, in terms of which features are community and which features are Enterprise. So I guess I’m wondering – is the functionality that’s in their community software enough to actually have a large community who actually uses this for production applications?

Ravi Mayuram: Actually, our general philosophy is to enable the developer and monetize deployments at scale.

So, from a feature functionality perspective, we do not sort anything back. What we basically have in the community edition, developers can go freely develop anything that an Enterprise can, actually.

But where the functional feature differentiation comes in, features like security, scale, performance, because we believe those are functions of large-scale deployments – which only major, successful Enterprises will need. And that’s where we would like to monetize that.

From a sort of API level, there is nothing that you will not be able to build on a community version, which you can only build on the Enterprise.

So, I hope I clarified that nuance. Yes, there are certain pieces which are Enterprise-only, but they fall mainly under the category of security, performance and scale, and manageability – a certain amount of manageability features, because you would need that only in large deployments.

Per Server Pricing

Michael Schwartz: On the licensing side, you license per core. Is that right?

Ravi Mayuram: We license per server, and there are three – small, medium, and large, if you will, in terms of the number of cores per server.

And that’s how we tier this thing. Per core pricing is not where we start. It’s basically built on the small box of 16 cores, from 16 – 64 and above. I think that’s how we tier our pricing model of – it’s per server licensing with a number of cores, as opposed to per core.

Michael Schwartz: Is that because, for most of the Couchbase Enterprise deployments, you’re seeing dedicated servers, for this database, and not containers, or VMs, etc?

Ravi Mayuram: Basically, it becomes easier from the standpoint of people who are procuring. Even about 40% of our customers have their stuff on the cloud, even they are provisioning, based on the quantities that they can buy, which is based on 3X large, or 4X large. So it comes with a certain number of cores per server kind of notion, as opposed to core pricing.

And so that was easy to start there, so it’s easy to describe and sell that, versus how many virtual versus real. We are a little bit more in the earlier stages of the company, so we are a little bit more lax, and we would rather have option than monetize every bit of it.

Challenges Of Containerization

Michael Schwartz: Do you see any challenges though with containers and some of the elasticity as pooling up and down servers and scaling? It’s hard to know, like, how many servers or even how many cores you have, and that’s a moving target overtime? How do you deal with that?

Ravi Mayuram: Yes, I think it is a little bit of the elasticity, the core thing that has really changed, if you will, in terms of consumption models.

So, it has become sort of utility computing, and in some cases you would call it, or shows on demand pricing, and there are more ways to get to the same problem. But cloud is all about elasticity, and capacity on demand is what it comes down to.

So, yes, you will not be able to squeeze the last drop out of it, but for the most part, you can get to it through a different proxy in terms of how much the API calls, how many are actually happening, how much throughput you are getting. So that’s another proxy for exactly how many cores one CPU is using.

But, the back end of the computation is always at the CPU core level, which is another way of sort of, may be more coarse-grain, as opposed to being too fine-grain, in terms of ops per second kind of monitoring. But we can get there as well, and we will get there.

At this point, we were just skeptic, like I said, simple and coarse-grain, so it’s an easier conversation in terms of pricing and adoption, and not worrying, in terms of – it’s a little bit more wholesale than retail, if you will, so that makes it easier.

License Enforcement

Michael Schwartz: License enforcement – are you actually enforcing the license, or is it just on the honor system?

Ravi Mayuram: It’s the honor system at this point. The licensing enforcement is not there, like it is one lesson learned from the ‘90s of not doing license managers. But, there is monitoring capability, so the rest of this commercial discussion happens based on that honor system of the usage. And most enterprises are very amenable to that, and that’s why we don’t see that to be any sort of an issue.

Michael Schwartz: It’s a lesson learned from the ‘90s that the licensing server could cause an outage, and you just don’t want that?

Ravi Mayuram: Exactly.

Michael Schwartz: The last moving parts that you need in a database, from a standpoint of anything is that it can limit your ops per second, I think that is the right way to go, and not impose more software on it.

Customers Of Couchbase

Michael Schwartz: Okay, can you describe who are the customers of Couchbase?

Ravi Mayuram: Our technology, being a horizontal one, is pretty wide.

It goes all the way from financial services to eCommerce, to gaming, to streaming media, the top 10 in any of these segments. I can go on and on, in terms of areas like travel.

Six or seven major segments, in which we have the top 10 using, there are about another six or seven verticals, if you will, where the top five use this. So, you can imagine our spread in the types of use cases, as well as performance, and the scale requirements, because these are the digital leaders in their segments, so they are the ones who are in the forefront of technology.

And their demands are something that has never been met in many cases because they never have the technology to go to this global scale. There are places where there are like 1.5 billion ID’s sitting in Couchbase, servicing any touchpoint. There are places where people are doing 8 and 9 million operations per second for travel reservations and the stuff.

There are places where people are doing customer 360, where they are managing hundreds of millions of documents, which is basically the information that is coming from multitude systems in one place.

Airline reservation systems are running on Couchbase, flights cannot take off unless that transaction in that sense goes through Couchbase.

Logistics companies uses any bit of information that you’ve actually seen in terms of packing their packages runs on Couchbase. So, high volume, high transactional stuff, which is globally scaling with geo-distributed data, and guaranteed performance, whether you’re the first user or the millionth user, you get the same low-latency.

These are some of the use cases where Couchbase shines, and many, many, many mission and business-critical applications are run on Couchbase. That’s what keeps us going here, that’s what gives us all the validation for all the hard work and the deep work we do in the architecture of the product.

Is Couchbase Only An Enterprise Model?

Michael Schwartz: You know, when I hear that requirement, I almost think that it’s only a requirement that large Enterprise has. So, there’s no small businesses that need this like super high throughput and multi-data center, let’s say, redundancy, and fast-response times. So, it’s not necessarily an open source type of problem, though.

Ravi Mayuram: Actually not, I would beg to disagree.

Simply because, what has really happened, if you look, is that, back in the day, most of the systems that were built for Enterprises, small, or medium, or large, is basically for those systems to be targeted to a set of agents – who are the middlemen between the end-user and the service – to which they were the agents: A travel agent, a call center agent, or any of these agents, you can keep looking at all these agents that you’ve had in the past.

The real movement that is happening now, this is the digital transformation, we call it “disintermediation of the intermediary.”

If you look at who is doing the travel reservation, there are no more agents. It’s you and me doing the travel reservation.

So, your world is your community right now, in terms of your user base, if you will. You have a billion users who are all on the internet, on the information highway, if you want to call it. They are the ones you’re servicing. Every small business that they put their first service up, that’s why going to the cloud is important to them, because it’s got the features – it can give you the performance at scale, it can give you the reach across the globe, across different geo-centers.

So, these have become table stakes now. It is not just a requirement, which is only for the 50 companies on the top.

Every gaming company that is coming up and wants to put up its first game, they should have a hundred million users, running on their software. And you need to show the leaderboard of the Five Guys who are actually on the top of that thing – how do you get to those Five Guys a hundred million users playing the game? That is a challenge that a platform like Couchbase solves for them.

And the same thing happens across the globe in any kind of service, if you want, to small, medium, or large. Your problems are the same.

The larger enterprise is, this problem is persistent and continuous throughout the year. And the smaller ones, the span of this, maybe, they use one or two applications, but the intensity remains the same. Does it make sense?

Develop But Scale

Michael Schwartz: Yes, I guess what you’re saying is that if you’re launching a game, you start with Couchbase, and you develop it on Couchbase, and then if you need to scale it to billions, you don’t have to re-architect your application?

Ravi Mayuram: It runs on my laptop, or it runs on three nodes. That is fine as far as a developer is concerned, but seamlessly, you’d be able to scale this to 1500 and more clusters, and across three geo-centers with redundancy, and geo-distribution of data, and manage your GDPR requirements of data privacy – all that stuff with a click of a button.

So, stuff that you can do on the glass, without you ever having to go back to redesign your applications. That’s what we really built here, so that it becomes easy. Our general mantra is “develop with agility, deploy it at any scale,” anywhere, whether it be bare metal, or virtualized, or containerized, or in the cloud – all orchestrated and managed through one common infrastructure.

And I think that is what you need in this stage, because there are a lot of unknowns that are thrown in your way.

Your application can change, your deployment can change, your usage patterns change. Your data needs change, so this is the database that is built for that change, and built for a failure. Because you should be basically taken into account that when you’re running such a large-scale system, it can fail.

Your act can fail, your data-center can fail, your cell tower near you can fail. Yet, your application should be running, and be able to recover, and go back, and get the job done for you.

That is what we have, and all this with as minimal manual intervention as possible. We have automated a lot of that stuff to make the problem appear simple to the end-users, where we do sort of heavy lifting to solve difficult problems underneath the hood.

Can The Community Contribute?

Michael Schwartz: This is probably an understatement, but what you’re doing is actually very difficult. And my question is, the open source development methodology has been good for innovation, but because what you’re doing is so hard – can the open source community actually contribute in a meaningful way?

Ravi Mayuram: It’s a good question. Yes, they can in certain areas. And in certain areas, perhaps best left to the professionals.

What I mean by the code innovation in distributed computing, our code innovation in some deep areas of transaction, or multidimensional scaling that we do, those are not the areas where community can actually get in and develop some new feature.

But there are a lot of consumption-oriented stuff on this platform that needs to be built, because a database doesn’t stand alone by itself. It’s got to be in the ecosystem. There are so many tools and integrations, and all those interactions that actually have to do with the database that needs to be built.

And our client API’s, there’s a lot of stuff to be built out there, because there are so many new frameworks and paradigms coming out there. So, that’s where we find the community involvement. And by doing that, they actually enhance the core of the product, with even some code in some areas, by suggesting, “hey, how about we do this for it to be more secure, or for it to be easier and more flexible?”

So, from that experience, we learn, and the community also contributes. In some code areas, there’s less contribution, but in some of our client, and integration, and tooling areas, there is a lot of excitement from the community.

Evolution Of Monetizing Strategy

Michael Schwartz: I realize you haven’t been there since the beginning, but you’ve been there for some time. I’m wondering if it’s really hard to get the monetization strategy right for open source companies? Has there been any evolution of how to charge, or what to charge for overtime since you’ve been there?

Ravi Mayuram: Yes.The evolution basically has been in terms of bringing more capabilities into the platform and charging from the standpoint of solving tougher issues in the platform.

So, the philosophy is, bring more logic to data as opposed to moving data to logic.

This is the fundamental problem, in one sense, this platform style thinking actually solves. Which is, earlier you would have a database. Then you’ll write a connector to move this data to a search. You’ll write a connector and move this data to a warehouse. You will move this to a faster performing cache.

So you are a sort of duplicating data all over the place. And the problem with the duplication of data of course is more usage of the resources, but the bigger problem is consistency. You don’t know which is the consistent representation of the data is because you have just copied them all across.

So, in this platform, what we’ve really done is bring a key-value, a standard second index with a coding capability, with a full-on coding language. And for this, we very deliberately chose a sequel because that’s the only coding language that has withstood the test of time in the last 40 years.

And then, we added the search, which is the inverted or excel analysis base search, not the classic database type search – this is the information that will be truly sitting next to a database.

And, finally, we added the analytics piece to this one, so you can do an analysis of the data that you have in the same platform. For the first time, you can do these four things in the same platform, and workload not impeding the other – that’s what the magic is.

And, now, by doing this, what we have really done is added different types of workload underneath our platform, and so, the way we monetize this platform is by different types of workload actually running on the same platform. So that has basically been the evolution.

When we started, it was a straight-up key-value store, so you could get set, update and delete. That’s all the workload we are monetizing.

Now, we can monetize beyond that, select start from workload along with all the subqueries and SQL-92 standard queries, so you can write a serious enterprise app on top of this. And then, you can do all your faceted navigation, and search, and textual analysis. That type of application, that workload can run on the same, so you always have had this problem of trying to do, or solving a search problem away from a database problem – you don’t have to do that now.

And, finally, for all this data that are sitting in this platform, you can run your analytical query, which is a pretty heavy workload as you can imagine. And we have a query engine in the back, which is chewing through that.

In the same platform, we have workloads, which are microseconds, which is our key-value get sets, millisecond response time, which is our query. It is the same millisecond response time for our search, and finally, tenths of seconds or even hundredths of seconds, for our analytical queries, all running into the same platform, one not impeding the other.

So, kind of what we call “Hybrid Transactional Analytical System” is what this platform is.

So, how has it evolved? Different workload has been added and serviced under the same server, and so, generally, the monetization workspace on the capabilities that we have added here.

Partners

Michael Schwartz: Switching gears just a little bit, I wanted to ask about partnerships. There is technology partnerships with other vendors, but I guess I’m more interested in sort of the channel partnerships.

Has Couchbase been working on developing channel partners? And how has that worked out for you? Has it lived up to your expectations, or just, how’s it going with the partnership side?

Ravi Mayuram: We have started to build those out the last year and a half or so.

We have channel partners, we also have ISVs, and also we have the GSIs, as Global Service Integrators. These are different channels through which we are pursuing the further adoption of this.

You can see some of our partners in our sort of channels and partners website. I wouldn’t want to pick any one of them out to highlight, but we work with technology partners, we work with channel partners, we work with GSI implementers of our technology, and that’s generally our strategy.

As a platform, we need to be where, so to say, where the conversation is, and in many cases, partners are in those conversations, and we work with them to be in those conversations.

Partner Support

Michael Schwartz: Have the partners been able to take over some of the support burden from you?

Ravi Mayuram: Yes, but it’s an evolving thing, where they have been able to take on some.

I would say they have made more progress in taking on the professional services or the servicing element of it now. Eventually, they’re also getting geared up for some of these support needs, which is an automatic organic evolution from there, so those are in the stages of infancy.

History Of Couchbase

Michael Schwartz: One historical question. Couchbase, when I mention it to people, sometimes there’s some confusion around CouchDB. Can you talk a little bit about sort of the evolution of, are those project-related, or how did the name come about? Just help people understand.

Ravi Mayuram: Actually, the genesis of Couchbase is the merger of two companies, a company Membase, which was the company behind the Memcached, the open source project, and CouchOne, which was a company behind the CouchDB project.

The people that were behind the CouchDB project came over to this merged company, and they brought their ideas. So, the CouchDB was what was built earlier, that’s a separate thing. Couchbase, the code base has indigenously evolved here, a combination of what was Memcached, and eventually, what we added to that, in terms of the persistency.

That is the evolution, and at that stage then, it was a merger of two equals, Membase and CouchOne. Obviously, the name had to have both parties represented, so it became Couchbase, and since then, CouchDB vs. Couchbase has been a question in many people’s minds, but we do not share any code between these two projects.

Couchbase, if anything, has the API compatibility with Memcached protocol, and so, it’s more of the Membase interfaces, plus all the stuff that are developed on top of it.

Couchbase As A SaaS Service

Michael Schwartz: Are you thinking about launching a SaaS service, or maybe you already have a SaaS database-as-a-service?

Ravi Mayuram: We have a Couchbase managed service available, which is offered since last June timeframe or so. Database-as-a-service is an area we are really actively thinking, and it will be the right time to talk about what we’re doing there.

Open Source Strip Mining

Michael Schwartz: You surely have been following all of the sort of controversy around open source strip mining and evolution of licenses to prevent large SaaS providers like Amazon, from monetizing your hard work.

Any thoughts about sort of what’s happening there right now? Is this a good thing for open source-first SaaS providers, or is it a natural evolution?

Ravi Mayuram: I think there are few classes of open source software, and so, whatever the behemoths do, it should be consistent and fair from that standpoint.

There are open source projects which are started by communities, so there is no single company behind them that was putting the resource and money behind it to develop that, it just came about because of a set of people who started to develop something.

If they are going to monetize on that, then there should be some way to share some of bounties from there, with that community. How that can actually happen has to evolve, but that’s one set.

A company like ours, or many others out there, I recently saw news about, yet another open source-oriented company, source being formed and offered as a service.

In all these situations, it’s a question of fairness, like you say. And, yes, it’s an open source thing, but it is an open source, you should think of it as, in one sense, as an escrow of the core, with the customers who want to actually buy.

Somebody else profiting from it, without actually contributing to it is where the unfairness of it actually comes about. If that is a really clear way of contributing first before monetizing from there, I think there will be a lot less heartache, in terms of how some of these bigger companies are approaching this problem.

I would rather they all become part of this community and contribute to it, and after that, them offering some of the stuff as a service would seem fair.

Advice For Entrepreneurs

Michael Schwartz: You’ve probably talked to a number of entrepreneurs who are starting companies around open source software. What is the advice, or do you have any advice for those entrepreneurs?

Ravi Mayuram: I think there are a couple of things that any entrepreneur first has to be very focused on.

First is the problem that they’re actually trying to solve.

You have to be very close to the problem first, you have to live it, you have to understand the problem. You really need to have your value proposition in solving the problem.

Whether it is open source, or not, is a decision that you can take eventually. Because the reason why I’m saying that is that, otherwise, you get into this popularity game, and monetizing has got nothing to do with the popularity game. It’s not based on eyeball revenues, those days are over.

You need to be really solving a difficult problem in the domain that you are entering, that there is value in that.

Even if you open source stuff over there, you will not lose value in what you are actually providing. So get close to the problem, talk to the people who are living the problem, and evolve your business plan around that.

If you solve the right problem, will they hire you to solve the problem is the question you need to ask. If I build this, will they come?

If that question is answered, open versus closed, and all these are fait accompli, which will take care of themselves, and even if someone actually profits from your open source, you will profit even more. I think that’s what market’s actually treating in that way.

So, licensing, open sourcing, somebody else running your stuff – these are all the secondary issues eventually, if you solve the real problem correctly.

And of course, you have to have defensible stuff in there, in terms of what is it that you’re going to have, which is your magic sauce versus what is it that is really available. That is what really will take you to your promised land.

Closing

Michael Schwartz: Good advice, Ravi. Thank you so much for joining us today.

Ravi Mayuram: Fantastic! Thank you for having me. It was a pleasure talking to you.

Michael Schwartz: Thanks for the Couchbase team for helping to schedule with Ravi.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie.

Our audio editor is Ines Cetenji.

Our production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Follow us on Twitter. Our handle is fosspodcast.

Tune in next week for the conclusion of Season 2.

Until then, thanks for listening.