>> From every ISV to solve the problems. You want there to be tools in place that you can use, either open source tools or whatever it is that help you build it. And slowly over time, that building will become easier and easier. So my question to you was, where do you see you playing? Do you see yourself playing to ISVs as a set of tools, which will make their life a lot easier and provide that work? >> Absolutely. >> If they don't have, so they don't have to do it. Or you're providing this for the end users? Or both? >> So it's a progression. If you go to the ISVs first, you're doomed to starved before you have time for that other option. >> Yeah. >> Right? So it's a question of phase, the phasing of it. And also if you go directly to end users, you can demonstrate the power of it and get the attention of the ISVs. I believe that the ISVs, especially those with the biggest footprints and the most, you know, coveted estates, they have already made massive investments at trying to solve decentralization of their software stack. And I believe that they have used it as a hook to try to move to a software as a service model and rope people into leasing their infrastructure. So if you look at the clouds that have been propped up by Autodesk or by Adobe, or you name the company, they are building proprietary makeshift solutions for decentralizing or hybrid clouding. Or maybe they're not even doing that at all and all they're is saying hey, if you want to get location agnosticness, then what you should just, is just move into our cloud. >> Right. >> And then they try to solve on the background how to decentralize it between different regions so they can have decent offerings in each region. But those who are more advanced have already made larger investments and will be more averse to, you know, throwing that stuff away, all of their makeshift machinery away, and using a platform that gives them high performance parallel, low level file system access, while at the same time having metadata-driven, you know, policy-based, intent-based orchestration to manage the diffusion of data across a decentralized infrastructure. They are not going to be as open because they've made such an investment and they're going to look at how do they monetize it. So what we have found with like the movie studios who are using us already, many of the app they're using, many of those software offerings, the ISVs have their own cloud that offers that software for the cloud. But what we got when I asked about this, 'cause I was dealt specifically into this question because I'm very interested to know how we're going to make that leap from end user upstream into the ISVs where I believe we need to, and they said, look, we cannot use these software ISV-specific SAS clouds for two reasons. Number one is we lose control of the data. We're giving it to them. That's security and other issues. And here you're talking about we're doing work for Disney, we're doing work for Netflix, and they're not going to let us put our data on those software clouds, on those SAS clouds. Secondly, in any reasonable pipeline, the data is shared by many different applications. We need to be agnostic as to the application. 'Cause the inputs to one application, you know, the output for one application provides the input to the next, and it's not necessarily from the same vendor. So they need to have a data platform that lets them, you know, go from one software stack, and you know, to run it on another. Because they might do the rendering with this and yet, they do the editing with that, and you know, et cetera, et cetera. So I think the further you go up the stack in the structured data and dedicated applications for specific functions in specific verticals, the further up the stack you go, the harder it is to justify a SAS offering where you're basically telling the end users you need to park all your data with us and then you can run your application in our cloud and get this. That ultimately is a dead end path versus having the data be open and available to many applications across this supercloud layer. >> Okay, so-- >> Is that making any sense? >> Yes, so if I could just ask a clarifying question. So, if I had to take Snowflake as an example, I think they're doing exactly what you're saying is a dead end, put everything into our proprietary system and then we'll figure out how to distribute it. >> Yeah. >> And and I think if you're familiar with Zhamak Dehghaniis' data mesh concept. Are you? >> A little bit, yeah. >> But in her model, Snowflake, a Snowflake warehouse is just a node on the mesh and that mesh is-- >> That's right. >> Ultimately the supercloud and you're an enabler of that is what I'm hearing. >> That's right. What they're doing up at the structured level and what they're talking about at the structured level we're doing at the underlying, unstructured level, which by the way has implications for how you implement those distributed database things. In other words, implementing a Snowflake on top of Hammerspace would have made building stuff like in the first place easier. It would allow you to easily shift and run the database engine anywhere. You still have to solve how to shard and distribute at the transaction layer above, so I'm not saying we're a substitute for what you need to do at the app layer. By the way, there is another example of that and that's Microsoft Office, right? It's one thing to share that, to have a file share where you can share all the docs. It's something else to have Word and PowerPoint, Excel know how to allow people to be simultaneously editing the same doc. That's always going to happen in the app layer. But not all applications need that level of, you know, in-app decentralization. You know, many of them, many workflows are pipelined, especially the ones that are very data intensive where you're doing drug discovery or you're doing rendering, or you're doing machine learning training. These things are human in the loop with large stages of processing across tens of thousands of cores. And I think that kind of data processing pipeline is what we're focusing on first. Not so much the Microsoft Office or the Snowflake, you know, parking a relational database because that takes a lot of application layer stuff and that's what they're good at. >> Right. >> But I think... >> Go ahead, sorry. >> Later entrance in these markets will find Hammerspace as a way to accelerate their work so they can focus more narrowly on just the stuff that's app-specific, higher level sharing in the app. >> Yes, Snowflake founders-- >> I think it might be worth mentioning also, just keep this confidential guys, but one of our customers is Blue Origin. And one of the things that we have found is kind of the point of what you're talking about with our customers. They're needing to build this and since it's not commercially available or they don't know where to look for it to be commercially available, they're all building themselves. So this layer is needed. And Blue is just one of the examples of quite a few we're now talking to. And like manufacturing, HPC, research where they're out trying to solve this problem with their own scripting tools and things like that. And I just, I don't know if there's anything you want to add, David, but you know, but there's definitely a demand here and customers are trying to figure out how to solve it beyond what Hammerspace is doing. Like the need is so great that they're just putting developers on trying to do it themselves. >> Well, and you know, Snowflake founders, they didn't have a Hammerspace to lean on. But, one of the things that's interesting about supercloud is we feel as though industry clouds will emerge, that as part of company's digital transformations, they will, you know, every company's a software company, they'll begin to build their own clouds and they will be able to use a Hammerspace to do that. >> A super pass layer. >> Yes. It's really, I don't know if David's speaking, I don't want to speak over him, but we can't hear you. May be going through a bad... >> Well, a regional, regional talks that make that possible. And so they're doing these render farms and editing farms, and it's a cloud-specific to the types of workflows in the median entertainment world. Or clouds specifically to workflows in the chip design world or in the drug and bio and life sciences exploration world. There are large organizations that are kind of a blend of end users, like the Broad, which has their own kind of cloud where they're asking collaborators to come in and work with them. So it starts to even blur who's an end user versus an ISV. >> Yes. >> Right? When you start talking about the massive data is the main gravity is to having lots of people participate. >> Yep, and that's where the value is. And that's where the value is. And this is a megatrend that we see. And so it's really important for us to get to the point of what is and what is not a supercloud and, you know, that's where we're trying to evolve. >> Let's talk about this for a second 'cause I want to, I want to challenge you on something and it's something that I got challenged on and it has led me to thinking differently than I did at first, which Molly can attest to. Okay? So, we have been looking for a way to talk about the concept of cloud of utility computing, run anything anywhere that isn't addressed in today's realization of cloud. 'Cause today's cloud is not run anything anywhere, it's quite the opposite. You park your data in AWS and that's where you run stuff. And you pretty much have to. Same with with Azure. They're using data gravity to keep you captive there, just like the old infrastructure guys did. But now it's even worse because it's coupled back with the software to some degree, as well. And you have to use their storage, networking, and compute. It's not, I mean it fell back to the mainframe era. Anyhow, so I love the concept of supercloud. By the way, I was going to suggest that a better term might be hyper cloud since hyper speaks to the multidimensionality of it and the ability to be in a, you know, be in a different dimension, a different plane of existence kind of thing like hyperspace. But super and hyper are somewhat synonyms. I mean, you have hyper cars and you have super cars and blah, blah, blah. I happen to like hyper maybe also because it ties into the whole Hammerspace notion of a hyper-dimensional, you know, reality, having your data centers connected by a wormhole that is Hammerspace. But regardless, what I got challenged on is calling it something different at all versus simply saying, this is what cloud has always meant to be. This is the true cloud, this is real cloud, this is cloud. And I think back to what happened, you'll remember, at Fusion IO we talked about IO memory and we did that because people had a conceptualization of what an SSD was. And an SSD back then was low capacity, low endurance, made to go military, aerospace where things needed to be rugged but was completely useless in the data center. And we needed people to imagine this thing as being able to displace entire SAND, with the kind of capacity density, performance density, endurance. And so we talked IO memory, we could have said enterprise SSD, and that's what the industry now refers to for that concept. What will people be saying five and 10 years from now? Will they simply say, well this is cloud as it was always meant to be where you are truly able to run anything anywhere and have not only the same APIs, but you're same data available with high performance access, all forms of access, block file and object everywhere. So yeah. And I wonder, and this is just me throwing it out there, I wonder if, well, there's trade offs, right? Giving it a new moniker, supercloud, versus simply talking about how cloud is always intended to be and what it was meant to be, you know, the real cloud or true cloud, there are trade-offs. By putting a name on it and branding it, that lets people talk about it and understand they're talking about something different. But it also is that an affront to people who thought that that's what they already had. >> What's different, what's new? Yes, and so we've given a lot of thought to this. >> Right, it's like you. >> And it's because we've been asked that why does the industry need a new term, and we've tried to address some of that. But some of the inside baseball that we haven't shared is, you remember the Web 2.0, back then? >> Yep. >> Web 2.0 was the same thing. And I remember Tim Burners Lee saying, "Why do we need Web 2.0? "This is what the Web was always supposed to be." But the truth is-- >> I know, that was another perfect-- >> But the truth is it wasn't, number one. Number two, everybody hated the Web 2.0 term. John Furrier was actually in the middle of it all. And then it created this groundswell. So one of the things we wrote about is that supercloud is an evocative term that catalyzes debate and conversation, which is what we like, of course. And maybe that's self-serving. But yeah, HyperCloud, Metacloud, super, meaning, it's funny because super came from Latin supra, above, it was never the superlative. But the superlative was a convenient byproduct that caused a lot of friction and flack, which again, in the media business is like a perfect storm brewing. >> The bad thing to have to, and I think you do need to shake people out of their, the complacency of the limitations that they're used to. And I'll tell you what, the fact that you even have the terms hybrid cloud, multi-cloud, private cloud, edge computing, those are all just referring to the different boundaries that isolate the silo that is the current limited cloud. >> Right. >> So if I heard correctly, what just, in terms of us defining what is and what isn't in supercloud, you would say traditional applications which have to run in a certain place, in a certain cloud can't run anywhere else, would be the stuff that you would not put in as being addressed by supercloud. And over time, you would want to be able to run the data where you want to and in any of those concepts. >> Or even modern apps, right? Or even modern apps that are siloed in SAS within an individual cloud, right? >> So yeah, I guess it's twofold. Number one, if you're going at the high application layers, there's lots of ways that you can give the appearance of anything running anywhere. The ISV, the SAS vendor can engineer stuff to have the ability to serve with low enough latency to different geographies, right? So if you go too high up the stack, it kind of loses its meaning because there's lots of different ways to make due and give the appearance of omni-presence of the service. Okay? As you come down more towards the platform layer, it gets harder and harder to mask the fact that supercloud is something entirely different than just a good regionally-distributed SAS service. So I don't think you, I don't think you can distinguish supercloud if you go too high up the stack because it's just SAS, it's just a good SAS service where the SAS vendor has done the hard work to give you low latency access from different geographic regions. >> Yeah, so this is one of the hardest things, David. >> Common among them. >> Yeah, this is really an important point. This is one of the things I've had the most trouble with is why is this not just SAS? >> So you dilute your message when you go up to the SAS layer. If you were to focus most of this around the super pass layer, the how can you host applications and run them anywhere and not host this, not run a service, not have a service available everywhere. So how can you take any application, even applications that are written, you know, in a traditional legacy data center fashion and be able to run them anywhere and have them have their binaries and their datasets and the runtime environment and the infrastructure to start them and stop them? You know, the jobs, the, what the Kubernetes, the job scheduler? What we're really talking about here, what I think we're really talking about here is building the operating system for a decentralized cloud. What is the operating system, the operating environment for a decentralized cloud? Where you can, and that the main two functions of an operating system or an operating environment are the process scheduler, the thing that's scheduling what is running where and when and so forth, and the file system, right? The thing that's supplying a common view and access to data. So when we talk about this, I think that the strongest argument for supercloud is made when you go down to the platform layer and talk of it, talk about it as an operating environment on which you can run all forms of applications. >> Would you exclude--? >> Not a specific application that's been engineered as a SAS. (audio distortion) >> He'll come back. >> Are you there? >> Yeah, yeah, you just cut out for a minute. >> I lost your last statement when you broke up. >> We heard you, you said that not the specific application. So would you exclude Snowflake from supercloud? >> Frankly, I would. I would. Because, well, and this is kind of hard to do because Snowflake doesn't like to, Frank doesn't like to talk about Snowflake as a SAS service. It has a negative connotation. >> But it is. >> I know, we all know it is. We all know it is and because it is, yes, I would exclude them. >> I think I actually have him on camera. >> There's nothing in common. >> I think I have him on camera or maybe Benoit as saying, "Well, we are a SAS." I think it's Slootman. I think I said to Slootman, "I know you don't like to say you're a SAS." And I think he said, "Well, we are a SAS." >> Because again, if you go to the top of the application stack, there's any number of ways you can give it location agnostic function or you know, regional, local stuff. It's like let's solve the location problem by having me be your one location. How can it be decentralized if you're centralizing on (audio distortion)? >> Well, it's more decentralized than if it's all in one cloud. So let me actually, so the spectrum. So again, in the spirit of what is and what isn't, I think it's safe to say Hammerspace is supercloud. I think there's no debate there, right? Certainly among this crowd. And I think we can all agree that Dell, Dell Storage is not supercloud. Where it gets fuzzy is this Snowflake example or even, how about a, how about a Cohesity that instantiates its stack in different cloud regions in different clouds, and synchronizes, however magic sauce it does that. Is that a supercloud? I mean, so I'm cautious about having too strict of a definition 'cause then only-- >> Fair enough, fair enough. >> But I could use your help and thoughts on that. >> So I think we're talking about two different spectrums here. One is the spectrum of platform to application-specific. As you go up the application stack and it becomes this specific thing. Or you go up to the more and more structured where it's serving a specific application function where it's more of a SAS thing. I think it's harder to call a SAS service a supercloud. And I would argue that the reason there, and what you're lacking in the definition is to talk about it as general purpose. Okay? Now, that said, a data warehouse is general purpose at the structured data level. So you could make the argument for why Snowflake is a supercloud by saying that it is a general purpose platform for doing lots of different things. It's just one at a higher level up at the structured data level. So one spectrum is the high level going from platform to, you know, unstructured data to structured data to very application-specific, right? Like a specific, you know, CAD/CAM mechanical design cloud, like an Autodesk would want to give you their cloud for running, you know, and sharing CAD/CAM designs, doing your CAD/CAM anywhere stuff. Well, the other spectrum is how well does the purported supercloud technology actually live up to allowing you to run anything anywhere with not just the same APIs but with the local presence of data with the exact same runtime environment everywhere, and to be able to correctly manage how to get that runtime environment anywhere. So a Cohesity has some means of running things in different places and some means of coordinating what's where and of serving diff, you know, things in different places. I would argue that it is a very poor approximation of what Hammerspace does in providing the exact same file system with local high performance access everywhere with metadata ability to control where the data is actually instantiated so that you don't have to wait for it to get orchestrated. But even then when you do have to wait for it, it happens automatically and so it's still only a matter of, well, how quick is it? And on the other end of the spectrum is you could look at NetApp with Flexcache and say, "Is that supercloud?" And I would argue, well kind of because it allows you to run things in different places because it's a cache. But you know, it really isn't because it presumes some central silo from which you're cacheing stuff. So, you know, is it or isn't it? Well, it's on a spectrum of exactly how fully is it decoupling a runtime environment from specific locality? And I think a cache doesn't, it stretches a specific silo and makes it have some semblance of similar access in other places. But there's still a very big difference to the central silo, right? You can't turn off that central silo, for example. >> So it comes down to how specific you make the definition. And this is where it gets kind of really interesting. It's like cloud. Does IBM have a cloud? >> Exactly. >> I would say yes. Does it have the kind of quality that you would expect from a hyper-scale cloud? No. Or see if you could say the same thing about-- >> But that's a problem with choosing a name. That's the problem with choosing a name supercloud versus talking about the concept of cloud and how true up you are to that concept. >> For sure. >> Right? Because without getting a name, you don't have to draw, yeah. >> I'd like to explore one particular or bring them together. You made a very interesting observation that from a enterprise point of view, they want to safeguard their store, their data, and they want to make sure that they can have that data running in their own workflows, as well as, as other service providers providing services to them for that data. So, and in in particular, if you go back to, you go back to Snowflake. If Snowflake could provide the ability for you to have your data where you wanted, you were in charge of that, would that make Snowflake a supercloud? >> I'll tell you, in my mind, they would be closer to my conceptualization of supercloud if you can instantiate Snowflake as software on your own infrastructure, and pump your own data to Snowflake that's instantiated on your own infrastructure. The fact that it has to be on their infrastructure or that it's on their, that it's on their account in the cloud, that you're giving them the data and they're, that fundamentally goes against it to me. If they, you know, they would be a pure, a pure plate if they were a software defined thing where you could instantiate Snowflake machinery on the infrastructure of your choice and then put your data into that machinery and get all the benefits of Snowflake. >> So did you see--? >> In other words, if they were not a SAS service, but offered all of the similar benefits of being, you know, if it were a service that you could run on your own infrastructure. >> So did you see what they announced, that--? >> I hope that's making sense. >> It does, did you see what they announced at Dell? They basically announced the ability to take non-native Snowflake data, read it in from an object store on-prem, like a Dell object store. They do the same thing with Pure, read it in, running it in the cloud, and then push it back out. And I was saying to Dell, look, that's fine. Okay, that's interesting. You're taking a materialized view or an extended table, whatever you're doing, wouldn't it be more interesting if you could actually run the query locally with your compute? That would be an extension that would actually get my attention and extend that. >> That is what I'm talking about. That's what I'm talking about. And that's why I'm saying I think Hammerspace is more progressive on that front because with our technology, anybody who can instantiate a service, can make a service. And so I, so MSPs can use Hammerspace as a way to build a super pass layer and host their clients on their infrastructure in a cloud-like fashion. And their clients can have their own private data centers and the MSP or the public clouds, and Hammerspace can be instantiated, get this, by different parties in these different pieces of infrastructure and yet linked together to make a common file system across all of it. >> But this is data mesh. If I were HPE and Dell it's exactly what I'd be doing. I'd be working with Hammerspace to create my own data. I'd work with Databricks, Snowflake, and any other-- >> Data mesh is a good way to put it. Data mesh is a good way to put it. And this is at the lowest level of, you know, the underlying file system that's mountable by the operating system, consumed as a real file system. You can't get lower level than that. That's why this is the foundation for all of the other apps and structured data systems because you need to have a data mesh that can at least mesh the binary blob. >> Okay. >> That hold the binaries and that hold the datasets that those applications are running. >> So David, in the third week of January, we're doing supercloud 2 and I'm trying to convince John Furrier to make it a data slash data mesh edition. I'm slowly getting him to the knothole. I would very much, I mean you're in the Bay Area, I'd very much like you to be one of the headlines. As Zhamak Dehghaniis going to speak, she's the creator of Data Mesh, >> Sure. >> I'd love to have you come into our studio as well, for the live session. If you can't make it, we can pre-record. But you're right there, so I'll get you the dates. >> We'd love to, yeah. No, you can count on it. No, definitely. And you know, we don't typically talk about what we do as Data Mesh. We've been, you know, using global data environment. But, you know, under the covers, that's what the thing is. And so yeah, I think we can frame the discussion like that to line up with other, you know, with the other discussions. >> Yeah, and Data Mesh, of course, is one of those evocative names, but she has come up with some very well defined principles around decentralized data, data as products, self-serve infrastructure, automated governance, and and so forth, which I think your vision plugs right into. And she's brilliant. You'll love meeting her. >> Well, you know, and I think.. Oh, go ahead. Go ahead, Peter. >> Just like to work one other interface which I think is important. How do you see yourself and the open source? You talked about having an operating system. Obviously, Linux is the operating system at one level. How are you imagining that you would interface with cost community as part of this development? >> Well, it's funny you ask 'cause my CTO is the kernel maintainer of the storage networking stack. So how the Linux operating system perceives and consumes networked data at the file system level, the network file system stack is his purview. He owns that, he wrote most of it over the last decade that he's been the maintainer, but he's the gatekeeper of what goes in. And we have leveraged his abilities to enhance Linux to be able to use this decentralized data, in particular with decoupling the control plane driven by metadata from the data access path and the many storage systems on which the data gets accessed. So this factoring, this splitting of control plane from data path, metadata from data, was absolutely necessary to create a data mesh like we're talking about. And to be able to build this supercloud concept. And the highways on which the data runs and the client which knows how to talk to it is all open source. And we have, we've driven the NFS 4.2 spec. The newest NFS spec came from my team. And it was specifically the enhancements needed to be able to build a spanning file system, a data mesh at a file system level. Now that said, our file system itself and our server, our file server, our data orchestration, our data management stuff, that's all closed source, proprietary Hammerspace tech. But the highways on which the mesh connects are actually all open source and the client that knows how to consume it. So we would, honestly, I would welcome competitors using those same highways. They would be at a major disadvantage because we kind of built them, but it would still be very validating and I think only increase the potential adoption rate by more than whatever they might take of the market. So it'd actually be good to split the market with somebody else to come in and share those now super highways for how to mesh data at the file system level, you know, in here. So yeah, hopefully that answered your question. Does that answer the question about how we embrace the open source? >> Right, and there was one other, just that my last one is how do you enable something to run in every environment? And if we take the edge, for example, as being, as an environment which is much very, very compute heavy, but having a lot less capability, how do you do a hold? >> Perfect question. Perfect question. What we do today is a software appliance. We are using a Linux RHEL 8, RHEL 8 equivalent or a CentOS 8, or it's, you know, they're all roughly equivalent. But we have bundled and a software appliance which can be instantiated on bare metal hardware on any type of VM system from VMware to all of the different hypervisors in the Linux world, to even Nutanix and such. So it can run in any virtualized environment and it can run on any cloud instance, server instance in the cloud. And we have it packaged and deployable from the marketplaces within the different clouds. So you can literally spin it up at the click of an API in the cloud on instances in the cloud. So with all of these together, you can basically instantiate a Hammerspace set of machinery that can offer up this file system mesh. like we've been using the terminology we've been using now, anywhere. So it's like being able to take and spin up Snowflake and then just be able to install and run some VMs anywhere you want and boom, now you have a Snowflake service. And by the way, it is so complete that some of our customers, I would argue many aren't even using public clouds at all, they're using this just to run their own data centers in a cloud-like fashion, you know, where they have a data service that can span it all. >> Yeah and to Molly's first point, we would consider that, you know, cloud. Let me put you on the spot. If you had to describe conceptually without a chalkboard what an architectural diagram would look like for supercloud, what would you say? >> I would say it's to have the same runtime environment within every data center and defining that runtime environment as what it takes to schedule the execution of applications, so job scheduling, runtime stuff, and here we're talking Kubernetes, Slurm, other things that do job scheduling. We're talking about having a common way to, you know, instantiate compute resources. So a global compute environment, having a common compute environment where you can instantiate things that need computing. Okay? So that's the first part. And then the second is the data platform where you can have file block and object volumes, and have them available with the same APIs in each of these distributed data centers and have the exact same data omnipresent with the ability to control where the data is from one moment to the next, local, where all the data is instantiate. So my definition would be a common runtime environment that's bifurcate-- >> Oh. (attendees chuckling) We just lost them at the money slide. >> That's part of the magic makes people listen. We keep someone on pin and needles waiting. (attendees chuckling) >> That's good. >> Are you back, David? >> I'm on the edge of my seat. Common runtime environment. It was like... >> And just wait, there's more. >> But see, I'm maybe hyper-focused on the lower level of what it takes to host and run applications. And that's the stuff to schedule what resources they need to run and to get them going and to get them connected through to their persistence, you know, and their data. And to have that data available in all forms and have it be the same data everywhere. On top of that, you could then instantiate applications of different types, including relational databases, and data warehouses and such. And then you could say, now I've got, you know, now I've got these more application-level or structured data-level things. I tend to focus less on that structured data level and the application level and am more focused on what it takes to host any of them generically on that super pass layer. And I'll admit, I'm maybe hyper-focused on the pass layer and I think it's valid to include, you know, higher levels up the stack like the structured data level. But as soon as you go all the way up to like, you know, a very specific SAS service, I don't know that you would call that supercloud. >> Well, and that's the question, is there value? And Marianna Tessel from Intuit said, you know, we looked at it, we did it, and it just, it was actually negative value for us because connecting to all these separate clouds was a real pain in the neck. Didn't bring us any additional-- >> Well that's 'cause they don't have this pass layer underneath it so they can't even shop around, which actually makes it hard to stand up your own SAS service. And ultimately they end up having to build their own infrastructure. Like, you know, I think there's been examples like Netflix moving away from the cloud to their own infrastructure. Basically, if you're going to rent it for more than a few months, it makes sense to build it yourself, if it's at any kind of scale. >> Yeah, for certain components of that cloud. But if the Goldman Sachs came to you, David, and said, "Hey, we want to collaborate and we want to build "out a cloud and essentially build our SAS system "and we want to do that with Hammerspace, "and we want to tap the physical infrastructure "of not only our data centers but all the clouds," then that essentially would be a SAS, would it not? And wouldn't that be a Super SAS or a supercloud? >> Well, you know, what they may be using to build their service is a supercloud, but their service at the end of the day is just a SAS service with global reach. Right? >> Yeah. >> You know, look at, oh shoot. What's the name of the company that does? It has a cloud for doing bookkeeping and accounting. I forget their name, net something. NetSuite. >> NetSuite. NetSuite, yeah, Oracle. >> Yeah. >> Yep. >> Oracle acquired them, right? Is NetSuite a supercloud or is it just a SAS service? You know? I think under the covers you might ask are they using supercloud under the covers so that they can run their SAS service anywhere and be able to shop the venue, get elasticity, get all the benefits of cloud in the, to the benefit of their service that they're offering? But you know, folks who consume the service, they don't care because to them they're just connecting to some endpoint somewhere and they don't have to care. So the further up the stack you go, the more location-agnostic it is inherently anyway. >> And I think it's, paths is really the critical layer. We thought about IAS Plus and we thought about SAS Minus, you know, Heroku and hence, that's why we kind of got caught up and included it. But SAS, I admit, is the hardest one to crack. And so maybe we exclude that as a deployment model. >> That's right, and maybe coming down a level to saying but you can have a structured data supercloud, so you could still include, say, Snowflake. Because what Snowflake is doing is more general purpose. So it's about how general purpose it is. Is it hosting lots of other applications or is it the end application? Right? >> Yeah. >> So I would argue general purpose nature forces you to go further towards platform down-stack. And you really need that general purpose or else there is no real distinguishing. So if you want defensible turf to say supercloud is something different, I think it's important to not try to wrap your arms around SAS in the general sense. >> Yeah, and we've kind of not really gone, leaned hard into SAS, we've just included it as a deployment model, which, given the constraints that you just described for structured data would apply if it's general purpose. So David, super helpful. >> Had it sign. Define the SAS as including the hybrid model hold SAS. >> Yep. >> Okay, so with your permission, I'm going to add you to the list of contributors to the definition. I'm going to add-- >> Absolutely. >> I'm going to add this in. I'll share with Molly. >> Absolutely. >> We'll get on the calendar for the date. >> If Molly can share some specific language that we've been putting in that kind of goes to stuff we've been talking about, so. >> Oh, great. >> I think we can, we can share some written kind of concrete recommendations around this stuff, around the general purpose, nature, the common data thing and yeah. >> Okay. >> Really look forward to it and would be glad to be part of this thing. You said it's in February? >> It's in January, I'll let Molly know. >> Oh, January. >> What the date is. >> Excellent. >> Yeah, third week of January. Third week of January on a Tuesday, whatever that is. So yeah, we would welcome you in. But like I said, if it doesn't work for your schedule, we can prerecord something. But it would be awesome to have you in studio. >> I'm sure with this much notice we'll be able to get something. Let's make sure we have the dates communicated to Molly and she'll get my admin to set it up outside so that we have it. >> I'll get those today to you, Molly. Thank you. >> By the way, I am so, so pleased with being able to work with you guys on this. I think the industry needs it very bad. They need something to break them out of the box of their own mental constraints of what the cloud is versus what it's supposed to be. And obviously, the more we get people to question their reality and what is real, what are we really capable of today that then the more business that we're going to get. So we're excited to lend the hand behind this notion of supercloud and a super pass layer in whatever way we can. >> Awesome. >> Can I ask you whether your platforms include ARM as well as X86? >> So we have not done an ARM port yet. It has been entertained and won't be much of a stretch. >> Yeah, it's just a matter of time. >> Actually, entertained doing it on behalf of NVIDIA, but it will absolutely happen because ARM in the data center I think is a foregone conclusion. Well, it's already there in some cases, but not quite at volume. So definitely will be the case. And I'll tell you where this gets really interesting, discussion for another time, is back to my old friend, the SSD, and having SSDs that have enough brains on them to be part of that fabric. Directly. >> Interesting. Interesting. >> Very interesting. >> Directly attached to ethernet and able to create a data mesh global file system, that's going to be really fascinating. Got to run now. >> All right, hey, thanks you guys. Thanks David, thanks Molly. Great to catch up. Bye-bye. >> Bye >> Talk to you soon.

