>>We'll come back to the cubes coverage of AWS reinvent 2021, the industry's most important hybrid event. Very few hybrid events, of course, in the last two years. And the cube is excited to be here. Uh, this is our ninth year covering AWS reinvent this the 10th reinvent we're here with Joel Minnick, who the vice president of product and partner marketing at smoking hot company, Databricks and Greg Rokita, who is executive director of technology at Edmonds. If you're buying a car or leasing a car, you gotta go to Edmund's. We're gonna talk about busting data silos, guys. Great to see you again. >>Welcome. Welcome. Glad to be here. >>All right. So Joel, what the heck is a lake house? This is all over the place. Everybody's talking about lake house. What is it? >>And it did well in a nutshell, a Lakehouse is the ability to have one unified platform to handle all of your traditional analytics workloads. So your BI and reporting Trisha, the lake, the workloads that you would have for your data warehouse on the same platform as the workloads that you would have for data science and machine learning. And so if you think about kind of the way that, uh, most organizations have built their infrastructure in the cloud today, what we have is generally customers will land all their data in a data lake and a data lake is fantastic because it's low cost, it's open. It's able to handle lots of different kinds of data. Um, but the challenges that data lakes have is that they don't necessarily scale very well. It's very hard to govern data in a data lake house. It's very hard to manage that data in a data lake, sorry, in a, in a data lake. >>And so what happens is that customers then move the data out of a data lake into downstream systems and what they tend to move it into our data warehouses to handle those traditional reporting kinds of workloads that they have. And they do that because data warehouses are really great at being able to have really great scale, have really great performance. The challenge though, is that data warehouses really only work for structured data. And regardless of what kind of data warehouse you adopt, all data warehouse and platforms today are built on some kind of proprietary format. So once you've put that data into the data warehouse, that's, that is kind of what you're locked into. The promise of the data lake house was to say, look, what if we could strip away all of that complexity and having to move data back and forth between all these different systems and keep the data exactly where it is today and where it is today is in the data lake. >>And then being able to apply a transaction layer on top of that. And the Databricks case, we do that through a technology and open source technology called data lake, or sorry, Delta lake. And what Delta lake allows us to do is when you need it, apply that performance, that reliability, that quality, that scale that you would expect out of a data warehouse directly on your data lake. And if I can do that, then what I'm able to do now is operate from one single source of truth that handles all of my analytics workloads, both my traditional analytics workloads and my data science and machine learning workloads, and being able to have all of those workloads on one common platform. It means that now not only do I get much, much more simple in the way that my infrastructure works and therefore able to operate at much lower costs, able to get things to production much, much faster. >>Um, but I'm also able to now to leverage open source in a much bigger way being that lake house is inherently built on an open platform. Okay. So I'm no longer locked into any kind of data format. And finally, probably one of the most, uh, lasting benefits of a lake house is that all the roles that have to take that have to touch my data for my data engineers, to my data analyst, my data scientists, they're all working on the same data, which means that collaboration that has to happen to go answer really hard problems with data. I'm now able to do much, much more easy because those silos that traditionally exist inside of my environment no longer have to be there. And so Lakehouse is that is the promise to have one single source of truth, one unified platform for all of my data. Okay, >>Great. Thank you for that very cogent description of what a lake house is now. Let's I want to hear from the customer to see, okay, this is what he just said. True. So actually, let me ask you this, Greg, because the other problem that you, you didn't mention about the data lake is that with no schema on, right, it gets messy and Databricks, I think, correct me if I'm wrong, has begun to solve that problem, right? Through series of tooling and AI. That's what Delta liked us. It's a man, like it's a managed service. Everybody thought you were going to be like the cloud era of spark and Brittany Britain, a brilliant move to create a managed service. And it's worked great. Now everybody has a managed service, but so can you paint a picture at Edmonds as to what you're doing with, maybe take us through your journey the early days of a dupe, a data lake. Oh, that sounds good. Throw it in there, paint a picture as to how you guys are using data and then tie it into what y'all just said. >>As Joel said, that they'll the, it simplifies the architecture quite a bit. Um, in a modern enterprise, you have to deal with a variety of different data sources, structured semi-structured and unstructured in the form of images and videos. And with Delta lake and built a lake, you can have one system that handles all those data sources. So what that does is that basically removes the issue of multiple systems that you have to administer. It lowers the cost, and it provides consistency. If you have multiple systems that deal with data, you always arise as the issue as to which data has to be loaded into which system. And then you have issues with consistency. Once you have issues with consistency, business users, as analysts will stop trusting your data. So that was very critical for us to unify the system of data handling in the one place. >>Additionally, you have a massive scalability. So, um, I went to the talk with from apple saying that, you know, he can process two years worth of data. Instead of just two days in an Edmonds, we have this use case of backfilling the data. So often we changed the logic and went to new. We need to reprocess massive amounts of data with the lake house. We can reprocess months worth of data in, in a matter of minutes or hours. And additionally at the data lake houses based on open, uh, open standards, like parquet that allowed us, allowed us to basically hope open source and third-party tools on top of the Delta lake house. Um, for example, a Mattson, we use a Matson for data discovery, and finally, uh, the lake house approach allows us for different skillsets of people to work on the same source data. We have analysts, we have, uh, data engineers, we have statisticians and data scientists using their own programming languages, but working on the same core of data sets without worrying about duplicating data and consistency issues between the teams. >>So what, what is, what are the primary use cases where you're using house Lakehouse Delta? >>So, um, we work, uh, we have several use cases, one of them more interesting and important use cases as vehicle pricing, you have used the Edmonds. So, you know, you go to our website and you use it to research vehicles, but it turns out that pricing and knowing whether you're getting a good or bad deal is critical for our, uh, for our business. So with the lake house, we were able to develop a data pipeline that ingests the transactions, curates the transactions, cleans them, and then feeds that curated a curated feed into the machine learning model that is also deployed on the lake house. So you have one system that handles this huge complexity. And, um, as you know, it's very hard to find unicorns that know all those technologies, but because we have flexibility of using Scala, Java, uh, Python and SQL, we have different people working on different parts of that pipeline on the same system and on the same data. So, um, having Lakehouse really enabled us to be very agile and allowed us to deploy new sources easily when we, when they arrived and fine tune the model to decrease the error rates for the price prediction. So that process is ongoing and it's, it's a very agile process that kind of takes advantage of the, of the different skill sets of different people on one system. >>Because you know, you guys democratized by car buying, well, at least the data around car buying because as a consumer now, you know, I know what they're paying and I can go in of course, but they changed their algorithms as well. I mean, the, the dealers got really smart and then they got kickbacks from the manufacturer. So you had to get smarter. So it's, it's, it's a moving target, I guess. >>Great. The pricing is actually very complex. Like I, I don't have time to explain it to you, but knowing, especially in this crazy market inflationary market where used car prices are like 38% higher year over year, and new car prices are like 10% higher and they're changing rapidly. So having very responsive pricing model is, is extremely critical. Uh, you, I don't know if you're familiar with Zillow. I mean, they almost went out of business because they mispriced their, uh, their houses. So, so if you own their stock, you probably under shorthand of it, but, you know, >>No, but it's true because I, my lease came up in the middle of the pandemic and I went to Edmonds, say, what's this car worth? It was worth like $7,000. More than that. Then the buyout costs the residual value. I said, I'm taking it, can't pass up that deal. And so you have to be flexible. You're saying the premises though, that open source technology and Delta lake and lake house enabled that flexible. >>Yes, we are able to ingest new transactions daily recalculate our model within less than an hour and deploy the new model with new pricing, you know, almost real time. So, uh, in this environment, it's very critical that you kind of keep up to date and ingest their latest transactions as they prices change and recalculate your model that predicts the future prices. >>Because the business lines inside of Edmond interact with the data teams, you mentioned data engineers, data scientists, analysts, how do the business people get access to their data? >>Originally, we only had a core team that was using Lakehouse, but because the usage was so powerful and easy, we were able to democratize it across our units. So other teams within software engineering picked it up and then analysts picked it up. And then even business users started using the dashboarding and seeing, you know, how the price has changed over time and seeing other, other metrics within the, >>What did that do for data quality? Because I feel like if I'm a business person, I might have context of the data that an analyst might not have. If they're part of a team that's servicing all these lines of business, did you find that the data quality, the collaboration affected data? >>Th the biggest thing for us was the fact that we don't have multiple systems now. So you don't have to load the data. Whenever you have to load the data from one system to another, there is always a lag. There's always a delay. There is always a problematic job that didn't do the copy correctly. And the quality is uncertain. You don't know which system tells you the truth. Now we just have one layer of data. Whether you do reports, whether you're data processing or whether you do modeling, they all read the same data. And the second thing is that with the dashboarding capabilities, people that were not very technical that before we could only use Tableau and Tableau is not the easiest thing to use as if you're not technical. Now they can use it. So anyone can see how our pricing data looks, whether you're an executive, whether you're an analyst or a casual business users, >>But Hey, so many questions, you guys are gonna have to combat. I'm gonna run out of time, but you now allow a consumer to buy a car directly. Yes. Right? So that's a new service that you launched. I presume that required new data. We give, we >>Give consumers offers. Yes. And, and that offer you >>Offered to buy my league. >>Exactly. And that offer leverages the pricing that we develop on top of the lake house. So the most important thing is accurately giving you a very good offer price, right? So if we give you a price, that's not so good. You're going to go somewhere else. If we give you price, that's too high, we're going to go bankrupt like Zillow debt, right. >>It took to enable that you're working off the same dataset. Yes. You're going to have to spin up a, did you have to inject new data? Was there a new data source that we're working on? >>Once we curate the data sources and once we clean it, we see the directly to the model. And all of those components are running on the lake house, whether you're curating the data, cleaning it or running the model. The nice thing about lake house is that machine learning is the first class citizen. If you use something like snowflake, I'm not going to slam snowflake here, but you >>Have two different use case. You have >>To, you have to load it into a different system later. You have to load it into a different system. So like good luck doing machine learning on snowflake. Right. >>Whereas, whereas Databricks, that's kind of your raison d'etre >>So what are your, your, your data engineer? I feel like I should be a salesman or something. Yeah. I'm not, I'm not saying that. Just, just because, you know, I was told to, like, I'm saying it because of that's our use case, >>Your use case. So question for each of you, what, what business results did you see when you went to kind of pre lake house, post lake house? What are the, any metrics you can share? And then I wonder, Joel, if you could share a sort of broader what you're seeing across your customer base, but Greg, what can you tell us? Well, >>Uh, before their lake house, we had two different systems. We had one for processing, which was still data breaks. And the second one for serving and we iterated over Nateeza or Redshift, but we figured that maintaining two different system and loading data from one to the other was a huge overhead administration security costs. Um, the fact that you had to consistency issues. So the fact that you can have one system, um, with, uh, centralized data, solves all those issues. You have to have one security mechanism, one administrative mechanism, and you don't have to load the data from one system to the other. You don't have to make compromises. >>It's scale is not a problem because of the cloud, >>Because you can spend clusters at will for different use cases. So your clusters are independent. You have processing clusters that are not affecting your serving clusters. So, um, in the past, if you were running a serving, say on Nateeza or Redshift, if you were doing heavy processing, your reports would be affected, but now all those clusters are separated. So >>Consumer data consumer can take that data from the producer independ >>Using its own cluster. Okay. >>Yeah. I'll give you the final word, Joel. I know it's been, I said, you guys got to come back. This is what have you seen broadly? >>Yeah. Well, I mean, I think Greg's point about scale. It's an interesting one. So if you look at cross the entire Databricks platform, the platform is launching 9 million VMs every day. Um, and we're in total processing over nine exabytes a month. So in terms of just how much data the platform is able to flow through it, uh, and still maintain a extremely high performance is, is bar none out there. And then in terms of, if you look at just kind of the macro environment of what's happening out there, you know, I think what's been most exciting to watch or what customers are experiencing traditionally or, uh, on the traditional data warehouse and kinds of workloads, because I think that's where the promise of lake house really comes into its own is saying, yes, I can run these traditional data warehousing workloads that require a high concurrency high scale, high performance directly on my data lake. >>And, uh, I think probably the two most salient data points to raise up there is, uh, just last month, Databricks announced it's set the world record for the, for the, uh, TPC D S 100 terabyte benchmark. So that is a place where Databricks at the lake house architecture, that benchmark is built to measure data warehouse performance and the lake house beat data warehouse and sat their own game in terms of overall performance. And then what's that spends from a price performance standpoint, it's customers on Databricks right now are able to enjoy that level of performance at 12 X better price performance than what cloud data warehouses provide. So not only are we jumping on this extremely high scale and performance, but we're able to do it much, much more efficiently. >>We're gonna need a whole nother section second segment to talk about benchmarking that guys. Thanks so much, really interesting session and thank you and best of luck to both join the show. Thank you for having us. Very welcome. Okay. Keep it right there. Everybody you're watching the cube, the leader in high-tech coverage at AWS reinvent 2021

