>> from Cambridge, Massachusetts. It's the Cube covering M I T. Chief data officer and information quality Symposium 2019. Brought to you by Silicon Angle Media. >> Welcome back to Cambridge, Massachusetts. Everybody, You're watching the Cube, the leader in live tech coverage, and we're covering the M I t CDO conference M I t. CDO. My name is David Monty in here with my co host, Paul Galen. Mike Stone breakers here. The legend is founder CTO of Of Tamer, as well as many other companies. Inventor Michael. Thanks for coming back in the Cube. Good to see again. Nice to be here. So this is kind of ah, repeat pattern for all of us. We kind of gather here in August that the CDO conference You're always the highlight of the show. You gave a talk this week on the top 10. Big data mistakes. You and I are one of the few. You were the few people who still use the term big data. I happen to like it. Sad that it's out of vogue already, but people associated with the doo doop it's kind of waning, but regardless, so welcome. How'd the talk go? What were you talking about. >> So I talked to a lot of people who were doing analytics. We're doing operation Offer operational day of data at scale, and they always make most of them make a collection of bad mistakes. And so the talk waas a litany of the blunders that I've seen people make, and so the audience could relate to the blunders about most. Most of the enterprise is represented. Make a bunch of the blunders. So I think no. One blunder is not planning on moving most everything to the cloud. >> So that's interesting, because a lot of people would would would love to debate that, but and I would imagine you probably could have done this 10 years ago in a lot of the blunders would be the same, but that's one that wouldn't have been there. But so I tend to agree. I was one of the two hands that went up this morning, and vocalist talk when he asked, Is the cloud cheaper for us? It is anyway. But so what? Why should everybody move everything? The cloud aren't there laws of physics, laws of economics, laws of the land that suggest maybe you >> shouldn't? Well, I guess 22 things and then a comment. First thing is James Hamilton, who's no techies. Techie works for Amazon. We know James. So he claims that he could stand up a server for 25% of your cost. I have no reason to disbelieve him. That number has been pretty constant for a few years, so his cost is 1/4 of your cost. Sooner or later, prices are gonna reflect costs as there's a race to the bottom of cloud servers. So >> So can I just stop you there for a second? Because you're some other date on that. All you have to do is look at a W S is operating margin and you'll see how profitable they are. They have software like economics. Now we're deploying servers. So sorry to interrupt, but so carry. So >> anyway, sooner or later, they're gonna have their gonna be wildly cheaper than you are. The second, then yet is from Dave DeWitt, whose database wizard. And here's the current technology that that Microsoft Azure is using. As of 18 months ago, it's shipping containers and parking lots, chilled water in power in Internet, Ian otherwise sealed roof and walls optional. So if you're doing raised flooring in Cambridge versus I'm doing shipping containers in the Columbia River Valley, who's gonna be a lot cheaper? And so you know the economies of scale? I mean, that, uh, big, big cloud guys are building data centers as fast as they can, using the cheapest technology around. You put up the data center every 10 years on dhe. You do it on raised flooring in Cambridge. So sooner or later, the cloud guys are gonna be a lot cheaper. And the only thing that isn't gonna the only thing that will change that equation is For example, my lab is up the street with Frank Gehry building, and we have we have an I t i t department who runs servers in Cambridge. Uh, and they claim they're cheaper than the cloud. And they don't pay rent for square footage and they don't pay for electricity. So yeah, if if think externalities, If there are no externalities, the cloud is assuredly going to be cheaper. And then the other thing is that most everybody tonight that I talk thio including me, has very skewed resource demands. So in the cloud finding three servers, except for the last day of the month on the last day of the month. I need 20 servers. I just do it. If I'm doing on Prem, I've got a provision for peak load. And so again, I'm just way more expensive. So I think sooner or later these combinations of effects was going to send everybody to the cloud for most everything, >> and my point about the operating margins is difference in price and cost. I think James Hamilton's right on it. If he If you look at the actual cost of deploying, it's even lower than the price with the market allows them to their growing at 40 plus percent a year and a 35 $40,000,000,000 run rate company sooner, Sooner or >> later, it's gonna be a race to the lot of you >> and the only guys are gonna win. You have guys have the best cost structure. A >> couple other highlights from your talk. >> Sure, I think 2nd 2nd thing like Thio Thio, no stress is that machine learning is going to be a game is going to be a game changer for essentially everybody. And not only is it going to be autonomous vehicles. It's gonna be automatic. Check out. It's going to be drone delivery of most everything. Uh, and so you can, either. And it's gonna affect essentially everybody gonna concert of, say, categorically. Any job that is easy to understand is going to get automated. And I think that's it's gonna be majorly impactful to most everybody. So if you're in Enterprise, you have two choices. You can be a disrupt or or you could be a disruptive. And so you can either be a taxi company or you can be you over, and it's gonna be a I machine learning that's going going to be determined which side of that equation you're on. So I was a big blunder that I see people not taking ml incredibly seriously. >> Do you see that? In fact, everyone I talked who seems to be bought in that this is we've got to get on the bandwagon. Yeah, >> I'm just pointing out the obvious. Yeah, yeah, I think, But one that's not quite so obvious you're is a lot of a lot of people I talked to say, uh, I'm on top of data science. I've hired a group of of 10 data scientists, and they're doing great. And when I talked, one vignette that's kind of fun is I talked to a data scientist from iRobot, which is the guys that have the vacuum cleaner that runs around your living room. So, uh, she said, I spend 90% of my time locating the data. I want to analyze getting my hands on it and cleaning it, leaving the 10% to do data science job for which I was hired. Of the 10% I spend 90% fixing the data cleaning errors in my data so that my models work. So she spends 99% of her time on what you call data preparation 1% of her time doing the job for which he was hired. So data science is not about data science. It's about data integration, data cleaning, data, discovery. >> But your new latest venture, >> so tamer does that sort of stuff. And so that's But that's the rial data science problem. And a lot of people don't realize that yet, And, uh, you know they will. I >> want to ask you because you've been involved in this by my count and starting up at least a dozen companies. Um, 99 Okay, It's a lot. >> It's not overstated. You estimated high fall. How do you How >> do you >> decide what challenge to move on? Because they're really not. You're not solving the same problems. You're You're moving on to new problems. How do you decide? What's the next thing that interests you? Enough to actually start a company. Okay, >> that's really easy. You know, I'm on the faculty of M i t. My job is to think of news new ship and investigate it, and I come up. No, I'm paid to come up with new ideas, some of which have commercial value, some of which don't and the ones that have commercial value, like, commercialized on. So it's whatever I'm doing at the time on. And that's why all the things I've commercialized, you're different >> s so going back to tamer data integration platform is a lot of companies out there claim to do it day to get integration right now. What did you see? What? That was the deficit in the market that you could address. >> Okay, great question. So there's the traditional data. Integration is extract transforming load systems and so called Master Data management systems brought to you by IBM in from Attica. Talent that class of folks. So a dirty little secret is that that technology does not scale Okay, in the following sense that it's all well, e t l doesn't scale for a different reason with an m d l e t l doesn't scale because e t. L is based on the premise that somebody really smart comes up with a global data model For all the data sources you want put together. You then send a human out to interview each business unit to figure out exactly what data they've got and then how to transform it into the global data model. How to load it into your data warehouse. That's very human intensive. And it doesn't scale because it's so human intensive. So I've never talked to a data warehouse operator who who says I integrate the average I talk to says they they integrate less than 10 data sources. Some people 20. If you twist my arm hard, I'll give you 50. So a Here. Here's a real world problem, which is Toyota Motor Europe. I want you right now. They have a distributor in Spain, another distributor in France. They have a country by country distributor, sometimes canton by Canton. Distribute distribution. So if you buy a Toyota and Spain and move to France, Toyota develops amnesia. The French French guys know nothing about you. So they've got 250 separate customer databases with 40,000,000 total records in 50 languages. And they're in the process of integrating that. It was single customer database so that they can Duke custom. They could do the customer service we expect when you cross cross and you boundary. I've never seen an e t l system capable of dealing with that kind of scale. E t l dozen scale to this level of problem. >> So how do you solve that problem? >> I'll tell you that they're a tamer customer. I'll tell you all about it. Let me first tell you why MGM doesn't scare. >> Okay. Great. >> So e t l says I now have all your data in one place in the same format, but now you've got following problems. You've got a d duplicated because if if I if I bought it, I bought a Toyota in Spain, I bought another Toyota in France. I'm both databases. So if you want to avoid double counting customers, you got a dupe. Uh, you know, got Duke 30,000,000 records. And so MGM says Okay, you write some rules. It's a rule based technology. So you write a rule. That's so, for example, my favorite example of a rule. I don't know if you guys like to downhill downhill skiing, All right? I love downhill skiing. So ski areas, Aaron, all kinds of public databases assemble those all together. Now you gotta figure out which ones are the same the same ski area, and they're called different names in different addresses and so forth. However, a vertical drop from bottom to the top is the same. Chances are they're the same ski area. So that's a rule that says how to how to put how to put data together in clusters. And so I now have a cluster for mount sanity, and I have a problem which is, uh, one address says something rather another address as something else. Which one is right or both? Right, so now you want. Now you have a gold. Let's call the golden Record problem to basically decide which, which, which data elements among a variety that maybe all associated with the same entity are in fact correct. So again, MDM, that's a rule's a rule based system. So it's a rule based technology and rule systems don't scale the best example I can give you for why Rules systems don't scale. His tamer has another customer. General Electric probably heard of them, and G wanted to do spend analytics, and so they had 20,000,000 spend transactions. Frank the year before last and spend transaction is I paid $12 to take a cab from here here to the airport, and I charged it to cost center X Y Z 20,000,000 of those so G has a pre built classification system for spend, so they have parts and underneath parts or computers underneath computers and memory and so forth. So pre existing preexisting class classifications for spend they want to simply classified 20,000,000 spent transactions into this pre existing hierarchy. So the traditional technology is, well, let's write some rules. So G wrote 500 rules, which is about the most any single human I can get there, their arms around so that classified 2,000,000 of the 20,000,000 transactions. You've now got 18 to go and another 500 rules is not going to give you 2,000,000 more. It's gonna give you love diminishing returns, right? So you have to write a huge number of rules and no one can possibly understand. So the technology simply doesn't scale, right? So in the case of G, uh, they had tamer health. Um, solve this. Solved this classification problem. Tamer used their 2,000,000 rule based, uh, tag records as training data. They used an ML model, then work off the training data classifies remaining 18,000,000. So the answer is machine learning. If you don't use machine learning, you're absolutely toast. So the answer to MDM the answer to MGM doesn't scale. You've got to use them. L The answer to each yell doesn't scale. You gotta You're putting together disparate records can. The answer is ml So you've got to replace humans by machine learning. And so that's that seems, at least in this conference, that seems to be resonating, which is people are understanding that at scale tradition, traditional data integration, technology's just don't work >> well and you got you got a great shot out on yesterday from the former G S K Mark Grams, a leader Mark Ramsay. Exactly. Guys. And how they solve their problem. He basically laid it out. BTW didn't work and GM didn't work, All right. I mean, kick it, kick the can top down data modelling, didn't work, kicked the candid governance That's not going to solve the problem. And But Tamer did, along with some other tooling. Obviously, of course, >> the Well, the other thing is No. One technology. There's no silver bullet here. It's going to be a bunch of technologies working together, right? Mark Ramsay is a great example. He used his stream sets and a bunch of other a bunch of other startup technology operating together and that traditional guys >> Okay, we're good >> question. I want to show we have time. >> So with traditional vendors by and large or 10 years behind the times, And if you want cutting edge stuff, you've got to go to start ups. >> I want to jump. It's a different topic, but I know that you in the past were critic of know of the no sequel movement, and no sequel isn't going away. It seems to be a uh uh, it seems to be actually gaining steam right now. What what are the flaws in no sequel? It has your opinion changed >> all? No. So so no sequel originally meant no sequel. Don't use it then. Then the marketing message changed to not only sequel, So sequel is fine, but no sequel does others. >> Now it's all sequel, right? >> And my point of view is now. No sequel means not yet sequel because high level language, high level data languages, air good. Mongo is inventing one Cassandra's inventing one. Those unless you squint, look like sequel. And so I think the answer is no sequel. Guys are drifting towards sequel. Meanwhile, Jason is That's a great idea. If you've got your regular data sequel, guys were saying, Sure, let's have Jason is the data type, and I think the only place where this a fair amount of argument is schema later versus schema first, and I pretty much think schema later is a bad idea because schema later really means you're creating a data swamp exactly on. So if you >> have to fix it and then you get a feel of >> salary, so you're storing employees and salaries. So, Paul salaries recorded as dollars per month. Uh, Dave, salary is in euros per week with a lunch allowance minds. So if you if you don't, If you don't deal with irregularities up front on data that you care about, you're gonna create a mess. >> No scheme on right. Was convenient of larger store, a lot of data cheaply. But then what? Hard to get value out of it created. >> So So I think the I'm not opposed to scheme later. As long as you realize that you were kicking the can down the road and you're just you're just going to give your successor a big mess. >> Yeah, right. Michael, we gotta jump. But thank you so much. Sure appreciate it. All right. Keep it right there, everybody. We'll be back with our next guest right into the short break. You watching the cue from M i t cdo Ike, you right back