(upbeat music) >> Welcome back to Boston, Massachusetts. We're here at the Seaport. You're watching theCUBE's coverage of Red Hat Summit 2022. My name is Dave Vellante and Paul Gillin is here. He's my cohost for the next day. We are going to dig in to the famous RHEL, Red Hat Enterprise Linux. Gunnar Hellekson is here, he's the Vice President and General Manager of Red Hat Enterprise Linux. Gunnar, welcome to theCUBE. Good to see you. >> Thanks for having me. Nice to be here, Dave, Paul. >> RHEL 9 is, wow, nine, Holy cow. It's been a lot of iterations. >> It's the highest version of RHEL we've ever shipped. >> And now we're talking edge. >> Yeah, that's right. >> And so, what's inside, tell us. to keep happy with a new RHEL release. to keep happy with a new RHEL release. The first is the hardware partners, right, because they rely on RHEL to light up all their delicious hardware that they're making, then you got application developers and the ISVs who rely on RHEL to be that kind of stable platform for innovation, and then you've got the operators, the people who are actually using the operating system itself and trying to keep it running every day. So we've got on the, I'll start with the hardware side, So we've got on the, I'll start with the hardware side, which is something, as you know, RHEL success, and I think you talked about this with Matt, just in a few sessions earlier that the success of RHEL is really, hinges on our partnerships with the hardware partners and in this case, we've got, let's see, in RHEL 9 we've got all the usual hardware suspects and we've added, just recently in January, we added support for ARM servers, as general ARM server class hardware. And so that's something customers have been asking for, delighted to be shipping that in RHEL 9. So now ARM is kind of a first-class citizen, right? Alongside x86, PowerZ and all the other usual suspects. And then of course, working with our favorite public cloud providers. So making sure that RHEL 9 is available at AWS and Azure and GCP and all our other cloud friends, right? >> Yeah, you mentioned ARM, we're seeing ARM in the enterprise. We're obviously seeing ARM at the edge. You guys have been working with ARM for a long time. You're working with Intel, you're working with NVIDIA, you've got some announcements this week. Gunnar, how do you keep Linux from becoming Franken OS with all these capabilities? >> This is a great question. First is, the most important thing is to be working closely with, I mean, the whole point of Linux and the reason why Linux works is because you have all these people working together to make the same thing, right? And so fighting that is a bad idea. Working together with everyone, leaning into that collaboration, that's an important part of making it work over time. The other one is having, just like in any good relationship, having healthy boundaries. And so making sure that we're clear about the things that we need to keep stable and the places where we're allowed to innovate and striking the right balance between those two things, that allows us to continue to ship one coherent operating system while still keeping literally thousands of platforms happy. >> So you're not trying to suck in all the full function, you're trying to accommodate that function that the ecosystem is going to develop? >> Yeah, that's right. So the idea is that what we strive for is consistency across all of the infrastructures and then allowing for kind of optimizations and we still let ourselves take advantage of whatever indigenous feature might appear on, such an ARM chip or thus in a such cloud platform. But really, we're trying to deliver a uniform platform experience to the application developers, right? Because they can't be having, like there can't be kind of one version of RHEL over here and another version of RHEL over here, the ecosystem wouldn't work. The whole point of Linux and the whole point of Red Hat Enterprise Linux is to be the same so that everything else can be different. >> And what incentives do you use to keep customers current? >> To keep customers current? Well so the best thing to do I found is to meet customers where they are. So a lot of people think we release RHEL 9 at the same time we have Red Hat Enterprise Linux 8, we have Red Hat Enterprise Linux 7, all these are running at the same time, and then we also have multiple minor release streams inside those. So at any given time, we're running, let's say, a dozen different versions of RHEL are being maintained and kept up-to-date, and we do this precisely to make sure that we're not force marching people into the new version and they have a Red Hat Enterprise Linux subscription, they should just be able to sit there and enjoy the minor version that they like. And we try and keep that going for as long as possible. >> Even if it's 10 years out of date? >> So, 10 years, interesting you chose that number because that's the end of life. >> That's the end of the life cycle. >> Right. And so 10 years is about, that's the natural life of a given major release, but again inside that you have several 10-year life cycles kind of cascading on each other, right? So nine is the start of the next 10-year cycle while we're still living inside the 10-year cycle of seven and eight. So lots of options for customers. >> How are you thinking about the edge? how do you define, let's not go to the definition, but at high level. (Gunnar laughing) Like I've been in a conference last week. It was Dell Tech World, I'll just say it. They were sort of the edge to them was the retail store. >> Yeah. >> Lowe's, okay, cool, I guess that's edgy, I guess, But I think space is the edge. (Gunnar chuckling) >> Right, right, right. >> Or a vehicle. How do you think about the edge? All the above or but the exciting stuff to me is that far edge, but I wonder if you can comment. >> Yeah, so there's all kinds of taxonomies out there for the edge. For me, I'm a simple country product manager at heart and so, I try to keep it simple, right? And the way I think about the edge is, here's a use case in which somebody needs a small operating system that deploys on probably a small piece of hardware, usually varying sizes, but it could be pretty small. That thing needs to be updated without any human touching it, right? And it needs to be reliably maintained without any human touching it. Usually in the edge cases, actually touching the hardware is a very expensive proposition. So we're trying to be as hands off as possible. >> No truck rolls. >> No truck rolls ever, right, exactly. (Dave chuckling) And then, now that I've got that stable base, I'm going to go take an application. I'll probably put it in a container for simplicity's sake and same thing, I want to be able to deploy that application. If something goes wrong, I need to build a roll back to a known good state and then I need to set of management tools that allow me to touch things, make sure that everything is healthy, make sure that the updates roll out correctly, maybe do some AB testing, things like that. So I think about that as, that's the, when we talk about the edge case for RHEL, that's the horizontal use case and then we can do specializations inside particular verticals or particular industries, but at bottom that's the use case we're talking about when we talk about the edge. >> And an assumption of connectivity at some point? >> Yeah. >> Right, you didn't have to always be on. >> Intermittent, latent, eventual connectivity. >> Eventual connectivity. (chuckles) That's right in some tech terms. >> Red Hat was originally a one trick pony. I mean, RHEL was it and now you've got all of these other extensions and different markets that you expanded into. What's your role in coordinating what all those different functions are doing? >> Yes, you look at all the innovations we've made, whether it's in storage, whether it's in OpenShift and elsewhere, RHEL remains the beating heart, right? It's the place where everything starts. And so a lot of what my team does is, yes, we're trying to make all the partners happy, we're also trying to make our internal partners happy, right? So the OpenShift folks need stuff out of RHEL, just like any other software vendor. And so I really think about RHEL is yes, we're a platform, yes, we're a product in our own right, but we're also a service organization for all the other parts of the portfolio. And the reason for that is we need to make sure all this stuff works together, right? Part of the whole reasoning behind the Red Hat Portfolio at large is that each of these pieces build on each other and compliment each other, right? I think that's an important part of the Red Hat mission, the RHEL mission. >> There's an article in the journal yesterday about how the tech industry was sort of pounding the drum on H-1B visas, there's a limit. I think it's been the same limit since 2005, 65,000 a year. We are facing, customers are facing, you guys, I'm sure as well, we are, real skills shortage, there's a lack of talent. How are you seeing companies deal with that? What are you advising them? What are you guys doing yourselves? >> Yeah, it's interesting, especially as everybody went through some flavor of digital transformation during the pandemic and now everybody's going through some, and kind of connected to that, everybody's making a move to the public cloud. They're making operating system choices when they're making those platform choices, right? And I think what's interesting is that, what they're coming to is, "Well, I have a Linux skills shortage and for a thousand reasons the market has not provided enough Linux admins." I mean, these are very lucrative positions, right? With command a lot of money, you would expect their supply would eventually catch up, but for whatever reason, it's not catching up. So I can't solve this by throwing bodies at it so I need to figure out a more efficient way of running my Linux operation. People are making a couple choices. The first is they're ensuring that they have consistency in their operating system choices, whether it's on premise or in the cloud, or even out on the edge, if I have to juggle three, four different operating systems, as I'm going through these three or four different infrastructures, that doesn't make any sense, 'cause the one thing is most precious to me is my Linux talent, right? And so I need to make sure that they're consistent, optimized and efficient. The other thing they're doing is tooling and automation and especially through tools like Ansible, right? Being able to take advantage of as much automation as possible and much consistency as possible so that they can make the most of the Linux talent that they do have. And so with Red Hat Enterprise Linux 9, in particular, you see us make a big investment in things like more automation tools for things like SAP and SQL server deployments, you'll see us make investments in things like basic stuff like the web console, right? We should now be able to go and point and click and go basic Linux administration tasks that lowers the barrier to entry and makes it easier to find people to actually administer the systems that you have. >> As you move out onto these new platforms, particularly on the edge, many of them will be much smaller, limited function. How do you make the decisions about what features you're going to keep or what you're going to keep in RHEL when you're running on a thermostat? >> Okay, so let me be clear, I don't want RHEL to run on a thermostat. (everybody laughing) >> I gave you advantage over it. >> I can't handle the margins on something like that, but at the end. >> You're running on, you're running on the GM. >> Yeah, no that's, right? And so the, so the choice at the, the most important thing we can do is give customers the tools that they need to make the choice that's appropriate for their deployment. I have learned over several years in this business that if I start choosing what content a customer decide wants on their operating system I will always guess it wrong, right? So my job is to make sure that I have a library of reliable, secure software options for them, that they can use as ingredients into their solution. And I give them tools that allow them to kind of curate the operating system that they need. So that's the tool like Image Builder, which we just announced, the image builder service lets a customer go in and point and click and kind of compose the edge operating system they need, hit a button and now they have an atomic image that they can go deploy out on the edge reliably, right? >> Gunnar can you clarify the cadence of releases? >> Oh yeah. >> You guys, the change that you made there. >> Yeah. >> Why that change occurred and what what's the standard today? >> Yeah, so back when we released RHEl 8, so we were just talking about hardware and you know, it's ARM and X86, all these different kinds of hardware, the hardware market is internally. I tell everybody the hardware market just got real weird, right? It's just got, the schedules are crazy. We got so many more entrance. Everything is kind of out of sync from where it used to be, it used to be there was a metronome, right? You mentioned Moore's law earlier. It was like a 18 month metronome. Everybody could kind of set their watch to. >> Right. >> So that's gone, and so now we have so much hardware that we need to reconcile. The only way for us to provide the kind of stability and consistency that customers were looking for was to set a set our own clock. So we said three years for every major release, six months for every minor release and that we will ship a new minor release every six months and a new major release every three years, whether we need it or not. And that has value all by itself. It means that customers can now plan ahead of time and know, okay, in 36 months, the next major release is going to come on. And now that's something I can plan my workload around, that something I can plan a data center migration around, things like that. So the consistency of this and it was a terrifying promise to make three years ago. I am now delighted to announce that we actually made good on it three years later, right? And plan two again, three years from now. >> Is it follow up, is it primarily the processor, optionality and diversity, or as I was talking to an architect, system architect the other day in his premise was that we're moving from a processor centric world to a connect centric world, not just the processor, but the memories, the IO, the controllers, the nics and it's just keeping that system in balance. Does that affect you or is it primarily the processor? >> Oh, it absolutely affects us, yeah. >> How so? >> Yeah, so the operating system is the thing that everyone relies on to hide all that stuff from everybody else, right? And so if we cannot offer that abstraction from all of these hardware choices that people need to make, then we're not doing our job. And so that means we have to encompass all the hardware configurations and all the hardware use cases that we can in order to make an application successful. So if people want to go disaggregate all of their components, we have to let 'em do that. If they want to have a kind of more traditional kind of boxed up OEM experience, they should be able to do that too. So yeah, this is what I mean is because it is RHEL responsibility and our duty to make sure that people are insulated from all this chaos underneath, that is a good chunk of the job, yeah. >> The hardware and the OS used to be inseparable right before (indistinct) Hence the importance of hardware. >> Yeah, that's right. >> I'm curious how your job changes, so you just, every 36 months you roll on a new release, which you did today, you announced a new release. You go back into the workplace two days, how is life different? >> Not at all, so the only constant is change, right? And to be honest, a major release, that's a big event for our release teams. That's a big event for our engineering teams. It's a big event for our product management teams, but all these folks have moved on and like we're now we're already planning. RHEL 9.1 and 9.2 and 8.7 and the rest of the releases. And so it's kind of like brief celebration and then right back to work. >> Okay, don't change so much. >> What can we look forward to? What's the future look like of RHEL, RHEL 10? >> Oh yeah, more bigger, stronger, faster, more optimized for those and such and you get, >> Longer lower, wider. >> Yeah, that's right, yeah, that's right, yeah. >> I am curious about CentOS Stream because there was some controversy around the end of life for CentOS and the move to CentOS Stream. >> Yeah. >> A lot of people including me are not really clear on what stream is and how it differs from CentOS, can you clarify that? >> Absolutely, so when Red Hat Enterprise Linux was first created, this was back in the days of Red Hat Linux, right? And because we couldn't balance the needs of the hobbyist market from the needs of the enterprise market, we split into Red Hat Enterprise Linux and Fedora, okay? So then for 15 years, yeah, about 15 years we had Fedora which is where we took all of our risks. That was kind of our early program where we started integrating new components, new open source projects and all the rest of it. And then eventually we would take that innovation and then feed it into the next version of Red Hat Enterprise Linux. The trick with that is that the Red Hat Enterprise Linux work that we did was largely internal to Red Hat and wasn't accessible to partners. And we've just spent a lot of time talking about how much we need to be collaborating with partners. They really had, a lot of them had to wait until like the beta came out before they actually knew what was going to be in the box, okay, well that was okay for a while but now that the market is the way that it is, things are moving so quickly. We need a better way to allow partners to work together with us further upstream from the actual product development. So that's why we created CentOS Stream. So CentOS Stream is the place where we kind of host the party and people can watch the next version of Red Hat Enterprise get developed in real time, partners can come in and help, customers can come in and help. And we've been really proud of the fact that Red Hat Enterprise Linux 9 is the first release that came completely out of CentOS Stream. Another way of putting that is that Red Hat Enterprise Linux 9 is the first version of RHEL that was actually built, 80, 90% of it was built completely in the open. >> Okay, so that's the new playground. >> Yeah, that's right. >> You took a lot of negative pushback when you made the announcement, is that basically because the CentOS users didn't understand what you were doing? >> No, I think the, the CentOS Linux, when we brought CentOS Linux on, this was one of the things that we wanted to do, is we wanted to create this space where we could start collaborating with people. Here's the lesson we learned. It is very difficult to collaborate when you are downstream of the product you're trying to improve because you've already shipped the product. And so once you're for collaborating downstream, any changes you make have to go all the way up the water slide and before they can head all the way back down. So this was the real pivot that we made was moving that partnership and that collaboration activity from the downstream of Red Hat Enterprise Linux to putting it right in the critical path of Red Hat Enterprise Linux development. >> Great, well, thank you for that Gunnar. Thanks for coming on theCUBE, it's great to, >> Yeah, my pleasure. >> See you and have a great day tomorrow. Thanks, and we look forward to seeing you tomorrow. We start at 9:00 AM. East Coast time. I think the keynotes, we will be here right after that to break that down, Paul Gillin and myself. This is day one for theCUBE's coverage of Red Hat Summit 2022 from Boston. We'll see you tomorrow, thanks for watching. (upbeat music)

