 Live from Boston, Massachusetts, it's theCUBE, covering Spark Summit East 2017, brought to you by Databricks. Now, here are your hosts, Dave Vellante and George Gilbert. Back to Snowy Boston, everybody. This is theCUBE, the leader in live tech coverage. We're here at Spark Summit East. Hashtag Spark Summit, Manish Gupta is here. He's the CMO at Redis Labs. Manish, welcome to theCUBE. Thank you, good to be here. So, you know, 10 years ago, you say they're in the database business and everybody would yawn, you know. Now you're the life of the party. Yeah, the world has changed. I think the party has lots and lots of players. We are happy to be on the top of that heap. Yeah, well, it is a crowded space. So how does Redis Labs differentiate? Redis Labs is the company behind the massively popular open source Redis. And Redis became popular because of its performance, primarily, and then simplicity. The developers could very easily run up an instance of Redis, solve some very hairy problems. And it didn't, time to market was a big, big issue for them. Redis Enterprise took that forward and enabled it to be mission critical, ready for the largest of workloads, ready for things that the enterprises need in a highly distributed, clustered environment. So they have resilience and they benefit from the performance of Redis. And your claim to fame, as you say, is that top-gun performance. You guys will talk about some of the benchmarks later, but we're talking about use cases like fraud detection, as an example. Obviously, ad-serving would be another one. And, but add some color to that, if you would. Yeah, Redis is, whenever you need to make real-time real, Redis plays a very important role. It is able to deliver millions of operations per second with some millisecond latency. And that's the hallmark. Now, with data structures that comprise Redis, you can solve the problems in a way and the reason you can get the performance is because the data structures take some very complex issues and simplify the operation. Depending on the use case, you could use one of the data structures. You can mix and match the data structures. So that's the power of Redis. We used for IoT, for machine learning, for metering of billing and telecommunications environment, for personalization, for ad-serving with companies like Groupon and others, and the list goes on and on. Yeah, you've got a big list on your website of all your customers, you can check that out. So let's get the business model piece out of the way. Everybody's always fascinated. Okay, you got open source, how do you make money? How does Redis make money? Yeah, we believe strategically fostering the growth of open source is foundational in our business model and we invest heavily, both R&D and marketing, to do that. On top of that, to enable enterprise success and deployment of Redis, we have the mission critical, highly available Redis enterprise offerings. Our monetization is entirely based on the Redis enterprise platform, which takes advantage of the data structures and performance of core Redis, but layers on top management and the capabilities that make things like auto recovery, auto sharding, management, much, much easier for the enterprise. We make that available in four deployment models, which can be, the enterprise can select us Redis Cloud, which runs on a public infrastructure on any of the four major platforms. We also allow for the enterprise to select a VPC environment in their own private clouds. They can also get software and self manage that or get our software and we can manage it for them. So four deployment options are the modalities and other ways where the enterprise customers help us monetize. When you said four major platforms, you meant cloud platforms? Yeah, that's right. So AWS, your IBMs, Azure, Google and IBM. Is IBM software, it got there in the fourth, all right. That's right, all four. Go to the whip, IBM, go ahead George. So along the lines of the business model and we were sort of starting to talk about this earlier, offline, you're just one component in building an application and there's always this challenge of, well I can manage my component better than anyone else but it's got to fit with a bunch of other vendors components and how do you make that seamless to the customer so that it's not defaulting over to a cloud vendor who has to build all the components themselves to make it work together? Certainly, certainly. Database is an integral part of your stack, the application stack, but it is a stack so there are other components. Redis and Redis Labs has a very, very large ecosystem within which we operate. We work closely with others for interfaces, for connectors, for interoperability and that's a sustained environment that we invest in on a continuous basis. How do you handle application consistency? I mean, a lot of it in the NoSQL world, even in the AWS world, you hear about eventual consistency but in the real time world, you know, there's a need for more rigorous. What's your philosophy there? How do you approach that? Yeah, I think that's an issue that many NoSQL vendors have not been able to crack. Redis Labs has been at the forefront of that. We are taking an approach and we are offering what we call tunable consistency. Depending on the economics and the business model and the use case, the needs of consistency vary. In some cases, you do need immediate consistency. In other cases, you don't ever need consistency and to give that flexibility to the customer is very important. So we have taken the approach where you can go from loose consistency to what we call strong eventual consistency and that approach is based on a fairly well trusted architecture and approach called CRDT, Conflict-Free Replication Data Type and that approach allows us to, regardless of what the cluster magnitude or the distribution looks like geographically, we can deliver strong eventual consistency, which meets the needs of a majority of the customers. What do you see in terms of, there's also not discussion about asset properties and how many workloads really need that asset properties? What are you seeing now as you get more cloud native workloads and more NoSQL oriented workloads in terms of the requirement for those asset properties? Well, first of all, we truly believe and agree that not all environments required asset support. Having said that, to be a truly credible database, you must support asset and we do. Redis is asset compliant or supports asset and Redis Labs certainly supports that. Yeah, okay, so I remember I was on a stage once I'm with Kurt Monash, for sure you know Kurt, a very famous database person and he basically had a similar answer. So, but you would say that increasingly there are workloads that the growth workloads don't necessarily require that. Is that fair statement? That's a fair statement, I would say, yeah. Great, go ahead. There's a trade-off though when you talk about strong eventual consistency, potentially you have to wait for presumably a quorum of the partitions on getting really technical here, but in other words, you've got a copy of the data here. Good CMO question. Yeah, this one. But your value proposition to the customers, we get this stuff done fast. But if you have to wait for a couple other servers to make sure that they've got the update, that can slow things way down. So, how does that trade-off work? I think that's part of the power of our architecture. We have a nothing shared single proxy architecture where all of the replication, the disaster recovery and the consistency management in the backend is handled by the proxy and we ensure that the performance is not degraded when you are working through the consistency challenges. And that's where a significant amount of IP is in the development of that proxy. Okay, I'll take that as let's go into it even more offline. Well, so, and I have some other CMO questions if I may. So, a lot of young companies like yours, especially in open source world, when they go to get the word out, they rely on their community, their open source community, and that's the core and that makes a lot of sense that it's their peeps. As you become, grow more into enterprise grade apps and workloads, how do you extend beyond that? What is Redis Labs doing to sort of reach that C-suite or you're even trying to reach that C-suite, up level the messaging? How do you as a CMO deal with those challenges? Yeah, maybe I'll begin by talking about our personas that matter to us in the ecosystem. So, the enterprise level, the architects, the developers, are the primary target which we try to influence in early part of the decision cycles at the architecture level. The ultimate teams that manage, run, and operate, the infrastructure is certainly the DevOps or the operations teams and we spend time there. All along for some of the enterprise engagements, CIOs, chief data officers, and CTOs tend to play a very important role in the decisions and the selection process and so we do influence and interact with the C-suite quite heavily. What the power of the open source gives us is that groundswell of love for Redis. Literally you can walk around a developer environment such as the Spark Summit here and you'll find people wearing Redis geek shirts and we get emails from Kazakhstan and places from all over the world where we don't necessarily have sales force and requesting t-shirts, send us stickers because people love Redis and the word of mouth that ground level love for the technology enables the decisions to be so much easier and smoother. We're not convincing, it's not a philosophical battle anymore. It's simply about the use case and the solution where Redis Enterprise fits or doesn't fit. Okay, so it really is that core developer community that are your advocates and they're able to internally sell to the C-suite. A lot of times the C-suite, not the CTO so much but certainly the CIO, CTO are like, yeah, yeah, they're geeking out on some new hot thing. What's the business impact? You get that question a lot and how do you address it? I think then you get to some of the very basic tools, ROI calculators and the value proposition. For the C-level, the message is very simple. We are the least risky bet. We are the best long-term proposition and we are the best cost answer for their implementation. Particularly as the needs are increasingly becoming more real-time in nature, they are not batch processing. Yes, there will always be some of that but as the workloads are becoming, there is a need for faster processing. There is a need for quick insights and real-time is not a moniker anymore, right? Real-time truly needs to be delivered today. And so I think those three propositions for the C-suite are resonating very well. So let's talk about ROI calculators for a second. And I love talking about it because it underscores what a company feels as though it's core value proposition, isn't it? I would think with the Redis Labs, part of the value proposition is you're enabling new types of workloads and new types of, whether it's sources of revenue or productivity. And these are generally telephone numbers as compared to some of the cost savings head-to-head to your competition, which of course you want to stress as well because the CFO cares about the CAPEX. What do you emphasize in that? We don't have to get into the calculator itself but in the conceptual model, what's the emphasis? Is it on those sort of business value attributes? Is it on the sort of cost savings? How do you translate performance into that business value? I mean a lot of questions there but if you could summarize that would be great. I think you can think of it in three dimensions. The very first one is does the performance support the use case or the solution that is required? That's a very first one. The second piece that fits in and that's in our books, that's operations per second and the latency. The second piece is the cost side and that has two components to it. The first component is what are the compute requirements? So what is the infrastructure underneath that has to support it? And the efficiency that Redis and Redis Enterprise has is dramatically superior to the alternatives and so the economics show up to run a million operations per second we can do that in two nodes as opposed to our alternative which might need 15 nodes or 300 nodes and those are best possible. You can utilize your assets on the floor much better than maybe the competition. And this is where the data structures come into play quite a bit. So that's one part of the cost. The other part of the cost is the human cost. And because this goes back to the open source because the people are available with the talent and the competency and appreciation for Redis it's easy to procure those people and your cost of acquisition and deploying goes down quite a bit. So there's a human cost to it. The third dimension to this whole equation is time to market. And time to market is measured in many ways is a lost revenue if it takes you longer to get there. And Redis consistently from multiple analyst reports gets top ranking for fastest way to get to market because of how simple it is. Beyond performance, simplicity is a second hallmark. So that's a benefit acceleration and you can quantify that. Absolutely, absolutely. And that's a revenue parameter, right? Right, awesome. You know, for years people have been saying this Cambrian explosion of databases is unsustainable and sort of in response we've gotten a square of that Cambrian explosion. The question is with your sort of very flexible I don't want to get too geeky because Dave will cut me off. But you know the idea that you can accommodate time series and all these different ways of all these different types of data. Are we approaching a situation where customers can start consolidating their database choices and have fewer vendors fewer products in their landscape? I think not only are we getting there but we must get there. You know, you've got over 300 databases in the marketplace and imagine a CIO or an architect trying to have a sort through that to make a decision. It's difficult and you certainly cannot support it from a trading standpoint or from an investment CapEx and Alpec standpoint. What we have done with Redis is introduce something called Redis modules. We did that at the last Redis Conf in Maine, San Francisco. And the Redis module is a very simple concept but a very powerful concept. It's an API which can be utilized to take an existing development effort written as CC++ that can be ported onto the Redis data structures. This gives you the flexibility without having to reinvent the wheel every single time to take that investment ported on top of Redis and you get the performance and you can make now Redis becomes a multi-model database. And I'm going to get to your answer of how do you address the multiple needs so you don't need multiple databases. So to give you some examples, since the introduction of Redis modules we have now over 50 modules that have been published by a variety of places, not just Redis labs to indicate how simple and how powerful this model is. We took Lucene and developed the world's fastest full-text search engine as a module. We have very recently introduced Redis machine learning as a module that works with Spark ML and serves as a great serving layer in the machine learning domain. Just two very simple examples but work that's been done ported over onto Redis data structures and now you have ability to do some very powerful things because of what Redis is. And this is the way the future is going to be. I think every database is trying to offer multi-functionality to be multi-model in nature but instead of doing it one step at a time this approach gives us the ability to leverage the entire ecosystem. Again, if your point being consolidation is inevitable in this business as well. Architectural consolidation. Yes, but also we would think company consolidation, isn't that going to follow? I mean, what do you make of the market? And Tim, if you look back in the database market and what Oracle was able to achieve in the face of, maybe not as many players but you had CyBase and Informix and certainly DB2 still around and SQL service still around but Oracle won. And maybe it was SQL standards that it's great to be lucky and good. Can we learn from that or is this a whole different world? Are there similarities and how do you see that consolidation potentially shaking out if you agree that there will be consolidation? Yeah, there has to be first and foremost an architectural approach that solves the OPEX, CAPEX challenge for the enterprise, right? But beyond that, no industry can sustain the diversity and the fragmentation that exists in the database world. I think there will always be new things coming out of universities particularly. There's great innovation and research happening and that is required to augment. But at the end of the day, the commercial enterprises cannot be of the fragmented volume that we have today in the database world. So there is going to be some consolidation and it's not unnatural. I think it's natural, it's expected. Time will tell what that looks like. We've seen some of our competitors acquire smaller companies to add graph functionality, to add search for functionality. We just don't think that's the level of consolidation that really moves the needle for the industry. It's got to be at a higher level of consolidation. And is, I don't want to, I'll take this the wrong way. I don't hate me for saying it but is Oracle the sort of the enemy? If I can say that, I mean it's like, no. I mean, depends how you define the term. You know what I mean by that. You mean by that is that I'm not going to go do many of the workloads that you're talking about on Oracle, despite what Larry tells me at Oracle Open Worlds. And I'm not going to make Oracle my choice for many of the workloads that you guys are working on. And so, I guess in terms, I mean everybody who's at the database business looks at that and say, hey, we can do it cheaper, better, you know, more productively. But if you'd respond to that and what do you make of Amazon's moves in the database world, is that concern you? Yeah, you know, we think of Amazon and Oracle as two very different philosophies, right? If you can use the word. The approach we have taken is really a forward-looking approach in philosophy. We believe that the needs of the market need to be solved in new ways. And new ways should not be encumbered by old approaches. So we're not trying to go and replicate what was done in the SQL world or in a relational database world. Our approach is how do you deliver a multi-model database that has the real-time attribute attached to it in a way that requires very limited compute horsepower and very few resources to manage, right? So you take all of those things as kind of the core philosophy, which is a forward-looking philosophy. We are definitely not trying to replicate what an Oracle needs to be. Now AWS, I think, is a very different animal. They have defined the cloud and I think play a very important role. We are a strong partner of theirs. Much of our traffic runs on AWS infrastructure, certainly also in other clouds. I think AWS is one to watch and how they evolve. They have database offerings, including Redis offerings. However, we fully recognize, and the industry recognizes, that that's not to the same capability as Redis Enterprise. It's open-source Redis managed by AWS and that's fine as a cache, but you cannot persist. And you really cannot have a multi-model capability that's a full database in that approach. And you're in the marketplace? We are in the marketplace. And actually, we announced earlier a few weeks ago that you can buy and get Redis Cloud Access, which is Redis Enterprise Cloud, on AWS through the integrated billing approach on the marketplace. So you can have an AWS account and get our service, the true Redis Enterprise service. Right, and as a software company, you figure, okay, the cloud infrastructure is a service, we don't care what infrastructure runs on, whatever the customer wants, but you see AWS making these moves up market, you got to obviously be paying attention to that. Certainly, certainly, certainly. Go ahead, last question. Yeah, interesting that you were saying that to solve this problem of proliferation of choice, it has to be multi-model with speed and low resource requirement. If I were to interpret that from an old-style database perspective, it would be, you're going to get, the multi-model is something you are addressing now with the extensibility, but the speed means taking out that abstraction layer that was the query optimizer, sort of and working almost at the storage layer or having an option to do that. Would that be a fair way to say it? No, I don't think that necessarily needs to be the case. For us, speed translates from the simplicity and the power of the data structures. And so instead of having to serialize, deserialize before you process data in a Spark context, or instead of having to look for data that is perhaps not put in sorted sets for a use case that you might be doing and running a query on, if the data is already handled through one of the data structures, you now have a much faster query time. You now have the ability to reach the data in the right approach. And again, this is no sequel, right? So it's a schema less on right, and it's your schema as you want it to be on read. We marry that with the data structures, and that gives you the ultimate speed. All right, we have to leave it there, but Minish, I'll give you the last word. Things we should be paying attention to for Redis Labs this year, events, announcements, what are we? I think the big thing I would leave the audience with is RedisCon 2017. It's May 31st to June 2nd in San Francisco. We are expecting over 1,000 people. The brightest minds around Redis and the database world will be there. And anybody who is considering deploying the next generation database should attend. Where are you doing that? It's at the Marriott Marquis in San Francisco. Great. Is that on Howard Street? That will cross from the- It is right across from Moscone. Great, awesome location, because easy people know it, easy to get through. Good. Well, congratulations on the success. We'll be looking for outputs from that event, and hope to see you again on theCUBE. Thank you, enjoy the conversation. All right, good. Keep right there, everybody. We'll be back with our next guest. This is theCUBE, we're live from Spark Summit East. Right back.