>> (bright music) >> Narrator: The Cube, presents Kubecon and Cloudnativecon, year of 2022, brought to you by Red Hat, the cloud native computing foundation and its ecosystem partners. >> Now what we're opening. Welcome to Valencia, Spain in Kubecon Cloudnativecon, Europe, 2022. I'm Keith Townsend, along with my host, Paul Gillin, who is the senior editor for architecture at Silicon angle, Paul. >> Keith you've been asking me questions all these last two days. Let me ask you one. You're a traveling man. You go to a lot of conferences. What's different about this one. >> You know what, we're just talking about that pre-conference, open source conferences are usually pretty intimate. This is big. 7,500 people talking about complex topics, all in one big area. And then it's, I got to say it's overwhelming. It's way more. It's not focused on a single company's product or messaging. It is about a whole ecosystem, very different show. >> And certainly some of the best t-shirts I've ever seen. And our first guest, Jim has one of the better ones. >> I mean a bit cockroach come on, right. >> Jim Walker, principal product evangelist at CockroachDB and Christian Huning, tech director of cloud technologies at Finleap Connect, a financial services company that's based out of Germany, now offering services in four countries now. >> Basically all over Europe. >> Okay. >> But we are in three countries with offices. >> So you're CockroachDB customer and I got to ask the obvious question. Databases are hard and started the company in 2015 CockroachDB, been a customer since 2019, I understand. Why take the risk on a four year old database. I mean that just sounds like a world of risk and trouble. >> So it was in 2018 when we joined the company back then and we did this cloud native transformation, that was our task basically. We had very limited amount of time and we were faced with a legacy infrastructure and we needed something that would run in a cloud native way and just blend in with everything else we had. And the idea was to go all in with Kubernetes. Though early days, a lot of things were alpha beta, and we were running on mySQL back then. >> Yeah. >> On a VM, kind of small setup. And then we were looking for something that we could just deploy in Kubernetes, alongside with everything else. And we had to stack and we had to duplicate it many times. So also to maintain that we wanted to do it all the same like with GitOps and everything and Cockroach delivered that proposition. So that was why we evaluate the risk of relatively early adopting that solution with the proposition of having something that's truly cloud native and really blends in with everything else we do in the same way was something we considered, and then we jumped the leap of faith and >> The fin leap of faith >> The fin leap of faith. Exactly. And we were not dissatisfied. >> So talk to me a little bit about the challenges because when we think of MySQL, MySQL scales to amazing sizes, it is the de facto database for many cloud based architectures. What problems were you running into with MySQL? >> We were running into the problem that we essentially, as a finTech company, we are regulated and we have companies, customers that really value running things like on-prem, private cloud, on-prem is a bit of a bad word, maybe. So it's private cloud, hybrid cloud, private cloud in our own data centers in Frankfurt. And we needed to run it in there. So we wanted to somehow manage that and with, so all of the managed solution were off the table, so we couldn't use them. So we needed something that ran in Kubernetes because we only wanted to maintain Kubernetes. We're a small team, didn't want to use also like full blown VM solution, of sorts. So that was that. And the other thing was, we needed something that was HA distributable somehow. So we also looked into other solutions back at the time, like Vitis, which is also prominent for having a MySQL compliant interface and great solution. We also got into work, but we figured, this is from the scale, and from the sheer amount of maintenance it would need, we couldn't deliver that, we were too small for that. So that's where then Cockroach just fitted in nicely by being able to distribute BHA, be resilient against failure, but also be able to scale out because we had this problem with a single MySQL deployment to not really, as it grew, as the data amounts grew, we had trouble to operatively keep that under control. >> So Jim, every time someone comes to me and says, I have a new database, I think we don't need it, yet another database. >> Right. >> What problem, or how does CockroachDB go about solving the types of problems that Christian had? >> Yeah. I mean, Christian laid out why it exists. I mean, look guys, building a database isn't easy. If it was easy, we'd have a database for every application, but you know, Michael Stonebraker, kind of godfather of all database says it himself, it takes seven, eight years for a database to fully gestate to be something that's like enterprise ready and kind of, be relied upon. We've been billing for about seven, eight years. I mean, I'm thankful for people like Christian to join us early on to help us kind of like troubleshoot and go through some things. We're building a database, it's not easy. You're right. But building a distributor system is also not easy. And so for us, if you look at what's going on in just infrastructure in general, what's happening in Kubernetes, like this whole space is Kubernetes. It's all about automation. How do I automate scale? How do I automate resilience out of the entire equation of what we're actually doing? I don't want to have to think about active passive systems. I don't want to think about sharding a database. Sure you can scale MySQL. You know, how many people it takes to run three or four shards of MySQL database. That's not automation. And I tell you what, this world right now with the advances in data how hard it is to find people who actually understand infrastructure to hire them. This is why this automation is happening, because our systems are more complex. So we started from the very beginning to be something that was very different. This is a cloud native database. This is built with the same exact principles that are in Kubernetes. In fact, like Kubernetes it's kind of a spawn of borg, the back end of Google. We are inspired by Spanner. I mean, this started by three engineers that worked at Google, are frustrated, they didn't have the tools, they had at Google. So they built something that was, outside of Google. And how do we give that kind of Google like infrastructure for everybody. And that's, the advent of Cockroach and kind of why we're doing, what we're doing. >> As your database has matured, you're now beginning a transition or you're in a transition to a serverless version. How are you doing that without disrupting the experience for existing customers? And why go serverless at all? >> Yeah, it's interesting. So, you know, serverless was, it was kind of a an R&D project for us. And when we first started on a path, because I think you know, ultimately what we would love to do for the database is let's not even think about database, Keith. Like, I don't want to think about the database. What we're building too is, we want a SQL API in the cloud. That's it. I don't want to think about scale. I don't want to think about upgrades. I literally like. that stuff should just go away. That's what we need, right. As developers, I don't want to think about isolation levels or like, you know, give me DML and I want to be able to communicate. And for us the realization of that vision is like, if we're going to put a database on the planet for everybody to actually use it, we have to be really, really efficient. And serverless, which I believe really should be infrastructure less because I don't think we should be thinking of just about service. We got to think about, how do I take the context of regions out of this thing? How do I take the context of cloud providers out of what we're talking about? Let's just not think about that. Let's just code against something. Serverless was the answer. Now we've been building for about a year and a half. We launched a serverless version of Cockroach last October and we did it so that everybody in the public could have a free version of a database. And that's what serverless allows us to do. It's all consumption based up to certain limits and then you pay. But I think ultimately, and we spoke a little bit about this at the very beginning. I think as ISVs, people who are building software today the serverless vision gets really interesting because I think what's on the mind of the CTO is, how do I drive down my cost to the cloud provider? And if we can basically, drive down costs through either making things multi-tenant and super efficient, and then optimizing how much compute we use, spinning things down to zero and back up and auto scaling these sort of things in our software. We can start to make changes in the way that people are thinking about spend with the cloud provider. And ultimately we did that, so we could do things for free. >> So, Jim, I think I disagree Christian, I'm sorry, Jim. I think I disagree with you just a little bit. Christian, I think the biggest challenge facing CTOs are people. >> True. >> Getting the people to worry about cost and spend and implementation. So as you hear the concepts of CoachDB moving to a serverless model, and you're a large customer how does that make you think or react to your people side of your resources? >> Well, I can say that from the people side of resources luckily Cockroach is our least problem. So it just kind of, we always said, it's an operator stream because that was the part that just worked for us, so. >> And it's worked as you have scaled it? without you having ... >> Yeah. I mean, we use it in a bit of a, we do not really scale out like the Cockroach, like really large. It's like, more that we use it with the enterprise features of encryption in the stack and our customers then demand. If they do so, we have the Zas offering and we also do like dedicated stacks. So by having a fully cloud native solution on top of Kubernetes, as the foundational layer we can just use that and stamp it out and deploy it. >> How does that translate into services you can provide your customers? Are there services you can provide customers that you couldn't have, if you were running, say, MySQL? >> No, what we do is, we run this, so the SAS offering runs in our hybrid private cloud. And the other thing that we offer is that we run the entire stack at a cloud provider of their choosing. So if they are an AWS, they give us an AWS account, we put it in there. Theoretically, we could then also talk about using the serverless variant, if they like so, but it's not strictly required for us. >> So Christian, talk to me about that provisioning process because if I had a MySQL deployment before I can imagine how putting that into a cloud native type of repeatable CICD pipeline or Ansible script that could be difficult. Talk to me about that. How CockroachDB enables you to create new onboarding experiences for your customers? >> So what we do is, we use helm charts all over the place as probably everybody else. And then each application team has their parts of services, they've packaged them to helm charts, they've wrapped us in a super chart that gets wrapped into the super, super chart for the entire stack. And then at the right place, somewhere in between Cockroach is added, where it's a dependency. And as they just offer a helm chart that's as easy as it gets. And then what the teams do is they have an inner job, that once you deploy all that, it would spin up. And as soon as Cockroach is ready it's just the same reconcile loop as everything. It will then provision users, set up database schema, do all that. And initialize, initial data sets that might be required for a new setup. So with that setup, we can spin up a new cluster and then deploy that stack chart in there. And it takes some time. And then it's done. >> So talk to me about life cycle management. Because when I have one database, I have one schema. When I have a lot of databases I have a lot of different schemas. How do you keep your stack consistent across customers? >> That is basically part of the same story. We have get offs all over the place. So we have this repository, we see the super helm chart versions and we maintain like minus three versions and ensure that we update the customers and keep them up to date. It's part of the contract sometimes, down to the schedule of the customer at times. And Cockroach nicely supports also, these updates with these migrations in the background, the schema migrations in the background. So we use in our case, in that integration SQL alchemy, which is also nicely supported. So there was also part of the story from MySQL to Postgres, was supported by the ORM, these kind of things. So the skill approach together with the ease of helm charts and the background migrations of the schema is a very seamless upgrade operations. Before that we had to have downtime. >> That's right, you could have online schema changes. Upgrading the database uses the same concept of rolling upgrades that you have in Kubernetes. It's just cloud native. It just fits that same context, I think. >> Christian: It became a no-brainer. >> Yeah. >> Yeah. >> Jim, you mentioned the idea of a SQL API in the cloud, that's really interesting. Why does such a thing not exist? >> Because it's really difficult to build. You know, SQL API, what does that mean? Like, okay. What I'm going to, where does that endpoint live? Is there one in California one on the east coast, one in Europe, one in Asia? Okay. And I'm asking that endpoint for data. Where does that data live? Can you control where data lives on the planet? Because ultimately what we're fighting in software today in a lot of these situations is the speed of light. And so how do you intelligently place data on this planet? So that, you know, when you're asking for data, when you're maybe home, it's a different latency than when you're here in Valencia. Does that data follow and move you? These are really, really difficult problems to solve. And I think that we're at that layer of, we're at this moment in time in software engineering, we're solving some really interesting, interesting things cause we are budding against this speed of light problem. And ultimately that's one of the biggest challenges. But underneath, it has to have all this automation like the ease at which we can scale this database like the always on resilient, the way that we can upgrade the entire thing with just rolling upgrades. The cloud native concepts is really what's enabling us to do things at global scale it's automation. >> Let's alk about that speed of light in global scale. There's no better conference for speed of light, for scale, than Kubecon. Any predictions coming out of the show? >> It's less a prediction for me and more of an observation, you guys. Like look at two years ago, when we were here in Barcelona at QCon EU, it was a lot of hype. It's a lot of hype, a lot of people walking around, curious, fascinated, this is reality. The conversations that I'm having with people today, there's a reality. There's people really doing, they're becoming cloud native. And to me, I think what we're going to see over the next two to three years is people start to adopt this kind of distributed mindset. And it permeates not just within infrastructure but it goes up into the stack. We'll start to see much more developers using, Go and these kind of the threaded languages, because I think that distributed mindset, if it starts at the chip all the way to the fingertip of the person clicking and you're distributed everywhere in between. It is extremely powerful. And I think that's what Finleap, I mean, that's exactly what the team is doing. And I think there's a lot of value and a lot of power in that. >> Jim, Christian, thank you so much for coming on the Cube and sharing your story. You know what we're past the hype cycle of Kubernetes, I agree. I was a nonbeliever in Kubernetes two, three years ago. It was mostly hype. We're looking at customers from Microsoft, Finleap and competitors doing amazing things with this platform and cloud native in general. Stay tuned for more coverage of Kubecon from Valencia, Spain. I'm Keith Townsend, along with Paul Gillin and you're watching the Cube, the leader in high tech coverage. (bright music)