>> Announcer: Live from Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2019. Brought to you by Red Hat. >> Welcome back here on theCUBE, joined by Stu Miniman, I'm John Walls, as we wrap up our coverage here of the Red Hat Summit here in 2019. We've been here in Boston all week, three days, Stu, of really fascinating programming on one hand, the keynotes showing quite a diverse ecosystem that Red Hat has certainly built, and we've seen that array of guests reflected as well here, on theCUBE. And you leave with a pretty distinct impression about the vast reach, you might say, of Red Hat, and how they diversified their offerings and their services. >> Yeah, so, John, as we've talked about, this is the sixth year we've had theCUBE here. It's my fifth year doing it and I'll be honest, I've worked with Red Hat for 19 years, but the first year I came, it was like, all right, you know, I know lots of Linux people, I've worked with Linux people, but, you know, I'm not in there in the terminal and doing all this stuff, so it took me a little while to get used to. Today, I know not only a lot more people in Red Hat and the ecosystem, but where the ecosystem is matured and where the portfolio is grown. There's been some acquisitions on the Red Hat side. There's a certain pending acquisition that is kind of a big deal that we talked about this week. But Red Hat's position in this IT marketplace, especially in the hybrid and multi-cloud world, has been fun to watch and really enjoyed digging in it with you this week and, John Walls, I'll turn the camera to you because- >> I don't like this. (laughing) >> It was your first time on the program. Yeah, you know- >> I like asking you the questions. >> But we have to do this, you know, three days of Walls to Miniman coverage. So let's get the Walls perspective. >> John: All right. >> On your take. You've been to many shows. >> John: Yeah, no, I think that what's interesting about what I've seen here at Red Hat is this willingness to adapt to the marketplace, at least that's the impression I got, is that there are a lot of command and control models about this is the way it's going to be, and this is what we're going to give you, and you're gonna have to take it and like it. And Red Hat's just on the other end of that spectrum, right? It's very much a company that's built on an open source philosophy. And it's been more of what has the marketplace wanted? What have you needed? And now how can we work with you to build it and make it functional? And now we're gonna just offer it to a lot of people, and we're gonna make a lot of money doing that. And so, I think to me, that's at least what I got talking to Jim Whitehurst, you know about his philosophy and where he's taken this company, and has made it obviously a very attractive entity, IBM certainly thinks so to the tune of 34 billion. But you see that. >> Yeah, it's, you know, some companies say, oh well, you know, it's the leadership from the top. Well, Jim's philosophy though, it is The Open Organization. Highly recommend the book, it was a great read. We've talked to him about the program, but very much it's 12, 13 thousand people at the company. They're very much opinionated, they go in there, they have discussions. It's not like, well okay, one person pass this down. It's we're gonna debate and argue and fight. Doesn't mean we come to a full consensus, but open source at the core is what they do, and therefore, the community drives a lot of it. They contribute it all back up-stream, but, you know, we know what Red Hat's doing. It's fascinating to talk to Jim about, yeah you know, on the days where I'm thinking half glass empty, it's, you know, wow, we're not yet quite four billion dollars of the company, and look what an impact they had. They did a study with IDC and said, ten trillion dollars of the economy that they touch through RHEL, but on the half empty, on the half full days, they're having a huge impact outside. He said 34 billion dollars that IBM's paying is actually a bargain- >> It's a great deal! (laughing) >> for where they're going. But big announcements. RHEL 8, which had been almost five years in the works there. Some good advancements there. But the highlight for me this week really was OpenShift. We've been watching OpenShift since the early days, really pre-Kubernetes. It had a good vision and gained adoption in the marketplace, and was the open source choice for what we called Paths back then. But, when Kubernetes came around, it really helped solidify where OpenShift was going. It is the delivery mechanism for containerization and that container cluster management and Red Hat has a leadership position in that space. I think that almost every customer that we talked to this week, John, OpenShift was the underpinning. >> John: Absolutely. >> You would expect that RHEL's underneath there, but OpenShift as the lever for digital transformation. And that was something that I really enjoyed talking to. DBS Bank from Singapore, and Delta, and UPS. It was, we talked about their actual transformation journeys, both the technology and the organizational standpoint, and OpenShift really was the lever to give them that push. >> You know, another thing, I know you've been looking at this and watching this for many many years. There's certainly the evolution of open source, but we talked to Chris Wright earlier, and he was talking about the pace of change and how it really is incremental. And yet, if you're on the outside looking in, and you think, gosh, technology is just changing so fast, it's so crazy, it's so disruptive, but to hear it from Chris, not so. You don't go A to Z, you go A to B to C to D to D point one. (laughing) It takes time. And there's a patience almost and a cadence that has this slow revolution that I'm a little surprised at. I sense they, or got a sense of, you know, a much more rapid change of pace and that's not how the people on the inside see it. >> Yeah. Couple of comment back at that. Number one is we know how much rapid change there is going because if you looked at the Linux kernel or what's happening with Kubernetes and the open source, there's so much change going on there. There's the data point thrown out there that, you know, I forget, that 75% or 95% of all the data in the world was created in the last two years. Yet, only 2% of that is really usable and searchable and things like that. That's a lot of change. And the code base of Linux in the last two years, a third of the code is completely overhauled. This is technology that has been around for decades. But if you look at it, if you think about a company, one of the challenges that we had is if they're making those incremental change, and slowly looking at them, a lot of people from the outside would be like, oh, Red Hat, yeah that's that little Linux company, you know, that I'm familiar with and it runs on lots of places there. When we came in six years ago, there was a big push by Red Hat to say, "We're much more than Linux." They have their three pillars that we spent a lot of time through from the infrastructure layer to the cloud native to automation and management. Lots of shows I go to, AnsiballZ all over the place. We talked about OpenShift 4 is something that seems to be resonating. Red Hat takes a leadership position, not just in the communities and the foundations, but working with their customers to be a more trusted and deeper partner in what they're doing with digital transformation. There might have been little changes, but, you know, this is not the Red Hat that people would think of two years or five years ago because a large percentage of Red Hat has changed. One last nugget from Chris Wright there, is, you know, he spent a lot of time talking about AI. And some of these companies go buzzwords in these environments, but, you know, but he hit a nice cogent message with the punchline is machines enhance human intelligence because these are really complex systems, distributed architectures, and we know that the people just can't keep up with all of the change, and the scope, and the scale that they need to handle. So software should be able to be helping me get my arms around it, as well as where it can automate and even take actions, as long as we're careful about how we do it. >> John: Sure. There's another, point at least, I want to pick your brain about, is really the power of presence. The fact that we have the Microsoft CEO on the stage. Everybody thought, well (mumbles) But we heard it from guest after guest after guest this week, saying how cool was that? How impressive was that? How monumental was that? And, you know, it's great to have that kind of opportunity, but the power of Nadella's presence here, it's unmistakable in the message that has sent to this community. >> Yeah, you know, John, you could probably do a case study talking about culture and the power of culture because, I talked about Red Hat's not the Red Hat that you know. Well, the Satya Nadella led Microsoft is a very different Microsoft than before he was on board. Not only are they making great strides in, you know, we talk about SaaS and public cloud and the like, but from a partnership standpoint, Microsoft of old, you know, Linux and Red Hat were the enemy and you know, Windows was the solution and they were gonna bake everything into it. Well, Microsoft partnered with many more companies. Partnerships and ecosystem, a key message this week. We talked about Microsoft with Red Hat, but, you know, announcement today was, surprised me a little bit, but when we think about it, not too much. OpenShift supported on VMware environments, so, you know, VMware has in that family of Dell, there's competitive solutions against OpenShift and, you know, so, and virtualization. You know, Red Hat has, you know, RHV, the Red Hat Virtualization. >> John: Right, right, right. >> The old day of the lines in the swim lanes, as one of our guests talked about, really are there. Customers are living in a heterogeneous, multi-cloud world and the customers are gonna go and say, "You need to work together, before you're not gonna be there." >> Azure. Right, also we have Azure compatibility going on here. >> Stu: Yeah, deep, not just some tested, but deep integration. I can go to Azure and buy OpenShift. I mean that, the, to say it's in the, you know, not just in the marketplace, but a deep integration. And yeah, there was a little poke, if our audience caught it, from Paul Cormier. And said, you know, Microsoft really understands enterprise. That's why they're working tightly with us. Uh, there's a certain other large cloud provider that created Kubernetes, that has their own solution, that maybe doesn't understand enterprise as much and aren't working as closely with Red Hat as they might. So we'll see what response there is from them out there. Always, you know, we always love on theCUBE to, you know, the horse is on the track and where they're racing, but, you know, more and more all of our worlds are cross-pollinating. You know, the AI and AI Ops stuff. The software ecosystems because software does have this unifying factor that the API economy, and having all these things work together, more and more. If you don't, customers will go look for solutions that do provide the full end to end solution stuff they're looking for. >> All right, so we're, I've got a couple in mind as far as guests we've had on the show. And we saw them in action on the keynotes stage too. Anybody that jumps out at you, just like, wow, that was cool, that was, not that we, we love all of our children, right? (laughing) But every once in awhile, there's a story or two that does stand out. >> Yeah, so, it is so tough, you know. I loved, you know, the stories. John, I'm sure I'm going to ask you, you know, Mr. B and what he's doing with the children. >> John: Right, Franklin Middle School. >> And the hospitals with Dr. Ellen and the end of the brains. You know, those tech for good are phenomenal. For me, you know, the CIOs that we had on our first day of program. Delta was great and going through transformation, but, you know, our first guest that we had on, was DBS Bank in Singapore and- >> John: David Gledhill. >> He was so articulate and has such a good story about, I took outsourced environments. I didn't just bring it into my environment, say okay, IT can do it a little bit better, and I'll respond to business. No, no, we're going to total restructure the company. Not we're a software company. We're a technology company, and we're gonna learn from the Googles of the world and the like. And he said, We want to be considered there, you know, what was his term there? It was like, you know, bank less, uh, live more and bank less. I mean, what- >> Joyful banking, that was another of his. >> Joyful banking. You don't think of a financial institution as, you know, we want you to think less of the bank. You know, that's just a powerful statement. Total reorganization and, as we mentioned, of course, OpenShift, one of those levers underneath helping them to do that. >> Yeah, you mentioned Dr. Ellen Grant, Boston Children's Hospital, I think about that. She's in fetal neuroimaging and a Professor of Radiology at Harvard Medical School. The work they're doing in terms of diagnostics through imaging is spectacular. I thought about Robin Goldstone at the Livermore Laboratory, about our nuclear weapon monitoring and efficacy of our monitoring. >> Lawrence Livermore. So good. And John, talk about the diversity of our guests. We had expats from four different countries, phenomenal accents. A wonderful slate of brilliant women on the program. From the customer side, some of the award winners that you interviewed. The executives on the program. You know, Stefanie Chiras, always great, and Denise who were up on the keynotes stage. Denise with her 3D printed, new Red Hat logo earrings. Yeah, it was an, um- >> And a couple of old Yanks (laughing). Well, I enjoyed it, Stu. As always, great working with you, and we thank you for being with us as well. For now, we're gonna say so long. We're gonna see you at the next Red Hat Summit, I'm sure, 2020 in San Francisco. Might be a, I guess a slightly different company, but it might be the same old Red Hat too, but they're going to have 34 billion dollars behind them at that point and probably riding pretty high. That will do it for our CUBE coverage here from Boston. Thanks for much for joining us. For Stu Miniman, and our entire crew, have a good day. (funky music)

