 Live from the wigwam in Phoenix, Arizona. It's theCUBE, covering Data Platforms 2017. Brought to you by Cubel. Hey, welcome back everybody. Jeff Frick here with theCUBE. I'm joined by George Gilbert. We're at Data Platforms 2017 at the wigwam resort, just outside of Phoenix, Arizona. 200 people talking about kind of a new approach to big data and we're really excited to have David C. He's the SVP of Marketing at Quoble. Join us and tell us, David, first welcome. Thank you. Why does a world need another big data conference? It's a great question. There's obviously lots of choices, but when we went around the country and we talked to practitioners, what they told us was that a lot of the conferences that exist already are focused on a technology, Hadoop Summit or Spark Summit, right? And so they're very focused on how to learn to use a new technology. But nobody actually really addressed your data platform. And your data platform is not just about technology, it's about team and skills and culture and process. And there wasn't really a forum for guys and gals who own and run data platforms to network with their peers, to trade best practices, to talk about not just technology, but operational issues. And so we decided to fill that gap. Yeah, I love the term data ops. I don't know if you guys coined it or piggybacked on it, but DevOps has been around for a while and people kind of get it. But really some interesting presentations this morning about truly taking a data-first approach to how you transform your business. Absolutely, yeah, we're fortunate that our two co-founders built the data team at Facebook. And during the course of doing that, they had to deal with hundreds and thousands of users of their analytic infrastructure and all the way from Mark Zuckerberg on down a desire to be a data-driven enterprise. And as they went and did that, they learned a bunch of lessons. They learned how hard it was to make that happen. And in particular, there were a bunch of best practices that emerged. And then it turns out that because there were very few companies who were operating at that scale, they all got to know each other. And so LinkedIn and Twitter and eBay and Uber and a bunch of others. So all these guys started to network with each other. And interestingly enough, they all sort of came to sort of very similar conclusions about how they had to scale their infrastructure, what the best practices were. And so we took the step this past year to write a book about data ops and about the sort of organizational and cultural shift that you have to make in order to scale big data and analytics across your enterprise. Right. A lot of great questions today too were about culture and fit and changing behavior and how do you measure success? Because those things are actually harder to implement than just the technology. If you saw the keynote this morning, we really believe that complexity is just killing big data. And you see people like Gartner predicting 70% failure rates of projects. I mean, that's enormous. There's no technology or no segment of the technology business that can survive 70% project failure. And so what it means is, we have to figure out how do we solve this complexity? And in Q-Balls there's two things. There's this notion of data ops, which is how your IT organization works with the end user community. And then there's autonomous data management, which is about basically churning over a lot of the mundane work that the data team does to machines who can do it faster, better and cheaper. So let's drill sort of or peel the onion on that one. It sounds like while most of the consumer web companies that were involved in the early Hadoop related or big data related technologies and open source them, they sort of brought a new technology out to the marketplace that mainstream organizations ideally would be able to adopt. But it sounds like you looked at that and said there's a missing ingredient, which is the simplification of the admin and eventually I guess a developer experience. And that affected what you built. Absolutely. When we looked at sort of where we could help customers the most, it had to do with data teams basically playing defense all the time. What do they do? They talk around and they get workloads to run, but they're under budget pressure. They're debugging pipelines that are blowing up. They're getting yelled at because somebody's reports too slow or a dashboard didn't get updated. And what they want to do is focus on helping to create amazing business outcomes. And one of the things that I thought was interesting this morning was every speaker, whether they set it explicitly or implicitly, talked about how their data platform was a strategic mission critical asset that was central to the competitive strategy of their company. So that's what the data teams want to do and that's what they should be doing. But in order to get there, they have to get themselves out of the weeds. And there's a lot of weeds in the big data area. So what we believe is with autonomous data management, we can automate, intelligently automate and use AI and machine learning technologies to make the work of data engineering easier, faster, cheaper, better. The part that I found really powerful, I took a bunch of pictures of the slides when Ashish was talking about back in the day at Facebook. You know, there are all these groups that needed data and data support and there was his team that then had the data. It's really a service model. And we hear that a lot that IT really should be, it's a service model to their customers. And he said, it was crushing them. And to reform that, to think of the data as a platform, the data team is servicing the platform to now enable everyone to have access to the data and democratize that use was, I thought, such a great way to reframe the opportunity and the problem. Absolutely, and if you talk to the attendees at this conference or talk to people who read the book, I think they all have a very similar sort of reaction, which is, there's a bunch of sort of slightly counterintuitive behaviors, right? Like decoupling your IT team from the end users and treating the data team as sort of a platform building team that can unleash amazing efficiencies, right? And really help companies achieve what they want to with creating data insights. So if some, look, we were talking earlier about how it was roughly a year ago, we picked up the sense hard to quantify, but that everyone was like, okay, this is really complicated, let's move to the cloud and see if we can't take the burden of admin complexity off, maybe not developer complexity in. So you were building for the cloud as the platform target, and so the other main distro vendors, so now also got into high gear on building for the cloud, how were they constrained by what they started with on-prem? Yeah, and then it's a great question. It really comes down to the fact that the native architecture for on-prem and in the cloud couldn't be any more different. On-premise, you have coupled compute and storage because basically you're trying to minimize network latency, right? So you put your compute and your storage in the same place and they build a whole bunch of software to take advantage of that. In the cloud, it's the exact opposite. In the cloud, compute is expensive, but storage is super cheap, so you decouple them, right? And you build these massive data lakes on super cheap cloud storage, and then basically you only deploy compute when you have something to do with it. And the whole goal is to use the least amount of compute that you absolutely need to. So in the on-prem world, you have basically a natural level of massive over provisioning because you provisioned a peak, right? Your peak workload. And then it's a utilization game, like, okay, I've got all this dead time. How do I fill in the dead time to basically get some kind of ROI on all this money I spent building a data center? In the cloud, it's the opposite. Like I just throw all the data I can up into the cloud, whatever I need to process I use, and I just pay for literally as much compute as I need. That architectural difference means that you have sort of differences in how the software works, how the orchestration works, the techniques that you use to process data, everything changes. And so it's really hard to build for both. And anybody that tells you, oh, well, we have a hybrid system is telling you they have a least common denominator system because these things are so different, right? Well, David, unfortunately, we have to leave it there. We're on a super tight schedule. You guys have given us a ton of great guests to go through. So congratulations on a great conference and look forward to learning more. Thanks for being here. I really appreciate it. Absolutely. David C. George Gilbert, I'm Jeff Frick. You're watching theCUBE from Data Platforms 2017. We'll be back with our next guest after this short break. Thanks for watching.