(upbeat music playing) >> Welcome to theCUBE's coverage of Couchbase ConnectONLINE Mary Roth, VP of Engineering Operations with Couchbase is here for Couchbase ConnectONLINE. Mary. Great to see you. Thanks for coming on remotely for this segment. >> Thank you very much. It's great to be here. >> Love the fire in the background, a little fireside chat here, kind of happening, but I want to get into it because, Engineering and Operations with the pandemic has really kind of shown that, engineers and developers have been good, working remotely for a while, but for the most part it's impacted companies in general, across the organizations. How did the Couchbase engineering team adapt to the remote work? >> Great question. And I actually think the Couchbase team responded very well to this new model of working imposed by the pandemic. And I have a unique perspective on the Couchbase journey. I joined in February, 2020 after 20 plus years at IBM, which had embraced a hybrid, in-office remote work model many years earlier. So in my IBM career, I live four minutes away from my research lab in Almaden Valley, but IBM is a global company with headquarters on the East Coast, and so throughout my career, I often found myself on phone calls with people around the globe at 5:00 AM in the morning, I quickly learned and quickly adapted to a hybrid model. I'd go into the office to collaborate and have in-person meetings when needed. But if I was on the phone at 5:00 AM in the morning, I didn't feel the need to get up at 4:30 AM to go in. I just worked from home and I discovered I could be more productive there, doing think time work, and I really only needed the in-person time for collaboration. This hybrid model allowed me to have a great career at IBM and raise my two daughters at the same time. So when I joined Couchbase, I joined a company that was all about being in-person and instead of a four minute commute, it was going to be an hour or more commute for me each way. This was going to be a really big transition for me, but I was excited enough by Couchbase and what it offered, that I decided to give it a try. Well, that was February, 2020. I showed up early in the morning on March 10th, 2020 for an early morning meeting in-person only to learn that I was one of the only few people that didn't get the memo. We were switching to a remote working model. And so over the last year, I have had the ability to watch Couchbase and other companies pivot to make this remote working model possible and not only possible, but effective. And I'm really happy to see the results. A remote work model does have its challenges, that's for sure, but it also has its benefits, better work-life balance and more time to interact with family members during the day and more quiet time just to think. We just did a retrospective on a major product release, Couchbase server 7.0, that we did over the past 18 months. And one of the major insights by the leadership team is that working from home actually made people more effective. I don't think a full remote model is the right approach going forward, but a hybrid model that IBM adopted many years ago and that I was able to participate in for most of my career, I believe is a healthier and more productive approach. >> Well, great story. I love the come back and now you take leverage of all the best practices from the IBM days, but how did they, your team and the Couchbase engineering team react? And were there any best practices or key learnings that you guys pulled out of that? >> The initial reaction was not good. I mean, as I mentioned, it was a culture based on in-person, people had to be in in-person meetings. So it took a while to get used to it, but there was a forcing function, right? We had to work remotely. That was the only option. And so people made it work. I think the advancement of virtual meeting technology really helps a lot. Over earlier days in my career where I had just bad phone connections, that was very difficult. But with the virtual meetings that you have, where you can actually see people and interact, I think is really quite helpful. And probably the key. >> What's the DNA of the company there? I mean, every company's got the DNA, Intel's Moore's Law, and what's the engineering culture at Couchbase like, if you could describe it. >> The engineering culture at Couchbase is very familiar to me. We are at our heart, a database company, and I grew up in the database world, which has a very unique culture based on two values, merit and mentorship. And we also focus on something that I like to call growing the next generation. Now database technology started in the late sixties, early seventies, with a few key players and institutions. These key players were extremely bright and they tackled and solved really hard problems with elegant solutions, long before anybody knew they were going to be necessary. Now, those original key players, people like Jim Gray, Bruce Lindsay, Don Chamberlin, Pat Selinger, David Dewitt, Michael Stonebraker. They just love solving hard problems. And they wanted to share that elegance with a new generation. And so they really focused on growing the next generation of leaders, which became the Mike Carey's and the Mohan's and the Lagerhaus's of the world. And that culture grew over multiple generations with the previous generation cultivating, challenging, and advocating for the next, I was really lucky to grow up in that culture. And I've advanced my career as a result, as being part of it. The reason I joined Couchbase is because I see that culture alive and well here. Our two fundamental values on the engineering side, are merit and mentorship. >> One of the things I want to get your thoughts on, on the database questions. I remember, back in the old glory days, you mentioned some of those luminaries, you know, there wasn't many database geeks out there, there was kind of a small community, now, as databases are everywhere. So you see, there's no one database that has rule in the world, but you starting to see a pattern of database, kinds of things are emerging, more databases than ever before, they are on the internet, they are on the cloud, there are none the edge. It's essentially, we're living in a large distributed computing environment. So now it's cool to be in databases because they're everywhere. (laughing) So, I mean, this is kind of where we are at. What's your reaction to that? >> You're absolutely right. There used to be a few small vendors and a few key technologies and it's grown over the years, but the fundamental problems are the same, data integrity, performance and scalability in the face of distributed systems. Those were all the hard problems that those key leaders solved back in the sixties and seventies. They're not new problems. They're still there. And they did a lot of the fundamental work that you can apply and reapply in different scenarios and situations. >> That's pretty exciting. I love that. I love the different architectures that are emerging and allows for more creativity for application developers. And this becomes like the key thing we're seeing right now, driving the business and a big conversation here at the, at the event is the powering of these modern applications that need low latency. There's no more, not many spinning disks anymore. It's all in RAM, all these kinds of different memory, you got centralization, you got all kinds of new constructs. How do you make sense of it all? How do you talk to customers? What's the main core thing happening right now? If you had to describe it. >> Yeah, it depends on the type of customer you're talking to. We have focused primarily on the enterprise market and in that market, there are really fundamental issues. Information for these enterprises is key. It's their core asset that they have and they understand very well that they need to protect it and make it available more quickly. I started as a DBA at Morgan Stanley, back, right out of college. And at the time I think it was, it probably still is, but at the time it was the best run IT shop that I'd ever seen in my life. The fundamental problems that we had to solve to get information from one stock exchange to another, to get it to the SEC are the same problems that we're solving today. Back then we were working on mainframes and over high-speed Datacom links. Today, it's the same kind of problem. It's just the underlying infrastructure has changed. >> Yeah, the key, there has been a big supporter of women in tech. We've done thousands of interviews and why I got you. I want to ask you if you don't mind, career advice that you give women who are starting out in the field of engineering, computer science. What do you wish you knew when you started your career? And if you could be that person now, what would you say? >> Yeah, well, a lot of things I wish I knew then that I know now, but I think there are two key aspects to a successful career in engineering. I actually got started as a math major and the reason I became a math major is a little convoluted. As a girl, I was told we were bad at math. And so for some reason I decided that I had to major in it. That's actually how I got my start, but I've had a great career. And I think there are really two key aspects. First, is that it is a discipline in which respect is gained through merit. As I had mentioned earlier, engineers are notoriously detail-oriented and most are, perfectionists. They love elegant, well thought-out solutions and give respect when they see one. So understanding this can be a very important advantage if you're always prepared and you always bring your A-game to every debate, every presentation, every conversation, you have build up respect among your team, simply through merit. While that may mean that you need to be prepared to defend every point early on, say, in your graduate career or when you're starting, over time others will learn to trust your judgment and begin to intuitively follow your lead just by reputation. The reverse is also true. If you don't bring your A-game and you don't come prepared to debate, you will quickly lose respect. And that's particularly true if you're a woman. So if you don't know your stuff, don't engage in the debate until you do. >> That's awesome advice. >> That's... >> All right, continue. >> Thank you. So my second piece of advice that I wish I could give my younger self is to understand the roles of leaders and influencers in your career and the importance of choosing and purposely working with each. I like to break it down into three types of influencers, managers, mentors, and advocates. So that first group are the people in your management chain. It's your first line manager, your director, your VP, et cetera. Their role in your career is to help you measure short-term success. And particularly with how that success aligns with their goals and the company's goals. But it's important to understand that they are not your mentors and they may not have a direct interest in your long-term career success. I like to think of them as, say, you're sixth grade math teacher. You know, you getting an A in the class and advancing to seventh grade. They own you for that. But whether you get that basketball scholarship to college or getting to Harvard or become a CEO, they have very little influence over that. So a mentor is someone who does have a shared interest in your long-term success, maybe by your relationship with him or her, or because by helping you shape your career and achieve your own success, you help advance their goals. Whether it be the company success or helping more women achieve leadership positions or getting more kids into college on a basketball scholarship, whatever it is, they have some long-term goal that aligns with helping you with your career. And they give great advice. But that mentor is not enough because they're often outside the sphere of influence in your current position. And while they can offer great advice and coaching, they may not be able to help you directly advance. That's the role of the third type of influencer. Somebody that I call an advocate. An advocate is someone that's in a position to directly influence your advancement and champion you and your capabilities to others. They are in influential positions and others place great value in their opinions. Advocates stay with you throughout your career, and they'll continue to support you and promote you wherever you are and wherever they are, whether that's the same organization or not. They're the ones who, when a leadership position opens up will say, I think Mary's the right person to take on that challenge, or we need to move in a new direction, I think Mary's the right person to lead that effort. Now advocates are the most important people to identify early on and often in your career. And they're often the most overlooked. People early on often pay too much attention and rely on their management chain for advancement. Managers change on a dime, but mentors and advocates are there for you for the long haul. And that's one of the unique things about the database culture. Those set of advocates were just there already because they had focused on building the next generation. So I consider, you know, Mike Carey as my father and Mike Stonebraker as my grandfather, and Jim Gray as my great-grandfather and they're always there to advocate for me. >> That's like a schema and a database. You got to have it all right there, kind of teed up. Beautiful. (laughing) Great advice. >> Exactly. >> Thank you for that. That was really a masterclass. And that's going to be great advice for folks, really trying to figure out how to play the cards they have and the situation, and to double down or move and find other opportunities. So great stuff there. I do have to ask you Mary, thanks for coming on the technical side and the product side. Couchbase Capella was launched in conjunction with the event. What is the bottom line for that as, as an Operations and Engineering, built the products and rolled it out. What's the main top line message for about that product? >> Yeah. Well, we're very excited about the release of Capella and what it brings to the table is that it's a fully managed and automated database cloud offering so that customers can focus on development and building and improving their applications and reducing the time to market without having to worry about the hard problems underneath, and the operational database management efforts that come with it. As I mentioned earlier, I started my career as a DBA and it was one of the most sought after and highly paid positions in IT because operating a database required so much work. So with Capella, what we're seeing is, taking that job away from me. I'm not going to be able to apply for a DBA tomorrow. >> That's great stuff. Well, great. Thanks for coming. I really appreciate it. Congratulations on the company and the public offering this past summer in July and thanks for that great commentary and insight on theCUBE here. Thank you. >> Thank you very much. >> Okay. Mary Roth, VP of Engineering Operations at Couchbase part of Couchbase ConnectONLINE. I'm John Furrier, host of theCUBE. Thanks for watching. (upbeat music playing)