>> Voiceover: Live from Boston, Massachusetts, it's the CUBE. Covering your Red Hat Summit 2019. Brought to you by Red Hat. >> And welcome back to our coverage here on the CUBE Red Hat Summit 2019. We're at the BCEC in Beantown, Boston, Massachusetts playing host this week to some 9000 strong attendees, pack keynotes. Just a great three days of programming here and educational sessions. Stu Miniman and I'm John Walls. We're joined by Mike Piech, who's the VP and general manager of Middleware at Red Hat. Mike, good to see you today. >> Great to be back. >> And Mark Little, VP of engineering Middleware at Red Hat. Mark, Good to see you as well, sir. >> You too. >> Yeah. First of, let's just talk about your ideas at the show here. Been here for a few days. As we've seen on the keynote stage, wide variety of first off, announcements and great case studies, great educational sessions. But your impressions of what's going on and some of the announcements we've heard about this week. >> Well, sure. I mean definitely some very big announcements with RHEL 8 and OpenShift 4. So as Middleware we're a little bit more in sort of gorilla mode here while some of the bigger announcements take a lot of the limelight. But nevertheless those announcements and the advances that they represent are very important for us as Middleware. Particularly OpenShift 4 as sort of the next layer up from OpenShift which the developers sort of touch and feel and live and breathe on a daily basis. We are the immediate beneficiaries of much of the advances in OpenShift and so that's something that, we as the Middleware guys sort of make real for the enterprise application developer. >> I'd say, probably for me, building on that in a way, one of the biggest announcements, one of the biggest surprises is gotta be the first keynote where we had Satya from Microsoft on stage with Jim announcing the collaboration that we're doing. I never believed that would ever happen and that's, that's fantastic. Has a benefit for Middleware as well but just for Red Hat as a whole. Who would've thought it? >> John: Who would have thought it, right? Yeah, we actually just had Marco Bill-Peter on and he was talking about, he's like "Look, we've actually had some of our support people up in Redmond now for a couple of years." And we had Chris Wright on earlier and he says "You know, sometimes we got to these shows and you get the big bang announcement. It's like, well, really we're working incrementally along the way and open source you can watch it. Sure sometimes you get the new chipset or there's a new this or that. But you know, it's very very small things." So in the spirit of that, maybe, you know, give us the updates since last time we got together. What's happening in the Middleware space as you said. If we build up the stack, you know, we got RHEL 8, we got OpenShift 4 and you're sitting on top. >> Yeah. Well one aspect that's an event like this makes clear in almost a reverse sort of way. We put a lot of effort particularly in Mark's team in getting to a much more frequent and more incremental release cycle and style, right. So getting away from sort of big bang releases every year, couple of years, to a much more agile incremental again sort of regime of rolling out functionality. Now, one of the downsides of that is that you don't have these big grand product announcements to make a big deal about in the same way as RHEL just did with 8 for example. So we need to rethink how we sort of (Laughs) >> absence the sort of big .0 releases, you know how we sort of batch up interesting news and roll it out at a large event like this. Now one of the things that we have been working on is our application environment narrative. Right now, the whole idea of the story here is that many people talk about Cloud-Native and about having lot's of different capabilities and services in a cloud environment. And as we've sort of gone through the, particularly the last year or so, it's really become apparent from what our customers tell us and from what we really see as the opportunities in the cloud-native world. The value that we bring is engineering all these pieces together, right? So that it's not simply a list of these disparate, disconnected, independent services but rather Middleware in the world of cloud native re-imagined. It is capabilities that when engineered together in the right way they make for this comprehensive, unified, cohesive environment within which our customers can develop applications and run those applications. And for the developer, you get developer productivity and then at runtime, you're getting operational reliability. So there really is a sort of a dual-sided value proposition there. And this notion of Middleware engineered together for the cloud is what the application environment idea is all about. >> Yeah. I'd add kinda one of the things that ties into that which has been big for us at least at summit this year is an effort that we kicked off or we announced two months ago called Quakers and as you all know a lot of what we do within Middleware, within Red Hat is based on Java and Java is still the dominant language in the enterprise but it's been around for 20 years. It developed in a pre-cloud era and that made lots of assumptions on the way in which the Java language and the JVM on which it runs would develop which aren't necessarily that conducive for running, in a cloud environment, a hybrid cloud environment and certainly public cloud environment based on Linux containers and Kubernetes. So, we've been working for a number of years in the upstream open JDK community to try and make Java much more cloud-native itself. And Quakers kind of builds on that. It essentially is what we call a kub-native approach where we optimize all of the Middleware stack upfront to work really really well in Kubernetes and specifically on OpenShift. And it's all Java though, that's the important thing. And now if people look into this they'll find that we're showing performance figures and memory utilization that is on a per with some of the newer languages like Go for instance, very very fast. Typically your boot time has gone from seconds to tens of milliseconds. And people who have seen it demonstrated have literally been blown away cause it allows them to leverage the skills that they've had invested in their employees to learn Java and move to the cloud without telling them "You guys are gonna have to learn a completely new language and start from scratch" >> All right, so Mark, if I get it right cause we've been at the Kubernetes show for a bunch of years but this is, you're looking at kinda the application side of what's happening in those Kubernetes environment >> Mark: Yeah. So many times we've talked about the platforms and the infrastructure down but it's the the art piece on top. Super important. I know down the DevZone people were buzzing around all the Quaker stuff. What else for people that are you know, looking at that kinda cloud-native containerization space? What other areas that they should be looking at when it comes to your space? >> Well, again, tying into the up environment thing, hopefully, you know, you'll have heard of knative and Istio. So knative is, to put it in a quick sentence is essentially an enabler for serverless if you like. It's where we're spinning containers really really quickly based on events. But really any serverless platform lives and dies based on the services in which your business logic can then rely upon. Do I have a messaging service there? Do I have a transaction service or a database service? So, we've been working with, with Google on knative and with Microsoft on knative to ensure that we have a really good story in OpenShift but tying it into our Middleware suite as well. So, many of our Middleware products are now knative enabled if you like. The second thing is, as I mentioned, Istio which is a sidecar approach. I won't go into details on that but again Istio the aim behind that is to remove from the application developer some of the non-functional business logic that they had to put in there like "How do I use a messaging service? How do I secure this endpoint and push it down the infrastructure?" So the security servers, the messaging servers, the cashing servers et cetera. They move out of the business logic and they move into Istio. But from our point of view, it's our security servers that we've been working on for years, it's our transactional servers that we've been working on for years. So, these are bullet-proof implementations that we have just made more cloud-native by embedding them in a way in Istio and like I said, enabling them with knative. >> I think we'd mentioned that Chris Wright was on earlier and one of the things he talked about was, this new data-eccentric focus and how, that's at the core so much of what enterprise is doing these days. The fact that whenever speed is distributed, they are and you've got so many data inputs come in from, so to a unified user trying to get their data the way they wanna see it. You might want it for a totally other reason, right? I'm just curious, how does that influence or how has that influenced your work in terms of making sure that transport goes smoothly? Because you do have so much more to work with in a much more complex environment for multiple uses that are unique, right? >> (Mike) Yeah. >> It's not all the same. >> Huge, huge impact for sure. The whole idea of decomposing an application into a much larger number of much smaller pieces than was done in the past has many benefits probably one of the most significant being the ability to make small changes, small incremental changes and afford a much more trial and error approach to innovation versus more macro-level planning waterfall as they call it. But one of the implications of that is now you have a large number of entities. Whether they be big or small, there's a large number of them running within the estate. And there's the orchestration of them and the interconnection of them for sure but it's a n-squared relationship, right. The more these entities you have, the more potential connections between each of them you have to somehow structure and manage and ensure are being done securely and so on. So that has really driven the need for new ways of tying things together, new ways essentially of integration. It has definitely amplified the need for disciplines, EPI management for example. It has driven a lot of increase demand for an event-driven approach where you're streaming in realtime and distributing events to many receivers and dealing with things asynchronously and not depending on round-trip times for everything to be consistent and so on. So, there's just a myriad of implications there that are very detailed technical-level drive some of the things that we're doing now. >> Yeah, I'll just add that in terms of data itself, you've probably heard this a number of times, data is king. Everything we do is based on data in one way or another, So we as Red Hat as a whole and Middleware specifically, we've had a very strong data strategy for a long time. Just as you've got myriad types of data, you can't assume that one way of storing that data is gonna be right for every type of data that you've got. So, we've worked through the integration efforts on ensuring that no sequel data stores, relational data stores^, in-memory data caching and even the messaging services as a whole is a way of sto^ring data in transit, that allows you to, in some ways it allows you to actually look at it in an event-driven way and make intelligent decisions. So that's a key part of what anybody should do if they are in the enterprise space. That's certainly what we're doing because at the end of the day people are building these apps to use that data. >> Well, gentlemen, I know you have another engagement. We're gonna cut you loose but I do wanna say you're the first guests to get applause. (guests laugh) >> From across all the way there. People at home can't hear but, so congratulations. You've been well received already. >> I think they're clearly tuned in to the renaissance of the job in here. >> Yes. >> Thank you both. >> Thanks for the time. >> Mark: Thanks so much. >> We appreciate that. Back with more, we are watching a Red Hat summer 2019 coverage live on the CUBE. (Upbeat music)