(upbeat music) >> Announcer: Live from San Francisco, It's the Cube. Covering Red Hat Summit 2018. Brought to you buy, Red Hat. >> Okay, welcome back everyone. We're live here in the Cube in San Francisco, California, Monscone West, Cube's exclusive coverage of Red Hat Summit 2018. I'm John Furrier, co-host. With John Troyer, he's my analyst co- host, he's the co -founder of Tech Reckoning Advisory and Community Development Firm. My next guest is Marco Bill-Peter, Senior vice-president of Customer Experience and Engagement at Red Hat. Welcome back to the Cube. Good to see you. So, you guys have a great track record with customer support. You guys use gold standard in open source, you've done it well, very reliable. It's a changing world. You know, Open Shift now, certainly the center piece, west, new acquisition. A lot of things happening with in the portfolio. Cloud native new capabilities are on the horizon. So, you've got to figure it out. So, what's the support strategy? What do you guys do? How are you looking? I'm sure it's challenging but never too much of a challenge for you guys. You're smart, what's the support strategy? >> I think the recipe it is really like not getting stuck in a wave, right? And be open to, you know I think Jim Whitehurst and his keynote talk quite a bit about, you used to do all plan, describe and execute. That thing just doesn't work, right? Because supporting customers on Linux, supporting them when they move to Open Shift or even application, is a whole different piece. So, as a leader you got to be flexible as in okay, here we do it this way, let's put more money in this. Let's say Open Shift support, Open Shift kind of, what's the customer experience there, right? Kind of figure out how it works. There's a lot of things that scare me in the daily business as in like okay, we can't do that. But I think Red Hat is really good in reconfiguring, Jim talked about that in a keynote as well, reconfiguring the organization. And so, we move for example, quality assurance into my organization and combining that with support. All of them give some more opportunities realizing, oh this product maybe not ready yet for the market, right? We can not support that. Or, you augmented with, I wouldn't call it AI capabilities, but more like those capabilities. All of the sudden stuff gets done automatically. >> And multi cloud is again, just like multi vendor environment, but it's a little bit different obviously. But multiple clouds you have different architectures. You guys do some progressive things. What's new, architecturally within the support group? Because you have deals announced here with IBM and Microsoft, one of them is a joint, I think integrated program where guys are teaming up. >> Microsoft is interesting. >> We've teamed last three, four years, right? With he first deal and gone further. You're like funny, right? I've been at Red Hat so long and you put people on premise. It's kind of funny. But it's good, right? And that's where you got to glue together. Sometimes it's people. Sometimes it's also more having the data, right? I mean if you go multi cloud. Difference between multi vendor, multi cloud. Multi vendor, you just call the vendor and tell them hey you handle it. Here, I'll put data, you handle it. Or maybe you do it a bit better. But, multi cloud is, well it's running there, how do you get access to that? Then the whole privacy laws comes in. So you got to be more instrumentation, you know, telemetry-- >> You're using tech to help you guys out. That's what you're referring by AI. >> I actually think that the next ten years you will see support changing quite a bit. >> John: In what way? >> But also you have to staff this up, right? You need to upscale your folks as well as technology. >> That doesn't go away. But I think you've got to go more that you really need deep skills. If you want to support Open Shift you've got to, either you understand it from the middle side, from the application side or from the bottom from the infrastructure. You need both skill sets. So you need really highly skilled people. But one the other hand if it's really like real time and people don't have patience to wait two weeks, especially if you're in the cloud. More and more tooling. I see the vision as in it would be less and less based on the scale but I think it's less people involved more and more automation, tooling. >> You kind of see it now with boss, kind of just tip of the iceberg. But you've got automation built into the culture of Red Hat. You've put coral west. They want to automate everything. >> You see Insights, right? We launched Insights three years ago out of support. They take support data, find out what's really happening, create rules that if you match it the customer systems say you have this and this issue. And now it's in the incentive stage of the strategy as in we can automate it, but you can automate it. you have a problem, you want to have it solved. >> You're presenting a support service. >> Exactly, and eventually, we'll not even tell you, in maybe hindsight we'll tell you, hey, you had this network issue or configured the wrong way, we fixed it have a good day. >> Well it came up in Cooper Netty's conversation we had last week in Copenhagen, we were in Denmark for CubeCon around things Cooper Netty's defacto standing, so great stuff, that's certainly great. Istio service mesh is atopic that's highly discussed. And one of the thing that comes up is the automation the down side is potentially it fixes things. So, you could have a memory leak for instance, that you never know gets fixed. But it just crashes every day and reboots itself. So, the new kinds of instrumentation that's emerging. So this is really the though job. >> Yeah. Yeah. >> How do you get in there-- >> Also have automation-- >> And you as the central provider, right, are pulling in data from across the world and across the customer base. So how do you take that, sift it to be more proactive about decision making and support. >> So we capture all this support data. And you know it's fascinating, we have some AI capabilities, some machine learning capabilities go through there. But it's fascinating, sometimes we see new issues coming up. What we do is then, we go well let's look who is exposed to that, just to get a footprint. And then you actually inform customers, hey, you had this and this issue or you have this. It's really a different, I want to get more proactive or I want to get more automated. With the automation I just want to be, right, so we installed, over the last, I would say 18 months, like a bot, simple bot basically, his name is Edmond. And he works on support cases. And we started slow, very slow. We didn't let it go as in total machine or anything. But now, I gave some stats earlier today. In one used case it's 25 percent faster solving a customer issue using Edmond. And he participates in 11 percent of all support cases. >> Wow. >> Edmond is a busy guy. >> And the game is changing too. I mean in the old days, first lines support, second lines support, offline support, then escalation. These things are older IT mechanisms. With this you're talking about completely doing away with, in essence first line support. But also first line support might come in, from say a Microsoft or an IBM. You've got to be ready for anything. >> Actually I think it's not just first line support. And it's not replacing them. It's helping them. It's really making them faster, right? I think the frustration piece is, like, customer opens his support case, some data is missing, right? So, you have a que it gets to that. Engineering looks and oh, there's data missing. Edmond sees that and says hey, I need this data. Based on all the support cases we fixed similar issues, this is the data we need. So Edmond gets the data ready, engineer looks and in some cases Edmond actually closes it out. >> Closes it out. >> Tells the customer here there's a better solution, do it this way. >> Yeah, that's fascinating. >> I'd love to pull the camera back a little bit, right? You are not the SVP of support. You're the SVP of customer experience and engagement, right? That's an entirely different role in some ways, in that you're responsible for customer success at some level. >> That is correct, yeah. >> Talk a little bit about reconfiguring organization to be that-- >> So I think maybe dive in a little bit on the customer success. So we have a organization, they call technical account. It's part of the customer success organization. That's a human business but it's fascinating, right. We put these claims on clients and have them work together. They understand the business. It's an old business but trust me, having still a human in there understanding, okay this is customer x, y, z. That's the business objective, I talked about this today as well, not to forget, hey this customer actually wants to do whatever, whatever on the like an SIP to actually take that further to actually support case and doing that the team helps quite a bit. And then also the commitment, right? We don't want just to do support cases and then that's why you renew with Red Head, we want to make sure you actually get value out of it and that's why you want to renew. So that's why we configured different. It's bigger, right? It's bigger as in really making sure the product is correct. So that's why quality assurance is in my team, this support. That's why I run internal IT for the engineering team. We run the stuff that we sell actually earlier. And some of my team is like, Marco why do we have to do that? Because we learn and I much rather have you feel the pain than the customer feel the pain. That's why we configure different than, I've been 12 a half years right on this and it's still exciting that we are still able to change around-- >> I think the quality assurance piece is still big too cause you're in there as well. Looking at the QA. >> Yeah. >> Making sure that's good too. You're testing out the products and doing QA all within the mindset of customer experience. >> Exactly, and you've got to move that being agile, is more you see developers actually submitting test cases. Tests, so that's the component testing and the basic tests. What we got to do more, is what you mentioned, if somebody does less with Open Shift to contain all that, that thing together, if some service software defines storage, that thing together to bring together that's the hard drive. So I want to move more and more. That we take used spaces from customers, we'll close it. This is how we do it. X, y, z, customer and apply that. >> At the end of the day it's the same game different playing field. The customer wants choice, best possible solution experience, for them. You guys got to enable that, and then support it, make it happen. >> Yeah. >> And with cloud. >> And you see how, I don't know if you saw the demo yesterday when they show basically I think or Amazon was slower and every traffic that routed. This is reality as well, right? I mean if you look at one press release we did yesterday, I just find it a fascinating story. They're kitchen appliances. I don't know if you saw that. But they have over a million kitchen appliances or cooking appliances connected to the internet. It's a German, Swiss company when they got to upgrade the system so they get recipes done, they actually spin up instances in Alibaba in Asia and I think in Amazon in the U.S. They spin it up, they scale out all the appliances connect then they shrink it together. How do you support these customers a whole different case. >> That's great for the customer. >> Yeah. >> But more of a challenge for you guys. >> Then again with preparation of the right integration testing before, with the right set up that we know this is what the customer is doing this weekend. Amadeus as well, talked at the keynote, we worked long time with Amadeus. >> You're a smart team. >> As part of your customer role, you were involved with the Innovation awards. They were up on stage this morning. What struck me was they were both about time to value. And speed of deployment as well as scale. Often these were global companies, we had Amadeus on yesterday, spanning the globe. Huge number of transactions. Anything stand out to you in those Innovation Awards this year? Perhaps, that's been different in previous years? I think that the scale is actually interesting that you say. I think we have much quicker now. I think that's awesome, technology matures. I think we used to have more smaller work projects in getting to a certain scale. But I just goes faster. I think the controlled piece is probably a bit more accepted. This whole containerization is not magic anymore. I think a lot is being moved, is coming from the development side but also from the Linux side. So I think there's a less struggle of that. But I do still see some cultural struggles. You talk to customers, maybe not the Innovation Award winners. but even them they say, hey it took us a long time to convince internal structures, how we change things around. >> Talk about the open source role because you mentioned, before we came on how you guys are all in the open, an open source. Is there like a project that you're part of that supports centric? Is there certain things you're picking out over the source? As you guys do the QA and build you own stuff. >> Yeah we do a lot. We submit a lot to open. There's very few. We don't share data. We can't share customer data for obvious reasons. But tooling, most of the tooling we share if it's data collectors. We re an open source road. There' not much that we don't, there's nothing proprietary. Engineers, that's why they're coming to write. That's the configuration. They want to see, hey how does this stuff get applied. They own the packages, then some stuff is shared. If it's tied to the customer portal, the AI pieces maybe the open source parts of it but-- >> What's it like this year, for the folks who are watching who couldn't make it? What's the vibe here at Red Hat Summit 2018? What's the hallway conversations like? What's some of the dinners? What are you talking about? What's the chatter? >> I think the big chatter for me is kind of like this Open Shift, containers, agile development. You know the agile development comes back and back and really like how do we do this right? And tech connects obviously, how do you take application develop them or how do you take applications put them in a container. And then you see these demos. With multi cloud. >> New applications is not stand alone Linux anymore. >> Yeah. We have containers and tend to be able to run public cloud or multi cloud on premise. The options are endless. And I think that's the strengths from Red Hat. We prove that with Linux we can have a solid API. We don't screw up the applications. And if we can guarantee that across the four footprints, that's Paul's vision five, six years ago. I think we are there. >> You talked about a bit of cultural shift. How can Red Hat help it's customers come up to speed? That's a little bit...but be more agile. >> It's a good example. I think we do a lot of these sessions. I actually think that our sales motion, they are pretty aware with open sources, what the culture is. They do a lot of these sessions with customers. Jim Whitehurst is actually awesome. When he comes to clients. We did a C level event at a bank, based in Zurich and it was in a Swiss bank. And I think that they got like 140 C level, CIO groups. And Jim did a talk about the open organization about breaking down the barriers. I think that's a role that we play. Well some is Red Hat's role, but we go to do that stuff. Because we can share part of it in how we are configured, how we are different. >> I think that kind of thing is high on every CIO's list of agendas. >> And everything in the open is proving that open is winning. Open beats closed pretty much every time and is now pretty standard operating wise we're starting to see but operational wise, not just for software development. >> I actually think that from practice and how to run the company. Some stuff is transparency, right? If you work in a company that you're not transparent with your associates, can you really do this in 2018? >> No. >> And so I think those are elements that I think we do well to have had. And we got to keep internal as well, reminding ourselves, these core principles from open source are really important. >> Hiring, so you're bringing new Red Hatters in? >> At the rate we are hiring it's actually big concerns. How do we maintain this culture, right. This talk is not always polite but it's the way we function. >> You guys are humble. You're playing the long game, I love that about you. So congratulations Marco. Thanks for coming on the Cube show. >> Thanks very much. >> Thanks. >> It's the Cube Live here in San Francisco for Red Hat Summit 2018 here in Moscone West. I'm John Furrier and John Troyer. Stay with us for more live coverage after this short break. (upbeat music)