>>And welcome to the cubes coverage of Couchbase connect online, Mary Roth, VP of engineering operations with couch basis here for Couchbase connect online. Mary. Great to see you. Thanks for coming on remotely for this segment. >>Thank you very much. It's great to be here. >>Love the fire in the background, a little fireside chat here, kind of happening, but I want to get into shooting, you know, engineering and operations with the pandemic has really kind of shown that, you know, engineers and developers have been good working remotely for a while, but for the most part it's impacted companies in general, across the organizations. How did the Couchbase engineering team adapt to the remote work? >>Uh, great question. Um, and I actually think the Couchbase team responded very well to this new model of working imposed by the pandemic. And I have a unique perspective on the couch space journey. I joined in February, 2020 after 20 plus years at IBM, which had embraced a hybrid in-office rewrote remote work model many years earlier. So in my IBM career, I live four minutes away from my research lab in almond and valley, but IBM is a global company with headquarters on the east coast and SU. So throughout my career, I often found myself on phone calls with people around the globe at 5:00 AM in the morning, I quickly learned and quickly adopted to a hybrid model. I'd go into the office to collaborate and have in-person meetings when needed. But if I was on the phone at >> 5: 00 AM in the morning, um, I didn't feel the need to get up at 4:30 AM to go in. >>I just worked from home and I discovered I could be more productive. They're doing think time work. And I really only needed the in-person time for collaboration. These hybrid model allowed me to have a great career at IBM and raise my two daughters at the same time. So when I joined Couchbase I joined a company that was all about being in-person and instead of a four minute commute, it was going to be an hour or more commute for me each way. This was going to be a really big transition for me, but I was excited enough by couch facing what it offered that I decided to give it a try. Well, that was February, 2020. I showed up early in the morning on March 10th, 2020 for an early morning meeting in person only to learn that I was one of the only few people that didn't get the memo. >>We were switching to a remote remote working model. And so over the last year, I have had the ability to watch cow's face and other companies pivot to make this remote working model possible and not only possible, but effective. And I'm really happy to see the results. Our remote work model does have its challenges that's for sure, but it also has its benefits better work-life balance and more time to interact with family members during the day and more quiet time, just to think we just did a retrospective on a major product release Couchbase server 7.0 that we did over the past 18 months. And one of the major insights by the leadership team is that working from home actually made people more effective. I don't think a full remote model is the right approach going forward, but a hybrid model that IBM adopted many years ago and that I was able to participate in for most of my career, I believe is a healthier and more productive approach. >>Well, great story. I love the, um, the, uh, you come back and now you take leverage all the best practices from the IBM days, but how did the, your team and the Couchbase engineering team react and were there any best practices or key learnings that you guys pulled out of that, >>Uh, the, the initial reaction was not good. I mean, as I mentioned, it was a culture based on in-person people had to be in person in person meetings. So it took a while to get used to it, but the, there was a forcing function, right? We had to work remotely. That was the only option. And so people made it work. I think the advancement of virtual meeting technology really, really helps a lot over earlier days in my career where I had just bad phone connections, that was very difficult. But with the virtual meetings that you have, where you can actually see people and interact, I think is really quite helpful. >>What's the DNA of the culture. What's the DNA. Every company's got the DNA entails Moore's law. Um, and at what's the engineering culture at Couchbase like if you could describe it. >>Uh, the engineering culture at Couchbase is very familiar to me. We are at our heart, a database company, and I grew up in the database world, which has a very unique culture based on two values, merit and mentorship. And we also focus on something that I like to call growing. The next generation. Now database technology started in the late sixties, early seventies with a few key players and institutions. These key players were extremely bright and they tackle it and solve really hard problems with elegant solutions long before anybody knew they were going to be necessary. Now, those original key players, people like Jim gray, Bruce Lindsey, Don Chamberlin, pat Salinger, David Dewitt, Michael Stonebraker. They just love solving hard problems. And they wanted to share that elegance with a new generation. And so they really focused on growing the next generation of leaders, which became the Mike caries and the Mohans and the lower houses of the world. And that culture grew over multiple generations with the previous generation cultivating, challenging and advocating for the next, I was really lucky to grow up in that culture. And I've advanced my career as a result, as being part of it. The reason I joined Couchbase is because I see that culture alive and well, here are two fundamental values on the engineering side, our merit and mentorship. >>One of the things I want to get your thoughts on, on the database questions. I remember, you know, back in the old glory days, you mentioned some of those luminaries, you know, there wasn't many database geeks out there, Zuri kind of small community now is databases are everywhere. So you see there's no one database that's ruling the world, but you starting to see a pattern of database kinds of things, and more emerging, more databases than ever before. They're on the internet, they're on the cloud. There are none the edge it's essentially we're living in a large distributed computing environment. So now it's cool to be in databases cause they're everywhere. So, I mean, this is kind of where we're at. What's your reaction to that? >>Uh, you're absolutely right there. There used to be a, a few small vendors and a few key technologies and it's grown over the years, but the fundamental problems are the same data, integrity, performance and scalability. And in the face of district distributed systems, those were all the hard problems that those key leaders solve back in the sixties and seventies. They're not, they're not new problems. They're still there. And they did a lot of the fundamental work that you can apply and reapply in different scenarios and situations. >>It's pretty exciting. I love that. I love the different architectures that are emerging and allows for more creativity for application developers. And this becomes like the key thing we're seeing right now, driving the business and a big conversation here at the, at the event is the powering, these modern applications that need low latency. There's no more, not many spinning disks anymore. It's all in Ram, all these kinds of different memory, you got decentralization and all kinds of new constructs. How do you make sense of it all? How do you talk to customers? What's the, what's the, what's the main core thing happening right now? If you had to describe it? >>Yeah, it depends on the type of customer you're talking to. Um, we have focused primarily on the enterprise market and in that market, there are really fundamental issues. Information for, for these enterprises is key. It's their core asset that they have and they understand very well that they need to protect it and make it available more quickly. I started as a DBA at Morgan Stanley back, um, right out of college. And at the time I think it was, it probably still is, but at the time it was the best run it shop that I'd ever seen in my life. The fundamental problems that we had to solve to get information from one stock exchange to another, to get it to the sec, um, are the same problems that we're solving today. Back then we were working on mainframes and over high-speed data comm links today, it's the same kind of problem. It's just the underlying infrastructure has changed. >>You know, the key has been a big supporter of women in tech. We've done thousands of interviews on why I got you. I want to ask you, uh, if you don't mind, um, career advice that you give women who are starting out in the field of engineering, computer science, what do you wish you knew when you started your career? And you could be that person now, what would you say? >>Yeah, well, there are a lot of things I wish I knew then, uh, that I know now, but I think there are two key aspects to a successful career in engineering. I actually got started as a math major and the reason I, I became a math major is a little convoluted. Is it as a girl, I was told we were bad at math. And so for some reason I decided that I had to major in it. That's actually how I got my start. Um, but I've had a great career and I think there are really two key aspects first. And is that it is a discipline in which respect is gained through merit. As I had mentioned earlier, engineers are notoriously detail oriented and most of our perfectionist, they love elegant, well thought out solutions and give respect when they see one. So understanding this can be a very important advantage if you're always prepared and you always bring your a game to every debate, every presentation, every conversation you have build up respect among your team, simply through merit. While that may mean that you need to be prepared to defend every point early on say, in your graduate career or when you're starting over time, others will learn to trust your judgment and begin to intuitively follow your lead just by reputation. The reverse is also true. If you don't bring your a game and you don't come prepared to debate, you will quickly lose respect. And that's particularly true if you're a woman. So if you don't know your stuff, don't engage in the debate until you do. That's awesome. >>That's >>Fine. Continue. Thank you. So my second piece of advice that I wish I could give my younger self is to understand the roles of leaders and influencers in your career and the importance of choosing and purposely working with each. I like to break it down into three types of influencers, managers, mentors, and advocates. So that first group are the people in your management chain. It's your first line manager, your director, your VP, et cetera. Their role in your career is to help you measure short-term success. And particularly with how that success aligns with their goals and the company's goals. But it's important to understand that they are not your mentors and they may not have a direct interest in your long-term career success. I like to think of them as say, you're sixth grade math teacher. You know, you're getting an a in the class and advancing to seventh grade. >>They own you for that. Um, but whether you get that basketball scholarship to college or getting to Harvard or become a CEO, they have very little influence over that. So a mentor is someone who does have a shared interest in your longterm success, maybe by your relationship with him or her, or because by helping you shape your career and achieve your own success, you help advance their goals. Whether it be the company success or helping more women achieve, we do put sip positions or getting more kids into college, on a basketball scholarship, whatever it is, they have some long-term goal that aligns with helping you with your career. And they gave great advice. But that mentor is not enough because they're often outside of the sphere of influence in your current position. And while they can offer great advice and coaching, they may not be able to help you directly advance. >>That's the role of the third type of influencer. Somebody that I call an advocate, an advocate is someone that's in a position to directly influence your advancement and champion you and your capabilities to others. They are in influential positions and others place, great value in their opinions. Advocates stay with you throughout your career, and they'll continue to support you and promote you wherever you are and wherever they are, whether that's the same organization or not. They're the ones who, when a leadership position opens up will say, I think Mary's the right person to take on that challenge, or we need to move in a new direction. I think Mary's the right person to lead that effort. Now advocates are the most important people to identify early on and often in your career. And they're often the most overlooked people early on, often pay too much attention and rely on their management chain for advanced managers, change on a dime, but mentors and advocates are there for you for the long haul. And that's one of the unique things about the database culture. Those set of advocates were just there already because they had focused on building the next generation. So I consider, you know, Mike Carey is my father and Mike Stonebraker is my grandfather. And Jim gray is my great-grandfather and they're always there to advocate for me. >>That's like a scheme and a database. You got to have it all white. They're kind of teed up. Beautiful, great advice. >>Thank you for that. That was really a masterclass. And that's going to be great advice for folks really trying to figure out how to play the cards they have a and the situation and to double down or move and find other opportunities. So great stuff there. I do have to ask you Maira, thanks for coming on the technical side and the product side Couchbase Capella was launched, uh, in conjunction with the event. What is, what is the bottom line for that as, as an operations and engineering, you know, built the products and roll it out. What's the main top line message for about that product? >>Yeah, well, we're very excited about the release of Capella and what it brings to the table is that it's a fully managed in an automated database cloud offering so that customers can focus on development and building and improving their applications and reducing the time to market without having to worry about the hard problems underneath and the operational database management efforts that come with it. Uh, as I mentioned earlier, I started my career as a UVA and it was one of the most sought after and highly paid positions in it because operating a database required so much work. So with Capella, what we're seeing is, you know, taking that job away from me, I'm not going to be able to apply for a DBA tomorrow. >>That's great stuff. Well, great. Thanks for coming. I really appreciate congratulations on the company and public offering this past summer in July and thanks for that great commentary and insight on the QPR. Thank you. >>Thank you very much. >>Okay. Mary Ross, VP of engineering operations at Couchbase part of Couchbase connect online. I'm John furry host of the cube. Thanks for watching.