(upbeat music) >> Narrator: Live, from Boston, Massachusetts, it's theCube! Covering Red Hat Summit 2019. Brought to you by Red Hat. >> Welcome back, live here on theCube, as we continue our coverage here of Red Hat Summit, along with Stu Miniman, I'm John Walls. It's great to have you here, in one of America's great cities! We're in Boston, Massachusetts, for day one of the three-day conference. And we're now joined with Denise Dumas, who is with Red Hat, and working on the RHEL 8 release that just became, I guess, available today, right? >> Today! >> Huge news! >> Yes! >> I have to first of compliment you on rocking these Red Hat red earrings. And then I look down below you've got the Red Hat sneakers on too, so you are company-branded >> Absolutely. >> up and down, literally, from head-to-toe. >> I'm very proud of the earrings, because some of the support guys made them up on their 3D printer back at the office. >> John: How cool is that? >> I love it. >> Now we had Stefanie Chiras on a little bit earlier, and we were talking about RHEL 8 and all that came with that, and we talked about the deeper dive we're gonna take with you a little bit later on, now we're at that moment. Just first off, in general, how do you feel when something like this finally gets out of the beta stage, gets moved into a much more active space, and now it's available to the marketplace? >> It's like fresh air, right? >> Thrilled. >> Oh, thrilled. Well, you know, and in a way, it's almost an anti-climax, because we're working on 8.1 already, and we're talking about RHEL 9, but this is just such an opportunity to take a moment, especially for so many of the RHEL engineering and QE team who are wandering around the summit, and for us all to just kind of say, (sighs) it's out. It's out, let's see if they like it, I hope they do. But you know, we've been working with so many of the customers and partners through the High Touch Beta Program, 40,000 downloads of the beta, and it has been tremendous feedback. We've been really pleased to see how many people are willing to pick it up and experiment with it, and tell us what they like and what they don't like. >> So Denise, it's always great to hear the customers, but take a second and celebrate that internal work, 'cause so much code, so many engineers, years worth of planning and coding that go into this, so give us a little but of a look behind the curtain, if you would. >> Well, you know so much community as well, right, because, like everything else that Red Hat does, it's totally Open Source. So, many communities feed into Fedora, and Fedora feeds into RHEL, so we took Fedora 28, and pulled it in, and then did a lot more work on it, to try to move it into, this year, we've done the distro differently. There's a core kernel, the noodles, you know, and then there are the application streams. So we've done a lot of work to separate out the two types of package that make up RHEL, so that we can spin the application streams faster. That's where things like developer tools, and language runtimes, databases, the things that are more aimed at developers, where a ten-year life cycle is not a natural for those, right, and yet the core of RHEL, the kernel, you rely on that, we're gonna support it for ten years, but you need your application streams to keep the developers happy. So we tried to make the admin side happy, and the developer side happy. >> All right so, as Vice President of Software Engineering, your team had, certainly, its focuses along this way. >> Denise: Oh, yeah. And dealing with, I guess, the complexities that you were, was there maybe a point in the process where you had an uh-oh moment, or, I'm just curious, because it's not always smooth sailing, right, you run into speed bumps, and some times there're barriers, they're not just bumps, but in terms of what you were trying to enable, and what your vision was to get there, talk about that journey from the engineering side of the equation, and maybe the hiccups you had to deal with along the way. >> So, RHEL 8 has been interesting because in the course of putting the product together, the RHEL organization went through our own digital transformation. So just like our customers have been moving to become more agile, the RHEL engineering team, and our partners in QE, and our partners in support, have worked together to deliver the operating system in a much more agile way. I mean, did you ever think you would hear agile and operating system in the same breath, right, it's like, wow. So that has been an interesting process, and a real set of challenges, because it's meant that people have had to change work habits that have served them well for many, many years. It's a different world. So we've been very fortunate to take people through a lot of changes, they've been very flexible. But there have been some times when it's just been too much too fast, like (gasps), And so it's like, everybody take a deep breath, okay, will do. You know, a couple of weeks, we'll consolidate. It's been a really interesting process. Clearly the kernel, so we've got the 4.18 kernel, and the kernel comes in and we have to understand what the kernel configuration is gonna be. And that can be a lengthy process, because it means you have to understand, when you pull a kernel out of the upstream some of the features are pretty solid, some are maybe less solid. We have to make an educated call about what's ready to go and what's not. So figuring out the kernel configuration can take a while. We do that with our friends in the performance team. And so every inch of the way, we build it, we see how the performance looks, maybe we do some tweaking, change that lock, everything we do goes back upstream, to make the upstream kernel better. So that, as well, has been an interesting process, because there's a lot of change. We're really proud of the performance in RHEL 8, we think that it's a significant improvement in many different areas. We've got the Shack and Larry Show tomorrow, we'll talk all the way through performance, but that's been a big differentiator, I think. >> All right so, Denise, security, absolutely is at top of mind always? >> Denise: Always. >> Some updates in RHEL 8, maybe if you walk us through security and some of the policy changes. >> Yeah, we bake security in, right, we have a secure supply chain, and, talk about difficult things for RHEL 8, right, every package that comes in, we totally refresh everything from upstream. But when they come in, we have to inspect all the crypto, we have to run them through security scans, vulnerability scanners, we've got three different vulnerability scanners that we're using, we run them through penetration testing, so there's a huge amount of work that comes just to inherit all that from the upstream. But in addition to that, we put a lot of work into making sure that, well, our crypto has to be FIP certified, right, which means you've got to meet standards. We also have work that's gone in to make sure that you can enable a security policy consistently across the system, so that no application that you load on can violate your security policy. We've got nftables in there, new firewalling, network-bound disk encryption, that actually, it kind of ties in with a lot of the system management work that we've done. So a thing that I think differentiates RHEL 8 is we put a lot of focus on making it easy to use on day one, and easy to manage day two. It's always been interesting, you know, our customers have been very very technical. They understand how to build their golden images, they understand how to fine-tweak everything. But it's becoming harder and harder to find that level of Linux expertise. I'll vouch for that. And also, once you have those guys, you don't want to waste their time on things that could be automated. And so we've done a lot of work with the management tooling, to make sure that the daily tasks are much easier, that we're integrated better with satellite, we've got Ansible system roles, so if you use Ansible system roles we wanted to make it easy, we wanted to make the operating system easy to configure. So the same work that we do for RHEL 8 itself also goes into Red Hat Enterprise Linux core OS, which will be shipping with OpenShift. So it's a subset of the package set, same kernel. But there it's a very, very focused workload that they're gonna run. So we've been able to do a really opinionated build for RHEL core OS. But for RHEL 8 itself, it's got to be much more general purpose, we've focused on some of our traditional workloads, things like SAP, SAP HANA, SQL Server, so we've done a lot to make sure that those deploy really easily, we've got tuning profiles that help you make sure you've got your system set up to get the right kind of performance. But at the same time, there are lots of other applications out there and we have to do a really good general-purpose operating system. We can be opinionated to some extent, but we have to support much, much wider range. >> Yeah, I mean, Denise, I think back, it's been five years since the last major release. >> Yeah. >> And in the last five years, you know, Red Hat lived a lot of places, but, oh, the diversity of location in today's multi cloud world, with containerization and everything happening there, and from an application standpoint, the machine learning and new modern apps, there's such breadth and depth, seems like in order of magnitude more effort must be needed to support the ecosystem today than it was five years ago. >> Well, it's interesting that you say ecosystem, because you don't play in those places without a tight network of partnerships. So we have lots, of course, hardware partnerships, that's the thing that you think about when you think about the operating system, but we also have lots of partnerships with the software vendors. We've done a lot of work this year with Nvidia, we've supported their one and two systems, right, and we've done a lot to make sure that the workloads are happy. But, increasingly, as ISVs move to containerize their applications, when you containerize you need a user space that you bring along with you, you need your libraries, you need your container runtime. So we've taken a lot of the RHEL user space content, and put it into something that we're calling the Universal Base Image. So, you can rely on that layer of RHEL content when you build your container, put your application into a container. You can rely on that, you can get a stream of updates associated with that, so you can maintain your security, and when you deploy it on top of RHEL, we're with OpenShift, we can actually support it well for you. >> Walk me through the migration process, a little bit, if I'm running 7, and I'm shifting over, and I'm gonna make the move, how does that work? >> Denise: Carefully (laughs). >> Yeah sure, right. (laughs) 'Cause I've got my own concerns, right, I've got-- >> Of course! >> Sure, I've got to think, daily operation, or moment-to-moment operation, I can't afford to have downtime, I've got to make sure it's done in a secure way, I've got to make sure that files aren't corrupted, and things aren't lost, and, so that in itself is a, teeth-gnashing moment I would think, a bit, how do you make that easier for me? >> Yeah, well, especially when you've got 10,000 servers that you need to manage, and you want to start migrating them. You absolutely have to come to tomorrow morning's demo, we're gonna do, it's live! >> It's always tricky, right, live is always, yeah. >> Yeah, but migration, so we've put a lot of effort into migration. We're looking at, it's no good if the applications can't come along, why would you migrate the operating system, you wanna migrate the application. So we've got tooling that examines your environment, and tries to automate as much of it as we can. It looks at your existing environment, it looks at what you're gonna move through, it'll ask a few questions, it's totally driven by plug-in equivalents, we call them actors, and they understand the various, like one understands how to do network configuration, one understands how to replicate your disk configuration. It's integrated with automated backup and rollback, which is a thing that people have wanted for a long time so that we've got a much tighter level of safety there. We won't be able to migrate everything, I'm sure, but, as time goes along we add more and more and more into that utility as we learn more about what matters to customers. >> So, tomorrow morning, live demo. >> Denise: Live demo! >> Get a good night's sleep tonight! >> Denise: Put on your crash helmets! >> Fingers crossed. But thanks for joining us here and talking about the RHEL 8, about the rollout, and we wish you well with that, off to a great start for sure. >> Thank you so much, >> Thank you Denise. >> the RHEL teams are amazing, I love my guys. >> Great, thanks for being with us. >> Denise: Thank you so much. >> We'll continue here at the Red Hat Summit. You're watching theCUBE, live from Boston. (upbeat music)

