 Live from San Francisco, California, theCUBE, covering MarkLogic World 2015. Brought to you by MarkLogic. Here are your hosts, John Furrier and Jeff Kelly. Okay, welcome back everyone. We are here live in Silicon Valley. This is theCUBE, our flagship program where we go out for the events and instruct the students with noise. We are here at MarkLogic World 2015. I'm John Furrier, my co-host Jeff Kelly, data analyst, big data analyst at Wikibon, next guest at Joe Pasqua. EVP, a product at MarkLogic. Welcome back to theCUBE, good to see you. Thank you, it's great to be here. Products are everything now. So I love the product conversation because you're in a tough market of amazing challenges because you have real time, no SQL databases, the cloud, agile, DevOps, enterprise software kind of all rolled into one. So it's exciting from a product perspective. It absolutely is. But the pressure is pretty significant. It tells, what's going on with you? What's the pressure points for you guys? What are you guys rolling out as new stuff? Where's the roadmap? Lay it all out for us. So we just rolled out MarkLogic 8 at the beginning of the year. And it's been, it's our best release ever actually and hits on a lot of the areas that you were just talking about. We're having a lot of conversations with developers these days. And that was a major, major emphasis for us in MarkLogic 8. We introduced lots of new features that were specifically targeted at the developer community, including our native JSON support and JavaScript support. And that's really opened up kind of a new model for how people approach development and a new set of conversations about how to approach the full stack. And people are kind of realizing now that all of the translations that they used to go through and all the steps from the browser layer to the middleware tier layer to the database tier, all of that complication can start dissolving away because they can use the same technologies, the same data formats at every tier of their architecture. And that's kind of getting people to think in a new way. So let's unpack that a little bit. So you mentioned JSON endpoints and all that stuff. You're talking about putting data to work. That's developers have to engineer out, build out. That's mobile, that's web, right? Absolutely. And you mentioned full stack developers. So where is this coming together? Do I have to be a full stack developer to do all this work? I mean, one of the things that's coming out is abstraction. I mean, we just saw an article we just posted on SiliconANGLE today about the research came out. There's more full stack developers emerging now than ever before. What is the trend in the developer community? And what does this mean? I mean, JSON and JavaScript, this is all about web development. Right. It doesn't relate to databases and doesn't relate to like middleware. It used to not relate to them. And that was the issue, right? If you were a web developer and you're trying to sell whatever it is, a service, a product at the web tier, you were sort of operating in your own world. And then when you wanted to do anything with that data, you had to change your mindset completely to go to the middleware tier. You're doing stuff in Angular and JavaScript in the browser and you're going to the middleware tier where it's all Java and enterprise Java beans, so you have to go through a big mindset shift. And it was really hard to be a full stack developer because every layer of the stack was completely different. And then you get to the database tier and you've got to start thinking about SQL and PL SQL. And it was really hard to even have the option to be a full stack developer. Now what you can do and what you can do with MarkLogic 8 is you can do JavaScript and JSON at the web tier and mobile just like you were talking about. And then instead of having to completely change your frame of mind, now you can take those same JSON objects, the same way of thinking about things with JavaScript, do that in the middleware tier with Express and Node.js. And now with MarkLogic, you don't have to change again. You can take the same JSON objects that you had all the way back out in your mobile tier and use that same JSON data right in the database, use the same programming model with JavaScript all the way down in the database. So basically everyone's a full stack developer, just call them developers. Unless you're a UX guy and then you have great salary as well. Let me unpack that so I can tease out what it means. So what you're saying is to translate is if I'm a CIO or I'm a senior manager in IT or an enterprise, I got to hire developers and my boss is banging me on the head saying more top line revenue, get our apps mobile, cloud first, be agile, I don't want all this costs. So what you're talking about really is the perfect storm for that, right? You get the web tier which means you can hire web developers and or quote, edge of the network kind of UI guys or whatever. You have full stack capabilities unmatched before because it's all been simplified. So that's perfect for the cloud developer. So if I wanted to say I'm hiring cloud developers, that's kind of where it gets in or is it just enterprise in general? Enterprise in general, but more and more the enterprise is moving to the cloud. And what it really enables is, I don't have to be a full stack developer. I may not want to be a full stack developer. I may want to hire people with specific skills in specific areas, but what it does is it reduces the friction between those tiers. So even if I've got a bunch of guys who do my middleware and even if I've got a bunch of guys who do my database layer, they're not speaking completely different languages anymore. They don't have to invest in an entire area of technology that translates between the data and the languages at each tier. So even if they're different groups of people, it's much easier and much less friction to move between those tiers. And also the APIs are now a normal thing. Are people need APIs? Absolutely. You need to use and also make them visually head tableau on earlier, a big partner of yours. So APIs means cloud. It means DevOps. So making it easier is a critical thing. Okay, so how do you guys relate to this? Because Gary Bloom was on earlier today talking about the goodness of your stack, talking about NoSQL is a gray house with a holy grail, making unstructured data available to be stored, acted upon and implemented, operationalized, if you will. Transactional data. What does that mean for you guys from a technology perspective and to the customers? How do you build your products? What's the guiding principles? Share with the audience how you organize and how do you make it easy? Right, so we have a couple of sort of guiding principles that are fairly different from what you see in the rest of the NoSQL world. And APIs that you mentioned is a huge aspect of that. So the model that we have that's fairly different from what you see elsewhere is we fundamentally believe that the database ought to be able to provide data services. And so if I was just with the customer last week and they're saying, you know, we're building this new platform and we want to be able to provide all these services and we don't want other people mucking around with the database. We want to control what's in the database but we want to provide APIs to all of this. So their standard model is they'll do everything in a middleware tier and the other clients will come through the middleware tier and the middleware tier will talk to the database, very typical. And you can do that with MarkLogic, works great. But MarkLogic sort of fundamentally embraces the idea that there are data services that you want to be able to provide directly from the database. You don't want another tier involved. So we have the notion that you can move code, JavaScript code, for example, directly into MarkLogic and that JavaScript code can publish APIs and it can have REST APIs. Everybody's doing REST APIs these days. You can put your own REST services in MarkLogic and publish those APIs out. And that's the key because you don't want that tight coupling of those other services down to the details of what's in the database. You want to be able to publish out those services. You want everything to be API based. You want those APIs to be delivered from the cloud, from on-premise wherever you want them to be and you don't want to have to care about it. So what DevOps did for networking and infrastructure, you guys are doing for databases. That's what we want to do. We really want to bring those worlds together. You call it DevDB, I mean, DevObs, I mean. If you look at our DBAs, they are much more of the mold of ops people than DBAs. That's what they do fundamentally with MarkLogic. It's not like the SQL world where DBA is the guy who's in there, who's tuning your queries, who's doing the re-indexing. We have about a factor of one to 10 in the number of people that it takes to operate MarkLogic and those people who are mostly ops-style people rather than DBA-style people. And that's a challenge, because the DBA is like storage, by the way. EMC is going through the same transformation. See Jeremy Byrd tonight at dinner, I'm going to bring up with him, but like storage is kind of going away. Some say spinning this is going to dive before tape where flash kind of comes in, which means faster data, faster information. So the old storage guys are like stuck like this and that population is shrinking down. We think the DBA, and even Gary said, mainframe programs are still around, so I mean, I'm sure DBAs won't be extinct by any matter, but they're not going to be massively the huge population. So that being said, what is the new normal for skill set? Is it more SOAs, service-oriented architectures, dashboarding, Lego blocks? And that's obviously the future we believe in, and I think you guys do too. But how does that play out in reality? What do you see specifically out there today and how does that connect to the future? Well, I think Lego blocks goes right back to what we were talking about a second ago. The way those Lego blocks connect is through APIs. And that's what we're seeing, more and more and more organizations go to, is everything's got to be delivered through an API. That's kind of the fundamental tenet that most organizations are moving to today. So rather than a model that says, we're going to build some big monolithic application and if you want new functionality added to that application, it's much more, we're going to build things on APIs and services. Yeah, there'll be an application on top of it, but you'll be able to do mashups as well. You'll be able to take bits, put them together with APIs, and be much more helpful. You mentioned Symantec that you did some research work in security. When I hear APIs, the first thing that jumps to my mind is Swiss cheese, no perimeter, big holes. So when you move from a perimeter, Alumeo, big startup funding today, only been around for a few years, $100 million in financing, ridiculous funding, amazing amount. Speaks volumes around the perimeter's gone, cloud, right, so there's no more lock and key, no more front door, I need bodyguards on every single asset, so. The perimeter's gone, the perimeter is absolutely gone. And actually, I think that's a good thing. I think it's, I mean, it's obviously a real challenge from the security point of view, but the perimeter being gone means that you can start opening up services and being much more agile than you ever had an opportunity to be in the past. But it does mean you have to completely rethink your security model. And of course, that's key to what we do. We have security ingrained very deeply in the database, but you have to think about that at every level. So you'd love if Dave Vellante was here, Jeff, because Dave asked Pat Gelsinger years ago at VMworld, is security a do-over? And he answered, this is 2011. I think it was still EMC at the time. Yes, because Pat's bold, he makes these bold predictions. Docker kind of bit him in the butt because he predicted Docker. That containers have been around for everywhere. He changed his position on that, but he said, yes, security's a do-over, I would agree. So what makes the do-over work? I mean, we see database security at the sell level, you've got security now with virtualization. So the question is, what is the enabling technology that's going to enable a perimeter-less world so that a developer can be like, hey, I don't want to do a scheme anymore. Thanks, Mark Logic. Now what's going on with the app developer? Yeah, unfortunately, I don't think there is a technology that's going to uniformly solve that problem in the same way that we thought the firewall solved that problem previously. I think what it's going to be is a collection of techniques and approaches that are going to be applied at every layer of the architecture, and it's just not there uniformly today. There are some pieces of the system that tend to act much more like a firewall does. They really are extremely restrictive and they just kind of move the perimeter in a little bit. There are other areas where, frankly, I don't think people have realized how exposed they are, but I don't think there is a silver bullet that applies across all those ways. It's not a one-point product, you're saying. So it's going to be software or some sort of scalable compute meets intelligent, algorithmic, operating system-like code? And some of it is going to be process. Some of the biggest exposures are process exposures. And people talk about, we can't move to the cloud, it's not secure. I would say that there's good reasons for worrying about that, but at the same time, I would put up Amazon's security practices against just about anybody. They're very, very good. They do that for a living and their practices are great. And what I think some people don't realize is that it isn't just the technology piece. You can have fantastic technology and fantastic security technology. You don't configure it correctly. You don't keep it up to date. It's worthless. So talk about how much you think about the cultural and process changes that are going to have to occur in your customers to take advantage of the product features that you're looking to build. As you are building out the product, how much do you think about, well, this is going to require a seed change in terms of mindset for our customers to get the most value from the feature XYZ. Is this the right time to do it? If it is, how do we enable adoption and how do we help move that mindset so that they can actually use it and take advantage of it? Yeah, that's a great question. And Gary kind of alluded to it this morning in his keynote. There's a really big spectrum right now. Some of our customers are absolutely living in the future. They are pushing us to where they want to be and the conversations they're having about the technologies they want to embrace. I was at a customer recently and they were all over this model of full stack development and everything as an API. It is their culture. That's what they're doing. We're not pushing them, they're pushing us into the future. We've got other folks who are just at the point where they're saying, you know, I just have fundamental problems that I need to solve. I don't want to talk about changing anything else. I just want to get past the fact that I can't model my data. Help me with that. Then we'll have those other conversations. So there's a really broad spectrum of discussions that we're having everywhere from, as I said, just help us over the problem. Help us get to a schema agnostic model to I really want to do everything in JavaScript, in JSON, in the server, publishing APIs out and they're pulling us along. It's a bell curve. Most people are in the middle of that, but we absolutely have folks on both ends of that spectrum. Talk about your differentiation on the product side. Share with the folks out there. Let's use the rest of the time to really share some of the key highlights on the product platform. Why are you guys winning? What's your big lever? Where's your real differentiator? I mean, I would argue and agree with you that as you look at Amazon security practices that at some point scale is a competitive advantage which hints to the massive funding rounds for these early startups. Not just late stage funding, but combined with the fact that if they don't scale up they have no differentiation. In open source, scale is a wonderful thing, but that aside, what are you guys doing for a product differentiator statement? What's your key jewels in the kingdom? There's three things from a Phyllisot product philosophy perspective that we always focus on. The first one is, we won't do anything that compromises enterprise grade. So fundamentally the promise we make to our customers is we'll keep running, we won't lose your data. We're going to allow you to the operational flexibility that you've come to expect from the big players. That's key number one. Key number two is, you're used to all of that HADR, acid transactions from your traditional world. We're going to move you into a world that is agile, scheme agnostic, moves quick, works across any of the platforms that we were talking about from cloud to locally hosted. So you're an end-to-end platform. Schemalis? We are absolutely scheme agnostic, but we do that, there are other people who are scheme agnostic, but we do it without giving up on the enterprise features. So those two are the things that- Such as what? Such as the acid transactions, the transactionalities support, the HA support, the flexible replication options, all of those kind of enterprise grade capabilities, and then the last thing that we add to the mix is what I was kind of alluding to before. Enterprise grade, got all the agility you expect, but then we've got the power features like semantics, like by-temporal, like real-time alerting, all of the smarts that we actually put into the base. You bring the semantic web to a developer environment in an unstructured data way, right? We do. I mean, that's really what I think you guys have, right? We do that, and we can do it temporarily as well. Now- And the enterprise is very difficult with all this stuff kind of hanging around. Absolutely. So, you know, semantics, you look at the industry standard query language for semantics, it doesn't have a security model. There is no security model. So when we put that in, we had to say, okay, well, that's great, but we've got to add a security model. We're not going to release it without security. It's all semantics, as they say. It's all semantics. So final question I had to ask you, because Gary made a comment, I didn't have a chance to cycle back with him. I wanted to ask you the question. He said a comment, I want to just give you thoughts on it real quickly, it's hard to add enterprise into the product as an afterthought. Okay, you've probably heard him say that before, maybe you haven't, maybe you haven't, but you probably know what it means. Give me an example of what that means. What is adding enterprise to the product as an afterthought? He's obviously implying of enterprise washing, but what specifically is he referring to? Bolting on security? Is it other certain compliance features? What specifically do you see other competitors and other vendors adding after the fact that should be in the front end of the product roadmap? I'll just mention two very quickly. The first one is asset transactions. The basic model of how you ingest data into the system, how you do it transactually, how you do updates, that's the core of the database. That is not something you layer on top. That's extremely hard to add after the fact. And the second one, again coming from a security background is security. If you try and add a security layer on top of an existing product, you are destined to fail. There's always holes. It's much, much harder to create a solid security solution after the fact than integrating it into the fabric of the product to begin with. Because if you're doing it after the fact, you're always looking for exceptions and things that are falling through. You're chasing your tail at that point. So quick, give you the last word here. I know we're getting the hook multiple times, but I'd love to have you on. Love the product conversation. It's super fun for us. What's coming up this year? What are you working on? Share some little bit of insight if you can. You have to be specific. I know you might want to keep things confidential, but directionally, what's happening? What's going around the corner for MarkLogic? So you think about what we did in MarkLogic 8 with the emphasis on the dev side. We're going to be putting a lot of emphasis on the ops side, right? We were talking about this. It's a dev ops world, right? So we're going to continue to expand out our picture in the same kind of emphasis that we put into the dev world. We're going to put into the ops world and have a really complete dev ops model. So you can expect that coming from us. If I'm sure Gary brought this up, the vast majority of our customers today are using MarkLogic for the integration of heterogeneous data. You can expect us to be doing more to make it simpler to get that heterogeneous data into MarkLogic and get the value out of it once it's done. Take that straight jacket off the data. And free it up. Yep, yep. Okay, Joe, thanks so much for the time. We went a little over, I'm getting the hook here, but thanks so much for joining theCUBE. EVP of products here from MarkLogic, breaking it down, a great insight. Extending the conversation, and obviously join the conversation, go to crowdchat.net slash MLW15. This is theCUBE, we'll be right back with more live action in Silicon Valley at MarkLogic World 2015 after the short break.