(upbeat music) >> Narrator: It's theCUBE, covering the Virtual Vertica Big Data Conference 2020. Brought to you by Vertica. >> Dave Vellante: Hello everyone, and welcome to theCUBE's exclusive coverage of the Vertica Virtual Big Data Conference. You're watching theCUBE, the leader in digital event tech coverage. And we're broadcasting remotely from our studios in Palo Alto and Boston. And, we're pleased to be covering wall-to-wall this digital event. Now, as you know, originally BDC was scheduled this week at the new Encore Hotel and Casino in Boston. Their theme was "Win big with big data". Oh sorry, "Win big with data". That's right, got it. And, I know the community was really looking forward to that, you know, meet up. But look, we're making the best of it, given these uncertain times. We wish you and your families good health and safety. And this is the way that we're going to broadcast for the next several months. Now, we want to unpack Colin Mahony's keynote, but, before we do that, I want to give a little context on the market. First, theCUBE has covered every BDC since its inception, since the BDC's inception that is. It's a very intimate event, with a heavy emphasis on user content. Now, historically, the data engineers and DBAs in the Vertica community, they comprised the majority of the content at this event. And, that's going to be the same for this virtual, or digital, production. Now, theCUBE is going to be broadcasting for two days. What we're doing, is we're going to be concurrent with the Virtual BDC. We got practitioners that are coming on the show, DBAs, data engineers, database gurus, we got a security experts coming on, and really a great line up. And, of course, we'll also be hearing from Vertica Execs, Colin Mahony himself right of the keynote, folks from product marketing, partners, and a number of experts, including some from Micro Focus, which is the, of course, owner of Vertica. But I want to take a moment to share a little bit about the history of Vertica. The company, as you know, was founded by Michael Stonebraker. And, Verica started, really they started out as a SQL platform for analytics. It was the first, or at least one of the first, to really nail the MPP column store trend. Not only did Vertica have an early mover advantage in MPP, but the efficiency and scale of its software, relative to traditional DBMS, and also other MPP players, is underscored by the fact that Vertica, and the Vertica brand, really thrives to this day. But, I have to tell you, it wasn't without some pain. And, I'll talk a little bit about that, and really talk about how we got here today. So first, you know, you think about traditional transaction databases, like Oracle or IMBDB tour, or even enterprise data warehouse platforms like Teradata. They were simply not purpose-built for big data. Vertica was. Along with a whole bunch of other players, like Netezza, which was bought by IBM, Aster Data, which is now Teradata, Actian, ParAccel, which was the basis for Redshift, Amazon's Redshift, Greenplum was bought, in the early days, by EMC. And, these companies were really designed to run as massively parallel systems that smoked traditional RDBMS and EDW for particular analytic applications. You know, back in the big data days, I often joked that, like an NFL draft, there was run on MPP players, like when you see a run on polling guards. You know, once one goes, they all start to fall. And that's what you saw with the MPP columnar stores, IBM, EMC, and then HP getting into the game. So, it was like 2011, and Leo Apotheker, he was the new CEO of HP. Frankly, he has no clue, in my opinion, with what to do with Vertica, and totally missed one the biggest trends of the last decade, the data trend, the big data trend. HP picked up Vertica for a song, it wasn't disclosed, but my guess is that it was around 200 million. So, rather than build a bunch of smart tokens around Vertica, which I always call the diamond in the rough, Apotheker basically permanently altered HP for years. He kind of ruined HP, in my view, with a 12 billion dollar purchase of Autonomy, which turned out to be one of the biggest disasters in recent M&A history. HP was forced to spin merge, and ended up selling most of its software to Microsoft, Micro Focus. (laughs) Luckily, during its time at HP, CEO Meg Whitman, largely was distracted with what to do with the mess that she inherited form Apotheker. So, Vertica was left alone. Now, the upshot is Colin Mahony, who was then the GM of Vertica, and still is. By the way, he's really the CEO, and he just doesn't have the title, I actually think they should give that to him. But anyway, he's been at the helm the whole time. And Colin, as you'll see in our interview, is a rockstar, he's got technical and business jobs, people love him in the community. Vertica's culture is really engineering driven and they're all about data. Despite the fact that Vertica is a 15-year-old company, they've really kept pace, and not been polluted by legacy baggage. Vertica, early on, embraced Hadoop and the whole open-source movement. And that helped give it tailwinds. It leaned heavily into cloud, as we're going to talk about further this week. And they got a good story around machine intelligence and AI. So, whereas many traditional database players are really getting hurt, and some are getting killed, by cloud database providers, Vertica's actually doing a pretty good job of servicing its install base, and is in a reasonable position to compete for new workloads. On its last earnings call, the Micro Focus CFO, Stephen Murdoch, he said they're investing 70 to 80 million dollars in two key growth areas, security and Vertica. Now, Micro Focus is running its Suse play on these two parts of its business. What I mean by that, is they're investing and allowing them to be semi-autonomous, spending on R&D and go to market. And, they have no hardware agenda, unlike when Vertica was part of HP, or HPE, I guess HP, before the spin out. Now, let me come back to the big trend in the market today. And there's something going on around analytic databases in the cloud. You've got companies like Snowflake and AWS with Redshift, as we've reported numerous times, and they're doing quite well, they're gaining share, especially of new workloads that are merging, particularly in the cloud native space. They combine scalable compute, storage, and machine learning, and, importantly, they're allowing customers to scale, compute, and storage independent of each other. Why is that important? Because you don't have to buy storage every time you buy compute, or vice versa, in chunks. So, if you can scale them independently, you've got granularity. Vertica is keeping pace. In talking to customers, Vertica is leaning heavily into the cloud, supporting all the major cloud platforms, as we heard from Colin earlier today, adding Google. And, why my research shows that Vertica has some work to do in cloud and cloud native, to simplify the experience, it's more robust in motor stack, which supports many different environments, you know deep SQL, acid properties, and DNA that allows Vertica to compete with these cloud-native database suppliers. Now, Vertica might lose out in some of those native workloads. But, I have to say, my experience in talking with customers, if you're looking for a great MMP column store that scales and runs in the cloud, or on-prem, Vertica is in a very strong position. Vertica claims to be the only MPP columnar store to allow customers to scale, compute, and storage independently, both in the cloud and in hybrid environments on-prem, et cetera, cross clouds, as well. So, while Vertica may be at a disadvantage in a pure cloud native bake-off, it's more robust in motor stack, combined with its multi-cloud strategy, gives Vertica a compelling set of advantages. So, we heard a lot of this from Colin Mahony, who announced Vertica 10.0 in his keynote. He really emphasized Vertica's multi-cloud affinity, it's Eon Mode, which really allows that separation, or scaling of compute, independent of storage, both in the cloud and on-prem. Vertica 10, according to Mahony, is making big bets on in-database machine learning, he talked about that, AI, and along with some advanced regression techniques. He talked about PMML models, Python integration, which was actually something that they talked about doing with Uber and some other customers. Now, Mahony also stressed the trend toward object stores. And, Vertica now supports, let's see S3, with Eon, S3 Eon in Google Cloud, in addition to AWS, and then Pure and HDFS, as well, they all support Eon Mode. Mahony also stressed, as I mentioned earlier, a big commitment to on-prem and the whole cloud optionality thing. So 10.0, according to Colin Mahony, is all about really doubling down on these industry waves. As they say, enabling native PMML models, running them in Vertica, and really doing all the work that's required around ML and AI, they also announced support for TensorFlow. So, object store optionality is important, is what he talked about in Eon Mode, with the news of support for Google Cloud and, as well as HTFS. And finally, a big focus on deployment flexibility. Migration tools, which are a critical focus really on improving ease of use, and you hear this from a lot of customers. So, these are the critical aspects of Vertica 10.0, and an announcement that we're going to be unpacking all week, with some of the experts that I talked about. So, I'm going to close with this. My long-time co-host, John Furrier, and I have talked some time about this new cocktail of innovation. No longer is Moore's law the, really, mainspring of innovation. It's now about taking all these data troves, bringing machine learning and AI into that data to extract insights, and then operationalizing those insights at scale, leveraging cloud. And, one of the things I always look for from cloud is, if you've got a cloud play, you can attract innovation in the form of startups. It's part of the success equation, certainly for AWS, and I think it's one of the challenges for a lot of the legacy on-prem players. Vertica, I think, has done a pretty good job in this regard. And, you know, we're going to look this week for evidence of that innovation. One of the interviews that I'm personally excited about this week, is a new-ish company, I would consider them a startup, called Zebrium. What they're doing, is they're applying AI to do autonomous log monitoring for IT ops. And, I'm interviewing Larry Lancaster, who's their CEO, this week, and I'm going to press him on why he chose to run on Vertica and not a cloud database. This guy is a hardcore tech guru and I want to hear his opinion. Okay, so keep it right there, stay with us. We're all over the Vertica Virtual Big Data Conference, covering in-depth interviews and following all the news. So, theCUBE is going to be interviewing these folks, two days, wall-to-wall coverage, so keep it right there. We're going to be right back with our next guest, right after this short break. This is Dave Vellante and you're watching theCUBE. (upbeat music)