(upbeat music) >> Live from Boston, Massachusetts It's theCUBE covering Red Hat Summit 2019. (upbeat music) Brought to you by Red Hat. >> Welcome back live here in Boston along with Stu Miniman, I'm John Walls. You are watching The Cube. We are at the Red Hat Summit for the sixth time in our cube history. Glad to be here. Beautiful, gorgeous day Stu by the way in your hometown. >> Yeah love, beautiful day. It was a little cold when we were here two years ago, but lovely spring day here in Boston Yeah great to be here Glad you're with us here on the Cube Glad to have John Healy with us as well He is the VP of the Internet of Things group at Intel as long as the GM of Platform Management and Customer Engineering John, good morning to you. >> Good morning to you too >> You're kind of the newbie on the block in the IOT group Your data center for a long time moving over to IOT, so just if you would tell me a little bit about that transition >> Yeah, it's been good. >> What you're seeing and kind of what's exciting you about this opportunity for you. >> So it's really interesting, I spent nearly 15 years with the data center group at Intel, did a ton of work with partners like Red Hat over the years. A lot of our focus was in how we bring a lot of data center technologies and grow them somewhat beyond the basic data center. I spent a lot of time on the data network side working with com service providers and Aviv and the build out of their softwarization or cloudification if you like of the infrastructure and now moving over to IOT it's almost like I'm going to the other end of the wire. You know all of the applications and the services we were focused on were very much IOT centric You know enabling new markets, enabling customers to do things when they connected their different devices in ways they couldn't have done before. So, a lot of the focus now is on how we continue to bring those cloud technologies. A lot of things that have matured in the data center further and further down and a lot of cases to the edge in talking about the cloudification of the edge and enable new IOT services and IOT applications to fulfilled and to be delivered. >> John you bring great context to this discussion and I've said the last 10 years there was that pull of the cloud and Intel is at every single show that we go to And a lot of people haven't fully understand and grasp. They hear edge computing, they hear IOT and it's big you know orders of magnitudes more devices you know the surface area that we're going to do their but a lot of times, they're like oh well we're bringing it out of the cloud and back there and we're back in the data center I'm like no no no no no This is not the data centers that you built before, but there is connection between data centers >> Sure >> And the cloud and the edge and the edge in there so you've got good content. Help frame it a little bit as to where we are in the discussion. Some of the users, where they are in the whole IOT discussion. >> Yeah and I think we need to take a step back from looking at one demographic versus another think of IOT versus cloud It really is the continued proliferation of distributed computing. Think of that as sort of the horizontal underpinning of all... >> Absolutely. >> It's how do I enable more and more advanced intelligence and insight to be gained from the data that is being created and derived in how I run my infrastructure and relay new services and new capabilities on top of it and then you start applying that to all of the different markets and there's almost no market that you could conceive that can't take advantage of that So, as we build out data center capability and all of the underpinnings and how you best build out those platforms and take advantage of all the innovation, work with you know partners like Red Hat as being a critical component of that. So, you know we've worked with them for almost actually since the beginning, we were one of the early investors and work with a partner like Red Hat to make sure that those infrastructure components are optimized to work well together build a reference architecture that can be deployable in a data center environment whether it's in an enterprise or in a cloud vendors environment and increasingly enable them to build open and hybrid implementations Now, the reason I start there is because really we are proliferating from that pace. So if you consider, and we do, that the future is open, hybrid implementations, hybrid cloud, multi cloud where the workload can be enabled and supported by the best implementation and best environment from it. Could be the best cloud environment, the best underpinning platforms and the best solution stacks to enable that to occur. We're now moving that into realm of more and more of the IOT applications whether it's in industrial environments, it's in healthcare environments, in retail and automotive, all across the different landscape the premises is essentially the same that we insure that the right environment is created for the application to be supported and we're bringing more and more of the environmental you know capabilities of cloud like deployment cloud like management, increasingly out into those applications So, if you look at each of the different markets they're at differing points of their maturity or of their development I like to use the example of the com service provider the telecom service providers as sort of a basis of this is what happened when an entire market looked at the benefits of data center technology or server technologies and wanted the economies of scale and the openness of those environments to be appropriate and deployed in their environment, in their networks and we've seen that over the last 10 years in the journey from software SaaS for defining networking all the way through to NFV and now it's happening with cloudification of the network. Industrial environments are very very similar Decades of building you know vertically integrated solutions but not looking for the economies of scale that cloud like technology and open interfaces and open extractions can provide and we're starting to see them embark on that journey in a very similar manner. So, I see parallels as we move through from one market to the other But the basic underpinning is very similar. How we take advantage of those capabilities. >> Yeah fascinating stuff You said it's distributed architectures is where were building I look at Intel and it's fascinating to me because one the one hand everything's becoming more and more distributed yet at the same time you're baking things down into the chip as much as you can, you're working with partners at Red Hat to make sure that you know what gets baked into the kernels so you've got that give and take that it is both being as distributed as possible yet every component gets things like security built in to it and it has to work with all of the environments so it's not the discreet components that we might have had before and you talk about6 you know IT versus OT well they're becoming very similar, telecommunications is not the telecom of the dot com boom. They're doing things like NFV and the likes so you know we're starting to see IT kind of take over a lot of those environments are we not? >> Well, I think IT constructs and the abilities and capabilities of IT and it's the merging really is and we saw this you know we seen it over the last number of years it really is a marriage of both environments coming together the mechanism but though which IT will deploy and manage the infrastructure married to the expectations from a SLA and quality of service and such that's required on the network just as one example and then as we work with our partner like Red Hat, what's critically important is that we have multiparty approaches to the market which I think Stu to your point is kind of another dynamic we're seeing is that the implementation of the final solution at a platform level requires collaboration across multiple different entities, multiple different partners so if we're working with Cisco or with Dell or with Lenovo and Red Hat we're bringing together reference architectures that take advantage of the innovations in the platform, the work we're doing, the innovations into the silicone and the enabling and preservation of those innovations through the software stack. So whether its RHEL or Rev or its OSP and make sure that those are exposed and can be preserved in the implementation so then the application that sits on top of the stack can take advantage all the way down and be provisioned such that it maintains the policies and the levels of performance and such that of being defined for it. >> I'd like to you know go back to the telecom illustration that you were talking about just a movement ago and we talked about the internet of things and this explosion of devices and capabilities and the new spectrum that's being rolled out right 5G on the horizon You know very much in a nascent stage right now What is that going to do in terms of your attention or your focus because of the capabilities are going to be provided you know that I can't even imagine the kinds of speeds we're talking about the kind of capabilities we're talking about. How does that change your world? >> I think what is fundamental about 5G is how it starts to address some of the underpinning challenges in deploying multiple billions of connected endpoints or devices so IOT you know subscribes really to two things Connectivity and then the access to our unleashing of all of the data it's really those two dynamics Once you comment these devices together or provide for connectivity to and from them, you now have the ability to drive more insight from the data that they're capturing and make more intelligent and informed decisions about how you provision and then all sources of new applications and service types become possible as a result of that but there in both of those there's a challenge. How do you connect all of those devices together in a manner that's you know efficient to deploy and easy to manage and also provide for the connectivity that is very burst in nature You know there are time when you will need pretty reasonable sizeable bandwidth if it's a video type application and times when you really won't need very much at all and how do you do that in an environment that's affordable and cost effective to deploy? If you're a manufacturing plant manager running cable to every single one of your You know nodes or connectors or sensors across your production plant is a pretty orneriest task and its an expensive capital deployment, but 5G provides you the ability to provide that connectivity within your enterprise or within your factory environment in an efficient manner. It's wireless based. It also provides for the very low latency that allows for real time applications and it provides for mass deployment and management of very large numbers of endpoints so if we think of the density of 5G the low latency capability of it and then the manageability in framework that is in an environment that is predictable that is policy and SLA governed you start to address some of the really fundamental challenges that connecting vast numbers of devices that that can present. So I see 5G as a path to significantly accelerating what we have always envisioned as being the internet of things and as a result of it, new services and new service categories will be enabled on top of it that were before maybe possible but not possible in an efficient and affordable manner >> Can you give me a practical example of that or just... >> Well, if you think even a smart city as an example where the light posts and the traffic signals and kiosks are all playing a role in a connected mesh of interconnected entities you could have a situation and you know for the US audience something like an Amber Alert which we'd see where we want to you know search for a very specific license plate in the city. Well today its a pretty manual process, the Amber Alert is issued, it may be a text on your phone. We get those alerts, there's often times a display over to the smart display over the freeway but then it's up to the drivers to look out. Well just consider the possibilities when the cars using their own vision, which the autonomous driving you know evolution or revolution is allowing us progressing All of the cameras on all of the cars now become actively watching for license plates and they can pick up whether and then a car can enroll itself into or out of that service so if your car is sitting at a garage and this request comes it'll report back I'm sitting in the garage I'm not part of the mix but if it's on the freeway, it can enroll itself and start to actively search for that license plate that's an example and then all of the connected nodes across the city become points for an exchange of data to and from the different cars as they are passing by and all of that infrastructure is enabled by 5G. So that's an application that yeah we don't have it today, but it becomes a very possible application in the future. >> Alright John, so we're at Red Hat Summit and as you said Intel and Red Hat have a long partnership RHEL 8 was announced today can you give us the latest on the deep integrations and what users should be expecting. >> Yeah and what we're really excited about with Red Hat over the years we've really shared a common vision about what we believe the industry should be capable of achieving and this concept of open hybrid environment, it's open hybrid clouds we've been working with them for a long time on how we best enable that so in upstream we work well together, we collaborate on what technologies we want to see exposed and supported within the different communities and then on the downstream into the products with the example of what you're describing to do with RHEL 8 What's really exciting is we did it just as a example, we did a very large data centric launch in early April We were extremely excited to bring you know a whole portfolio of new products to the market together to expand form new CPUs all the way through to some of our storage products and memory products and the capabilities of each of those is what really needs to continued to be integrated and supported with the product portfolio that Red Hat had so with RHEL 8 we're seeing things like our DL Boost for deep learning you know taking advantage of specific accelerations within the CPU in our scalable ZM processor so it can take advantage of those and really enhance the performance and behavior of the deep learning algorithms just as one example and that's you know time to market with us on RHEL 8 we're delighted about the integration as it happened same thing with some of our memory technologies and the support for those within RHEL so a customer deploying an application knows that the innovations within the hardware within the silicone are available and manageable form the software environment that they're deploying and that's the benefit of this tight collaboration as we plan together for future you know innovations and how they can best be integrated and do the work upstream in advance of that so that the community issues whether it's open shift or open stack is enabled and capable of the support at the same time >> Internet of things just before you head off where do you want to, you're still relatively fresh right to that space, where do you think you want it to go with Intel? Like what's your vision or what are your thoughts about the kinds of areas that you'd like to explore here over the next 18-24 months? >> I think we have, first thing is an incredibly exciting market some of the examples we just spoke about, the possibilities that they open up for our customers but also for our partners to really evoke new forms of business, new revenues, new capabilities as a result of bringing the marriage of cloud technology together with the economics of you know volume technology consumption and deployment and all of those assets across into a new set of applications that IOT opens up I see tremendous opportunity to make that marriage happen but also because I've spent so much time on the infrastructure side and very much with com service providers you know I can feel the pent up desire to find ways to deploy new types of manage services and new monetization models if they can get inside the data how we do optimal deployment of networks manage infrastructure on behalf of end customers and all that becomes possible if we bring the application and the IOT closer to the infrastructure so a lot of my focus will really be on bridging across those different worlds ensuring that work with you know partners like Red Hat continue to be the developed very successfully and we open up new opportunities for each other >> Sure. An exciting time, there's no doubt about that. You're at this great convergence right? You're at the fun and games part of this with devices and that exponential growth John thanks for thanks for the time. >> Sure, thank you. >> Glad to have you here on theCUBE once again John Healy joining us from Intel back with more live from Boston you're watching theCUBE. (upbeat music)