>> From Cambridge, Massachusetts. It's theCUBE, covering MIT Chief Data Officer and Information Quality Symposium 2019. Brought to you by SiliconANGLE Media. >> Welcome back to Cambridge, Massachusetts, everybody. We're here at MIT, sweltering Cambridge, Massachusetts. You're watching theCUBE, the leader in live tech coverage, my name is Dave Vellante. I'm here with my co-host, Paul Gillin. Special coverage of the MITCDOIQ. The Chief Data Officer event, this is the 13th year of the event, we started seven years ago covering it, Mark Ramsey is here. He's the Chief Data and Analytics Officer Advisor at Ramsey International, LLC and former Chief Data Officer of GlaxoSmithKline. Big pharma, Mark, thanks for coming onto theCUBE. >> Thanks for having me. >> You're very welcome, fresh off the keynote. Fascinating keynote this evening, or this morning. Lot of interest here, tons of questions. And we have some as well, but let's start with your history in data. I sat down after 10 years, but I could have I could have stretched it to 20. I'll sit down with the young guns. But there was some folks in there with 30 plus year careers. How about you, what does your data journey look like? >> Well, my data journey, of course I was able to stand up for the whole time because I was in the front, but I actually started about 32, a little over 32 years ago and I was involved with building. What I always tell folks is that Data and Analytics has been a long journey, and the name has changed over the years, but we've been really trying to tackle the same problems of using data as a strategic asset. So when I started I was with an insurance and financial services company, building one of the first data warehouse environments in the insurance industry, and that was in the 87, 88 range, and then once I was able to deliver that, I ended up transitioning into being in consulting for IBM and basically spent 18 years with IBM in consulting and services. When I joined, the name had evolved from Data Warehousing to Business Intelligence and then over the years it was Master Data Management, Customer 360. Analytics and Optimization, Big Data. And then in 2013, I joined Samsung Mobile as their first Chief Data Officer. So, moving out of consulting, I really wanted to own the end-to-end delivery of advanced solutions in the Data Analytics space and so that made the transition to Samsung quite interesting, very much into consumer electronics, mobile phones, tablets and things of that nature, and then in 2015 I joined GSK as their first Chief Data Officer to deliver a Data Analytics solution. >> So you have long data history and Paul, Mark took us through. And you're right, Mark-o, it's a lot of the same narrative, same wine, new bottle but the technology's obviously changed. The opportunities are greater today. But you took us through Enterprise Data Warehouse which was ETL and then MAP and then Master Data Management which is kind of this mapping and abstraction layer, then an Enterprise Data Model, top-down. And then that all failed, so we turned to Governance which has been very very difficult and then you came up with another solution that we're going to dig into, but is it the same wine, new bottle from the industry? >> I think it has been over the last 20, 30 years, which is why I kind of did the experiment at the beginning of how long folks have been in the industry. I think that certainly, the technology has advanced, moving to reduction in the amount of schema that's required to move data so you can kind of move away from the map and move type of an approach of a data warehouse but it is tackling the same type of problems and like I said in the session it's a little bit like Einstein's phrase of doing the same thing over and over again and expecting a different answer is certainly the definition of insanity and what I really proposed at the session was let's come at this from a very different perspective. Let's actually use Data Analytics on the data to make it available for these purposes, and I do think I think it's a different wine now and so I think it's just now a matter of if folks can really take off and head that direction. >> What struck me about, you were ticking off some of the issues that have failed like Data Warehouses, I was surprised to hear you say Data Governance really hasn't worked because there's a lot of talk around that right now, but all of those are top-down initiatives, and what you did at GSK was really invert that model and go from the bottom up. What were some of the barriers that you had to face organizationally to get the cooperation of all these people in this different approach? >> Yeah, I think it's still key. It's not a complete bottoms up because then you do end up really just doing data for the sake of data, which is also something that's been tried and does not work. I think it has to be a balance and that's really striking that right balance of really tackling the data at full perspective but also making sure that you have very definitive use cases to deliver value for the organization and then striking the balance of how you do that and I think of the things that becomes a struggle is you're talking about very large breadth and any time you're covering multiple functions within a business it's getting the support of those different business functions and I think part of that is really around executive support and what that means, I did mention it in the session, that executive support to me is really stepping up and saying that the data across the organization is the organization's data. It isn't owned by a particular person or a particular scientist, and I think in a lot of organization, that gatekeeper mentality really does put barriers up to really tackling the full breadth of the data. >> So I had a question around digital initiatives. Everywhere you go, every C-level Executive is trying to get digital right, and a lot of this is top-down, a lot of it is big ideas and it's kind of the North Star. Do you think that that's the wrong approach? That maybe there should be a more tactical line of business alignment with that threaded leader as opposed to this big picture. We're going to change and transform our company, what are your thoughts? >> I think one of the struggles is just I'm not sure that organizations really have a good appreciation of what they mean when they talk about digital transformation. I think there's in most of the industries it is an initiative that's getting a lot of press within the organizations and folks want to go through digital transformation but in some cases that means having a more interactive experience with consumers and it's maybe through sensors or different ways to capture data but if they haven't solved the data problem it just becomes another source of data that we're going to mismanage and so I do think there's a risk that we're going to see the same outcome from digital that we have when folks have tried other approaches to integrate information, and if you don't solve the basic blocking and tackling having data that has higher velocity and more granularity, if you're not able to solve that because you haven't tackled the bigger problem, I'm not sure it's going to have the impact that folks really expect. >> You mentioned that at GSK you collected 15 petabytes of data of which only one petabyte was structured. So you had to make sense of all that unstructured data. What did you learn about that process? About how to unlock value from unstructured data as a result of that? >> Yeah, and I think this is something. I think it's extremely important in the unstructured data to apply advanced analytics against the data to go through a process of making sense of that information and a lot of folks talk about or have talked about historically around text mining of trying to extract an entity out of unstructured data and using that for the value. There's a few steps before you even get to that point, and first of all it's classifying the information to understand which documents do you care about and which documents do you not care about and I always use the story that in this vast amount of documents there's going to be, somebody has probably uploaded the cafeteria menu from 10 years ago. That has no scientific value, whereas a protocol document for a clinical trial has significant value, you don't want to look through manually a billion documents to separate those, so you have to apply the technology even in that first step of classification, and then there's a number of steps that ultimately lead you to understanding the relationship of the knowledge that's in the documents. >> Side question on that, so you had discussed okay, if it's a menu, get rid of it but there's certain restrictions where you got to keep data for decades. It struck me, what about work in process? Especially in the pharmaceutical industry. I mean, post Federal Rules of Civil Procedure was everybody looking for a smoking gun. So, how are organizations dealing with what to keep and what to get rid of? >> Yeah, and I think certainly the thinking has been to remove the excess and it's to your point, how do you draw the line as to what is excess, right, so you don't want to just keep every document because then if an organization is involved in any type of litigation and there's disclosure requirements, you don't want to have to have thousands of documents. At the same time, there are requirements and so it's like a lot of things. It's figuring out how do you abide by the requirements, but that is not an easy thing to do, and it really is another driver, certainly document retention has been a big thing over a number of years but I think people have not applied advanced analytics to the level that they can to really help support that. >> Another Einstein bro-mahd, you know. Keep everything you must but no more. So, you put forth a proposal where you basically had this sort of three approaches, well, combined three approaches. The crawlers to go, the spiders to go out and do the discovery and I presume that's where the classification is done? >> That's really the identification of all of the source information >> Okay, so find out what you got, okay. >> so that's kind of the start. Find out what you have. >> Step two is the data repository. Putting that in, I thought it was when I heard you I said okay it must be a logical data repository, but you said you basically told the CIO we're copying all the data and putting it into essentially one place. >> A physical location, yes. >> Okay, and then so I got another question about that and then use bots in the pipeline to move the data and then you sort of drew the diagram of the back end to all the databases. Unstructured, structured, and then all the fun stuff up front, visualization. >> Which people love to focus on the fun stuff, right? Especially, you can't tell how many articles are on you got to apply deep learning and machine learning and that's where the answers are, we have to have the data and that's the piece that people are missing. >> So, my question there is you had this tactical mindset, it seems like you picked a good workload, the clinical trials and you had at least conceptually a good chance of success. Is that a fair statement? >> Well, the clinical trials was one aspect. Again, we tackled the entire data landscape. So it was all of the data across all of R&D. It wasn't limited to just, that's that top down and bottom up, so the bottom up is tackle everything in the landscape. The top down is what's important to the organization for decision making. >> So, that's actually the entire R&D application portfolio. >> Both internal and external. >> So my follow up question there is so that largely was kind of an inside the four walls of GSK, workload or not necessarily. My question was what about, you hear about these emerging Edge applications, and that's got to be a nightmare for what you described. In other words, putting all the data into one physical place, so it must be like a snake swallowing a basketball. Thoughts on that? >> I think some of it really does depend on you're always going to have these, IOT is another example where it's a large amount of streaming information, and so I'm not proposing that all data in every format in every location needs to be centralized and homogenized, I think you have to add some intelligence on top of that but certainly from an edge perspective or an IOT perspective or sensors. The data that you want to then make decisions around, so you're probably going to have a filter level that will impact those things coming in, then you filter it down to where you're going to really want to make decisions on that and then that comes together with the other-- >> So it's a prioritization exercise, and that presumably can be automated. >> Right, but I think we always have these cases where we can say well what about this case, and you know I guess what I'm saying is I've not seen organizations tackle their own data landscape challenges and really do it in an aggressive way to get value out of the data that's within their four walls. It's always like I mentioned in the keynote. It's always let's do a very small proof of concept, let's take a very narrow chunk. And what ultimately ends up happening is that becomes the only solution they build and then they go to another area and they build another solution and that's why we end up with 15 or 25-- (all talk over each other) >> The conventional wisdom is you start small. >> And fail. >> And you go on from there, you fail and that's now how you get big things done. >> Well that's not how you support analytic algorithms like machine learning and deep learning. You can't feed those just fragmented data of one aspect of your business and expect it to learn intelligent things to then make recommendations, you've got to have a much broader perspective. >> I want to ask you about one statistic you shared. You found 26 thousand relational database schemas for capturing experimental data and you standardized those into one. How? >> Yeah, I mean we took advantage of the Tamr technology that Michael Stonebraker created here at MIT a number of years ago which is really, again, it's applying advanced analytics to the data and using the content of the data and the characteristics of the data to go from dispersed schemas into a unified schema. So if you look across 26 thousand schemas using machine learning, you then can understand what's the consolidated view that gives you one perspective across all of those different schemas, 'cause ultimately when you give people flexibility they love to take advantage of it but it doesn't mean that they're actually doing things in an extremely different way, 'cause ultimately they're capturing the same kind of data. They're just calling things different names and they might be using different formats but in that particular case we use Tamr very heavily, and that again is back to my example of using advanced analytics on the data to make it available to do the fun stuff. The visualization and the advanced analytics. >> So Mark, the last question is you well know that the CDO role emerged in these highly regulated industries and I guess in the case of pharma quasi-regulated industries but now it seems to be permeating all industries. We have Goka-lan from McDonald's and virtually every industry is at least thinking about this role or has some kind of de facto CDO, so if you were slotted in to a CDO role, let's make it generic. I know it depends on the industry but where do you start as a CDO for an organization large company that doesn't have a CDO. Even a mid-sized organization, where do you start? >> Yeah, I mean my approach is that a true CDO is maximizing the strategic value of data within the organization. It isn't a regulatory requirement. I know a lot of the banks started there 'cause they needed someone to be responsible for data quality and data privacy but for me the most critical thing is understanding the strategic objectives of the organization and how will data be used differently in the future to drive decisions and actions and the effectiveness of the business. In some cases, there was a lot of discussion around monetizing the value of data. People immediately took that to can we sell our data and make money as a different revenue stream, I'm not a proponent of that. It's internally monetizing your data. How do you triple the size of the business by using data as a strategic advantage and how do you change the executives so what is good enough today is not good enough tomorrow because they are really focused on using data as their decision making tool, and that to me is the difference that a CDO needs to make is really using data to drive those strategic decision points. >> And that nuance you mentioned I think is really important. Inderpal Bhandari, who is the Chief Data Officer of IBM often says how can you monetize the data and you're right, I don't think he means selling data, it's how does data contribute, if I could rephrase what you said, contribute to the value of the organization, that can be cutting costs, that can be driving new revenue streams, that could be saving lives if you're a hospital, improving productivity. >> Yeah, and I think what I've shared typically shared with executives when I've been in the CDO role is that they need to change their behavior, right? If a CDO comes in to an organization and a year later, the executives are still making decisions on the same data PowerPoints with spinning logos and they said ooh, we've got to have 'em. If they're still making decisions that way then the CDO has not been successful. The executives have to change what their level of expectation is in order to make a decision. >> Change agents, top down, bottom up, last question. >> Going back to GSK, now that they've completed this massive data consolidation project how are things different for that business? >> Yeah, I mean you look how Barron joined as the President of R&D about a year and a half ago and his primary focus is using data and analytics and machine learning to drive the decision making in the discovery of a new medicine and the environment that has been created is a key component to that strategic initiative and so they are actually completely changing the way they're selecting new targets for new medicines based on data and analytics. >> Mark, thanks so much for coming on theCUBE. >> Thanks for having me. >> Great keynote this morning, you're welcome. All right, keep it right there everybody. We'll be back with our next guest. This is theCUBE, Dave Vellante with Paul Gillin. Be right back from MIT. (upbeat music)