(upbeat music) >> Live from Las Vegas, it's theCUBE, covering AWS re:Invent 2018, brought to you by Amazon Web Services, Intel, and their ecosystem partners. >> Well, welcome back here, as we continue our coverage at AWS re:Invent, along with Justin Warren, I'm John Walls, we are live in Las Vegas in the Sands. Day one of our coverage here, three days, with you all week. We're with Jon Masters now, who's the chief architect at Red Hat. Jon, good to see you this afternoon. >> Thank you, nice to be here. >> First off, give me your impression of what you've seen so far on the show floor, what's the feeling you've got as you come in this week? Well, it's been absolutely fabulous for me. It's my first time at re:Invent, so I've not had chance to witness firsthand the growth over the few years, but I've heard stories that we're up to 75,000 people, some very high number this year, and the growth is absolutely amazing. Very, very passionate people, it's very clear that the story of containerization and microservices is foremost this year, and yeah, it's just a fabulous experience to be here. >> Great, now yesterday, there was announcement from AWS about A1 instance, tell me a little bit about how that comes to play in a Red Hat and just your take on the release. >> Yeah, so Amazon did announce yesterday the new A1 instance type, and it's based on the Arm architecture, I think the interesting thing for me is that it's based on a processor that they themselves built called the Graviton. You know, this is really the culmination of what we've seen in the industry in the past few years. As the cloud vendors get bigger and have greater resources and greater capabilities, what they can do is they can take that self-determination aspect, and they can say, you know what, we're now big enough, and we now understand, and we're sophisticated enough that we can say we would like to deliver this to our customers, and we don't have to wait for someone to build it for us, we can just go and do it. And so what they did is they licensed an Arm design from Arm Holdings, the actual core inside the processor, and then they built the chip themselves, and contracted out to a foundry, manufactured and deployed these, and then, you know, they can snap their fingers and deploy these and, surprise, now we have Arm-based instances, so it's been very interesting. >> So I'm curious, 'cause we keep getting told that software is leading the world, and yet here we are, building hardware and customized hardware. So what is it about the Arm architecture in particular, but also the fact that you can build custom silicone, what is it that Amazon, or indeed any other cloud vendor, what benefit do they get from manufacturing their own silicone here? >> That's a very good question. Well, I think there's multiple aspects to it. At the end of the day, people tell me that the future is serverless, and I remind them that there's still servers somewhere, right? So we still need to have computers. Of course, we're going to have a smaller number of very big vendors on which we rely, I mean, we're seeing that with the adoption of public cloud, and as these vendors get bigger, they have that scale that they can invest what, for them, is a modest amount of money, for anybody else, it'd be a fortune, but a modest amount, and they can go and build a design. Now, with a traditional microprocessor design, you'd take a team of four people, and you would spend many hundreds of millions of dollars, maybe 300 million dollars over four years, to build a high-performance processor. What you can do with Arm is work with Arm Holdings, which is now a part of SoftBank, to license kind of cookie-cutter pre-made pieces, so you can license a processor core, and you can stamp it out and say, well, I'll have 16 of those in my chip. So you don't have to do the heavy lifting to design many of the building blocks, but you can integrate them together, so you get a lot of cost-efficiency there, you don't have to go and do all that design, but you can integrate building blocks. And the key piece there, I think, is the ability to choose how you want to integrate that and what you want to build. Right? And then, what we're seeing in the industry is that compute is becoming boring, right? I mean, everyone needs compute, but what are we talking about? We're talking about machine learning and GPUs and tensors and all kinds of other accelerators, right? So, the interesting thing for me is, once you've made the compute kind of so commodity that you can just license it from somebody and stamp out your own design, what opportunity does that bring later to maybe integrate various accelerators and other hardware goodies? I don't know what Amazon plan to do, but if I had a crystal ball, I would say this is probably not the end. This is kind of the beginning of a journey, and now they will have the ability to integrate some very interesting and novel hardware advances of their own as well. Okay, 'cause that does sort of lead into what my next question going to be. Which is, for a customer of Amazon, it's like, well, I don't know anything about the internals of chip design, why would I want to choose the A1 instance type over one of the other existing instance types? What's in it for me? >> Yeah, very good question. I think when Amazon announced it last night, the top line that the media picked up on first was the price benefit there, which was advertised as being 40% lower for certain workloads. Now the design that they've chosen today is not about having that top-shelf performance, that top-line performance. If you want that level of performance, clearly you're going to use one of the existing instance types. But if you want to have something that is more cost-effective for at-scale deployments, maybe where you're not using all the compute resources that you need, you're more memory-bound, or you're doing web app-serving, this kind of thing, in that case, you don't really need that level of compute. You still need the instances, and so this brings your cost down when you're doing that at-scale kind of deployment. And that seems to be where they're targeting. And in addition, they're targeting, I think, developers, and those that want to invest in the Arm ecosystem, because clearly this is the beginning of a journey, I don't know exactly where they'll go next, but one could imagine that it will continue from here. >> Okay, now you are an Arm fan. >> I am. >> But we don't actually work for Arm, you work for Red Hat, so what's the Red Hat angle here? >> Well, so I'll tell you a story. >> Okay, I like stories. (men laughing) >> Me too, so back at the end of-- >> I like stories too, Jon, go ahead. >> Well, I'll spare you the long form. The end of 2010, I was in one of my execs' offices, and I've been with Red Hat since 2006, and I had done a couple of things before that that kind of were very useful for the company but kind of dull, so they said, "All right, you choose something exciting to work on next," right? So I held up a BeagleBoard, which is a bit like a raspberry pie, and I told one of my execs, "This will be a server one day." And I walked through Moore's law and the pace of innovation and fast-forwarded and say, if these things were to happen, this technology would be in a server. Now why is that relevant to Red Hat? Well, if you look at it from Red Hat's point of view, we don't pick winners and losers, what we do is we work with customers and what they want to adopt, but we also need to be able to respond to our customers' needs, so kind of the concern was, this Arm thing looks like it could be interesting in a few years' time, what if it is? And if it is interesting, and it's kind of a zoo, as I used to call it, a free-for-all, you know, it's kind of an embedded mess, that works fine, well "fine" in quotes, if you're building cell phone widgets and so on, because it's kind of a different ecosystem there, but if you want to have a mainstream server play, we had to have a few of us in industry come in and say, all right, this looks interesting, but let's make sure that the level of standardization is there, so that if this does take off, standard operating systems and standard software can run on it, that's why we cared, was just in case it takes off. And then fans like me, of course, want to kind of promote it as well, but I think that's why Red Hat cared. >> You know, and this is kind of off-topic, but I'm just curious, because you've talked about the acceleration of change, you've talked about innovation, you've talked about new wrinkles, and Moore's law, is it possible, or do you see that the acceleration of change is so rapid that we're almost outpacing ourselves in a way? And that change is happening so dramatically and so quickly that to make a decision on a particular solution or service is difficult because you're afraid of missing the next flavor in eight months or nine months, instead of three or five years? >> That's right, and I think there's another piece there where the cloud makes even more sense, doesn't it? Because if you are a customer, or an end-user, and you're deploying an app, you could say, well, this Arm thing could be interesting, I don't know, I don't want to go and build out physical infrastructure and go and pay that tax to go and figure this out, what I want to do is I just want to try it out right now. And the fabulous thing that Amazon did yesterday, that no one had done, you know, there'd been some efforts out there to provide Arm to the mainstream, right? But Amazon put a giant rubber stamp on it and said, this is good enough for us, and it works. Now anyone who's used to a workflow in EC2, they can just use exactly the same flow to spin up one of these instances and try it out. It's a 30-second thing, just try it out, see what you think. If you like it, great, if you don't, then don't use it. And because you are able to just consume it, according to whatever you want, you don't have that commitment either, yeah. >> So a test drive? >> You can test drive it, if it works well, you can adopt it. There's no obligation, and that's, I think, key to exploring new technologies as well. >> Yeah, it does require you to have that software layer on top of it that runs, we were talking before, that Red Hat has invested a lot to actually get the Red Hat software suite to run on Arm. >> That's right. >> So I'm sure that with this announcement, there's going to be a whole lot of other people suddenly discovering how to compile to the Arm architecture. (Jon laughs) That'll be fun. >> That's right, we've invested for the last eight years in this, and what we have now is a strategy we call our multi-architecture strategy. So again, we don't pick winners and losers, we have all these different architectures that we support, obviously x86, also Power, and Mainframe, and now Arm, and all these architectures are treated equally going forward, so in RHEL 8, which we just announced the beta of RHEL 8, you'll see all these architectures treated just the same. And so the rule for our developers is, whenever they make a change, it has to run on all the architectures equally. >> Democratize it, and then make it so that it is standard across the board. >> That's right. >> Makes sense. Jon, thanks for the time. >> Oh, absolutely. >> Good to see you here at re:Invent, and wish you all the success down the road. >> Thank you very much. >> You bet. Jon Masters joining us from Red Hat. Back with more, we are here at AWS re:Invent, we're live in Las Vegas, and Justin and I'll be back in just a moment.