>> Announcer: Live from Las Vegas! It's theCUBE. Covering Edge 2016. Brought to you by IBM. Here's your host, Dave Vellante. >> Welcome back to IBM Edge everybody. This is theCUBE's fifth year covering IBM Edge. We were at the inaugural Edge five years ago in Orlando. Marc Linster is here and he's joined by Lenley Hensarling. Marc is the Senior Vice President of Product Development. And Lenley is the Senior Vice President of Product Management and Strategy at EDB, Enterprise Database. Gentlemen, welcome to theCUBE. Thanks for coming on. >> Male Voice: Thank you. >> Okay, who wants to start. Enterprise Database, tell us about the company and what you guys are all about. >> Well the company has been around for little over 10 years now. And our job is really to give companies the ability to use Postgres as the platform for their digital business. So think about this, Postgres is a great open source database. Great capabilities for transactional management of data. But also multi-model data management. So think about standard SQL data but think also about document oriented, think about key-value pair. Think about GIS. So a great capability that is very, very robust. Has been around for quite a few years. And is really ready to allow companies to build on them for the new digital business but also to migrate off their existing commercial databases that are too expensive. >> What's the history of Postgres? Can you sort of educate me on that? >> Sort of the same roots back with System R, where DB2 came from, Oracle came from. So Berkeley, that's where the whole thing started out. Postgres is really the successor to Ingres. >> Dave: Umhmm. >> And then it turned into PostgreSQL. And it has been licensed under open source license, the Postgres license since 1996. And it's a very, very vibrant open source community that has been driving forward for many years now. And our view is the best available relational and multi-model database today. >> It's the mainspring of relational database management systems essentially >> Marc: Yeah. >> is what you're saying. And Lindley, from a product standpoint, how do you productize that, open source. >> Open source really, companies that have a distribution of open source for database and operating system, whatever the open source company most people are acquainted with, is Red Hat and Linux right. And so, we do the same thing that they do but for Postgres database. We take the distribution, we add testing, we add some other functionality around it so you can run Postgres responsively as Marc likes to say. So high availability, capability, fail-over management, replication, a backup solution. And instead of leaving it as an exercise for a customer, who wants to use open source, we test all this together. And then we validate it and we give them a complete package with documentation and services that they can access to help them be successful it. >> So if Michael Stonebraker were sitting right here, I say Michael, what do you think about Postgres? I'd say I had to start Vertica because we needed a new way. Yet, sort of PostgreSQL, is the killer remains the killer platform in the industry, doesn't it? >> Male Voice: Umhmm. Why is that? It's interesting when you talk to guys like Stonebraker, it's sort of dogma almost. But yet, customers, talk with their wallet. >> And it is, >> He did a very, very nice job of architecting it. It is a database that is extensible. The reason we add the first JSONB or document oriented implementation in the relational database space is because it was designed to make it easy to add new capabilities, new datatypes, new indexes, et cetera, into the same transactional model. That's why we have JSONB. That's why we have PostGIS. That's why we have key-value pair. So it was really well architected. And when you think about who else, not just Vertica has taken this engine >> Dave: Yeah. >> It is in Netezza, it is in a bunch of other. >> Dave: Master Data. >> Lenley: Greenplum. >> Greenplum yes. So it's a really robust architecture. Very, very nicely designed. It just does the job and it does it really well. Which is, what you want a database to do, right. It's not that exciting but it's really stable. It really works. The data is still there tomorrow. That's what really the requirements are. >> And to translate a little bit, Marc mentioned PostGIS, which is geo spacial capability for the Postgres database. And so we distribute that along with Postgres and test it so that you know it works. And he mentioned H-Store, so that's how you can actually store internet of things data really well into Postgres. And we talk about SQL, noSQL databases, so they're document databases. And the ability to have personalization at the same level you can in a document oriented database but in a structured SQL database are the kinds of things that have been added to Postgres over the years. Again, it's because of the basic architecture that Stonebraker put in place as an object relational database. >> It's so interesting to look at the history of database. Talk about Stonebraker, he's been on a number of times. It's just fascinating to listen to one of the fathers of this industry. But 10 years ago, database was like such a boring topic. And now it's exploded. Now you got Amazon going after Oracle. Oracle fighting the good fight. So many noSQL databases coming in. SQL becoming the killer big data app if you will. >> Male Voice: Umhmm. >> Why all of a sudden did database get so interesting? >> What happened was, application models changed. Led by Facebook, led by Amazon and Google. They said, let's refactor the applications and let's refactor the way we handle storage. >> Dave: Umhmm. >> And that led to the rise of the polyglot of databases is what a lot of people are saying. You have fit for purpose solutions and you may have three or four or five of them in your overall architecture. One thing about Postgres is, we're able to, because of the datatypes support that Marc mentioned, fit into that well. We don't try and do everything so if somebody says, I'm going to use Mongo for data capture, or I'm going to use Cassandra for capturing my internet of things data. We have what we call foreign data wrappers in the Postgres world. We call them just Enterprise DB Adapters but to Mongo, to Casandra, to Hadoop and can do bidirectional data there and just keep that data at rest over there in the other world. But be able to project relational schema onto it. We can push our data into those. We've got a great use case we've been talking about with a customer who had over a petabyte of data. And in the past what you do is, you'd go buy an expensive archiving solution and add that to it. Now, you just use Hadoop distributed file system. Push the data off there as it ages and have a foreign data wrapper that allows you to still query that data when it's out of your basic operational dataset. And move forward. >> Can I call that a connector or? >> Lenley: Yeah, a connector, that's not a bad idea. >> And it's interesting because If you guys remember Hadapt, probably. [Male Voices] Yeah. Yes. >> They came out, they were the connector killer. >> Male Voice: Umhmm. >> And it failed. >> Male Voice: Yeah. >> Seems like connectors are just fine. >> Male Voice: Yeah. >> And one of the really interesting things is, we call it data federation right. With philosophy here is, leave the data where it is. There are some data that should live in Hadoop or Cassandra. If I'm doing an e-commerce site with transactions and click streams, well, the click streams really should live in Hadoop. That the night natural place for them. The transactions should be in a transactional database. With the foreign data wrapper, I can run queries without moving the data, that will allow me to say, well, before you bought the brown teddy bear, which pages did you look at? >> Dave: Yeah. >> And I can do that integrated system and I can do a fit for purpose architecture. And that's what we think is really exciting. >> And that's fundamental to this new sort of programming or application models. >> Male Voice: That's right. >> The one that you were talking about is moving five megabytes of code to a petabyte of data. As opposed to moving data which we know has gravity and speed of light issues and so forth. >> Thank you for that little brief education. Appreciate it. So let's get into your business now, your relationship with IBM. What customers are doing. You mentioned IoT data so talk more about your business and your relationship with IBM and what you guys are doing for customers. >> There are a couple of things. We mentioned Oracle. And there are all the new databases. And then there's your, dare we say, legacy, proprietary databases as well. And people are looking to become more efficient in how they spend. We've done another thing with Postgres. We've added Oracle compatibility in terms of datatypes. So we support all the datatypes that Oracle does. And we support PL/SQL, they're sort of variant of stored procedure language. And implemented a lot of the packages that they have as well. So we can migrate workloads from Oracle over into an open source based solution. And give a lot cost effectiveness options to customers. >> Dave: Steal. This is a way that I can sort of have Oracle licensed database licensed and maintenance avoidance. >> Lenley: Yes. Yeah. >> Where possible, right. >> Where it makes sense. Where it makes sense. >> Obvious my quorum, I keep, but let's face it, the number one cost component of a TCO analysis of an Oracle customer is the database license and maintenance cost. >> Male Voice: That's right. >> It's not the people. One of the few examples I can think of where that's the case. There's always the people cost. [Male Voice] That's right, that's right. IT is very labor intensive. But for an Oracle customer, it's the database license. Cuz they license by Core. >> Male Voice: Yup. Cores are going through the roof. >> Male Voice: That's right. It's been great for Oracle's business. Although, wouldn't you agree, Oracle sees the writing on the wall that the SAS is really sort of the new control point for the industry. You see the acquisition of NetSuite and competition with Workday >> Male Voice: Yup. >> and the like. >> But the database remains the heart of the business. >> And really it's movement to the cloud, both private cloud and public cloud. And so we've been doing work there. We've had public cloud database as a service solution on Amazon for, what, [Marc] Four years. >> Four years, Marc. And have gained a lot experience with that. And were running that sort of running a retail, you can license the database and we'll provision it there. And so what we've done recently is change our perspective and said, let's put this into hands of customers. And let them standup their own database as a service. But also do it in a way that they can choose what workload should go to Amazon and what workload might go to their private cloud, built on open stack. And be able to arbitrage that if you will. Because they now have a way to provision the databases and make a choice about where to put it. >> So that's a bring your own license model that you just talked about? >> Bring your own license model or >> Are you in the Marketplace and, >> We're in the Marketplace in Amazon, where we can supply it that way. But customers have shown a preference for bring your own license. They want to make the best enterprise deal they can with a vendor like us or whomever else. And then have control over it. >> Amazon obviously wants you to be in the Marketplace. I won't even mention but I talked to some CEOs of database companies and they say, you know, we're in the Marketplace but we get in the Marketplace, next thing you know, Amazon is pushing them towards DynamoDB or you know. >> Male Voice: That's right, that's right. >> Now Amazon's come out with Aurora and Oracle migration and you know the intent to go after that business. Amazon's moving up the stack and you got to be careful. >> They are. But the thing about Amazon is that, they're a pure play in the cloud company. >> Dave: Yup. >> And all of the data shows that it's like a mix, it's going to be a hybrid cloud. Half the company in this world [Dave] Not Angie Jassie's data >> Eighty percent of the people in the cloud are going to be on-prem, still continuing their journey through virtualization. >> Dave: Yeah, that's right. >> Let along going to the cloud. But we want to be something that let's them put what they want in the public cloud and let's them manage on the private cloud in the same manner. So they can provision databases with a few clicks. Just like they do on Amazon. But do it in their data center. >> You doing that with Softlayer as well or not yet? >> Lenley: Not yet. >> Marc: Not yet. >> We've built this provisioning capability ourselves. And it came out of the work we did putting up databases on Amazon. >> So what are you guys doing here at Edge. Edge is kind of infrastructure show. Database is infrastructure. >> We're talking about our work with Power. >> Power is a big partner for us. Power is I think very, very interesting for our database customers. Because of the much higher clock speeds and the capabilities that the Power processor has. When I'm looking at Power, I get more oomph out of a single core which really for a database customer is very, very interesting. Because all databases are licensed by Core. >> Dave: Right. >> So it's a much better deal for the customer. And specifically for Postgres, Postgres scales very well with higher clock speeds. So by having, let's say, by growing performance, not by adding more cores but by making the individual cores faster, that plays very, very well to the Postgres capabilities. >> Okay, so you are a Power partner, part of that ecosystem that IBM is appealing to to grow the OpenPOWER base. And what kind of workloads are you seeing your customers demand and where you're having success? >> Across the board. Database is mostly infrastructure capabilities so there's a lot of interest that we're seeing that, for all kinds of applications really. >> What's the typical Power customer look like these days? You got some Oracle, you got some DB2, you guys are running on there, what's the mix? Paint the picture for us. >> I think the typical Power customer is the typical enterprise company. And, [Dave] Little bit of everything. >> It's a little bit of everything. But one of the key things is that, people are also looking at what they've got and the skills they have in place. You were talking about people cost right. [Dave] Yeah. >> And their understanding of management. Their understanding of how to manage the relationship with the vendor even. And then saying, look, how can I move into the new world of digital transformation and start my own private cloud options and things like that in an efficient way. That makes efficient use of hardware I have in place and has a growth curve and new hardware that's coming out that fits my workloads. >> Dave: Umhmm. >> And the profiles that Marc was talking about. >> And also the resources. Which is very interesting when we look at these new digital applications with Postgres. Because you can do so much in Postgres from geographic information systems to document oriented to key-value. But you can do that with your existing developers through existing DBAs. They don't need to go to school to learn a new database. And that's also a very, very, interesting capability. So you can use your existing team to do new stuff. [Male Voice] Yup. >> What's happening in IoT, what problems are you solving there and where's the limit? >> Sensor data collection. >> Lenley: Yeah. Real interesting because sensor data tends to come in all different forms. We have customer who collects temperature sensor, temperature data. But the sensors are all sending different data packets. So because we can do document oriented or key-value, we can easily accommodate that. In the old days with the relational model, I had to do all kinds of tricks to sort of stuff all that into a relational table. My table would be almost empty at the end because I'd have to add columns for every vendor et cetera. Here, now I can use put all that into the same format and provide it for analysis. So that's a real interesting capability. >> And it's interesting too because we've got really strong geo spacial data support. And the intersection of that, with IoT is a big deal. They track your iPhone, they know where we are. They know what's going on. That's sensor data. They know which lights in which building, which you know, louvers that are controlling HVAC are malfunctioning or not. They want to know specifically where it is, not just what the sensor is. And some of that stuff moves around. And it gets replaced in a new place in the building and such. So we're well setup to handle those types of workloads. >> What's interesting, when IBM bought the weather company, [Lenley] Yeah. >> And they thought okay great, they're getting all these data scientists and weather data, that's cool. They can monetize that but it's an IoT play, isn't it? [Male Voice] Right. Right. >> Talk about sensor. >> It's reference data. It's reference data for other company specific IoT plays. To have a broader set of sensors out there in their region and understand what's happening with weather and things. And then play that against what their experience is, managing new building or manufacturing processes, everything. >> So what's the engagement model. I'm a customer, I want to do business with you. How do I do it, how do I engage? >> Well, a lot of our businesses direct with us. Others through partners. And then a lot of customers come to us because they want to get off legacy systems. But really, what they do is, once they understand the database and the capabilities, they say, okay yeah, you can do the Oracle stuff. But what I'm really going to do with you is my new things. Because that's really exciting and it helps me kind of put a lid on the commercial license growth. So maybe I'm not going to get off it, but I will stop growing it. So I will start doing my new stuff on Postgres. Whenever I modernize something, Postgres is going to be my database of choice. If I already open up an application with its whole stack, this is one of the changes I'm going to make. And then the database as service, is very, very interesting. So these four entry vectors and what happens is, quite a few customers after a short time when they started with project or applications, they end up making Postgres as one of their database standards. Not the only one. But they make it one of the database standards so it gets into the catalog and every new project then has to consider Postgres. >> It's interesting, there's a space created as Microsoft sort of put all their wood behind the era of becoming a competitor to high end Oracle. And with this last release, they probably are on there, arguable. But they've also raised their prices too. And they've made the solution more complex. So there's this space that was vacated for like a ton of workloads and Postgres fits in there just about perfectly. We see enterprise after enterprise come to us with a sheet that says, now we're going to get some of this noSQL stuff. We're going to keep Oracle or DB2 over here for these really high end things. Run my financials, run my sales order processing, my manufacturing. And then we got this space in here. We got a slot for relational database and we want to go open source. Because of the cost savings. Because of other factors. It's ability to grow and not be bound to, hey, what if the vendor decides they're going to go for a new cooler thing and make me upgrade. >> Dave: Right. >> And I want to stay there and know that there's still being an investment made. And so there's a vibrant community around it. And it just fits that slot perfectly. >> You got to pay for that digital transformation and all these IoT initiates. You can't just keep pouring [Male Voice] Somehow. >> down to database licenses. [Male Voice] That's right. >> Tell me, we have to leave it there. >> Thanks very much >> Male Voice: Alright. >> for coming to theCUBE. >> Thanks so much. >> We appreciate the time. You welcome. [Male Voice] Enjoy it. Keep it right there buddy. We'll be right back with our next guest. This is theCUBE. We're live from IBM Edge 2016, be right back. (upbeat music)