(upbeat music) >> Okay, welcome back everyone. I'm John Furrier here in theCUBE, in Palo Alto for "CUBE Conversation" with Chris Jones, Director of Product Management at Platform9. I've got a series of questions, had a great conversation earlier. Chris, I have a couple questions for you, what do you think? >> Let's do it, John. >> Okay, how does Platform9 Solution, you- can it be used on any infrastructure anywhere, cloud, edge, on-premise? >> It can, that's the beauty of our control plane, right? It was born in the cloud, and we primarily deliver that SaaS, which allows it to work in your data center, on bare metal, on VMs, or with public cloud infrastructure. We now give you the ability to take that control plane, install it in your data center, and then use it with anything, or even in air gap. And that includes capabilities with bare metal orchestration as well. >> Second question. How does Platform9 ensure maximum uptime, and proactive issue resolution? >> Oh, that's a good question. So if you come to Platform nine we're going to talk about always on assurance. What is driving that is a system of three components around self-healing, monitoring, and proactive assistance. So our software will heal broken things on nodes, right? If something stops running that should be running, it will attempt to restart that. We also have monitoring that's deployed with everything. So you build a cluster in AWS, well, we put open source monitoring agents, that are actually Prometheus, on every single node. That means it's resilient, right? So if you lose a node, you don't lose monitoring. But that data importantly comes back to our control plane, and that's the control plane that you can put in your data center as well. That data is what alerts us, and you as a user, anytime of the day that something's going wrong. Let's say etcd latency, good example, etcd is going slow. We'll find out, we might not be able to take restorative action immediately, but we're definitely going to reach out and say,, "You have a problem, let's get ahead of this and let's prevent that from becoming a bigger problem." And that's what we're delivering. When we say always on assurance, we're talking about self-healing, we're talking about remote monitoring, we're talking about being proactive with our customers, not waiting for the phone call or the support desk ticket saying, "Oh we think something's not working." Or worse, the customer has an outage. >> Awesome. Thanks for sharing. Can you explain the process for implementing Platform9 within a company's existing infrastructure. >> Are we doing air gap, or on-prem or SaaS approached? SaaS approach I think is by far the easiest, right? We can build a dedicated Platform9 control plane instance in a manner of minutes, for any customer. So when we do a proof of concept or onboarding, we just literally put in an email address, put in the name you want for your fully qualified domain name, and your instance is up. From that point onwards, the user can just log in, and using our CLI, talk to any number of, say, virtual machines, or physical servers in their environment for, you know, doing this in a data center or colo, and say, "I want these to be my Kubernetes control plane nodes. Here's the five of them. Here's the VIP for the load balancing, the API server and here are all of my compute nodes." And that CLI will work with the SaaS control plane, and go and build the cluster. That's as simple as it, CentOS, Ubuntu, just plain old operating system. Our software takes care of all the prerequisites, installing all the pieces, putting down MetalLB, CoreDNS, Metrics Server, Kubernetes dashboard, etcd backups. You built some servers. That's essentially what you've done, and the rest is being handled by Platform9. It's as simple as that. >> Great, thanks for that. What are the two traditional paths for companies considering the cloud native journey? The two paths. >> The traditional paths. I think that's your engineering team running so fast that before you even realize that you've got, you know, 10 EKS clusters. Or, hey, we can do this. You know, I've got the I can build it mentality. Let's go DIY completely open source Kubernetes on our infrastructure, and we're going to piecemeal build it all up together. They're, I think the pathways that people traditionally look at this journey, as opposed to having that third alternative saying can I just consume it on my infrastructure, be it cloud or on-premise or at the edge. >> Third is the new way, you guys do that. >> That's been our focus since the company was, you know, brought together back in the open OpenStack days. >> Awesome, what's the makeup of your customer base? Is there a certain pattern to the size or environments that you guys work with? Is there a pattern or consistency to your customer base? >> It's a spread, right? We've got large enterprises like Juniper, and we go all the way down to people with 20, 30, 50 nodes in total. We've got people in banking and finance, we've got things all the way through to telecommunications and storage infrastructure. >> What's your favorite feature of Platform9? >> My favorite feature? You know, if I ask, should I say this as a pre-sales engineer, let me show you a favorite thing. My immediate response is, I should never do this. (John laughs) To me it's just being able to define my cluster and say, go. And in five minutes I have that environment, I can see everything that's running, right? It's all unified, it's one spot, right? I'm a cluster admin. I said I wanted three control plane, 25 workers. Here's the infrastructure, it creates it, and once it's built, I can see everything that's running, right? All the applications that are there. One UI, I don't have to go click around. I'm not trying to solve things or download things. It's the fact that it's unified and just delivered in one hit. >> What is the one thing that people should know about Platform9 that they might not know about it? >> I think it's that we help developers and engineers as much as we can help our operations teams. I think, for a long time we've sort of targeted that user and said, hey, we, we really help you. It's like, but why are they doing this? Why are they building any infrastructure or any cloud platform? Well, it's to run applications and services, to help their customers, but how do they get there? There's people building and writing those things, and we're helping them, right? For the last two years, we've been really focused on making it simple, and I think that's an important thing to know. >> Chris, thanks so much, appreciate it. >> Yeah, thank you, John. >> Okay, that's theCUBE Q&A session here with Platform9. I'm John Furrier, thanks for watching. (light music)

>> 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 the Seaport in Boston. This is day two of theCUBES's coverage of Red Hat Summit 2022 different format this year for Red Hat Summit. You know we are used to the eight to 9,000 people big conferences, but this is definitely and a lot of developers this is definitely a smaller, more intimate, more abbreviated keynotes which I love that new style they've really catering to the virtual audience as well as the physical audience, a lot of good stuff going on last night in the Seaport, which a lot of fun Stephanie Chiras is here is the Senior Vice President of Partner Ecosystem Success at Red Hat. >> Yeah. >> On the move again, Stephanie love to see you. >> yeah. Thank you. It's great to be here with you and now in a little different bit of a role. >> Yeah, I'm happy that we're actually in Boston and we can meet face to face. >> Yes. >> We don't have to get in a plane, but you know we'll be on a lot of planes in the next few months. >> Yeah. >> But look, a new role for you in ecosystems. You are interviewing all the partners, which is very cool. So you get a big observation space as my friend Jeff Jonas would like to say. And so, but I'd like to observe the partner ecosystem in this new era is different. >> It's very different. >> I mean just press release is going back it's really deep engineering and really interesting flywheel approaches. How is the cloud and the hybrid cloud ecosystem and partner ecosystem different today? >> I think there's a couple of things, I think first of all cloud accelerating all the innovation, the whole cloud motion pulls in a cloud partner in addition to many of the other partners that you need to deploy a solution. So this makes almost every deployment a multi-partner deployment. So that creates the need not just for one on one partnerships between companies and vendors but really for a multi-partner experience. Right, how does an ISV work with a distributor work with a cloud vendor? How do you pull all of that together and I think at Red Hat, our view of being a platform company, we want to be able to span that and bring all of those folks together. So I see this transition going from a world of partnerships into a world of a networked ecosystem. And the real benefit is when you can pull together one ecosystem with another ecosystem, build that up and it really becomes an ecosystem of ecosystems. >> Well and I'm a fan, you're a multi tool star, so it may kind of makes you dangerous because you can talk tech in your technical roles. You've been a GM so you understand the business and that's really what it takes in the part of ecosystem. It can't be just technology and just engineering integration, it's got to be a business model associated with that. Talk about those two dimensions. >> And I think what we're seeing in the ecosystem is there are partners that you build with there are partners you service with, there are partners you sell with some do all three, some do two out of three. How do you work those relationships at the end of the day every partner in the ecosystem wants to bring their value to the customer. And their real goal is how do you merge those values together and I think as you know, right, I come from the technology and the product space. I love moving into this space where you look for those value and that synergy of value to bring better technology, a better procurement experience is often really important and simplicity of deployment to customers, but partners span everything we do. We develop with them, we build with them, we deploy with them, we service with them and all has to come together. >> So how do you make this simple for customers? I mean you're describing an increasingly complex environment. How do you simplify this? >> So a couple of things one, spot onto your point Paul, I think customer expectations now are more aggressive than they've ever been that the ecosystem has done pre-work before they show up. The customer doesn't want to be the one who's pulling together this from one vendor, this from another vendor and stitching it together themselves. So there's a number of things I think we've stepped in to try and do digital engagement for certification and deployment, the creation of operators on OpenShift is one way that technology from partners can be done and enabled more easily and quickly with Red Hat platforms. I think in addition, you've seen. >> Can you go a little deeper on that? >> Sure. >> Explain that a little bit more what does that mean? Yeah, First off, we have a digital experience where partners can come in, they can certify and test their applications to run it on Red Hat platforms themselves. So it's a bit of a come one, come all. We also have an engineering team and a developer team to work side by side with them to build those into solutions. We've done things again to supplement that with capabilities of what we call validated patterns things we've done in the market with customers, with partners, we pull together a validated pattern, we put it onto GitHub so anyone can get access to it. It becomes kind of a recipe for deployment that's available for partners to come in and augment on top of that or customers can come in and pull it up GitHub and build off of it. So I feel like there's different layers in the sort of build model that we work with partners and you want to be able to on-ramp any partner wherever they want to influence their value. It could be at the base certification level, it could be even with RHEL 9 was a good one, right. RHEL 9 was the first version of RHEL that we deployed based upon the CentOS Stream model. CentOS Stream is an upstream version of RHEL very tightly tied into the development model but it allowed partners to engage with that code prior to deployment everything from hardware partners to ISV partners, it becomes a much more open way for them to collaborate with us, so there's so much we can do. >> What's the pitch to partners. I mean I know hybrid cloud is fundamental to your value proposition. I mean most people want hybrid cloud even though the cloud guys might not admit it, right, but so what's the pitch, how do you approach partners there's got to be a common theme there pitch me. >> I think one of the things when it comes to the Red Hat ecosystem is the ecosystem itself has to bring value. Yes, we at Red Hat want to bring value, we want to come in and make it easy and simple for you to access our technology when want to make it easy and simple to engage side by side in front of a customer. But at the end of the day the value of the Red Hat ecosystem is not only Red Hat, it's our partnerships with others. It's our partnerships with the hyperscalers, it's our partnerships with ISVs, it's our work in open source communities. So it's not about Red Hat being this sort of epicenter of the ecosystem. The value comes from the collective ecosystem as it stands, and I think we've made a number of changes here at the beginning of the year in order to create a end to end team within Red Hat that does everything from the build to the sell with all the way from end to end. And I think that's bringing a new layer of simplicity for our engagement with their partners, and it's allowing us to stitch together and introduce partners to partners. >> But you are a dot connector in a sense. >> Absolutely. >> And you can't do it all, I mean nobody can. >> Yeah. But especially Red Hat your strategy is not to do it all by design, so where's the big white spaces where you feel as though your strengths need to be complimented by the partners? >> Oh, I think you caught it spot on. We don't think we can do it all, we're a platform company, we know the value of hybrid cloud is all about bringing a flexibility of an ecosystem together. I think the places where we're really doubling down on is simplicity. So the Ansible announcement that we did right with Ansible automation platform on Azure. With that announcement, it brings in certified collections of ecosystem partners on that deployment. We do the work with Azure in order to do that deployment of Ansible automation platform, and then it comes with a set of certified collections that have been done with other partners. And I think those are the pieces where we can really double down on bringing simplicity. Right, so if I look at areas of focus, that's a great space, and I think it is all about connecting the dots, right, it's about connecting our work with Azure with our work with other ISV partners to pull that together and show up to a customer with something that's fast time to value. >> With so many partners to manage, how do you make sure you're not playing favorites. I guess how do you treat all partners equally or do you even try? >> We absolutely try. I think any partnership is a relationship, right, so it is what Red Hat brings to the table, it's also what the partner brings to the table. Our goal is to understand what the value is the partner wants to deliver to the customer. We focus on that and bringing that to the forefront of what we deploy. We absolutely in a hybrid world it's about choice and flexibility. Certainly there are partners and we made some announcements of course, this week, right yesterday and today with some we're continued to deepen our partnerships with those folks who are doubling down with us where their strategy is very well aligned with us. But our goal is to bring a broad ecosystem that offers customers choice. That's what hybrid cloud's all about. >> I remember years ago, your colleague Bob Pitino, I went down and met him in his office and he schooled me, he was awesome and we did a white board on alternative processors. >> Yeah. >> You guys were doing combat duty in the power division at the time. But basically he helped me understand the trend that is absolutely come true which is alternative processors. It's not just about the CPU anymore, it's about all the CPU and GPU and NPU and accelerators and all these other connected parts. You guys obviously are in the middle of that, you've got relationships with ARM, NVIDIA, Intel, we saw on stage today. Explain the importance and the trends that you see of these alternative processors and accelerators and what that means for customers in terms of the applications that they're now going to be able to tap. >> Yeah, so you know I love this topic when it comes. So one of the spaces is edge, right, we talked about edge today. Edge to me is the epitome of kind of a white space and an opportunity where ecosystem is essential. Edge is pulling together unique hardware capabilities from an accelerator all the way out to new network capabilities and then to AI applications. I mean the number of ISVs building AI applications is just expanding. So it's really that top to bottom ecosystem story, and our work with the telco comes in, our work with the ARM partners, the NVIDIA of the world, the accelerators of the world comes in edge. And then you pull it up to the applications as well. And then to touch in, we're seeing edge be deployed a lot in industries and industry verticals, right. A lot of edge deployments are tailored for a retail market or for a financial services sector. Again, for us, we rely very much on the ecosystem to go into industry verticals where platform companies. So our goal is to find those key partners in those industry verticals who speak the speak, talk the language, and we partner with them in order to support them and so this whole edge space pulls all of that together I think even out to the go to market with industry alignment. >> It's interesting to partner, so we're talking about Silicon, we could talk about that all day long. >> Yes. >> And then it spans and that we had Accenture on we had Raj yesterday. And it was interesting 'cause you think Accenture's like deep vertical industry expertise which it is but Raj's role is really cross industry, and then to tap into that industry expertise you guys had an announcement yesterday with those guys and obviously the GSIs are a key player. >> Absolutely. >> We saw a bunch of 'em last night out and about. >> Yeah. >> So talk about the importance of those relationships. >> I think we are in the announcement with Accenture is a great one, right. We're really doubling down because customers are looking to them, they're looking to the Accentures of the world to help them move into this hybrid world. It's not simple, it's not simple to deploy and get that value of the flexibility. So Accenture has built a number of tools in order to help customers on that journey which we talked about yesterday it really is a continuum of how customers adopt for their cloud space. And so us partnering with them offers a platform underneath, give them technology capabilities and Accenture is able to help customers and guide them along that journey and add a new layer of simplicity. So I think the GSI are critical in this space. >> Yeah. >> You talked about the number of companies developing AI, new AI tools right now. And it seems like there's just the pace of innovation is amazing, the number of startups is unprecedented. How do you decide who makes it into your partner system? What bars do they have to jump over to become a Red Hat partner? >> I think our whole partner structure is layered out quite honestly a bit in tiering, depending upon how much the partner is moving forward with Red Hat, how strategically we aligned our et cetera. But there is definitely a tier that is a come one come all, get your technology to work with Red Hat. We do that digitally now in the world of digital it's much easier to do that to give accessibility but there is definitely a tier that is a come one come all and participate. And then above that, it comes into tierings. How deeply do we go to do joint building to do co-creation and how do we sort of partner even on things like we have ARO and ROSA as you know which is OpenShift built with AWS with Azure those provide very deep technical engagements to bring that level of simplicity, but I would say it spans all the layers, right. We do have a dedicated engineering team to work with the ecosystem partners. We have a dedicated digital team to reach out and proactively right, invite folks to participate and encourage them through the thing and through the whole path. And we've done some things on enablement, we just made early March, we made enablement free for all our partners in order to learn more and get more skilled in Red Hat. Skills and skill creation is just critical for partners, and we want to start there right. >> So we started this conversation with how cloud ecosystems are different. And I think AWS as the mother of all ecosystems, so does Microsoft too but they've had it for a while. And I got felt like last decade partners were kind of afraid, all right, we're going to partner with a cloud vendor, but they're going to eat our lunch. I noticed last year at Reinvent that whole dynamic is changing and I think the industry's realizing this is not a zero sum game. That there's just so much opportunity especially when you start thinking about the edge. So you guys use the term hybrid, right, and John and I wrote a piece prior to Reinvent last year, we said there's something new brewing, we've got on-prem connecting to the clouds, it's going across clouds. People call that multi-cloud, but multi-cloud has been like multi-vendor. It really hasn't been a sort of strategy or a technical layer. And now you're talking the edge and we see the hyperscaler spending a hundred billion dollars a year on infrastructure. And now we see companies like yours and your ecosystem building on top of that. They're not afraid of it anymore, they're actually looking at it as a gift and so we coined this term called Supercloud which is a abstraction layer, and it rises above highs all the complexity of the underlying primitives and APIs and people kind of wince at the term Ashesh called it Metacloud which I like it's kind of fun. But do you feel like that's happening in the ecosystem? Is that a real trend or is that just my imagination? >> I think it's definitely a real trend and it's coming from customers, right, that's what customers want. So customers want the ability to choose are they going to self-manage their applications within a public cloud. There's much more than just technology in the public cloud too right. There's a procurement experience that they provide a simplicity of our relationship. They may choose one of the hyperscalers. They pick a procurement experience, they deepen that relationship, they leverage the services. And I think now what you're seeing is customers are demanding it. They want to be a part of that, they want to run on multiple clouds. And now we're looking at cloud services you've seen our strategy double down on cloud services. I think that kind of comes back together to a customer wants simplicity. They expect the ecosystem to work together behind the scenes. That's what capabilities like ARO are or OpenShift on Azure and OpenShift on AWS. That's what we can provide. We have an SRV team, we jointly support it with those partners behind the scenes but as you said, it's no longer that fear, right. We've rolled up our sleeves together specifically because we wanted to show up to the customer as one. >> Yeah, and by the way, it's not just traditional technology vendors, it's insurance companies, it's banks, it's manufacturers who are building out these so-called super clouds. And to have a super cloud, you got to have a super PaaS and OpenShift is the supers of all PaaS So Stephanie cheers, thanks so much for coming back to theCUBE, >> Oh it's my pleasure. it great to see you again. >> Thank you for the time. >> All right, and thank you for watching keep it right there this is day two of Red Hat Summit 2022 from the Seaport in Boston. You're watching theCUBE. (upbeat music)

(bright music) >> Okay, we're back in theCUBE. We said we were signing off for the night, but during the hallway track, we ran into old friend Stu Miniman who was the Director of Market Insights at Red Hat. Stu, friend of theCUBE done the thousands of CUBE interviews. >> Dave, it's great to be here. Thanks for pulling me on, you and I hosted Red Hat Summit before. It's great to see Paul here. I was actually, I was talking to some of the Red Hatters walking around Boston. It's great to have an event here. Boston's got strong presence and I understand, I think was either first or second year, they had it over... What's the building they're tearing down right down the road here. Was that the World Trade Center? I think that's where they actually held it, the first time they were here. We hosted theCUBE >> So they moved up. >> at the Hines Convention Center. We did theCUBE for summit at the BCEC next door. And of course, with the pandemic being what it was, we're a little smaller, nice intimate event here. It's great to be able to room the hall, see a whole bunch of people and lots watching online. >> It's great, it's around the same size as those, remember those Vertica Big Data events that we used to have here. And I like that you were commenting out at the theater and the around this morning for the keynotes, that was good. And the keynotes being compressed, I think, is real value for the attendees, you know? 'Cause people come to these events, they want to see each other, you know? They want to... It's like the band getting back together. And so when you're stuck in the keynote room, it's like, "Oh, it's okay, it's time to go." >> I don't know that any of us used to sitting at home where I could just click to another tab or pause it or run for, do something for the family, or a quick bio break. It's the three-hour keynote I hope has been retired. >> But it's an interesting point though, that the virtual event really is driving the physical and this, the way Red Hat marketed this event was very much around the virtual attendee. Physical was almost an afterthought, so. >> Right, this is an invite only for in-person. So you're absolutely right. It's optimizing the things that are being streamed, the online audience is the big audience. And we just happy to be in here to clap and do some things see around what you're doing. >> Wonderful see that becoming the norm. >> I think like virtual Stu, you know this well when virtual first came in, nobody had a clue with what they were doing. It was really hard. They tried different things, they tried to take the physical and just jam it into the virtual. That didn't work, they tried doing fun things. They would bring in a famous person or a comedian. And that kind of worked, I guess, but everybody showed up for that and then left. And I think they're trying to figure it out what this hybrid thing is. I've seen it both ways. I've seen situations like this, where they're really sensitive to the virtual. I've seen others where that's the FOMO of the physical, people want physical. So, yeah, I think it depends. I mean, reinvent last year was heavy physical. >> Yeah, with 15,000 people there. >> Pretty long keynotes, you know? So maybe Amazon can get away with it, but I think most companies aren't going to be able to. So what is the market telling you? What are these insights? >> So Dave just talking about Amazon, obviously, the world I live in cloud and that discussion of cloud, the journey that customers are going on is where we're spending a lot of the discussions. So, it was great to hear in the keynote, talked about our deep partnerships with the cloud providers and what we're doing to help people with, you like to call it super cloud, some call it hybrid, or multi-cloud... >> New name. (crosstalk) Meta-Cloud, come on. >> All right, you know if Che's my executive, so it's wonderful. >> Love it. >> But we'll see, if I could put on my VR Goggles and that will help me move things. But I love like the partnership announcement with General Motors today because not every company has the needs of software driven electric vehicles all over the place. But the technology that we build for them actually has ramifications everywhere. We've working to take Kubernetes and make it smaller over time. So things that we do at the edge benefit the cloud, benefit what we do in the data center, it's that advancement of science and technology just lifts all boats. >> So what's your take on all this? The EV and software on wheels. I mean, Tesla obviously has a huge lead. It's kind of like the Amazon of vehicles, right? It's sort of inspired a whole new wave of innovation. Now you've got every automobile manufacturer kind of go and after. That is the future of vehicles is something you followed or something you have an opinion on Stu? >> Absolutely. It's driving innovation in some ways, the way the DOS drove innovation on the desktop, if you remember the 64K DOS limit, for years, that was... The software developers came up with some amazing ways to work within that 64K limit. Then when it was gone, we got bloatware, but it actually does enforce a level of discipline on you to try to figure out how to make software run better, run more efficiently. And that has upstream impacts on the enterprise products. >> Well, right. So following your analogy, you talk about the enablement to the desktop, Linux was a huge influence on allowing the individual person to write code and write software, and what's happening in the EV, it's software platform. All of these innovations that we're seeing across industries, it's how is software transforming things. We go back to the mark end reasons, software's eating the world, open source is the way that software is developed. Who's at the intersection of all those? We think we have a nice part to play in that. I loved tha- Dave, I don't know if you caught at the end of the keynote, Matt Hicks basically said, "Our mission isn't just to write enterprise software. "Our mission is based off of open source because open source unlocks innovation for the world." And that's one of the things that drew me to Red Hat, it's not just tech in good places, but allowing underrepresented, different countries to participate in what's happening with software. And we can all move that ball forward. >> Well, can we declare victory for open source because it's not just open source products, but everything that's developed today, whether proprietary or open has open source in it. >> Paul, I agree. Open source is the development model period, today. Are there some places that there's proprietary? Absolutely. But I had a discussion with Deepak Singh who's been on theCUBE many times. He said like, our default is, we start with open source code. I mean, even Amazon when you start talking about that. >> I said this, the $70 billion business on open source. >> Exactly. >> Necessarily give it back, but that say, Hey, this is... All's fair in tech and more. >> It is interesting how the managed service model has sort of rescued open source, open source companies, that were trying to do the Red Hat model. No one's ever really successfully duplicated the Red Hat model. A lot of companies were floundering and failing. And then the managed service option came along. And so now they're all cloud service providers. >> So the only thing I'd say is that there are some other peers we have in the industry that are built off open source they're doing okay. The recent example, GitLab and Hashicorp, both went public. Hashi is doing some managed services, but it's not the majority of their product. Look at a company like Mongo, they've heavily pivoted toward the managed service. It is where we see the largest growth in our area. The products that we have again with Amazon, with Microsoft, huge growth, lots of interest. It's one of the things I spend most of my time talking on. >> I think Databricks is another interesting example 'cause Cloudera was the now company and they had the sort of open core, and then they had the proprietary piece, and they've obviously didn't work. Databricks when they developed Spark out of Berkeley, everybody thought they were going to do kind of a similar model. Instead, they went for all in managed services. And it's really worked well, I think they were ahead of that curve and you're seeing it now is it's what customers want. >> Well, I mean, Dave, you cover the database market pretty heavily. How many different open source database options are there today? And that's one of the things we're solving. When you look at what is Red Hat doing in the cloud? Okay, I've got lots of databases. Well, we have something called, it's Red Hat Open Database Access, which is from a developer, I don't want to have to think about, I've got six different databases, which one, where's the repository? How does all that happen? We give that consistency, it's tied into OpenShift, so it can help abstract some of those pieces. we've got same Kafka streaming and we've got APIs. So it's frameworks and enablers to help bridge that gap between the complexity that's out there, in the cloud and for the developer tool chain. >> That's really important role you guys play though because you had this proliferation, you mentioned Mongo. So many others, Presto and Starbursts, et cetera, so many other open source options out there now. And companies, developers want to work with multiple databases within the same application. And you have a role in making that easy. >> Yeah, so and that is, if you talk about the question I get all the time is, what's next for Kubernetes? Dave, you and I did a preview for KubeCon and it's automation and simplicity that we need to be. It's not enough to just say, "Hey, we've got APIs." It's like Dave, we used to say, "We've got standards? Great." Everybody's implementation was a little bit different. So we have API Sprawl today. So it's building that ecosystem. You've been talking to a number of our partners. We are very active in the community and trying to do things that can lift up the community, help the developers, help that cloud native ecosystem, help our customers move faster. >> Yeah API's better than scripts, but they got to be managed, right? So, and that's really what you guys are doing that's different. You're not trying to own everything, right? It's sort of antithetical to how billions and trillions are made in the IT industry. >> I remember a few years ago we talked here, and you look at the size that Red Hat is. And the question is, could Red Hat have monetized more if the model was a little different? It's like, well maybe, but that's not the why. I love that they actually had Simon Sinek come in and work with Red Hat and that open, unlocks the world. Like that's the core, it's the why. When I join, they're like, here's a book of Red Hat, you can get it online and that why of what we do, so we never have to think of how do we get there. We did an acquisition in the security space a year ago, StackRox, took us a year, it's open source. Stackrox.io, it's community driven, open source project there because we could have said, "Oh, well, yeah, it's kind of open source and there's pieces that are open source, but we want it to be fully open source." You just talked to Gunnar about how he's RHEL nine, based off CentOS stream, and now developing out in the open with that model, so. >> Well, you were always a big fan of Whitehurst culture book, right? It makes a difference. >> The open organization and right, Red Hat? That culture is special. It's definitely interesting. So first of all, most companies are built with the hierarchy in mind. Had a friend of mine that when he joined Red Hat, he's like, I don't understand, it's almost like you have like lots of individual contractors, all doing their things 'cause Red Hat works on thousands of projects. But I remember talking to Rackspace years ago when OpenStack was a thing and they're like, "How do you figure out what to work on?" "Oh, well we hired great people and they work on what's important to them." And I'm like, "That doesn't sound like a business." And he is like, "Well, we struggle sometimes to that balance." Red Hat has found that balance because we work on a lot of different projects and there are people inside Red Hat that are, you know, they care more about the project than they do the business, but there's the overall view as to where we participate and where we productize because we're not creating IP because it's all an open source. So it's the monetizations, the relationships we have our customers, the ecosystems that we build. And so that is special. And I'll tell you that my line has been Red Hat on the inside is even more Red Hat. The debates and the discussions are brutal. I mean, technical people tearing things apart, questioning things and you can't be thin skinned. And the other thing is, what's great is new people. I've talked to so many people that started at Red Hat as interns and will stay for seven, eight years. And they come there and they have as much of a seat at the table, and when I talk to new people, your job, is if you don't understand something or you think we might be able to do it differently, you better speak up because we want your opinion and we'll take that, everybody takes that into consideration. It's not like, does the decision go all the way up to this executive? And it's like, no, it's done more at the team. >> The cultural contrast between that and your parent, IBM, couldn't be more dramatic. And we talked earlier with Paul Cormier about has IBM really walked the walk when it comes to leaving Red Hat alone. Naturally he said, "Yes." Well what's your perspective. >> Yeah, are there some big blue people across the street or something I heard that did this event, but look, do we interact with IBM? Of course. One of the reasons that IBM and IBM Services, both products and services should be able to help get us breadth in the marketplace. There are times that we go arm and arm into customer meetings and there are times that customers tell us, "I like Red Hat, I don't like IBM." And there's other ones that have been like, "Well, I'm a long time IBM, I'm not sure about Red Hat." And we have to be able to meet all of those customers where they are. But from my standpoint, I've got a Red Hat badge, I've got a Red Hat email, I've got Red Hat benefits. So we are fiercely independent. And you know, Paul, we've done blogs and there's lots of articles been written is, Red Hat will stay Red Hat. I didn't happen to catch Arvin I know was on CNBC today and talking at their event, but I'm sure Red Hat got mentioned, but... >> Well, he talks about Red Hat all time. >> But in his call he's talking backwards. >> It's interesting that he's not here, greeting this audience, right? It's again, almost by design, right? >> But maybe that's supposed to be... >> Hundreds of yards away. >> And one of the questions being in the cloud group is I'm not out pitching IBM Cloud, you know? If a customer comes to me and asks about, we have a deep partnership and IBM will be happy to tell you about our integrations, as opposed to, I'm happy to go into a deep discussion of what we're doing with Google, Amazon, and Microsoft. So that's how we do it. It's very different Dave, from you and I watch really closely the VMware-EMC, VMware-Dell, and how that relationship. This one is different. We are owned by IBM, but we mostly, it does IBM fund initiatives and have certain strategic things that are done, absolutely. But we maintain Red Hat. >> But there are similarities. I mean, VMware crowd didn't want to talk about EMC, but they had to, they were kind of forced to. Whereas, you're not being forced to. >> And then once Dell came in there, it was joint product development. >> I always thought a spin in. Would've been the more effective, of course, Michael Dell and Egon wouldn't have gotten their $40 billion out. But I think a spin in was more natural based on where they were going. And it would've been, I think, a more dominant position in the marketplace. They would've had more software, but again, financially it wouldn't have made as much sense, but that whole dynamic is different. I mean, but people said they were going to look at VMware as a model and it's been largely different because remember, VMware of course was a separate company, now is a fully separate company. Red Hat was integrated, we thought, okay, are they going to get blue washed? We're watching and watching, and watching, you had said, well, if the Red Hat culture isn't permeating IBM, then it's a failure. And I don't know if that's happening, but it's definitely... >> I think a long time for that. >> It's definitely been preserved. >> I mean, Dave, I know I read one article at the beginning of the year is, can Arvin make IBM, Microsoft Junior? Follow the same turnaround that Satya Nadella drove over there. IBM I think making some progress, I mean, I read and watch what you and the team are all writing about it. And I'll withhold judgment on IBM. Obviously, there's certain financial things that we'd love to see IBM succeed. We worry about our business. We do our thing and IBM shares our results and they've been solid, so. >> Microsoft had such massive cash flow that even bomber couldn't screw it up. Well, I mean, this is true, right? I mean, you think about how were relevant Microsoft was in the conversation during his tenure and yet they never got really... They maintained a position so that when the Nadella came in, they were able to reascend and now are becoming that dominant player. I mean, IBM just doesn't have that cash flow and that luxury, but I mean, if he pulls it off, he'll be the CEO of the decade. >> You mentioned partners earlier, big concern when the acquisition was first announced, was that the Dells and the HP's and the such wouldn't want to work with Red Hat anymore, you've sort of been here through that transition. Is that an issue? >> Not that I've seen, no. I mean, the hardware suppliers, the ISVs, the GSIs are all very important. It was great to see, I think you had Accenture on theCUBE today, obviously very important partner as we go to the cloud. IBM's another important partner, not only for IBM Cloud, but IBM Services, deep partnership with Azure and AWS. So those partners and from a technology standpoint, the cloud native ecosystem, we talked about, it's not just a Red Hat product. I constantly have to talk about, look, we have a lot of pieces, but your developers are going to have other tools that they're going to use and the security space. There is no such thing as a silver bullet. So I've been having some great conversations here already this week with some of our partners that are helping us to round out that whole solution, help our customers because it has to be, it's an ecosystem. And we're one of the drivers to help that move forward. >> Well, I mean, we were at Dell Tech World last week, and there's a lot of talk about DevSecOps and DevOps and Dell being more developer friendly. Obviously they got a long way to go, but you can't have that take that posture and not have a relationship with Red Hat. If all you got is Pivotal and VMware, and Tansu >> I was thrilled to hear the OpenShift mention in the keynote when they talked about what they were doing. >> How could you not, how could you have any credibility if you're just like, Oh, Pivotal, Pivotal, Pivotal, Tansu, Tansu. Tansu is doing its thing. And they smart strategy. >> VMware is also a partner of ours, but that we would hope that with VMware being independent, that does open the door for us to do more with them. >> Yeah, because you guys have had a weird relationship with them, under ownership of EMC and then Dell, right? And then the whole IBM thing. But it's just a different world now. Ecosystems are forming and reforming, and Dell's building out its own cloud and it's got to have... Look at Amazon, I wrote about this. I said, "Can you envision the day where Dell actually offers competitive products in its suite, in its service offering?" I mean, it's hard to see, they're not there yet. They're not even close. And they have this high say/do ratio, or really it's a low say/do, they say high say/do, but look at what they did with Nutanix. You look over- (chuckles) would tell if it's the Cisco relationship. So it's got to get better at that. And it will, I really do believe. That's new thinking and same thing with HPE. And, I don't know about Lenovo that not as much of an ecosystem play, but certainly Dell and HPE. >> Absolutely. Michael Dell would always love to poke at HPE and HP really went very far down the path of their own products. They went away from their services organization that used to be more like IBM, that would offer lots of different offerings and very much, it was HP Invent. Well, if we didn't invent it, you're not getting it from us. So Dell, we'll see, as you said, the ecosystems are definitely forming, converging and going in lots of different directions. >> But your position is, Hey, we're here, we're here to help. >> Yeah, we're here. We have customers, one of the best proof points I have is the solution that we have with Amazon. Amazon doesn't do the engineering work to make us a native offering if they didn't have the customer demand because Amazon's driven off of data. So they came to us, they worked with us. It's a lot of work to be able to make that happen, but you want to make it frictionless for customers so that they can adopt that. That's a long path. >> All right, so evening event, there's a customer event this evening upstairs in the lobby. Microsoft is having a little shin dig, and then serves a lot of customer dinners going on. So Stu, we'll see you out there tonight. >> All right, thanks you. >> Were watching a brewing somewhere. >> Keynotes tomorrow, a lot of good sessions and enablement, and yeah, it's great to be in person to be able to bump some people, meet some people and, Hey, I'm still a year and a half in still meeting a lot of my peers in person for the first time. >> Yeah, and that's kind of weird, isn't it? Imagine. And then we kick off tomorrow at 10:00 AM. Actually, Stephanie Chiras is coming on. There she is in the background. She's always a great guest and maybe do a little kickoff and have some fun tomorrow. So this is Dave Vellante for Stu Miniman, Paul Gillin, who's my co-host. You're watching theCUBEs coverage of Red Hat Summit 2022. We'll see you tomorrow. (bright music)

(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)

welcome back to the seaport in boston massachusetts with cities crazy with bruins and celtics talk but we're here we're talking red hat linux open shift ansible and ashesh badani is here he's the senior vice president and the head of products at red hat fresh off the keynotes had amex up in the state of great to see you face to face amazing that we're here now after two years of of the isolation economy welcome back thank you great to see you again as well and you as well paul yeah so no shortage of announcements uh from red hat this week paul wrote a piece on siliconangle.com i got my yellow highlights i've been through all the announcements which is your favorite baby hard for me to choose hard for me to choose um i'll talk about real nine right well nine's exciting um and in a weird way it's exciting because it's boring right because it's consistent three years ago we committed to releasing a major well uh every three years right so customers partners users can plan for it so we released the latest version of rel in between we've been delivering releases every six months as well minor releases a lot of capabilities that are bundled in around security automation edge management and then rel is also the foundation of the work we announced with gm with the in-vehicle operating system so you know that's extremely exciting news for us as well and the collaboration that we're doing with them and then a whole host of other announcements around you know cloud services work around devsecops and so on so yeah a lot of news a lot of announcements i would say rel nine and the work with gm probably you know comes right up to the top i wanted to get to one aspect of the rail 9 announcement that is the the rose centos streams in that development now in december i think it was red hat discontinued development or support for for centos and moved to central streams i'm still not clear what the difference is between the two can you clarify that i think we go into a situation especially with with many customers many partners as well that you know didn't sort of quite exactly uh get a sense of you know where centos was from a life cycle perspective so was it upstream to rel was it downstream to rel what's the life cycle for itself as well and then there became some sort of you know implied notions around what that looked like and so what we decided was to say well we'll make a really clean break and we'll say centos stream is the upstream for enterprise linux from day one itself partners uh you know software partners hardware partners can collaborate with us to develop rel and then take it all the way through life cycle right so now it becomes a true upstream a true place for development for us and then rel essentially comes uh out as a series of releases based on the work that we do in a fast-moving center-os environment but wasn't centos essentially that upstream uh development environment to begin with what's the difference between centos stream yeah it wasn't wasn't um it wasn't quite upstream it was actually a little bit downstream yeah it was kind of bi-directional yeah and yeah and so then you know that sort of became an implied life cycle to it when there really wasn't one but it was just became one because of some usage and adoption and so now this really clarifies the relationship between the two we've heard feedback for example from software partners users saying hey what do i do for development because i used you know centervis in the past we're like yup we have real for developers available we have rel for small teams available we have rel available for non-profit organizations up and so we've made rail now available in various form factors for the needs that folks had and they were perhaps using centos for because there was no such alternative or rel history so language so now it's this clarity so that's really the key point there so language matters a lot in the technology business we've seen it over the years the industry coalesces around you know terminology whether it was the pc era everything was pc this pc that the internet era and and certainly the cloud we we learned a lot of language from the likes of you know aws two pizza teams and working backwards and things like that became common commonplace hybrid and multi-cloud are kind of the the parlance of the day you guys use hybrid you and i have talked about this i feel like there's something new coming i don't think my term of super cloud is the right necessary terminology but it signifies something different and i feel like your announcements point to that within your hybrid umbrella point being so much talk about the edge and it's we heard paul cormier talk about new hardware architectures and you're seeing that at the edge you know what you're doing with the in-vehicle operating system these are new the cloud isn't just a a bunch of remote services in the cloud anymore it's on-prem it's a cloud it's cross-clouds it's now going out to the edge it's something new and different i think hybrid is your sort of term for that but it feels like it's transcending hybrid are your thoughts you know really really great question actually since you and i talked dave i've been spending some time you know sort of noodling just over that right and you're right right there's probably some terminology something sort of you know that will get developed you know either by us or you know in collaboration with the industry you know where we sort of almost have the connection almost like a meta cloud right that we're sort of working our way towards because there's if you will you know the cloud right so you know on premise you know virtualized uh bare metal by the way you know increasingly interesting and important you know we do a lot of work with nvidia folks want to run specific workloads there we announced support for arm right another now popular architecture especially as we go out to the edge so obviously there's private cloud public cloud then the edge becomes a continuum now you know on that process we actually have a major uh uh shipping company so uh a cruise lines that's talking about using openshift on cruise lines right so you know that's the edge right last year we had verizon talking about you know 5g and you know ran in the next generation there to then that's the edge when we talk to retail the store front's the edge right you talk to a bank you know the bank environments here so everyone's got a different kind of definition of edge we're working with them and then when we you know announce this collaboration with gm right now the edge there becomes the automobile so if you think of this as a continuum right you know bare metal private cloud public cloud take it out to the edge now we're sort of almost you know living in a world of you know a little bit of abstractions and making sure that we are focused on where uh data is being generated and then how can we help ensure that we're providing a consistent experience regardless of you know where meta meta cloud because i can work in nfts i can work a little bit we're going to get through this whole thing without saying metaverse i was hoping i do want to ask you about about the edge and the proliferation of hardware platforms paul comey mentioned this during the keynote today hardware is becoming important yeah there's a lot of people building hardware it's in development now for areas like uh like intelligent devices and ai how does this influence your development priorities you have all these different platforms that you need to support yeah so um we think about that a lot mostly because we have engagements with so many partners hardware right so obviously there's more traditional partners i'd say like the dell and the hpes that we work with we've historically worked with them also working with them in in newer areas uh with regard to appliances that are being developed um and then the work that we do with partners like nvidia or new architectures like arm and so our perspective is this will be uh use case driven more than anything else right so there are certain environments right where you have arm-based devices other environments where you've got specific workloads that can take advantage of being built on gpus that we'll see increasingly being used especially to address that problem and then provide a solution towards that so our belief has always been look we're going to give you a consistent platform a consistent abstraction across all these you know pieces of hardware um and so you mr miss customer make the best choice for yourself a couple other areas we have to hit on i want to talk about cloud services we've got to talk about security leave time to get there but why the push to cloud services what's driving that it's actually customers they're driving right so we have um customers consistently been asking us say you know love what you give us right want to make sure that's available to us when we consume in the cloud so we've made rel available for example on demand right you can consume this directly via public cloud consoles we are now making available via marketplaces uh talked about ansible available as a managed service on azure openshift of course available as a managed service in multiple clouds um all of this also is because you know we've got customers who've got these uh committed spends that they have you know with cloud providers they want to make sure that the environments that they're using are also counting towards that at the same time give them flexibility give them the choice right if in certain situations they want to run in the data center great we have that solution for them other cases they want to procure from the cloud and run it there we're happy to support them there as well let's talk about security because you have a lot of announcements like security everywhere yeah um and then some specific announcements as well i i always think about these days in the context of the solar wind supply chain hack would this have you know how would this have affected it but tell us about what's going on in security your philosophy there and the announcements that you guys made so our secure announcements actually span our entire portfolio yeah right and and that's not an accident right that's by design because you know we've really uh been thinking and emphasizing you know how we ensure that security profile is raised for users both from a malicious perspective and also helping accidental issues right so so both matters so one huge amounts of open source software you know out of the world you know and then estimates are you know one in ten right has some kind of security vulnerability um in place a massive amount of change in where software is being developed right so rate of change for example in kubernetes is dramatic right much more than even than linux right entire parts of kubernetes get rewritten over over a three-year period of time so as you introduce all that right being able to think for example about you know what's known as shift left security or devsec ops right how do we make sure we move security closer to where development is actually done how do we ensure we give you a pattern so you know we introduced a software supply chain pattern uh via openshift delivers complete stack of code that you know you can go off and run that follows best practices uh including for example for developers you know with git ops and support on the pipelines front a whole bunch of security capabilities in rel um a new image integrity measurement architecture which allows for a better ability to see in a post install environment what the integrity of the packages are signing technology they're incorporating open shift as well as an ansible so it's it's a long long list of cables and features and then also more and more defaults that we're putting in place that make it easier for example for someone not to hurt themselves accidentally on security front i noticed that uh this today's batch of announcements included support within openshift pipelines for sigstor which is an open source project that was birthed actually at red hat right uh we haven't heard a whole lot about it how important is zig store to to you know your future product direction yeah so look i i think of that you know as you know work that's you know being done out of our cto's office and obviously security is a big focus area for them um six store's great example of saying look how can we verify content that's in uh containers make sure it's you know digitally signed that's appropriate uh to be deployed across a bunch of environments but that thinking isn't maybe unique uh for us uh in the container side mostly because we have you know two decades or more of thinking about that on the rel side and so fundamentally containers are being built on linux right so a lot of the lessons that we've learned a lot of the expertise that we've built over the years in linux now we're starting to you know use that same expertise trying to apply it to containers and i'm my guess is increasingly we're going to see more of the need for that you know into the edge as well i i i picked up on that too let me ask a follow-up question on sigstor so if i'm a developer and i and i use that capability it it ensures the provenance of that code is it immutable the the signature uh and the reason i ask is because again i think of everything in the context of the solar winds where they were putting code into the the supply chain and then removing it to see what happened and see how people reacted and it's just a really scary environment yeah the hardest part you know in in these environments is actually the behavior change so what's an example of that um packages built verified you know by red hat when it went from red hat to the actual user have we been able to make sure we verify the integrity of all of those when they were put into use um and unless we have behavior that you know make sure that we do that then we find ourselves in trouble in the earliest days of open shift uh we used to get knocked a lot by by developers because i said hey this platform's really hard to use we investigate hey look why is that happening so by default we didn't allow for root access you know and so someone's using you know the openshift platform they're like oh my gosh i can't use it right i'm so used to having root access we're like no that's actually sealed by default because that's not a good security best practice now over a period of time when we you know randomly enough times explained that enough times now behavior changes like yeah that makes sense now right so even just kind of you know there's behaviors the more that we can do for example in in you know the shift left which is one of the reasons by the way why we bought uh sac rocks a year right right for declarative security contain native security so threat detection network segmentation uh watching intrusions you know malicious behavior is something that now we can you know essentially make native into uh development itself all right escape key talk futures a little bit so i went downstairs to the expert you know asked the experts and there was this awesome demo i don't know if you've seen it of um it's like a design thinking booth with what happened how you build an application i think they were using the who one of their apps um during covet and it's you know shows the the granularity of the the stack and the development pipeline and all the steps that have to take place and it strikes me of something we've talked about so you've got this application development stack if you will and the database is there to support that and then over here you've got this analytics stack and it's separate and we always talk about injecting more ai into apps more data into apps but there's separate stacks do you see a day where those two stacks can come together and if not how do we inject more data and ai into apps what are your thoughts on that so great that's another area we've talked about dave in the past right um so we definitely agree with that right and and what final shape it takes you know i think we've got some ideas around that what we started doing is starting to pick up specific areas where we can start saying let's go and see what kind of usage we get from customers around it so for example we have openshift data science which is basically a way for us to talk about ml ops right and you know how can we have a platform that allows for different models that you can use we can uh test and train data different frameworks that you can then deploy in an environment of your choice right and we run that uh for you up and assist you in in uh making sure that you're able to take the next steps you want with with your machine learning algorithms um there's work that we've uh introduced at summit around databases service so essentially our uh a cloud service that allows for deep as an easy way for customers to access either mongodb or or cockroach in a cloud native fashion and all of these things that we're sort of you know experimenting with is to be able to say look how do we sort of bring the world's closer together right off database of data of analytics with a core platform and a core stack because again right this will become part of you know one continuum that we're going to work with it's not i'd like your continuum that's that's i think really instructive it's not a technical barrier is what i'm hearing it's maybe organizational mindset i can i should be able to insert a column into my my my application you know development pipeline and insert the data i mean kafka tensorflow in there there's no technical reason i can't can't do that it's just we've created these sort of separate stovepipe organizations 100 right right so they're different teams right you've got the platform team or the ops team and you're a separate dev team there's a separate data team there's a separate storage team and each of them will work you know slightly differently independently right so the question then is i mean that's sort of how devops came along then you're like oh wait a minute yeah don't forget security and now we're at devsecops right so the more of that that we can kind of bring together i think the more convergence that we'll see when i think about the in-vehicle os i see the the that is a great use case for real-time ai inferencing streaming data i wanted to ask you that about that real quickly because at the very you know just before the conference began we got an announcement about gm but your partnership with gm it seems like this came together very quickly why is it so important for red hat this is a whole new category of application that you're going to be working on yeah so we've been working with gm not publicly for a while now um and it was very clear that look you know gm believes this is the future right you know electric vehicles into autonomous driving and we're very keen to say we believe that a lot of attributes that we've got in rel that we can bring to bear in a different form factor to assist with the different needs that exist in this industry so one it's interesting for us because we believe that's a use case that you know we can add value to um but it's also the future of automotive right so the opportunity to be able to say look we can get open source technology we can collaborate out with the community to fundamentally help transform that industry uh towards where it wants to go you know that that's just the passion that we have that you know is what wakes us up every morning you're opening into that yeah thank you for coming on the cube really appreciate your time and your insights and uh have a great rest of rest of the event thank you for having me metacloud it's a thing it's a thing right it's it's it's kind of there we're gonna we're gonna see it emerge over the next decade all right you're watching the cube's coverage of red hat summit 2022 from boston keep it right there be right back you

>> Announcer: From around the globe. It's the cube presenting active DQ, intelligent automation for data quality brought to you by Io Tahoe. (indistinct) >> Got it? all right if everybody is ready we'll opening on Dave in five, four, three. Now we're going to look at the role automation plays in mobilizing your data on snowflake. Let's welcome. And Duncan Turnbull who's partner sales engineer at snowflake, Ajay Vohora is back CEO of IO. Tahoe he's going to share his insight. Gentlemen. Welcome. >> Thank you, David good to be back. >> Yes it's great to have you back Ajay and it's really good to see Io Tahoe expanding the ecosystem so important now of course bringing snowflake in, it looks like you're really starting to build momentum. I mean, there's progress that we've seen every month month by month, over the past 12, 14 months. Your seed investors, they got to be happy. >> They are they're happy and they can see that we're running into a nice phase of expansion here new customers signing up, and now we're ready to go out and raise that next round of funding. Maybe think of us like Snowflake five years ago. So we're definitely on track with that. A lot of interest from investors and right now trying to focus in on those investors that can partner with us and understand AI data and an automation. >> Well, so personally, I mean you've managed a number of early stage VC funds. I think four of them. You've taken several comm software companies through many funding rounds and growth and all the way to exit. So you know how it works. You have to get product market fit, you got to make sure you get your KPIs, right. And you got to hire the right salespeople, but what's different this time around? >> Well, you know, the fundamentals that you mentioned those that never change. What I can see that's different that's shifted this time around is three things. One in that they used to be this kind of choice of do we go open source or do we go proprietary? Now that has turned into a nice hybrid model where we've really keyed into RedHat doing something similar with Centos. And the idea here is that there is a core capability of technology that underpins a platform, but it's the ability to then build an ecosystem around that made up of a community. And that community may include customers, technology partners, other tech vendors and enabling the platform adoption so that all of those folks in that community can build and contribute whilst still maintaining the core architecture and platform integrity at the core of it. And that's one thing that's changed. We're seeing a lot of that type of software company emerge into that model, which is different from five years ago. And then leveraging the Cloud, every Cloud, Snowflake Cloud being one of them here. In order to make use of what customers end customers in enterprise software are moving towards. Every CIO is now in some configuration of a hybrid. IT is state whether that is Cloud, multi-Cloud, on-prem. That's just the reality. The other piece is in dealing with the CIO, his legacy. So the past 15, 20 years I've purchased many different platforms, technologies, and some of those are still established and still (indistinct) How do you enable that CIO to make purchase whilst still preserving and in some cases building on and extending the legacy material technology. So they've invested their people's time and training and financial investment into. Yeah, of course solving a problem, customer pain point with technology that never goes out in a fashion >> That never changes. You have to focus like a laser on that. And of course, speaking of companies who are focused on solving problems, Duncan Turnbull from Snowflake. You guys have really done a great job and really brilliantly addressing pain points particularly around data warehousing, simplified that you're providing this new capability around data sharing really quite amazing. Duncan, Ajay talks about data quality and customer pain points in enterprise IT. Why is data quality been such a problem historically? >> So one of the biggest challenges that's really affected that in the past is that because to address everyone's needs for using data, they've evolved all these kinds of different places to store it, all these different silos or data marts or all this kind of pluralfiation of places where data lives and all of those end up with slightly different schedules for bringing data in and out, they end up with slightly different rules for transforming that data and formatting it and getting it ready and slightly different quality checks for making use of it. And this then becomes like a big problem in that these different teams are then going to have slightly different or even radically different ounces to the same kinds of questions, which makes it very hard for teams to work together on their different data problems that exist inside the business, depending on which of these silos they end up looking at. And what you can do. If you have a single kind of scalable system for putting all of your data, into it, you can kind of side step along this complexity and you can address the data quality issues in a single way. >> Now, of course, we're seeing this huge trend in the market towards robotic process automation, RPA that adoption is accelerating. You see in UI paths, IPO, 35 plus billion dollars, valuation, Snowflake like numbers, nice comms there for sure. Ajay you've coined the phrase data RPA what is that in simple terms? >> Yeah I mean, it was born out of seeing how in our ecosystem (indistinct) community developers and customers general business users for wanting to adopt and deploy Io Tahoe's technology. And we could see that. I mean, there's not marketing out here we're not trying to automate that piece but wherever there is a process that was tied into some form of a manual overhead with handovers. And so on, that process is something that we were able to automate with Io Tahoe's technology and the employment of AI and machine learning technologies specifically to those data processes, almost as a precursor to getting into marketing automation or financial information automation. That's really where we're seeing the momentum pick up especially in the last six months. And we've kept it really simple with snowflake. We've kind of stepped back and said, well, the resource that a Snowflake can leverage here is the metadata. So how could we turn Snowflake into that repository of being the data catalog? And by the way, if you're a CIO looking to purchase the data catalog tool, stop there's no need to. Working with Snowflake we've enabled that intelligence to be gathered automatically and to be put to use within snowflake. So reducing that manual effort and I'm putting that data to work. And that's where we've packaged this with our AI machine learning specific to those data tasks. And it made sense that's what's resonated with our customers. >> You know, what's interesting here just a quick aside, as you know I've been watching snowflake now for awhile and of course the competitors come out and maybe criticize, "Why they don't have this feature. They don't have that feature." And snowflake seems to have an answer. And the answer oftentimes is, well ecosystem, ecosystem is going to bring that because we have a platform that's so easy to work with. So I'm interested Duncan in what kind of collaborations you are enabling with high quality data. And of course, your data sharing capability. >> Yeah so I think the ability to work on datasets isn't just limited to inside the business itself or even between different business units you're kind of discussing maybe with those silos before. When looking at this idea of collaboration. We have these challenges where we want to be able to exploit data to the greatest degree possible, but we need to maintain the security, the safety, the privacy, and governance of that data. It could be quite valuable. It could be quite personal depending on the application involved. One of these novel applications that we see between organizations of data sharing is this idea of data clean rooms. And these data clean rooms are safe, collaborative spaces which allow multiple companies or even divisions inside a company where they have particular privacy requirements to bring two or more data sets together, for analysis. But without having to actually share the whole unprotected data set with each other. And this lets you to you know, when you do this inside of Snowflake you can collaborate using standard tool sets. You can use all of our SQL ecosystem. You can use all of the data science ecosystem that works with Snowflake. You can use all of the BI ecosystem that works with snowflake. But you can do that in a way that keeps the confidentiality that needs to be presented inside the data intact. And you can only really do these kinds of collaborations especially across organization but even inside large enterprises, when you have good reliable data to work with, otherwise your analysis just isn't going to really work properly. A good example of this is one of our large gaming customers. Who's an appetizer. They were able to build targeted ads to acquire customers and measure the campaign impact in revenue but they were able to keep their data safe and secure while doing that while working with advertising partners. The business impact of that was they're able to get a lift of 20 to 25% in campaign effectiveness through better targeting and actually pull through into that of a reduction in customer acquisition costs because they just didn't have to spend as much on the forms of media that weren't working for them. >> So, Ajay I wonder, I mean with the way public policy is shaping out, you know, obviously GDPR started it in the States, California consumer privacy Act, and people are sort of taking the best of those. And there's a lot of differentiation but what are you seeing just in terms of governments really driving this move to privacy. >> Government, public sector, we're seeing a huge wake up an activity and across (indistinct), part of it has been data privacy. The other part of it is being more joined up and more digital rather than paper or form based. We've all got, so there's a waiting in the line, holding a form, taking that form to the front of the line and handing it over a desk. Now government and public sector is really looking to transform their services into being online (indistinct) self service. And that whole shift is then driving the need to emulate a lot of what the commercial sector is doing to automate their processes and to unlock the data from silos to put through into those processes. And another thing that I can say about this is the need for data quality is as Duncan mentions underpins all of these processes government, pharmaceuticals, utilities, banking, insurance. The ability for a chief marketing officer to drive a a loyalty campaign, the ability for a CFO to reconcile accounts at the end of the month to do a quick accurate financial close. Also the ability of a customer operations to make sure that the customer has the right details about themselves in the right application that they can sell. So from all of that is underpinned by data and is effective or not based on the quality of that data. So whilst we're mobilizing data to the Snowflake Cloud the ability to then drive analytics, prediction, business processes of that Cloud succeeds or fails on the quality of that data. >> I mean it really is table stakes. If you don't trust the data you're not going to use the data. The problem is it always takes so long to get to the data quality. There's all these endless debates about it. So we've been doing a fair amount of work and thinking around this idea of decentralized data. Data by its very nature is decentralized but the fault domains of traditional big data is that everything is just monolithic. And the organizations monolithic that technology's monolithic, the roles are very, you know, hyper specialized. And so you're hearing a lot more these days about this notion of a data fabric or what Jimit Devani calls a data mesh and we've kind of been leaning into that and the ability to connect various data capabilities whether it's a data, warehouse or a data hub or a data lake, that those assets are discoverable, they're shareable through API APIs and they're governed on a federated basis. And you're using now bringing in a machine intelligence to improve data quality. You know, I wonder Duncan, if you could talk a little bit about Snowflake's approach to this topic >> Sure so I'd say that making use of all of your data is the key kind of driver behind these ideas of beta meshes or beta fabrics? And the idea is that you want to bring together not just your kind of strategic data but also your legacy data and everything that you have inside the enterprise. I think I'd also like to kind of expand upon what a lot of people view as all of the data. And I think that a lot of people kind of miss that there's this whole other world of data they could be having access to, which is things like data from their business partners, their customers, their suppliers, and even stuff that's, more in the public domain, whether that's, you know demographic data or geographic or all these kinds of other types of data sources. And what I'd say to some extent is that the data Cloud really facilitates the ability to share and gain access to this both kind of, between organizations, inside organizations. And you don't have to, make lots of copies of the data and kind of worry about the storage and this federated, idea of governance and all these things that it's quite complex to kind of manage. The snowflake approach really enables you to share data with your ecosystem or the world without any latency with full control over what's shared without having to introduce new complexities or having complex interactions with APIs or software integration. The simple approach that we provide allows a relentless focus on creating the right data product to meet the challenges facing your business today. >> So Ajay, the key here is Duncan's talking about it my mind and in my cake takeaway is to simplicity. If you can take the complexity out of the equation you're going to get more adoption. It really is that simple. >> Yeah, absolutely. I think that, that whole journey, maybe five, six years ago the adoption of data lakes was a stepping stone. However, the Achilles heel there was the complexity that it shifted towards consuming that data from a data lake where there were many, many sets of data to be able to cure rate and to consume. Whereas actually, the simplicity of being able to go to the data that you need to do your role, whether you're in tax compliance or in customer services is key. And listen for snowflake by Io Tahoe. One thing we know for sure is that our customers are super smart and they're very capable. They're data savvy and they'll want to use whichever tool and embrace whichever Cloud platform that is going to reduce the barriers to solving what's complex about that data, simplifying that and using good old fashioned SQL to access data and to build products from it to exploit that data. So simplicity is key to it to allow people to make use of that data and CIO is recognize that. >> So Duncan, the Cloud obviously brought in this notion of DevOps and new methodologies and things like agile that's brought in the notion of DataOps which is a very hot topic right now basically DevOps applies to data about how does Snowflake think about this? How do you facilitate that methodology? >> So I agree with you absolutely that DataOps takes these ideas of agile development or agile delivery and have the kind of DevOps world that we've seen just rise and rise. And it applies them to the data pipeline, which is somewhere where it kind of traditionally hasn't happened. And it's the same kinds of messages. As we see in the development world it's about delivering faster development having better repeatability and really getting towards that dream of the data-driven enterprise, where you can answer people's data questions they can make better business decisions. And we have some really great architectural advantages that allow us to do things like allow cloning of data sets without having to copy them, allows us to do things like time travel so we can see what the data looked like at some point in the past. And this lets you kind of set up both your own kind of little data playpen as a clone without really having to copy all of that data so it's quick and easy. And you can also, again with our separation of storage and compute, you can provision your own virtual warehouse for dev usage. So you're not interfering with anything to do with people's production usage of this data. So these ideas, the scalability, it just makes it easy to make changes, test them, see what the effect of those changes are. And we've actually seen this, that you were talking a lot about partner ecosystems earlier. The partner ecosystem has taken these ideas that are inside Snowflake and they've extended them. They've integrated them with DevOps and DataOps tooling. So things like version control and get an infrastructure automation and things like Terraform. And they've kind of built that out into more of a DataOps products that you can make use of. So we can see there's a huge impact of these ideas coming into the data world. We think we're really well-placed to take advantage to them. The partner ecosystem is doing a great job with doing that. And it really allows us to kind of change that operating model for data so that we don't have as much emphasis on like hierarchy and change windows and all these kinds of things that are maybe viewed as a lot as fashioned. And we kind of taken the shift from this batch stage of integration into streaming continuous data pipelines in the Cloud. And this kind of gets you away from like a once a week or once a month change window if you're really unlucky to pushing changes in a much more rapid fashion as the needs of the business change. >> I mean those hierarchical organizational structures when we apply those to begin to that it actually creates the silos. So if you're going to be a silo buster, which Ajay I look at you guys in silo busters, you've got to put data in the hands of the domain experts, the business people, they know what data they want, if they have to go through and beg and borrow for a new data sets cetera. And so that's where automation becomes so key. And frankly the technology should be an implementation detail not the dictating factor. I wonder if you could comment on this. >> Yeah, absolutely. I think making the technologies more accessible to the general business users or those specialists business teams that's the key to unlocking. So it is interesting to see is as people move from organization to organization where they've had those experiences operating in a hierarchical sense, I want to break free from that. And we've been exposed to automation. Continuous workflows change is continuous in IT. It's continuous in business. The market's continuously changing. So having that flow across the organization of work, using key components, such as GitHub and similar towards your drive process, Terraform to build in, code into the process and automation and with Io Tahoe, leveraging all the metadata from across those fragmented sources is good to see how those things are coming together. And watching people move from organization to organization say, "Hey okay, I've got a new start. I've got my first hundred days to impress my new manager. What kind of an impact can I bring to this?" And quite often we're seeing that as, let me take away the good learnings from how to do it or how not to do it from my previous role. And this is an opportunity for me to bring in automation. And I'll give you an example, David, recently started working with a client in financial services. Who's an asset manager, managing financial assets. They've grown over the course of the last 10 years through M&A and each of those acquisitions have bought with its technical debt, it's own set of data, that multiple CRM systems now multiple databases, multiple bespoke in-house created applications. And when the new CIO came in and had a look at those he thought well, yes I want to mobilize my data. Yes, I need to modernize my data state because my CEO is now looking at these crypto assets that are on the horizon and the new funds that are emerging that's around digital assets and crypto assets. But in order to get to that where absolutely data underpins that and is the core asset cleaning up that that legacy situation mobilizing the relevant data into the Snowflake Cloud platform is where we're giving time back. You know, that is now taking a few weeks whereas that transitioned to mobilize that data start with that new clean slate to build upon a new business as a digital crypto asset manager as well as the legacy, traditional financial assets, bonds, stocks, and fixed income assets, you name it is where we're starting to see a lot of innovation. >> Tons of innovation. I love the crypto examples, NFTs are exploding and let's face it. Traditional banks are getting disrupted. And so I also love this notion of data RPA. Especially because Ajay I've done a lot of work in the RPA space. And what I would observe is that the early days of RPA, I call it paving the cow path, taking existing processes and applying scripts, letting software robots do its thing. And that was good because it reduced mundane tasks, but really where it's evolved is a much broader automation agenda. People are discovering new ways to completely transform their processes. And I see a similar analogy for the data operating model. So I'm wonder what do you think about that and how a customer really gets started bringing this to their ecosystem, their data life cycles. >> Sure. Yeah. Step one is always the same. It's figuring out for the CIO, the chief data officer, what data do I have? And that's increasingly something that they want to automate, so we can help them there and do that automated data discovery whether that is documents in the file share backup archive in a relational data store in a mainframe really quickly hydrating that and bringing that intelligence the forefront of what do I have, and then it's the next step of, well, okay now I want to continually monitor and curate that intelligence with the platform that I've chosen let's say Snowflake. In order such that I can then build applications on top of that platform to serve my internal external customer needs. and the automation around classifying data, reconciliation across different fragmented data silos building that in those insights into Snowflake. As you say, a little later on where we're talking about data quality, active DQ, allowing us to reconcile data from different sources as well as look at the integrity of that data. So then go on to remediation. I want to harness and leverage techniques around traditional RPA but to get to that stage, I need to fix the data. So remediating publishing the data in Snowflake, allowing analysis to be formed, performed in Snowflake but those are the key steps that we see and just shrinking that timeline into weeks, giving the organization that time back means they're spending more time on their customer and solving their customer's problem which is where we want them to be. >> Well, I think this is the brilliance of Snowflake actually, you know, Duncan I've talked to Benoit Dageville about this and your other co-founders and it's really that focus on simplicity. So I mean, that's you picked a good company to join in my opinion. So I wonder Ajay, if you could talk about some of the industry sectors that again are going to gain the most from data RPA, I mean traditional RPA, if I can use that term, a lot of it was back office, a lot of financial, what are the practical applications where data RPA is going to impact businesses and the outcomes that we can expect. >> Yes, so our drive is really to make that business general user's experience of RPA simpler and using no code to do that where they've also chosen Snowflake to build their Cloud platform. They've got the combination then of using a relatively simple scripting techniques such as SQL without no code approach. And the answer to your question is whichever sector is looking to mobilize their data. It seems like a cop-out but to give you some specific examples, David now in banking, where our customers are looking to modernize their banking systems and enable better customer experience through applications and digital apps, that's where we're seeing a lot of traction in this approach to pay RPA to data. And health care where there's a huge amount of work to do to standardize data sets across providers, payers, patients and it's an ongoing process there. For retail helping to to build that immersive customer experience. So recommending next best actions. Providing an experience that is going to drive loyalty and retention, that's dependent on understanding what that customer's needs, intent are, being able to provide them with the content or the offer at that point in time or all data dependent utilities. There's another one great overlap there with Snowflake where helping utilities telecoms, energy, water providers to build services on that data. And this is where the ecosystem just continues to expand. If we're helping our customers turn their data into services for their ecosystem, that's exciting. Again, they were more so exciting than insurance which it always used to think back to, when insurance used to be very dull and mundane, actually that's where we're seeing a huge amounts of innovation to create new flexible products that are priced to the day to the situation and risk models being adaptive when the data changes on events or circumstances. So across all those sectors that they're all mobilizing their data, they're all moving in some way but for sure form to a multi-Cloud setup with their IT. And I think with Snowflake and with Io Tahoe being able to accelerate that and make that journey simple and less complex is why we've found such a good partner here. >> All right. Thanks for that. And thank you guys both. We got to leave it there really appreciate Duncan you coming on and Ajay best of luck with the fundraising. >> We'll keep you posted. Thanks, David. >> All right. Great. >> Okay. Now let's take a look at a short video. That's going to help you understand how to reduce the steps around your DataOps let's watch. (upbeat music)

>> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, (upbeat music) >> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, I've got the Keynote file there. YAMLs, I've got Dockerfiles, Compose files, all that good stuff. If you want to follow along, great, if not go back and review later, kind of fun. So let me tell you a little bit about myself. I am a former DOD contractor. This is my seventh DockerCon. I've spoken, I had the pleasure to speak at a few of them, one even in Europe. I was even a Docker employee for quite a number of years, providing solutions to the federal government and customers around containers and all things Docker. So I've been doing this a little while. One of the things that I always found interesting was the lack of understanding around labels. So why labels, right? Well, as a former DOD contractor, I had built out a large registry. And the question I constantly got was, where did this image come from? How did you get it? What's in it? Where did it come from? How did it get here? And one of the things we did to kind of alleviate some of those questions was we established a baseline set of labels. Labels really are designed to provide as much metadata around the image as possible. I ask everyone in attendance, when was the last time you pulled an image and had 100% confidence, you knew what was inside it, where it was built, how it was built, when it was built, you probably didn't, right? The last thing we obviously want is a container fire, like our image on the screen. And one kind of interesting way we can kind of prevent that is through the use of labels. We can use labels to address security, address some of the simplicity on how to run these images. So think of it, kind of like self documenting, Think of it also as an audit trail, image provenance, things like that. These are some interesting concepts that we can definitely mandate as we move forward. What is a label, right? Specifically what is the Schema? It's just a key-value. All right? It's any key and pretty much any value. What if we could dump in all kinds of information? What if we could encode things and store it in there? And I've got a fun little demo to show you about that. Let's start off with some of the simple keys, right? Author, date, description, version. Some of the basic information around the image. That would be pretty useful, right? What about specific labels for CI? What about a, where's the version control? Where's the source, right? Whether it's Git, whether it's GitLab, whether it's GitHub, whether it's Gitosis, right? Even SPN, who cares? Where are the source files that built, where's the Docker file that built this image? What's the commit number? That might be interesting in terms of tracking the resulting image to a person or to a commit, hopefully then to a person. How is it built? What if you wanted to play with it and do a git clone of the repo and then build the Docker file on your own? Having a label specifically dedicated on how to build this image might be interesting for development work. Where it was built, and obviously what build number, right? These kind of all, not only talk about continuous integration, CI but also start to talk about security. Specifically what server built it. The version control number, the version number, the commit number, again, how it was built. What's the specific build number? What was that job number in, say, Jenkins or GitLab? What if we could take it a step further? What if we could actually apply policy enforcement in the build pipeline, looking specifically for some of these specific labels? I've got a good example of, in my demo of a policy enforcement. So let's look at some sample labels. Now originally, this idea came out of label-schema.org. And then it was a modified to opencontainers, org.opencontainers.image. There is a link in my GitHub page that links to the full reference. But these are some of the labels that I like to use, just as kind of like a standardization. So obviously, Author's, an email address, so now the image is attributable to a person, that's always kind of good for security and reliability. Where's the source? Where's the version control that has the source, the Docker file and all the assets? How it was built, build number, build server the commit, we talked about, when it was created, a simple description. A fun one I like adding in is the healthZendpoint. Now obviously, the health check directive should be in the Docker file. But if you've got other systems that want to ping your applications, why not declare it and make it queryable? Image version, obviously, that's simple declarative And then a title. And then I've got the two fun ones. Remember, I talked about what if we could encode some fun things? Hypothetically, what if we could encode the Compose file of how to build the stack in the first image itself? And conversely the Kubernetes? Well, actually, you can and I have a demo to show you how to kind of take advantage of that. So how do we create labels? And really creating labels as a function of build time okay? You can't really add labels to an image after the fact. The way you do add labels is either through the Docker file, which I'm a big fan of, because it's declarative. It's in version control. It's kind of irrefutable, especially if you're tracking that commit number in a label. You can extend it from being a static kind of declaration to more a dynamic with build arguments. And I can show you, I'll show you in a little while how you can use a build argument at build time to pass in that variable. And then obviously, if you did it by hand, you could do a docker build--label key equals value. I'm not a big fan of the third one, I love the first one and obviously the second one. Being dynamic we can take advantage of some of the variables coming out of version control. Or I should say, some of the variables coming out of our CI system. And that way, it self documents effectively at build time, which is kind of cool. How do we view labels? Well, there's two major ways to view labels. The first one is obviously a docker pull and docker inspect. You can pull the image locally, you can inspect it, you can obviously, it's going to output as JSON. So you going to use something like JQ to crack it open and look at the individual labels. Another one which I found recently was Skopeo from Red Hat. This allows you to actually query the registry server. So you don't even have to pull the image initially. This can be really useful if you're on a really small development workstation, and you're trying to talk to a Kubernetes cluster and wanting to deploy apps kind of in a very simple manner. Okay? And this was that use case, right? Using Kubernetes, the Kubernetes demo. One of the interesting things about this is that you can base64 encode almost anything, push it in as text into a label and then base64 decode it, and then use it. So in this case, in my demo, I'll show you how we can actually use a kubectl apply piped from the base64 decode from the label itself from skopeo talking to the registry. And what's interesting about this kind of technique is you don't need to store Helm charts. You don't need to learn another language for your declarative automation, right? You don't need all this extra levels of abstraction inherently, if you use it as a label with a kubectl apply, It's just built in. It's kind of like the kiss approach to a certain extent. It does require some encoding when you actually build the image, but to me, it doesn't seem that hard. Okay, let's take a look at a demo. And what I'm going to do for my demo, before we actually get started is here's my repo. Here's a, let me actually go to the actual full repo. So here's the repo, right? And I've got my Jenkins pipeline 'cause I'm using Jenkins for this demo. And in my demo flask, I've got the Docker file. I've got my compose and my Kubernetes YAML. So let's take a look at the Docker file, right? So it's a simple Alpine image. The org statements are the build time arguments that are passed in. Label, so again, I'm using the org.opencontainers.image.blank, for most of them. There's a typo there. Let's see if you can find it, I'll show you it later. My source, build date, build number, commit. Build number and get commit are derived from the Jenkins itself, which is nice. I can just take advantage of existing URLs. I don't have to create anything crazy. And again, I've got my actual Docker build command. Now this is just a label on how to build it. And then here's my simple Python, APK upgrade, remove the package manager, kind of some security stuff, health check getting Python through, okay? Let's take a look at the Jenkins pipeline real quick. So here is my Jenkins pipeline and I have four major stages, four stages, I have built. And here in build, what I do is I actually do the Git clone. And then I do my docker build. From there, I actually tell the Jenkins StackRox plugin. So that's what I'm using for my security scanning. So go ahead and scan, basically, I'm staging it to scan the image. I'm pushing it to Hub, okay? Where I can see the, basically I'm pushing the image up to Hub so such that my StackRox security scanner can go ahead and scan the image. I'm kicking off the scan itself. And then if everything's successful, I'm pushing it to prod. Now what I'm doing is I'm just using the same image with two tags, pre-prod and prod. This is not exactly ideal, in your environment, you probably want to use separate registries and non-prod and a production registry, but for demonstration purposes, I think this is okay. So let's go over to my Jenkins and I've got a deliberate failure. And I'll show you why there's a reason for that. And let's go down. Let's look at my, so I have a StackRox report. Let's look at my report. And it says image required, required image label alert, right? Request that the maintainer, add the required label to the image, so we're missing a label, okay? One of the things we can do is let's flip over, and let's look at Skopeo. Right? I'm going to do this just the easy way. So instead of looking at org.zdocker, opencontainers.image.authors. Okay, see here it says build signature? That was the typo, we didn't actually pass in. So if we go back to our repo, we didn't pass in the the build time argument, we just passed in the word. So let's fix that real quick. That's the Docker file. Let's go ahead and put our dollar sign in their. First day with the fingers you going to love it. And let's go ahead and commit that. Okay? So now that that's committed, we can go back to Jenkins, and we can actually do another build. And there's number 12. And as you can see, I've been playing with this for a little bit today. And while that's running, come on, we can go ahead and look at the Console output. Okay, so there's our image. And again, look at all the build arguments that we're passing into the build statement. So we're passing in the date and the date gets derived on the command line. With the build arguments, there's the base64 encoded of the Compose file. Here's the base64 encoding of the Kubernetes YAML. We do the build. And then let's go down to the bottom layer exists and successful. So here's where we can see no system policy violations profound marking stack regimes security plugin, build step as successful, okay? So we're actually able to do policy enforcement that that image exists, that that label sorry, exists in the image. And again, we can look at the security report and there's no policy violations and no vulnerabilities. So that's pretty good for security, right? We can now enforce and mandate use of certain labels within our images. And let's flip back over to Skopeo, and let's go ahead and look at it. So we're looking at the prod version again. And there's it is in my email address. And that validated that that was valid for that policy. So that's kind of cool. Now, let's take it a step further. What if, let's go ahead and take a look at all of the image, all the labels for a second, let me remove the dash org, make it pretty. Okay? So we have all of our image labels. Again, author's build, commit number, look at the commit number. It was built today build number 12. We saw that right? Delete, build 12. So that's kind of cool dynamic labels. Name, healthz, right? But what we're looking for is we're going to look at the org.zdockerketers label. So let's go look at the label real quick. Okay, well that doesn't really help us because it's encoded but let's base64 dash D, let's decode it. And I need to put the dash r in there 'cause it doesn't like, there we go. So there's my Kubernetes YAML. So why can't we simply kubectl apply dash f? Let's just apply it from standard end. So now we've actually used that label. From the image that we've queried with skopeo, from a remote registry to deploy locally to our Kubernetes cluster. So let's go ahead and look everything's up and running, perfect. So what does that look like, right? So luckily, I'm using traefik for Ingress 'cause I love it. And I've got an object in my Kubernetes YAML called flask.doctor.life. That's my Ingress object for traefik. I can go to flask.docker.life. And I can hit refresh. Obviously, I'm not a very good web designer 'cause the background image in the text. We can go ahead and refresh it a couple times we've got Redis storing a hit counter. We can see that our server name is roundrobing. Okay? That's kind of cool. So let's kind of recap a little bit about my demo environment. So my demo environment, I'm using DigitalOcean, Ubuntu 19.10 Vms. I'm using K3s instead of full Kubernetes either full Rancher, full Open Shift or Docker Enterprise. I think K3s has some really interesting advantages on the development side and it's kind of intended for IoT but it works really well and it deploys super easy. I'm using traefik for Ingress. I love traefik. I may or may not be a traefik ambassador. I'm using Jenkins for CI. And I'm using StackRox for image scanning and policy enforcement. One of the things to think about though, especially in terms of labels is none of this demo stack is required. You can be in any cloud, you can be in CentOs, you can be in any Kubernetes. You can even be in swarm, if you wanted to, or Docker compose. Any Ingress, any CI system, Jenkins, circle, GitLab, it doesn't matter. And pretty much any scanning. One of the things that I think is kind of nice about at least StackRox is that we do a lot more than just image scanning, right? With the policy enforcement things like that. I guess that's kind of a shameless plug. But again, any of this stack is completely replaceable, with any comparative product in that category. So I'd like to, again, point you guys to the andyc.infodc20, that's take you right to the GitHub repo. You can reach out to me at any of the socials @clemenko or andy@stackrox.com. And thank you for attending. I hope you learned something fun about labels. And hopefully you guys can standardize labels in your organization and really kind of take your images and the image provenance to a new level. Thanks for watching. (upbeat music) >> Narrator: Live from Las Vegas It's theCUBE. Covering AWS re:Invent 2019. Brought to you by Amazon Web Services and Intel along with it's ecosystem partners. >> Okay, welcome back everyone theCUBE's live coverage of AWS re:Invent 2019. This is theCUBE's 7th year covering Amazon re:Invent. It's their 8th year of the conference. I want to just shout out to Intel for their sponsorship for these two amazing sets. Without their support we wouldn't be able to bring our mission of great content to you. I'm John Furrier. Stu Miniman. We're here with the chief of AWS, the chief executive officer Andy Jassy. Tech athlete in and of himself three hour Keynotes. Welcome to theCUBE again, great to see you. >> Great to be here, thanks for having me guys. >> Congratulations on a great show a lot of great buzz. >> Andy: Thank you. >> A lot of good stuff. Your Keynote was phenomenal. You get right into it, you giddy up right into it as you say, three hours, thirty announcements. You guys do a lot, but what I liked, the new addition, the last year and this year is the band; house band. They're pretty good. >> Andy: They're good right? >> They hit the queen notes, so that keeps it balanced. So we're going to work on getting a band for theCUBE. >> Awesome. >> So if I have to ask you, what's your walk up song, what would it be? >> There's so many choices, it depends on what kind of mood I'm in. But, uh, maybe Times Like These by the Foo Fighters. >> John: Alright. >> These are unusual times right now. >> Foo Fighters playing at the Amazon Intersect Show. >> Yes they are. >> Good plug Andy. >> Headlining. >> Very clever >> Always getting a good plug in there. >> My very favorite band. Well congratulations on the Intersect you got a lot going on. Intersect is a music festival, I'll get to that in a second But, I think the big news for me is two things, obviously we had a one-on-one exclusive interview and you laid out, essentially what looks like was going to be your Keynote, and it was. Transformation- >> Andy: Thank you for the practice. (Laughter) >> John: I'm glad to practice, use me anytime. >> Yeah. >> And I like to appreciate the comments on Jedi on the record, that was great. But I think the transformation story's a very real one, but the NFL news you guys just announced, to me, was so much fun and relevant. You had the Commissioner of NFL on stage with you talking about a strategic partnership. That is as top down, aggressive goal as you could get to have Rodger Goodell fly to a tech conference to sit with you and then bring his team talk about the deal. >> Well, ya know, we've been partners with the NFL for a while with the Next Gen Stats that they use on all their telecasts and one of the things I really like about Roger is that he's very curious and very interested in technology and the first couple times I spoke with him he asked me so many questions about ways the NFL might be able to use the Cloud and digital transformation to transform their various experiences and he's always said if you have a creative idea or something you think that could change the world for us, just call me he said or text me or email me and I'll call you back within 24 hours. And so, we've spent the better part of the last year talking about a lot of really interesting, strategic ways that they can evolve their experience both for fans, as well as their players and the Player Health and Safety Initiative, it's so important in sports and particularly important with the NFL given the nature of the sport and they've always had a focus on it, but what you can do with computer vision and machine learning algorithms and then building a digital athlete which is really like a digital twin of each athlete so you understand, what does it look like when they're healthy and compare that when it looks like they may not be healthy and be able to simulate all kinds of different combinations of player hits and angles and different plays so that you could try to predict injuries and predict the right equipment you need before there's a problem can be really transformational so we're super excited about it. >> Did you guys come up with the idea or was it a collaboration between them? >> It was really a collaboration. I mean they, look, they are very focused on players safety and health and it's a big deal for their- you know, they have two main constituents the players and fans and they care deeply about the players and it's a-it's a hard problem in a sport like Football, I mean, you watch it. >> Yeah, and I got to say it does point out the use cases of what you guys are promoting heavily at the show here of the SageMaker Studio, which was a big part of your Keynote, where they have all this data. >> Andy: Right. >> And they're data hoarders, they hoard data but the manual process of going through the data was a killer problem. This is consistent with a lot of the enterprises that are out there, they have more data than they even know. So this seems to be a big part of the strategy. How do you get the customers to actually wake up to the fact that they got all this data and how do you tie that together? >> I think in almost every company they know they have a lot of data. And there are always pockets of people who want to do something with it. But, when you're going to make these really big leaps forward; these transformations, the things like Volkswagen is doing where they're reinventing their factories and their manufacturing process or the NFL where they're going to radically transform how they do players uh, health and safety. It starts top down and if the senior leader isn't convicted about wanting to take that leap forward and trying something different and organizing the data differently and organizing the team differently and using machine learning and getting help from us and building algorithms and building some muscle inside the company it just doesn't happen because it's not in the normal machinery of what most companies do. And so it always, almost always, starts top down. Sometimes it can be the Commissioner or CEO sometimes it can be the CIO but it has to be senior level conviction or it doesn't get off the ground. >> And the business model impact has to be real. For NFL, they know concussions, hurting their youth pipe-lining, this is a huge issue for them. This is their business model. >> They lose even more players to lower extremity injuries. And so just the notion of trying to be able to predict injuries and, you know, the impact it can have on rules and the impact it can have on the equipment they use, it's a huge game changer when they look at the next 10 to 20 years. >> Alright, love geeking out on the NFL but Andy, you know- >> No more NFL talk? >> Off camera how about we talk? >> Nobody talks about the Giants being 2 and 10. >> Stu: We're both Patriots fans here. >> People bring up the undefeated season. >> So Andy- >> Everybody's a Patriot's fan now. (Laughter) >> It's fascinating to watch uh, you and your three hour uh, Keynote, uh Werner in his you know, architectural discussion, really showed how AWS is really extending its reach, you know, it's not just a place. For a few years people have been talking about you know, Cloud is an operational model its not a destination or a location but, I felt it really was laid out is you talked about Breadth and Depth and Werner really talked about you know, Architectural differentiation. People talk about Cloud, but there are very-there are a lot of differences between the vision for where things are going. Help us understand why, I mean, Amazon's vision is still a bit different from what other people talk about where this whole Cloud expansion, journey, put ever what tag or label you want on it but you know, the control plane and the technology that you're building and where you see that going. >> Well I think that, we've talked about this a couple times we have two macro types of customers. We have those that really want to get at the low level building blocks and stitch them together creatively however they see fit to create whatever's in their-in their heads. And then we have the second segment of customers that say look, I'm willing to give up some of that flexibility in exchange for getting 80% of the way there much faster. In an abstraction that's different from those low level building blocks. And both segments of builders we want to serve and serve well and so we've built very significant offerings in both areas. I think when you look at microservices um, you know, some of it has to do with the fact that we have this very strongly held belief born out of several years of Amazon where you know, the first 7 or 8 years of Amazon's consumer business we basically jumbled together all of the parts of our technology in moving really quickly and when we wanted to move quickly where you had to impact multiple internal development teams it was so long because it was this big ball, this big monolithic piece. And we got religion about that in trying to move faster in the consumer business and having to tease those pieces apart. And it really was a lot of impetus behind conceiving AWS where it was these low level, very flexible building blocks that6 don't try and make all the decisions for customers they get to make them themselves. And some of the microservices that you saw Werner talking about just, you know, for instance, what we-what we did with Nitro or even what we did with Firecracker those are very much about us relentlessly working to continue to uh, tease apart the different components. And even things that look like low level building blocks over time, you build more and more features and all of the sudden you realize they have a lot of things that are combined together that you wished weren't that slow you down and so, Nitro was a completely re imagining of our Hypervisor and Virtualization layer to allow us, both to let customers have better performance but also to let us move faster and have a better security story for our customers. >> I got to ask you the question around transformation because I think that all points, all the data points, you got all the references, Goldman Sachs on stage at the Keynote, Cerner, I mean healthcare just is an amazing example because I mean, that's demonstrating real value there there's no excuse. I talked to someone who wouldn't be named last night, in and around the area said, the CIA has a cost bar like this a cost-a budget like this but the demand for mission based apps is going up exponentially, so there's need for the Cloud. And so, you see more and more of that. What is your top down, aggressive goals to fill that solution base because you're also a very transformational thinker; what is your-what is your aggressive top down goals for your organization because you're serving a market with trillions of dollars of spend that's shifting, that's on the table. >> Yeah. >> A lot of competition now sees it too, they're going to go after it. But at the end of the day you have customers that have a demand for things, apps. >> Andy: Yeah. >> And not a lot of budget increase at the same time. This is a huge dynamic. >> Yeah. >> John: What's your goals? >> You know I think that at a high level our top down aggressive goals are that we want every single customer who uses our platform to have an outstanding customer experience. And we want that outstanding customer experience in part is that their operational performance and their security are outstanding, but also that it allows them to build, uh, build projects and initiatives that change their customer experience and allow them to be a sustainable successful business over a long period of time. And then, we also really want to be the technology infrastructure platform under all the applications that people build. And we're realistic, we know that you know, the market segments we address with infrastructure, software, hardware, and data center services globally are trillions of dollars in the long term and it won't only be us, but we have that goal of wanting to serve every application and that requires not just the security operational premise but also a lot of functionality and a lot of capability. We have by far the most amount of capability out there and yet I would tell you, we have 3 to 5 years of items on our roadmap that customers want us to add. And that's just what we know today. >> And Andy, underneath the covers you've been going through some transformation. When we talked a couple of years ago, about how serverless is impacting things I've heard that that's actually, in many ways, glue behind the two pizza teams to work between organizations. Talk about how the internal transformations are happening. How that impacts your discussions with customers that are going through that transformation. >> Well, I mean, there's a lot of- a lot of the technology we build comes from things that we're doing ourselves you know? And that we're learning ourselves. It's kind of how we started thinking about microservices, serverless too, we saw the need, you know, we would have we would build all these functions that when some kind of object came into an object store we would spin up, compute, all those tasks would take like, 3 or 4 hundred milliseconds then we'd spin it back down and yet, we'd have to keep a cluster up in multiple availability zones because we needed that fault tolerance and it was- we just said this is wasteful and, that's part of how we came up with Lambda and you know, when we were thinking about Lambda people understandably said, well if we build Lambda and we build this serverless adventure in computing a lot of people were keeping clusters of instances aren't going to use them anymore it's going to lead to less absolute revenue for us. But we, we have learned this lesson over the last 20 years at Amazon which is, if it's something that's good for customers you're much better off cannibalizing yourself and doing the right thing for customers and being part of shaping something. And I think if you look at the history of technology you always build things and people say well, that's going to cannibalize this and people are going to spend less money, what really ends up happening is they spend less money per unit of compute but it allows them to do so much more that they ultimately, long term, end up being more significant customers. >> I mean, you are like beating the drum all the time. Customers, what they say, we encompass the roadmap, I got that you guys have that playbook down, that's been really successful for you. >> Andy: Yeah. >> Two years ago you told me machine learning was really important to you because your customers told you. What's the next traunch of importance for customers? What's on top of mind now, as you, look at- >> Andy: Yeah. >> This re:Invent kind of coming to a close, Replay's tonight, you had conversations, you're a tech athlete, you're running around, doing speeches, talking to customers. What's that next hill from if it's machine learning today- >> There's so much I mean, (weird background noise) >> It's not a soup question (Laughter) And I think we're still in the very early days of machine learning it's not like most companies have mastered it yet even though they're using it much more then they did in the past. But, you know, I think machine learning for sure I think the Edge for sure, I think that um, we're optimistic about Quantum Computing even though I think it'll be a few years before it's really broadly useful. We're very um, enthusiastic about robotics. I think the amount of functions that are going to be done by these- >> Yeah. >> robotic applications are much more expansive than people realize. It doesn't mean humans won't have jobs, they're just going to work on things that are more value added. We're believers in augmented virtual reality, we're big believers in what's going to happen with Voice. And I'm also uh, I think sometimes people get bored you know, I think you're even bored with machine learning already >> Not yet. >> People get bored with the things you've heard about but, I think just what we've done with the Chips you know, in terms of giving people 40% better price performance in the latest generation of X86 processors. It's pretty unbelievable in the difference in what people are going to be able to do. Or just look at big data I mean, big data, we haven't gotten through big data where people have totally solved it. The amount of data that companies want to store, process, analyze, is exponentially larger than it was a few years ago and it will, I think, exponentially increase again in the next few years. You need different tools and services. >> Well I think we're not bored with machine learning we're excited to get started because we have all this data from the video and you guys got SageMaker. >> Andy: Yeah. >> We call it the stairway to machine learning heaven. >> Andy: Yeah. >> You start with the data, move up, knock- >> You guys are very sophisticated with what you do with technology and machine learning and there's so much I mean, we're just kind of, again, in such early innings. And I think that, it was so- before SageMaker, it was so hard for everyday developers and data scientists to build models but the combination of SageMaker and what's happened with thousands of companies standardizing on it the last two years, plus now SageMaker studio, giant leap forward. >> Well, we hope to use the data to transform our experience with our audience. And we're on Amazon Cloud so we really appreciate that. >> Andy: Yeah. >> And appreciate your support- >> Andy: Yeah, of course. >> John: With Amazon and get that machine learning going a little faster for us, that would be better. >> If you have requests I'm interested, yeah. >> So Andy, you talked about that you've got the customers that are builders and the customers that need simplification. Traditionally when you get into the, you know, the heart of the majority of adoption of something you really need to simplify that environment. But when I think about the successful enterprise of the future, they need to be builders. how'l I normally would've said enterprise want to pay for solutions because they don't have the skill set but, if they're going to succeed in this new economy they need to go through that transformation >> Andy: Yeah. >> That you talk to, so, I mean, are we in just a total new era when we look back will this be different than some of these previous waves? >> It's a really good question Stu, and I don't think there's a simple answer to it. I think that a lot of enterprises in some ways, I think wish that they could just skip the low level building blocks and only operate at that higher level abstraction. That's why people were so excited by things like, SageMaker, or CodeGuru, or Kendra, or Contact Lens, these are all services that allow them to just send us data and then run it on our models and get back the answers. But I think one of the big trends that we see with enterprises is that they are taking more and more of their development in house and they are wanting to operate more and more like startups. I think that they admire what companies like AirBnB and Pintrest and Slack and Robinhood and a whole bunch of those companies, Stripe, have done and so when, you know, I think you go through these phases and eras where there are waves of success at different companies and then others want to follow that success and replicate it. And so, we see more and more enterprises saying we need to take back a lot of that development in house. And as they do that, and as they add more developers those developers in most cases like to deal with the building blocks. And they have a lot of ideas on how they can creatively stich them together. >> Yeah, on that point, I want to just quickly ask you on Amazon versus other Clouds because you made a comment to me in our interview about how hard it is to provide a service to other people. And it's hard to have a service that you're using yourself and turn that around and the most quoted line of my story was, the compression algorithm- there's no compression algorithm for experience. Which to me, is the diseconomies of scale for taking shortcuts. >> Andy: Yeah. And so I think this is a really interesting point, just add some color commentary because I think this is a fundamental difference between AWS and others because you guys have a trajectory over the years of serving, at scale, customers wherever they are, whatever they want to do, now you got microservices. >> Yeah. >> John: It's even more complex. That's hard. >> Yeah. >> John: Talk about that. >> I think there are a few elements to that notion of there's no compression algorithm for experience and I think the first thing to know about AWS which is different is, we just come from a different heritage and a different background. We ran a business for a long time that was our sole business that was a consumer retail business that was very low margin. And so, we had to operate at very large scale given how many people were using us but also, we had to run infrastructure services deep in the stack, compute storage and database, and reliable scalable data centers at very low cost and margins. And so, when you look at our business it actually, today, I mean its, its a higher margin business in our retail business, its a lower margin business in software companies but at real scale, it's a high volume, relatively low margin business. And the way that you have to operate to be successful with those businesses and the things you have to think about and that DNA come from the type of operators we have to be in our consumer retail business. And there's nobody else in our space that does that. So, you know, the way that we think about costs, the way we think about innovation in the data center, um, and I also think the way that we operate services and how long we've been operating services as a company its a very different mindset than operating package software. Then you look at when uh, you think about some of the uh, issues in very large scale Cloud, you can't learn some of those lessons until you get to different elbows of the curve and scale. And so what I was telling you is, its really different to run your own platform for your own users where you get to tell them exactly how its going to be done. But that's not the way the real world works. I mean, we have millions of external customers who use us from every imaginable country and location whenever they want, without any warning, for lots of different use cases, and they have lots of design patterns and we don't get to tell them what to do. And so operating a Cloud like that, at a scale that's several times larger than the next few providers combined is a very different endeavor and a very different operating rigor. >> Well you got to keep raising the bar you guys do a great job, really impressed again. Another tsunami of announcements. In fact, you had to spill the beans earlier with Quantum the day before the event. Tight schedule. I got to ask you about the musical festival because, I think this is a very cool innovation. It's the inaugural Intersect conference. >> Yes. >> John: Which is not part of Replay, >> Yes. >> John: Which is the concert tonight. Its a whole new thing, big music act, you're a big music buff, your daughter's an artist. Why did you do this? What's the purpose? What's your goal? >> Yeah, it's an experiment. I think that what's happened is that re:Invent has gotten so big, we have 65 thousand people here, that to do the party, which we do every year, its like a 35-40 thousand person concert now. Which means you have to have a location that has multiple stages and, you know, we thought about it last year and when we were watching it and we said, we're kind of throwing, like, a 4 hour music festival right now. There's multiple stages, and its quite expensive to set up that set for a party and we said well, maybe we don't have to spend all that money for 4 hours and then rip it apart because actually the rent to keep those locations for another two days is much smaller than the cost of actually building multiple stages and so we thought we would try it this year. We're very passionate about music as a business and I think we-I think our customers feel like we've thrown a pretty good music party the last few years and we thought we would try it at a larger scale as an experiment. And if you look at the economics- >> At the headliners real quick. >> The Foo Fighters are headlining on Saturday night, Anderson Paak and the Free Nationals, Brandi Carlile, Shawn Mullins, um, Willy Porter, its a good set. Friday night its Beck and Kacey Musgraves so it's a really great set of um, about thirty artists and we're hopeful that if we can build a great experience that people will want to attend that we can do it at scale and it might be something that both pays for itself and maybe, helps pay for re:Invent too overtime and you know, I think that we're also thinking about it as not just a music concert and festival the reason we named it Intersect is that we want an intersection of music genres and people and ethnicities and age groups and art and technology all there together and this will be the first year we try it, its an experiment and we're really excited about it. >> Well I'm gone, congratulations on all your success and I want to thank you we've been 7 years here at re:Invent we've been documenting the history. You got two sets now, one set upstairs. So appreciate you. >> theCUBE is part of re:Invent, you know, you guys really are apart of the event and we really appreciate your coming here and I know people appreciate the content you create as well. >> And we just launched CUBE365 on Amazon Marketplace built on AWS so thanks for letting us- >> Very cool >> John: Build on the platform. appreciate it. >> Thanks for having me guys, I appreciate it. >> Andy Jassy the CEO of AWS here inside theCUBE, it's our 7th year covering and documenting the thunderous innovation that Amazon's doing they're really doing amazing work building out the new technologies here in the Cloud computing world. I'm John Furrier, Stu Miniman, be right back with more after this short break. (Outro music)

>> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, I've got the Keynote file there. YAMLs, I've got Dockerfiles, Compose files, all that good stuff. If you want to follow along, great, if not go back and review later, kind of fun. So let me tell you a little bit about myself. I am a former DOD contractor. This is my seventh DockerCon. I've spoken, I had the pleasure to speak at a few of them, one even in Europe. I was even a Docker employee for quite a number of years, providing solutions to the federal government and customers around containers and all things Docker. So I've been doing this a little while. One of the things that I always found interesting was the lack of understanding around labels. So why labels, right? Well, as a former DOD contractor, I had built out a large registry. And the question I constantly got was, where did this image come from? How did you get it? What's in it? Where did it come from? How did it get here? And one of the things we did to kind of alleviate some of those questions was we established a baseline set of labels. Labels really are designed to provide as much metadata around the image as possible. I ask everyone in attendance, when was the last time you pulled an image and had 100% confidence, you knew what was inside it, where it was built, how it was built, when it was built, you probably didn't, right? The last thing we obviously want is a container fire, like our image on the screen. And one kind of interesting way we can kind of prevent that is through the use of labels. We can use labels to address security, address some of the simplicity on how to run these images. So think of it, kind of like self documenting, Think of it also as an audit trail, image provenance, things like that. These are some interesting concepts that we can definitely mandate as we move forward. What is a label, right? Specifically what is the Schema? It's just a key-value. All right? It's any key and pretty much any value. What if we could dump in all kinds of information? What if we could encode things and store it in there? And I've got a fun little demo to show you about that. Let's start off with some of the simple keys, right? Author, date, description, version. Some of the basic information around the image. That would be pretty useful, right? What about specific labels for CI? What about a, where's the version control? Where's the source, right? Whether it's Git, whether it's GitLab, whether it's GitHub, whether it's Gitosis, right? Even SPN, who cares? Where are the source files that built, where's the Docker file that built this image? What's the commit number? That might be interesting in terms of tracking the resulting image to a person or to a commit, hopefully then to a person. How is it built? What if you wanted to play with it and do a git clone of the repo and then build the Docker file on your own? Having a label specifically dedicated on how to build this image might be interesting for development work. Where it was built, and obviously what build number, right? These kind of all, not only talk about continuous integration, CI but also start to talk about security. Specifically what server built it. The version control number, the version number, the commit number, again, how it was built. What's the specific build number? What was that job number in, say, Jenkins or GitLab? What if we could take it a step further? What if we could actually apply policy enforcement in the build pipeline, looking specifically for some of these specific labels? I've got a good example of, in my demo of a policy enforcement. So let's look at some sample labels. Now originally, this idea came out of label-schema.org. And then it was a modified to opencontainers, org.opencontainers.image. There is a link in my GitHub page that links to the full reference. But these are some of the labels that I like to use, just as kind of like a standardization. So obviously, Author's, an email address, so now the image is attributable to a person, that's always kind of good for security and reliability. Where's the source? Where's the version control that has the source, the Docker file and all the assets? How it was built, build number, build server the commit, we talked about, when it was created, a simple description. A fun one I like adding in is the healthZendpoint. Now obviously, the health check directive should be in the Docker file. But if you've got other systems that want to ping your applications, why not declare it and make it queryable? Image version, obviously, that's simple declarative And then a title. And then I've got the two fun ones. Remember, I talked about what if we could encode some fun things? Hypothetically, what if we could encode the Compose file of how to build the stack in the first image itself? And conversely the Kubernetes? Well, actually, you can and I have a demo to show you how to kind of take advantage of that. So how do we create labels? And really creating labels as a function of build time okay? You can't really add labels to an image after the fact. The way you do add labels is either through the Docker file, which I'm a big fan of, because it's declarative. It's in version control. It's kind of irrefutable, especially if you're tracking that commit number in a label. You can extend it from being a static kind of declaration to more a dynamic with build arguments. And I can show you, I'll show you in a little while how you can use a build argument at build time to pass in that variable. And then obviously, if you did it by hand, you could do a docker build--label key equals value. I'm not a big fan of the third one, I love the first one and obviously the second one. Being dynamic we can take advantage of some of the variables coming out of version control. Or I should say, some of the variables coming out of our CI system. And that way, it self documents effectively at build time, which is kind of cool. How do we view labels? Well, there's two major ways to view labels. The first one is obviously a docker pull and docker inspect. You can pull the image locally, you can inspect it, you can obviously, it's going to output as JSON. So you going to use something like JQ to crack it open and look at the individual labels. Another one which I found recently was Skopeo from Red Hat. This allows you to actually query the registry server. So you don't even have to pull the image initially. This can be really useful if you're on a really small development workstation, and you're trying to talk to a Kubernetes cluster and wanting to deploy apps kind of in a very simple manner. Okay? And this was that use case, right? Using Kubernetes, the Kubernetes demo. One of the interesting things about this is that you can base64 encode almost anything, push it in as text into a label and then base64 decode it, and then use it. So in this case, in my demo, I'll show you how we can actually use a kubectl apply piped from the base64 decode from the label itself from skopeo talking to the registry. And what's interesting about this kind of technique is you don't need to store Helm charts. You don't need to learn another language for your declarative automation, right? You don't need all this extra levels of abstraction inherently, if you use it as a label with a kubectl apply, It's just built in. It's kind of like the kiss approach to a certain extent. It does require some encoding when you actually build the image, but to me, it doesn't seem that hard. Okay, let's take a look at a demo. And what I'm going to do for my demo, before we actually get started is here's my repo. Here's a, let me actually go to the actual full repo. So here's the repo, right? And I've got my Jenkins pipeline 'cause I'm using Jenkins for this demo. And in my demo flask, I've got the Docker file. I've got my compose and my Kubernetes YAML. So let's take a look at the Docker file, right? So it's a simple Alpine image. The org statements are the build time arguments that are passed in. Label, so again, I'm using the org.opencontainers.image.blank, for most of them. There's a typo there. Let's see if you can find it, I'll show you it later. My source, build date, build number, commit. Build number and get commit are derived from the Jenkins itself, which is nice. I can just take advantage of existing URLs. I don't have to create anything crazy. And again, I've got my actual Docker build command. Now this is just a label on how to build it. And then here's my simple Python, APK upgrade, remove the package manager, kind of some security stuff, health check getting Python through, okay? Let's take a look at the Jenkins pipeline real quick. So here is my Jenkins pipeline and I have four major stages, four stages, I have built. And here in build, what I do is I actually do the Git clone. And then I do my docker build. From there, I actually tell the Jenkins StackRox plugin. So that's what I'm using for my security scanning. So go ahead and scan, basically, I'm staging it to scan the image. I'm pushing it to Hub, okay? Where I can see the, basically I'm pushing the image up to Hub so such that my StackRox security scanner can go ahead and scan the image. I'm kicking off the scan itself. And then if everything's successful, I'm pushing it to prod. Now what I'm doing is I'm just using the same image with two tags, pre-prod and prod. This is not exactly ideal, in your environment, you probably want to use separate registries and non-prod and a production registry, but for demonstration purposes, I think this is okay. So let's go over to my Jenkins and I've got a deliberate failure. And I'll show you why there's a reason for that. And let's go down. Let's look at my, so I have a StackRox report. Let's look at my report. And it says image required, required image label alert, right? Request that the maintainer, add the required label to the image, so we're missing a label, okay? One of the things we can do is let's flip over, and let's look at Skopeo. Right? I'm going to do this just the easy way. So instead of looking at org.zdocker, opencontainers.image.authors. Okay, see here it says build signature? That was the typo, we didn't actually pass in. So if we go back to our repo, we didn't pass in the the build time argument, we just passed in the word. So let's fix that real quick. That's the Docker file. Let's go ahead and put our dollar sign in their. First day with the fingers you going to love it. And let's go ahead and commit that. Okay? So now that that's committed, we can go back to Jenkins, and we can actually do another build. And there's number 12. And as you can see, I've been playing with this for a little bit today. And while that's running, come on, we can go ahead and look at the Console output. Okay, so there's our image. And again, look at all the build arguments that we're passing into the build statement. So we're passing in the date and the date gets derived on the command line. With the build arguments, there's the base64 encoded of the Compose file. Here's the base64 encoding of the Kubernetes YAML. We do the build. And then let's go down to the bottom layer exists and successful. So here's where we can see no system policy violations profound marking stack regimes security plugin, build step as successful, okay? So we're actually able to do policy enforcement that that image exists, that that label sorry, exists in the image. And again, we can look at the security report and there's no policy violations and no vulnerabilities. So that's pretty good for security, right? We can now enforce and mandate use of certain labels within our images. And let's flip back over to Skopeo, and let's go ahead and look at it. So we're looking at the prod version again. And there's it is in my email address. And that validated that that was valid for that policy. So that's kind of cool. Now, let's take it a step further. What if, let's go ahead and take a look at all of the image, all the labels for a second, let me remove the dash org, make it pretty. Okay? So we have all of our image labels. Again, author's build, commit number, look at the commit number. It was built today build number 12. We saw that right? Delete, build 12. So that's kind of cool dynamic labels. Name, healthz, right? But what we're looking for is we're going to look at the org.zdockerketers label. So let's go look at the label real quick. Okay, well that doesn't really help us because it's encoded but let's base64 dash D, let's decode it. And I need to put the dash r in there 'cause it doesn't like, there we go. So there's my Kubernetes YAML. So why can't we simply kubectl apply dash f? Let's just apply it from standard end. So now we've actually used that label. From the image that we've queried with skopeo, from a remote registry to deploy locally to our Kubernetes cluster. So let's go ahead and look everything's up and running, perfect. So what does that look like, right? So luckily, I'm using traefik for Ingress 'cause I love it. And I've got an object in my Kubernetes YAML called flask.doctor.life. That's my Ingress object for traefik. I can go to flask.docker.life. And I can hit refresh. Obviously, I'm not a very good web designer 'cause the background image in the text. We can go ahead and refresh it a couple times we've got Redis storing a hit counter. We can see that our server name is roundrobing. Okay? That's kind of cool. So let's kind of recap a little bit about my demo environment. So my demo environment, I'm using DigitalOcean, Ubuntu 19.10 Vms. I'm using K3s instead of full Kubernetes either full Rancher, full Open Shift or Docker Enterprise. I think K3s has some really interesting advantages on the development side and it's kind of intended for IoT but it works really well and it deploys super easy. I'm using traefik for Ingress. I love traefik. I may or may not be a traefik ambassador. I'm using Jenkins for CI. And I'm using StackRox for image scanning and policy enforcement. One of the things to think about though, especially in terms of labels is none of this demo stack is required. You can be in any cloud, you can be in CentOs, you can be in any Kubernetes. You can even be in swarm, if you wanted to, or Docker compose. Any Ingress, any CI system, Jenkins, circle, GitLab, it doesn't matter. And pretty much any scanning. One of the things that I think is kind of nice about at least StackRox is that we do a lot more than just image scanning, right? With the policy enforcement things like that. I guess that's kind of a shameless plug. But again, any of this stack is completely replaceable, with any comparative product in that category. So I'd like to, again, point you guys to the andyc.infodc20, that's take you right to the GitHub repo. You can reach out to me at any of the socials @clemenko or andy@stackrox.com. And thank you for attending. I hope you learned something fun about labels. And hopefully you guys can standardize labels in your organization and really kind of take your images and the image provenance to a new level. Thanks for watching. (upbeat music)

(bright upbeat music) >> Reporter: From theCUBE Studios in Palo Alto in Boston. Connecting with thought leaders all around the world. This is theCUBE conversation. >> Hey, welcome back everybody. Jeff Frick here with theCUBE. We're coming to you today from our Palo Alto studios, talking about a really important topic. And that's data. And as we hear over and over and over, right data is the oil. Data is the new currency. Data is driving business decisions. Data drives AI. Data drives machine learning. Data is increasingly important. And we're still kind of waiting for it, to show up on balance sheets. Which is kind of implied in a lot of the big iterations, that we see in companies that are built on data. But one of the important things about data, is taking care of it. And we're excited to have our next guest here to talk about, some of the things you need to think about, and best practices in securing your data. Backing up your data, protecting your data. We're joined today by Tim Burlowski. He is the senior director, Product Management from Veritas. Joining us from remote. I believe you're in Minnesota. Tim, great to see you. >> Yep, thanks for having me. >> Absolutely, so let's just jump into it. So all we hear about is data these days. It's such an important topic, that is growing exponentially. And it's structured and it's unstructured. And it's so core to the business. And are you making database decisions? And are you getting enough data to drive your AI? And your machine learning algorithms? I mean, data is only exploding. You've been in this business for a long, a long, long time. I wonder if you can share your perspective, when you hear these things. more data is going to be created in the next 15 minutes. And wasn't the entire history of men before us? I'm making that up, but it's been quite an explosion. >> I know yeah, I know where you're coming from. And frankly, I don't even put that, in my presentation anymore. Because it's a lot like saying gravity exists, And things that you drop out, of a window will fall to the ground. Everyone's heard it. Everyone's aware of it. The numbers are just so staggering. You don't even know what to do with it. Like how many iPhones could you stack to the moon and back and then to Saturn? Doesn't make sense. But the truth is, we are seeing an explosion. Everyone knows it. We have to manage it better. Now for us, a lot of what we do, is in this data protection space. Where we want to make sure, that data is protected and always available. All of the data that's been created, and the growth in mission-critical applications. It's no longer seven to 20 mission-critical applications. It's hundreds and hundreds of mission-critical applications. Means you have to be ready, with a recent recovery if necessary. And you need to provide that data back to the consumer, as quickly as you possibly can. Because you've got people waiting on it. We've all got our apps on our phone, where we're looking at our bank account 24 seven. We don't wait until a teller appears at nine a.m anymore. It's not the world we live in. >> Right, I'm just curious if you've got some tailwinds, in terms of you're kind of, you've been in this market for a very long time. In terms of people finally realizing that their data, is really more of an asset and a liability. In the investments, to gather it, protect it, analyze it, have it ready for refresh it, If there's some problem. It's a positive investment towards, kind of revenue and strategic importance to the company, as opposed to kind of a back-office IT function, that we're kind of taking care of business because we have to. >> Boy that one really varies a lot by company. I see companies taking shortcuts and outsourcing, and then suddenly you'll see them in the news. And they discover that they had a major outage for a couple of days. And suddenly practices change very, very quickly. The relative comprehensive, sturdy and reliable infrastructure that people run today, sometimes lulls people into false security. And then you see a major airlines with a multi-day outage. And you go hmm, I think we missed a few steps in the process. So it sometimes takes those rude awakenings. But the companies who are really taking it seriously, and starting to practice pruning their data, examining their data for PII. So they meet various compliance regimes, and other in various states and countries. And starting to think about their backup stream, really being, how do we get a fast recovery? Instead of how do I make a copy, which I will never use again? Are really starting to drive a more efficient IT operation, when it comes to data protection. >> No, it's an interesting take, in reference to having some issue. Because we do a lot of stuff around security. Which is related to but not equal to this conversation. And one of the topics in security is that, most people have already been breached. It's just a function of how fast can you find out, and how fast can you minimize the damage? And how fast can you move on? Why are they breaching? They're breaching to get the data. So I would imagine, with this constant reading in the newspaper, of who was breached here there and everywhere, pretty much every day. That's got to be a huge driver, in terms of people kind of upping their game, and the sophistication, of the way they really think about data protection. >> It is and I'll tell you, I've had the misfortune, I would say. Of talking to customers who are in the middle of recovering, from a major ransomware malware attack. And it's a very difficult proposition. And what customers often discover is, they haven't practiced enough, they don't have enough of a DR plan present. We are certainly rising the occasion. Our products are sort of the last thing, that often stands between the customer, losing their data completely. And so we're looking at a number of technology innovations, that will enable them to store their data on immutable devices. And for the backup infrastructure, to be completely aware of that. Which we'll be announcing later this summer. Which we're very excited about. Of course, from our perspective of our appliance portfolio, we've always provided a couple of extra layers of security against intrusion detection, and intrusion prevention right out of the box. Because we know the backup infrastructure becomes this collection of the very most important data in your infrastructure. Because that's the thing you back up. And you want to restore. If there's ever any sort of manmade disaster or otherwise. >> Right. So I want to shift gears a little bit, and talk about kind of the evolution of the infrastructure kind of scene. If you will. With the rise of public clouds, with Amazon and Google and Microsoft, is sure. And then obviously, you tried into a data center. Lot of talk about HP discover, this week kind of going from edge to cloud and data center in the middle. So the environment in which these applications live, and these applications run, and where the data is, relative to those applications. Is evolved dramatically over the last, you probably have a much better time perspective than I do. Five years, 10 years. But it continues to accelerate, in this kind of Application-Centric World versus, kind of an Infrastructure Centric World. Just curious to get your take on, The kind of the challenges that presents to your company, and what you guys are trying to do to accomplish. And how do you see that continuing to evolve and get, not simpler but more complex over time? >> That is a very astute acknowledgement of what's going on in the industry. And I often call it the industry's getting weirder. I would have thought at some point, we'd sort of have Linux and Windows, and a couple of database vendors. And the truth is that database vendors exploded. And it's not just Linux anymore. It's containers. And it might be a container based on CentOS. And it might be container running in the cloud. Or it might be a simple function, like a lambda function running on nothing in AWS. And so this whole world has gotten a lot stranger. From my perspective, I think the biggest change for Veritas, has been a renewed focus on API's that we make public to customers, in ways that we can glue and stitch these systems together. Now, of course, it doesn't replace the deep integration, we do with companies like VMware, with Docker, as well as the the container ecosystem around. OpenShift and some of those technologies. But from our perspective, we've had to be a little bit more prolific, in what we support. And the truth is, it's all files, it's all objects, it's all things we've done before. But they just keep bubbling up in new and different ways. >> Right, but what's interesting though, is you touch on all kinds of stuff there with Kubernetes and clouds and in containers. Is a lot of it's kind of ethereal, right? The whole idea of of a cloud-based infrastructure, is that you can bring it up and bring it down as you need it. You can adjust it as you go. And literally turn it off when you don't need it. And bring it back up. And then you add to that serverless. And this kind of increasing atomization, of all the different parts of compute. Kind of an interesting thing for you guys, to try to back up as these things are created and destructed. We hear these crazy stories of, automating Kubernetes to spin up tons of these things at a time and then bring them back back down. And then I'm curious too. Within that is also the open source. kind of challenge in continuing to have evolution in open source technologies, API's, et cetera. So it is getting weirder and weirder, on a number of fronts as you guys continue to evolve with the market. >> Absolutely, and all I'll tell you, you have to think about all technologies as being on a bridge. As I remind people, we have washing machines. They work really well but washboards still exist, even though it's a technology from 18th century, or beforehand. Now, they may be used as still do exist. Now, my point in this is, people need a bridge. Most enterprises run on an amazing amount of technology, they've developed as a stack over the last 10 to 15 years. And they can't immediately rewrite that, and put it all in a cloud container. So we're actually seeing a lot of use of containers, and Kubernetes with fairly heavy application stacks. When you think about something as heavy as, all have Oracle inside of a container. You can understand that, that's a big lift for container. And it's not ephemeral at all. Then it reaches out to storage, that has that persistence value. And that's where we come in. 'Cause we want to make sure that persistent storage, is always protected. And easily available to the customer for any recovery needs. >> Is great, so I want to shift gears a little bit Tim, to talk about regulations and compliance. 'Cause, regulatory requirements drive a lot of behavior and activity, and really oftentimes, are ahead of maybe the business prerogative to do things like provide backups, provide quick and dirty, quick and easy access. Because you needed it for, a public Freedom of Information Act request. Or you need it for some type of court type of activity. So I wonder if you can kind of talk about, how the regulatory environment, continues to evolve over time. And how does that impact, what you guys are doing in the marketplace? >> Great question. The biggest place is It's affected us, is customers are starting to think about privacy. And where do I have data which relates to, personally identifying information. And that's really driven a lot, by the European regulations around GDPR. Then we're seeing the California Privacy Act come in. And a number of other states are considering legislation in this area. In some ways, it's actually been a good news story for data protection and data management. Because people are starting to say, I should identify where the data is, I should figure out where the PII is. And I should make sure, I'm actually using my backups for the right purposes. Which is something we've always believed in. We've always thought, Hey, Mr. Customer, I see you're backing up an Oracle database for 10 years. What are you going to do with it in 10 years? Are you going to install Oracle seven and reboot it? It doesn't really add up to me. So, how can you get to a true archive, for that data you really need archive? And then for your backup set, how can you keep it lean and mean. And just keep it for the length of time you actually need it? Which for many customers, could be as little as 14, 15 days, maybe six months, maybe a year. But it's often not those extreme retentions people were thinking of, when they were building their tape based infrastructure 10 years ago. >> Right, that's funny. 'Cause as you mentioned, also I'm thinking of, is big data. Right in this constant kind of conversation. In the Big Data world is they keep everything forever, with the hopes that at some point in time, there may be a different algorithm or a different kind of process, you might run on that, but you didn't think about. Right kind of scheme on read versus scheme on right. But to your point, is that necessarily something that has to be backed up, but it sounds like a lot of, kind of policy driven activity. Than to drive the software to define what to back up, what you don't back up, how you back it up, how long you back it up? And a lot of kind of business decisions as opposed to technology decisions. >> Absolutely, that's been on the back of, the price of storing a bit of data, has declined over the last 10 years. An average 15 percent year over year. For a very long time. So people have ignored the problem. But the truth is, when you're really working at scale, there's a tremendous amount of waste. And we've identified for customers, using our data analytics technology. Millions of dollars of cost savings, where they were, both had storing files on, expensive primary tier one storage. And they were backing up those same, that same bit of information every single week. Even though it hadn't changed, or hadn't been read in seven plus years, and they couldn't find an owner for the information in the company. They literally didn't know why they had it. And I think people are starting to consider that. Especially in budget constraint times. >> Right, it's so funny, right? Sometimes it's such a simple answer, a friend one time had a startup, and he was doing contract management. This is 20 years ago. And I was like, how do you manage the complexity of contracts inside software. Again 20 years ago. And he said, Jeff, that's not it at all. We just need to know like, where is the contract? who signed it and when does it expire? And they built the business, on answering simple questions like that. It's sometimes the simple stuff that's the hard stuff. I want to shift gears a little bit Tim, on what bear toss dude in the market in terms of still having appliances? I'm sure a lot of people like weight appliances. Why are we still using appliances? This is a software defined world. And everything just runs on x86 architecture. You guys still have appliances, tell us a little bit about the why. And some of the benefits of having, kind of a dedicated hardware, software piece of equipment, versus just a pure software solution that sits on anybody's box. >> That's a great question. Thanks for asking. When I think about that world, you have to understand Veritas at its core is absolutely a software company. We build software and we preserve the choice and how the customer implements. When I say we preserve choice. We obviously still support old school Unix. We certainly have enormous investment in the x86 world, both on Windows and various Linux flavors. And of course, you can run those same That same software in the cloud. And of course, you can run it inside of a virtualized infrastructure. So we always like to preserve choice. Now why did we create the appliance business, it's frankly because customers asked us to. The thing that made storing backups on disk affordable, was this technology known as deduplication. Which at its heart is just a fancy kind of compression, That's very, very good at copies of data, where there's a lot of blocks that are have been seen before. And so we don't store them if we've seen them before. We simply store the ones that are new and fresh. So from our perspective, customers said, "we want this technology." And the market really moved away, from general purpose solutions on servers to do that. Because it was very hard to build something, that could have a very high throughput, very high memory, and at the same time, could give excellent support for random access reads, when the customer actually needed to read that data. And so we created a purpose built appliances as a result. And what we discovered in the the process was, there were a lot of pieces that were actually fairly hard in the enterprise. So when a customer would describe, the purchasing process of their typical solution before appliances, they would talk about, filing tickets with the server team. Filing tickets with the storage team. Filing tickets with security team. And sometimes taking six or nine months, to get a piece of equipment ready to install the backup software on the floor. Whereas with ours, they placed an order, it showed up on the dock, as soon as it when it was in the rack, they were ready to go and working independently. Now while we have a great and thriving appliance business, we're very, very proud of, we always preserve choice at Veritas. And even though that's the business I represent, I would make sure our customers always understand, that we're interested in the best platform for the customer. So that's our basic perspective. If you want to go deeper, let me know where you have questions. (chuckles) >> Well, I'm curious on the process, when there's a fail, when there's attack, when there's ransomware, whatever. When you need to go back to your backup. What are some of the things that your approach enables, or what are kind of the typical stumbling blocks that are the hardest things to overcome. That people miss when they're planning for that. Or thinking about it. That kind of rear their ugly heads, when the time comes that, oh, I guess we need to go back to a backup version. >> Yeah, and I'll break that input into this disaster recovery or restore process. And then also the process of backup. So when you think about that disaster recovery, and I'll use ransomware as that piece of it. Because that's the real kind of disaster, when you're looking at equipment in the infrastructure, which has been wiped clean. That's a worst case scenario for most IT managers. When you think about that situation, we've built into our appliances first of all, a hardened Linux OS. Meaning we've shrank down that OS as much as we possibly could. Second, we've added role-based access protection. To make sure that you simply can't log in and perform activities which you're not privileged to perform. And then we have intrusion protection software, intrusion detection software. To ensure that even for those zero day attacks, that we may not even be aware of when we release our software, that the system is hardened. Of course, you have firewalls and STIG rules, STIG or rules are DoD standard, for hardening Linux based devices. So we've got a hardened device. And I was talking to a customer, in a different part of the world this week. Where they described having a data center, where everything had been wiped. And there's one thing left there, their NetBackup appliances. And they were then able to then take that, and use that for the restore. Because that was a real vault for their data. Now, the flipside is, that's a rare day. So that is truly a black swan event. When you think about day to day, and we're running a data protection operation, really think about speed of backup. And for us being able to take something that's neatly tuned for the hardware, the operating system, the tuning, the net backup software is all configured out of the box and ready to go. And the data protection folks, can be independently able to drive that is a great value. Because essentially, you have Lego style building blocks. Where you can order device, it always performs the same. And three years from now, you don't have to redesign it. And take your expensive IT staff and ask them to figure out what's the best solution. We've just got another one off the shelf for you, another series in the model. >> Right >> Now, as you said earlier, the world's getting weirder. It definitely is. So we'll be branching off into what kind of appliances we offer. And you'll see some announcements later, in the year where we'll be offering some reference architecture approaches, which will be a little different than what we offer today. Just to meet the customer demand that's out there. >> Yeah, that's great. I mean, 'cause as you said, it's all about customer choice. And meeting the customer where they want to meet. But before I let you go, this is pretty interesting conversation. I want to get your perspective, as someone who's been in the business, for a really long time. And as you look at opportunities around, machine learning and artificial intelligence, and you look at kind of the I'm going to steal your line about things getting weirder. And use over and over. But as they continue to get weirder and weirder, where do you see kind of the evolution is, you kind of sit back, not necessarily in the next six months or so. But where do you see growth opportunities and places you want to go? That better still out in front of you, even though you've been doing this for many, many years? >> Well, that's a great question. So this is yet another wave. And that's often how I look at it. Meaning, there's a wave of Unix. There's a wave of windows. There's wave of virtualization. And each of these technologies, brought some real shifts to our environment. I think, from my perspective, the next big wave is dealing with ransomware. And some of these compliance requirements we talked about earlier. And then I can't get away from this big data, AI piece and my son's studying computer science in college. And that's a weekly conversation for us. What's new in that front? Because I think we're going to see, a lot more technology developed there. We are just truly on the beginning of that curve. And frankly, when I think about the companies I work with, they have a tremendous amount of data. But that's really only going to increase, as they realize they can actually develop value from it. And as you mentioned, first thing once it shows up on the balance sheet, suddenly everyone's going to get very excited about that. >> Yeah, it's so funny, right? 'Cause it basically does show up on the balance sheet of Facebook, and it shows up on the balance sheet of Google. But it's just not a line item. And I keep waiting for the tipping point, to happen where that becomes, a line item on the balance sheet. Because increasingly, that is arguably, the most important asset. 0r certainly the information and learning that goes around that data. >> You're right. And frankly, it's an insurable asset at this point. You can go to a company in a number of commercial settings and get ransomware insurance, for instance. So people are definitely recognizing the value of it if they're willing to insure it. >> Right, right. All right, Tim. Well, thank you very much for stopping by. And giving us an update really interesting times in, kind of taking care of business and really the core of the business, which is the data inside the business. So, important work. And thanks for taking a few minutes. >> All right, thanks. I'll be glad to be back anytime you want me. >> Alright, He's Tim. I'm Jeff. You're watching theCUBE. Thanks for watching. We'll see you next time. (upbeat music)

(bright upbeat music) >> Reporter: From theCUBE Studios in Palo Alto in Boston. Connecting with thought leaders all around the world. This is theCUBE conversation. >> Hey, welcome back everybody. Jeff Frick here with theCUBE. We're coming to you today from our Palo Alto studios, talking about a really important topic. And that's data. And as we hear over and over and over, right data is the oil. Data is the new currency. Data is driving business decisions. Data drives AI. Data drives machine learning. Data is increasingly important. And we're still kind of waiting for it, to show up on balance sheets. Which is kind of implied in a lot of the big iterations, that we see in companies that are built on data. But one of the important things about data, is taking care of it. And we're excited to have our next guest here to talk about, some of the things you need to think about, and best practices in securing your data. Backing up your data, protecting your data. We're joined today by Tim Burlowski. He is the senior director, Product Management from Veritas. Joining us from remote. I believe you're in Minnesota. Tim, great to see you. >> Yep, thanks for having me. >> Absolutely, so let's just jump into it. So all we hear about is data these days. It's such an important topic, that is growing exponentially. And it's structured and it's unstructured. And it's so core to the business. And are you making database decisions? And are you getting enough data to drive your AI? And your machine learning algorithms? I mean, data is only exploding. You've been in this business for a long, a long, long time. I wonder if you can share your perspective, when you hear these things. more data is going to be created in the next 15 minutes. And wasn't the entire history of men before us? I'm making that up, but it's been quite an explosion. >> I know yeah, I know where you're coming from. And frankly, I don't even put that, in my presentation anymore. Because it's a lot like saying gravity exists, And things that you drop out, of a window will fall to the ground. Everyone's heard it. Everyone's aware of it. The numbers are just so staggering. You don't even know what to do with it. Like how many iPhones could you stack to the moon and back and then to Saturn? Doesn't make sense. But the truth is, we are seeing an explosion. Everyone knows it. We have to manage it better. Now for us, a lot of what we do, is in this data protection space. Where we want to make sure, that data is protected and always available. All of the data that's been created, and the growth in mission-critical applications. It's no longer seven to 20 mission-critical applications. It's hundreds and hundreds of mission-critical applications. Means you have to be ready, with a recent recovery if necessary. And you need to provide that data back to the consumer, as quickly as you possibly can. Because you've got people waiting on it. We've all got our apps on our phone, where we're looking at our bank account 24 seven. We don't wait until a teller appears at nine a.m anymore. It's not the world we live in. >> Right, I'm just curious if you've got some tailwinds, in terms of you're kind of, you've been in this market for a very long time. In terms of people finally realizing that their data, is really more of an asset and a liability. In the investments, to gather it, protect it, analyze it, have it ready for refresh it, If there's some problem. It's a positive investment towards, kind of revenue and strategic importance to the company, as opposed to kind of a back-office IT function, that we're kind of taking care of business because we have to. >> But that one really varies a lot by company. I see companies taking shortcuts and outsourcing, and then suddenly you'll see them in the news. And they discover that they had a major outage for a couple of days. And suddenly practices change very, very quickly. The relative comprehensive, sturdy and reliable infrastructure that people run today, sometimes lulls people into false security. And then you see a major airlines with a multi-day outage. And you go hmm, I think we missed a few steps in the process. So it sometimes takes those rude awakenings. But the companies who are really taking it seriously, and starting to practice pruning their data, examining their data for PII. So they meet various compliance regimes, and other in various states and countries. And starting to think about their backup stream, really being, how do we get a fast recovery? Instead of how do I make a copy, which I will never use again? Are really starting to drive a more efficient IT operation, when it comes to data protection. >> No, it's an interesting take, in reference to having some issue. Because we do a lot of stuff around security. Which is related to but not equal to this conversation. And one of the topics in security is that, most people have already been breached. It's just a function of how fast can you find out, and how fast can you minimize the damage? And how fast can you move on? Why are they breaching? They're breaching to get the data. So I would imagine, with this constant reading in the newspaper, of who was breached here there and everywhere, pretty much every day. That's got to be a huge driver, in terms of people kind of upping their game, and the sophistication, of the way they really think about data protection. >> It is and I'll tell you, I've had the misfortune, I would say. Of talking to customers who are in the middle of recovering, from a major ransomware malware attack. And it's a very difficult proposition. And what customers often discover is, they haven't practiced enough, they don't have enough of a DR plan present. We are certainly rising the occasion. Our products are sort of the last thing, that often stands between the customer, losing their data completely. And so we're looking at a number of technology innovations, that will enable them to store their data on immutable devices. And for the backup infrastructure, to be completely aware of that. Which we'll be announcing later this summer. Which we're very excited about. Of course, from our perspective of our appliance portfolio, we've always provided a couple of extra layers of security against intrusion detection, and intrusion prevention right out of the box. Because we know the backup infrastructure becomes this collection of the very most important data in your infrastructure. Because that's the thing you back up. And you want to restore. If there's ever any sort of manmade disaster or otherwise. >> Right. So I want to shift gears a little bit, and talk about kind of the evolution of the infrastructure kind of scene. If you will. With the rise of public clouds, with Amazon and Google and Microsoft, is sure. And then obviously, you tried into a data center. Lot of talk about HP discover, this week kind of going from edge to cloud and data center in the middle. So the environment in which these applications live, and these applications run, and where the data is, relative to those applications. Is evolved dramatically over the last, you probably have a much better time perspective than I do. Five years, 10 years. But it continues to accelerate, in this kind of Application-Centric World versus, kind of an Infrastructure Centric World. Just curious to get your take on, The kind of the challenges that presents to your company, and what you guys are trying to do to accomplish. And how do you see that continuing to evolve and get, not simpler but more complex over time? >> That is a very astute acknowledgement of what's going on in the industry. And I often call it the industry's getting weirder. I would have thought at some point, we'd sort of have Linux and Windows, and a couple of database vendors. And the truth is that database vendors exploded. And it's not just Linux anymore. It's containers. And it might be a container based on CentOS. And it might be container running in the cloud. Or it might be a simple function, like a lambda function running on nothing in AWS. And so this whole world has gotten a lot stranger. From my perspective, I think the biggest change for Veritas, has been a renewed focus on API's that we make public to customers, in ways that we can glue and stitch these systems together. Now, of course, it doesn't replace the deep integration, we do with companies like VMware, with Docker, as well as the the container ecosystem around. Open shift and some of those technologies. But from our perspective, we've had to be a little bit more prolific, in what we support. And the truth is, it's all files, it's all objects, it's all things we've done before. But they just keep bubbling up in new and different ways. >> Right, but what's interesting though, is you touch on all kinds of stuff there with Kubernetes and clouds and in containers. Is a lot of it's kind of ethereal, right? The whole idea of of a cloud-based infrastructure, is that you can bring it up and bring it down as you need it. You can adjust it as you go. And literally turn it off when you don't need it. And bring it back up. And then you add to that serverless. And this kind of increasing atomization, of all the different parts of compute. Kind of an interesting thing for you guys, to try to back up as these things are created and destructed. We hear these crazy stories of, automating Kubernetes to spin up tons of these things at a time and then bring them back back down. And then I'm curious too. Within that is also the open source. kind of challenge in continuing to have evolution in open source technologies, API's, et cetera. So it is getting weirder and weirder, on a number of fronts as you guys continue to evolve with the market. >> Absolutely, and all I'll tell you, you have to think about all technologies as being on a bridge. As I remind people, we have washing machines. They work really well but washboards still exist, even though it's a technology from 18th century, or beforehand. Now, they may be used as still do exist. Now, my point in this is, people need a bridge. Most enterprises run on an amazing amount of technology, they've developed as a stack over the last 10 to 15 years. And they can't immediately rewrite that, and put it all in a cloud container. So we're actually seeing a lot of use of containers, and Kubernetes with fairly heavy application stacks. When you think about something as heavy as, all have Oracle inside of a container. You can understand that, that's a big lift for container. And it's not ephemeral at all. Then it reaches out to storage, that has that persistence value. And that's where we come in. 'Cause we want to make sure that persistent storage, is always protected. And easily available to the customer for any recovery needs. >> Is great, so I want to shift gears a little bit Tim, to talk about regulations and compliance. 'Cause, regulatory requirements drive a lot of behavior and activity, and really oftentimes, are ahead of maybe the business prerogative to do things like provide backups, provide quick and dirty, quick and easy access. Because you needed it for, a public Freedom of Information Act request. Or you need it for some type of court type of activity. So I wonder if you can kind of talk about, how the regulatory environment, continues to evolve over time. And how does that impact, what you guys are doing in the marketplace? >> Great question. The biggest place is It's affected us, is customers are starting to think about privacy. And where do I have data which relates to, personally identifying information. And that's really driven a lot, by the European regulations around GDPR. Then we're seeing the California Privacy Act come in. And a number of other states are considering legislation in this area. In some ways, it's actually been a good news story for data protection and data management. Because people are starting to say, I should identify where the data is, I should figure out where the PII is. And I should make sure, I'm actually using my backups for the right purposes. Which is something we've always believed in. We've always thought, Hey, Mr. Customer, I see you're backing up an Oracle database for 10 years. What are you going to do with it in 10 years? Are you going to install Oracle seven and reboot it? It doesn't really add up to me. So, how can you get to a true archive, for that data you really need archive? And then for your backup set, how can you keep it lean and mean. And just keep it for the length of time you actually need it? Which for many customers, could be as little as 14, 15 days, maybe six months, maybe a year. But it's often not those extreme retentions people were thinking of, when they were building their tape based infrastructure 10 years ago. >> Right, that's funny. 'Cause as you mentioned, also I'm thinking of, is big data. Right in this constant kind of conversation. In the Big Data world is they keep everything forever, with the hopes that at some point in time, there may be a different algorithm or a different kind of process, you might run on that, but you didn't think about. Right kind of scheme on read versus scheme on right. But to your point, is that necessarily something that has to be backed up, but it sounds like a lot of, kind of policy driven activity. Than to drive the software to define what to back up, what you don't back up, how you back it up, how long you back it up? And a lot of kind of business decisions as opposed to technology decisions. >> Absolutely, that's been on the back of, the price of storing a bit of data, has declined over the last 10 years. An average 15 percent year over year. For a very long time. So people have ignored the problem. But the truth is, when you're really working at scale, there's a tremendous amount of waste. And we've identified for customers, using our data analytics technology. Millions of dollars of cost savings, where they were, both had storing files on, expensive primary tier one storage. And they were backing up those same, that same bit of information every single week. Even though it hadn't changed, or hadn't been read in seven plus years, and they couldn't find an owner for the information in the company. They literally didn't know why they had it. And I think people are starting to consider that. Especially in budget constraint times. >> Right, it's so funny, right? Sometimes it's such a simple answer, a friend one time had a startup, and he was doing contract management. This is 20 years ago. And I was like, how do you manage the complexity of contracts inside software. Again 20 years ago. And he said, Jeff, that's not it at all. We just need to know like, where is the contract? who signed it and when does it expire? And they built the business, on answering simple questions like that. It's sometimes the simple stuff that's the hard stuff. I want to shift gears a little bit Tim, on what bear toss dude in the market in terms of still having appliances? I'm sure a lot of people like weight appliances. Why are we still using appliances? This is a software defined world. And everything just runs on x86 architecture. You guys still have appliances, tell us a little bit about the why. And some of the benefits of having, kind of a dedicated hardware, software piece of equipment, versus just a pure software solution that sits on anybody's box. >> That's a great question. Thanks for asking. When I think about that world, you have to understand Veritas at its core is absolutely a software company. We build software and we preserve the choice and how the customer implements. When I say we preserve choice. We obviously still support old school Unix. We certainly have enormous investment in the x86 world, both on Windows and various Linux flavors. And of course, you can run those same That same software in the cloud. And of course, you can run it inside of a virtualized infrastructure. So we always like to preserve choice. Now why did we create the appliance business, it's frankly because customers asked us to. The thing that made storing backups on disk affordable, was this technology known as deduplication. Which at its heart is just a fancy kind of compression, That's very, very good at copies of data, where there's a lot of blocks that are have been seen before. And so we don't store them if we've seen them before. We simply store the ones that are new and fresh. So from our perspective, customers said, "we want this technology." And the market really moved away, from general purpose solutions on servers to do that. Because it was very hard to build something, that could have a very high throughput, very high memory, and at the same time, could give excellent support for random access reads, when the customer actually needed to read that data. And so we created a purpose built appliances as a result. And what we discovered in the the process was, there were a lot of pieces that were actually fairly hard in the enterprise. So when a customer would describe, the purchasing process of their typical solution before appliances, they would talk about, filing tickets with the server team. Filing tickets with the storage team. Filing tickets with security team. And sometimes taking six or nine months, to get a piece of equipment ready to install the backup software on the floor. Whereas with ours, they placed an order, it showed up on the dock, as soon as it when it was in the rack, they were ready to go and working independently. Now while we have a great and thriving appliance business, we're very, very proud of, we always preserve choice at Veritas. And even though that's the business I represent, I would make sure our customers always understand, that we're interested in the best platform for the customer. So that's our basic perspective. If you want to go deeper, let me know where you have questions. (chuckles) >> Well, I'm curious on the process, when there's a fail, when there's attack, when there's ransomware, whatever. When you need to go back to your backup. What are some of the things that your approach enables, or what are kind of the typical stumbling blocks that are the hardest things to overcome. That people miss when they're planning for that. Or thinking about it. That kind of rear their ugly heads, when the time comes that, oh, I guess we need to go back to a backup version. >> Yeah, and I'll break that input into this disaster recovery or restore process. And then also the process of backup. So when you think about that disaster recovery, and I'll use ransomware as that piece of it. Because that's the real kind of disaster, when you're looking at equipment in the infrastructure, which has been wiped clean. That's a worst case scenario for most IT managers. When you think about that situation, we've built into our appliances first of all, a hardened Linux OS. Meaning we've shrank down that OS as much as we possibly could. Second, we've added role-based access protection. To make sure that you simply can't log in and perform activities which you're not privileged to perform. And then we have intrusion protection software, intrusion detection software. To ensure that even for those zero day attacks, that we may not even be aware of when we release our software, that the system is hardened. Of course, you have firewalls and STIG rules, STIG or rules are DoD standard, for hardening Linux based devices. So we've got a hardened device. And I was talking to a customer, in a different part of the world this week. Where they described having a data center, where everything had been wiped. And there's one thing left there, their NetBackup appliances. And they were then able to then take that, and use that for the restore. Because that was a real vault for their data. Now, the flipside is, that's a rare day. So that is truly a black swan event. When you think about day to day, and we're running a data protection operation, really think about speed of backup. And for us being able to take something that's neatly tuned for the hardware, the operating system, the tuning, the net backup software is all configured out of the box and ready to go. And the data protection folks, can be independently able to drive that is a great value. Because essentially, you have Lego style building blocks. Where you can order device, it always performs the same. And three years from now, you don't have to redesign it. And take your expensive IT staff and ask them to figure out what's the best solution. We've just got another one off the shelf for you, another series in the model. >> Right >> Now, as you said earlier, the world's getting weirder. It definitely is. So we'll be branching off into what kind of appliances we offer. And you'll see some announcements later, in the year where we'll be offering some reference architecture approaches, which will be a little different than what we offer today. Just to meet the customer demand that's out there. >> Yeah, that's great. I mean, 'cause as you said, it's all about customer choice. And meeting the customer where they want to meet. But before I let you go, this is pretty interesting conversation. I want to get your perspective, as someone who's been in the business, for a really long time. And as you look at opportunities around, machine learning and artificial intelligence, and you look at kind of the I'm going to steal your line about things getting weirder. And use over and over. But as they continue to get weirder and weirder, where do you see kind of the evolution is, you kind of sit back, not necessarily in the next six months or so. But where do you see growth opportunities and places you want to go? That better still out in front of you, even though you've been doing this for many, many years? >> Well, that's a great question. So this is yet another wave. And that's often how I look at it. Meaning, there's a wave of Unix. There's a wave of windows. There's wave of virtualization. And each of these technologies, brought some real shifts to our environment. I think, from my perspective, the next big wave is dealing with ransomware. And some of these compliance requirements we talked about earlier. And then I can't get away from this big data, AI piece and my son's studying computer science in college. And that's a weekly conversation for us. What's new in that front? Because I think we're going to see, a lot more technology developed there. We are just truly on the beginning of that curve. And frankly, when I think about the companies I work with, they have a tremendous amount of data. But that's really only going to increase, as they realize they can actually develop value from it. And as you mentioned, first thing once it shows up on the balance sheet, suddenly everyone's going to get very excited about that. >> Yeah, it's so funny, right? 'Cause it basically does show up on the balance sheet of Facebook, and it shows up on the balance sheet of Google. But it's just not a line item. And I keep waiting for the tipping point, to happen where that becomes, a line item on the balance sheet. Because increasingly, that is arguably, the most important asset. 0r certainly the information and learning that goes around that data. >> You're right. And frankly, it's an insurable asset at this point. You can go to a company in a number of commercial settings and get ransomware insurance, for instance. So people are definitely recognizing the value of it if they're willing to insure it. >> Right, right. All right, Tim. Well, thank you very much for stopping by. And giving us an update really interesting times in, kind of taking care of business and really the core of the business, which is the data inside the business. So, important work. And thanks for taking a few minutes. >> All right, thanks. I'll be glad to be back anytime you want me. >> Alright, He's Tim. I'm Jeff. You're watching theCUBE. Thanks for watching. We'll see you next time. (upbeat music)

>> Jeff: Hello everybody, and thank you for joining us today for the virtual Vertica BDC 2020. Today's break-out session has been titled, "Migrating Your Vertica Cluster to the Cloud." I'm Jeff Healey, and I'm in Vertica marketing. I'll be your host for this break-out session. Joining me here are Sumeet Keswani and Chris Daly, Vertica product technology engineers and key members of our customer success team. Before we begin, I encourage you to submit questions and comments during the virtual session. You don't have to wait, just type your question or comment in the question box below the slides and click Submit. As always, there will be a Q&A session at the end of the presentation. We'll answer as many questions as we're able to during that time. Any questions that we don't address, we'll do our best to answer them offline. And alternatively, you can visit Vertica forums at forum.vertica.com to post your questions there after the session. Our engineering team is planning to join the forums to keep the conversation going. Also as a reminder that you can maximize your screen by clicking the double arrow button in the lower right corner of the slides. And yes, this virtual session is being recorded and will be available to view on demand this week. We'll send you a notification as soon as it's ready. Now let's get started. Over to you, Sumeet. >> Sumeet: Thank you, Jeff. Hello everyone, my name is Sumeet Keswani, and I will be talking about planning to deploy or migrate your Vertica cluster to the Cloud. So you may be moving an on-prem cluster or setting up a new cluster in the Cloud. And there are several design and operational considerations that will come into play. You know, some of these are cost, which industry you are in, or which expertise you have, in which Cloud platform. And there may be a personal preference too. After that, you know, there will be some operational considerations like VM and cluster sizing, what Vertica mode you want to deploy, Eon or Enterprise. It depends on your use keys. What are the DevOps skills available, you know, what elasticity, separation you need, you know, what is your backup and DR strategy, what do you want in terms of high availability. And you will have to think about, you know, how much data you have and where it's going to live. And in order to understand the cost, or the cost and the benefit of deployment and you will have to understand the access patterns, and how you are moving data from and to the Cloud. So things to consider before you move a deployment, a Vertica deployment to the Cloud, right, is one thing to keep in mind is, virtual CPUs, or CPUs in the Cloud, are not the same as the usual CPUs that you've been familiar with in your data center. A vCPU is half of a CPU because of hyperthreading. There is definitely the noisy neighbor effect. There is, depending on what other things are hosted in the Cloud environment, you may see performance, you may occasionally see performance issues. There are I/O limitations on the instance that you provision, so that what that really means is you can't always scale up. You might have to scale up, basically, you have to add more instances rather than getting bigger or the right size instances. Finally, there is an important distinction here. Virtualization is not free. There can be significant overhead to virtualization. It could be as much as 30%, so when you size and scale your clusters, you must keep that in mind. Now the other important aspect is, you know, where you put Vertica cluster is important. The choice of the region, how far it is from your various office locations. Where will the data live with respect to the cluster. And remember, popular locations can fill up. So if you want to scale out, additional capacity may or may not be available. So these are things you have to keep in mind when picking or choosing your Cloud platform and your deployment. So at this point, I want to make a plug for Eon mode. Eon mode is the latest mode, is a Cloud mode from Vertica. It has been designed with Cloud economics in mind. It uses shared storage, which is durable, available, and very cheap, like S3 storage or Google Cloud storage. It has been designed for quick scaling, like scale out, and highly elastic deployments. It has also been designed for high workload isolation, where each application or user group can be isolated from the other ones, so that they'll be paid and monitored separately, without affecting each other. But there are some disadvantages, or perhaps, you know, there's a cost for using Eon mode. Storage in S3 is neither cheap nor efficient. So there is a high latency of I/O when accessing data from S3. There is API and data access cost. There is API and data access cost associated with accessing your data in S3. Vertica in Eon mode has a pay as you go model, which you know, works for some people and does not work for others. And so therefore it is important to keep that in mind. And performance can be a little bit variable here, because it depends on cache, it depends on the local depot, which is a cache, and it is not as predictable as EE mode, so that's another trade-off. So let's spend about a minute and see how a Vertica cluster in Eon mode looks like. A Vertica cluster in Eon mode has S3 as the durability layer where all the data sits. There are subclusters, which are essentially just aggregation groups, which is separated compute, which will service different workloads. So for in this example, you may have two subclusters, one servicing ETL workload and the other one servicing (mic interference obscures speaking). These clusters are isolated, and they do not affect each other's performance. This allows you to scale them independently and isolate workloads. So this is the new Vertica Eon mode which has been specifically designed by us for use in the Cloud. But beyond this, you can use EE mode or Eon mode in the Cloud, it really depends on what your use case is. But both of these are possible, and we highly recommend Eon mode wherever possible. Okay, let's talk a little bit about what we mean by Vertica support in the Cloud. Now as you know, a Cloud is a shared data center, right. Performance in the Cloud can vary. It can vary between regions, availability zones, time of the day, choice of instance type, what concurrency you use, and of course the noisy neighbor effect. You know, we in Vertica, we performance, load, and stress test our product before every release. We have a bunch of use cases, we go through all of them, make sure that we haven't, you know, regressed any performance, and make sure that it works up to standards and gives you the high performance that you've come to expect. However, your solution or your workload is unique to you, and it is still your responsibility to make sure that it is tuned appropriately. To do this, one of the easiest things you can do is you know, pick a tested operating system, allocate the virtual machine, you know, with enough resources. It's something that we recommend, because we have tested it thoroughly. It goes a long way in giving you predictability. So after this I would like to now go into the various platforms, Cloud platforms, that Vertica has worked on. And I'll start with AWS, and my colleague Chris will speak about Azure and GCP. And our thoughts forward. So without further ado, let's start with the Amazon Web Services platform. So this is Vertica running on the Amazon Web Services platform. So as you probably are all aware, Amazon Web Services is the market leader in this space, and indeed really our biggest provider by far, and have been here for a very long time. And Vertica has a deep integration in the Amazon Web Services space. We provide a marketplace offering which has both pay as you go or a bring your own license model. We have many, you know, knowledge base articles, best practices, scripts, and resources that help you configure and use a Vertica database in the Cloud. We have several customers in the Cloud for many, many years now, and we have managed and console-based point and click deployments, you know, for ease of use in the Cloud. So Vertica has a deep integration in the Amazon space, and has been there for quite a bit now. So we communicate a lot of experience here. So let's talk about sizing on AWS. And sizing on any platform comes down to you know, these four or five different things. It comes down to picking the right instance type, picking the right disk volume and type, tuning and optimizing your networking, and finally, you know, some operational concerns like security, maintainability, and backup. So let's go into each one of these on the AWS ecosystem. So the choice of instance type is one of the important choices that you will make. In Eon mode, you know, you don't really need persistent disk. You can, you should probably choose ephemeral disk because it gives you extra speed, and speed with the instance type. We highly recommend the i3.4x instance types, which are very economical, have a big, 4 terabyte depot or cache per node. The i3.metal is similar to the i3.4, but has got significantly better performance, for those subclusters that need this extra oomph. The i3.2 is good for scale out of small ad hoc clusters. You know, they have a smaller cache and lower performance but it's cheap enough to use very indiscriminately. If you were in EE mode, well we don't use S3 as the layer of durability. Your local volumes is where we persist the data. Hence you do need an EBS volume in EE mode. In order to make sure that, you know, that the instance or the deployment is manageable, you might have to use some sort of a software RAID array over the EBS volumes. The most common instance type you see in EE mode is the r4.4x, the c4, or the m4 instance types. And then of course for temp space and depot we always recommend instance volumes. They're just much faster. Okay. So let's go, let's talk about optimizing your network or tuning your network. So the best, the best thing you can do about tuning your network, especially in Eon mode but in other modes too, is to get a VPC S3 endpoint. This is essentially a route table that makes sure that all traffic between your cluster and S3 goes over an internal fabric. This makes it much faster, you don't pay for egress cost, especially if you're doing external tables or your communal storage, but you do need to create it. Many times people will forget doing it. So you really do have to create it. And best of all, it's free. It doesn't cost you anything extra. You just have to create it during cluster creation time, and there's a significant performance difference for using it. The next thing about tuning your network is, you know, sizing it correctly. Pick the closest geographical region to where you'll consume the data. Pick the right availability zone. We highly recommend using cluster placement groups. In fact, they are required for the stability of the cluster. A cluster placement group is essentially, it operates this notion of rack. Nodes in a cluster placement group, are, you know, physically closer to each other than they would otherwise be. And this allows, you know, a 10 Gbps, bidirectional, TCP/IP flow between the nodes. And this makes sure that, you know, you get a high amount of Gbps per second. As you probably are all aware, the Cloud does not support broadcast or UDP broadcast. Hence you must use point-to-point UDP for spread in the Cloud, or in AWS. Beyond that, you know, point-to-point UDP does not scale very well beyond 20 nodes. So you know, as your cluster sizes increase, you must switch over to large cluster mode. And finally, use instances with enhanced networking or SR-IOV support. Again, it's free, it comes with the choice of the instance type and the operating system. We highly recommend it, it makes a big difference in terms of how your workload will perform. So let's talk a little bit about security, configuration, and orchestration. As I said, we provide CloudFormation scripts to make the ease of deployment. You can use the MC point and click. With regard to security, you know, Vertica does support instance profiles out of the box in Amazon. We recommend you use it. This is highly desirable so that you're not passing access keys and secret keys around. If you use our marketplace image, we have picked the latest operating systems, we have patched them, Amazon actually validates everything on marketplace and scans them for security vulnerabilities. So you get that for free. We do some basic configuration, like we disable root ssh access, we disallow any password access, we turn on encryption. And we run a basic set of security checks to make sure that the image is secure. Of course, it could be made more secure. But we try to balance out security, performance, and convenience. And finally, let's talk about backups. Especially in Eon mode I get the question, "Do we really need to back up our system, "since the data is in S3?" And the answer is yes, you do. Because you know, S3's not going to protect you against an accidental drop table. You know, S3 has a finite amount of reliability, durability, and availability. And you may want to be able to restore data differently. Also, backups are important if you're doing DR, or if you have additional cluster in a different region. The other cluster can be considered a backup. And finally, you know, why not create a backup or a disaster recovery cluster, you know, storage is cheap in the Cloud. So you know, we highly recommend you use it. So with this, I would like to hand it over to my colleague Christopher Daly, who will talk about the other two platforms that we support, that is Google and Azure. Over to you, Chris, thank you. >> Chris: Thanks, Sumeet, and hi everyone. So while there's no argument that we here at Vertica have a long history of running within the Amazon Web Services space, there are other alternative Cloud service providers where we do have a presence, such as Google Cloud Platform, or GCP. For those of you who are unfamiliar with GCP, it's considered the third-largest Cloud service provider in the marketspace, and it's priced very competitively to its peers. Has a lot of similarities to AWS in the products and services that it offers, but it tends to be the go-to place for newer businesses or startups. We officially started supporting GCP a little over a year ago with our first entry into their GCP marketplace. So a solution that deployed a fully-functional and ready-to-use Enterprise mode cluster. We followed up on that with the release and the support of Google storage buckets, and now I'm extremely pleased to announce that with the launch of Vertica 10, we're officially supporting Eon mode architecture in GCP as well. But that's not all, as we're adding additional offerings into the GCP marketplace. With the launch of version 10 we'll be introducing a second listing in the marketplace that allows for the deployment of an Eon mode cluster. It's all being driven by our own management consult. This will allow customers to quickly spin up Eon-based clusters within the GCP space. And if that wasn't enough, I'm also pleased to tell you that very soon after the launch we're going to be offering Vertica by the hour in GCP as well. And while we've done a lot to automate the solutions coming out of the marketplace, we recognize the simple fact that for a lot of you, building your cluster manually is really the only option. So with that in mind, let's talk about the things you need to understand in GCP to get that done. So wag me if you think this slide looks familiar. Well nope, it's not an erroneous duplicate slide from Sumeet's AWS section, it's merely an acknowledgement of all the things you need to consider for running Vertica in the Cloud. In Vertica, the choice of the operational mode will dictate some of the choices you'll need to make in the infrastructure, particularly around storage. Just like on-prem solutions, you'll need to understand the disk and networking capacities to get the most out of your cluster. And one of the most attractive things in GCP is the pricing, as it tends to run a little less than the others. But it does translate into less choices and options within the environment. If nothing else, I want you to take one thing away from this slide, and Sumeet said this earlier. VMs running, about AWS, Sumeet said this about AWS earlier. VMs running in the GCP space run on top of hardware that has hyperthreading enabled. And that a vCPU doesn't equate to a core, but rather a processing thread. This becomes particularly important if you're moving from an on-prem environment into the Cloud. Because a physical Vertica node with 32 cores is not the same thing as a VM with 32 vCPUs. In fact, with 32 vCPUs, you're only getting about 16 cores worth of performance. GCP does offer a handful of VM types, which they categorize by letter, but for us, most of these don't make great choices for Vertica nodes. The M series, however, does offer a good core to memory ratio, especially when you're looking at the high-mem variants. Also keep in mind, performance in I/O, such as network and disk, are partially dependent on the VM size, so customers in GCP space should be focusing on 16 vCPU VMs and above for their Vertica nodes. Disk options in GCP can be broken down into two basic types, persistent disks and local disks, which are ephemeral. Persistent disks come in two forms, standard or SSD. For Vertica in Eon mode, we recommend that customers use persistent SSD disks for the catalog, and either local SSD disks or persistent SSD disks for the depot and the temp space. Couple of things to think about here, though. Persistent disks are provisioned as a single device with a settable size. Local disks are provisioned as multiple disk devices with a fixed size, requiring you to use some kind of software RAIDing to create a single storage device. So while local SSD disks provide much more throughput, you're using CPU resources to maintain that RAID set. So you're giving, it's a little bit of a trade-off. Persistent disks offer redundancy, either within the zone that they exist or within the region, and if you're selecting regional redundancy, the disks are replicated across multiple zones in the region. This does have an effect in the performance to VM, so we don't recommend this. What we do recommend is the zonal redundancy when you're using persistent disks, as it gives you that redundancy level without actually affecting the performance. Remember also, in the Cloud space, all I/O is network I/O, as disks are basically block storage devices. This means that disk actions can and will slow down network traffic. And finally, the storage bucket access in GCP is based on GCP interoperability mode, which means that it's basically compliant with the AWS S3 API. In interoperability mode, access to the bucket is granted by a key pair that GCP refers to as HMAC keys. HMAC keys can be generated for individual users or for service accounts. We will recommend that when you're creating HMAC keys, choose a service account to ensure that the keys are not tied to a single employee. When thinking about storage for Enterprise mode, things change a little bit. We still recommend persistent SSD disks over standard ones. However, the use of local SSD disks for anything other than temp space is highly discouraged. I said it before, local SSD disks are ephemeral, meaning that the data's lost if the machine is turned off or goes down. So not really a place you want to store your data. In GCP, multiple persistent disks placed into a software RAID set does not create more throughput like you can find in other Clouds. The I/O saturation usually hits the VM limit long before it hits the disk limit. In fact, performance of a persistent disk is determined not just by the size of the disk but also by the size of the VM. So a good rule of thumb in GCP is to maximize your I/O throughput for persistent disks, is that the size tends to max out at two terabytes for SSDs and 10 terabytes for standard disks. Network performance in GCP can be thought of in two distinct ways. There's node-to-node traffic, and then there's egress traffic. Node-to-node performance in GCP is really good within the zone, with typical traffic between nodes falling in the 10-15 gigabits per second range. This might vary a little from zone to zone and region to region, but usually it's only limited, they're only limited by the existing traffic where the VMs exist. So kind of a noisy neighbor effect. Egress traffic from a VM, however, is subject to throughput caps, and these are based on the size of the VM. So the speed is set for the number of vCPUs in the VM at two gigabits per second per vCPU, and tops out at 32 gigabits per second. So the larger the VM, the more vCPUs you get, the larger the cap. So some things to consider in the NAV ring space for your Vertica cluster, pick a region that's physically close to you, even if you're connecting to the GCP network from a corporate LAN as opposed to the internet. The further the packets have to travel, the longer it's going to take. Also, GCP, like most Clouds, doesn't support UDP broadcast traffic on their virtual NAV ring, so you do have to use the point-to-point flag for spread when you're creating your cluster. And since the network cap on VMs is set at 32 gigabits per second per VM, maximize your network egress throughput and don't use VMs that are smaller than 16 vCPUs for your Vertica nodes. And that gets us to the one question I get asked the most often. How do I get my data into and out of the Cloud? Well, GCP offers many different methods to support different speeds and different price points for data ingress and egress. There's the obvious one, right, across the internet either directly to the VMs or into the storage bucket. Or you can, you know, light up a VPN tunnel to encrypt all that traffic. But additionally, GCP offers direct network interconnect from your corporate network. These get provided either by Google or by a partner, and they vary in speed. They also offer things called direct or carrier peering, which is connecting the edges of the networks between your network and GCP, and you can use a CDN interconnect, which creates, I believe, an on-demand connection from the GCP network, your network to the GCP network provided by a large host of CDN service providers. So GCP offers a lot of ways to move your data around in and out of the GCP Cloud. It's really a matter of what price point works for you, and what technology your corporation is looking to use. So we've talked about AWS, we've talked about GCP, it really only leaves one more Cloud. So last, and by far not the least, there's the Microsoft Azure environment. Holding on strong to the number two place in the major Cloud providers, Azure offers a very robust Cloud offering that's attractive to customers that already consume services from Microsoft. But what you need to keep in mind is that the underlying foundation of their Cloud is based on the Microsoft Windows products. And this makes their Cloud offering a little bit different in the services and offerings that they have. The good news here, though, is that Microsoft has done a very good job of getting their virtualization drivers baked into the modern kernels of most Linux operating systems, making running Linux-based VMs in Azure fairly seamless. So here's the slide again, but now you're going to notice some slight differences. First off, in Azure we only support Enterprise mode. This is because the Azure storage product is very different from Google Cloud storage and S3 on AWS. So while we're working on getting this supported, and we're starting to focus on this, we're just not there yet. This means that since we're only supporting Enterprise mode in Azure, getting the local disk performance right is one of the keys to success of running Vertica here, with the other major key being making sure that you're getting the appropriate networking speeds. Overall, Azure's a really good platform for Vertica, and its performance and pricing are very much on par with AWS. But keep in mind that the newer versions of the Linux operating systems like RHEL and CentOS run much better here than the older versions. Okay, so first things first again, just like GCP, in Azure VMs are running on top of hardware that has hyperthreading enabled. And because of the way Hyper-V, Azure's virtualization engine works, you can actually see this, right? So if you look down into the CPU information of the VM, you'll actually see how it groups the vCPUs by core and by thread. Azure offers a lot of VM types, and is adding new ones all the time. But for us, we see three VM types that make the most sense for Vertica. For customers that are looking to run production workloads in Azure, the Es_v3 and the Ls_v2 series are the two main recommendations. While they differ slightly in the CPU to memory ratio and the I/O throughput, the Es_v3 series is probably the best recommendation for a generalized Vertica node, with the Ls_v2 series being recommended for workloads with higher I/O requirements. If you're just looking to deploy a sandbox environment, the Ds_v3 series is a very suitable choice that really can reduce your overall Cloud spend. VM storage in Azure is provided by a grouping of four different types of disks, all offering different levels of performance. Introduced at the end of last year, the Ultra Disk option is the highest-performing disk type for VMs in Azure. It was designed for database workloads where high throughput and low latency is very desirable. However, the Ultra Disk option is not available in all regions yet, although that's been changing slowly since their launch. The Premium SSD option, which has been around for a while and is widely available, can also offer really nice performance, especially higher capacities. And just like other Cloud providers, the I/O throughput you get on VMs is dictated not only by the size of the disk, but also by the size of the VM and its type. So a good rule of thumb here, VM types with an S will have a much better throughput rate than ones that don't, meaning, and the larger VMs will have, you know, higher I/O throughput than the smaller ones. You can expand the VM disk throughput by using multiple disks in Azure and using a software RAID. This overcomes limitations of single disk performance, but keep in mind, you're now using CPU cycles to maintain that raid, so it is a bit of a trade-off. The other nice thing in Azure is that all their managed disks are encrypted by default on the server side, so there's really nothing you need to do here to enable that. And of course I mentioned this earlier. There is no native access to Azure storage yet, but it is something we're working on. We have seen folks using third-party applications like MinIO to access Azure's storage as an S3 bucket. So it might be something you want to keep in mind and maybe even test out for yourself. Networking in Azure comes in two different flavors, standard and accelerated. In standard networking, the entire network stack is abstracted and virtualized. So this works really well, however, there are performance limitations. Standard networking tends to top out around four gigabits per second. Accelerated networking in Azure is based on single root I/O virtualization of the Mellanox adapter. This is basically the VM talking directly to the physical network card in the host hardware, and it can produce network speeds up to 20 gigabits per second, so much, much faster. Keep in mind, though, that not all VM types and operating systems actually support accelerated networking, and you know, just like disk throughput, network throughput is based on VM type and size. So what do you need to think about for networking in the Azure space? Again, stay close to home. Pick regions that are geographically close to your location. Yes, the backbones between the regions are very, very fast, but the more hops your packets have to make, the longer it takes. Azure offers two types of groupings of their VMs, availability sets and availability zones. Availability zones offer good redundancy across multiple zones, but this actually increases the node-to-node latency, so we recommend you avoid this. Availability sets, on the other hand, keep all your VMs grouped together within a single zone, but makes sure that no two VMs are running on the same host hardware, for redundancy. And just like the other Clouds, UDP broadcast is not supported. So you have to use the point-to-point flag when you're creating your database to ensure that the spread works properly. Spread time out, okay, this is a good one. So recently, Microsoft has started monthly rolling updates of their environment. What this looks like is VMs running on top of hardware that's receiving an update can be paused. And this becomes problematic when the pausing of the VM exceeds eight seconds, as the unpaused members of the cluster now think the paused VM is down. So consider adjusting the spread time out for your clusters in Azure to 30 seconds, and this will help avoid a little of that. If you're deploying a large cluster in Azure, more than 20 nodes, use large closer mode, as point-to-point for spread doesn't really scale well with a lot of Vertica nodes. And finally, you know, pick VM types and operating systems that support accelerated networking. The difference in the node-to-node speeds can be very dramatic. So how do we move data around in Azure, right? So Microsoft views data egress a little differently than other Clouds, as it classifies any data being transmitted by a VM as egress. However, it only bills for data egress that actually leaves the Azure environment. Egress speed limits in Azure are based entirely on the VM type and size, and then they're limited by your connection to them. While not offering as many pathways to access their Cloud as GCP, Azure does offer a direct network-to-network connection called ExpressRoute. Offered by a large group of third-party processors, partners, the ExpressRoute offers multiple tiers of performance that are based on a flat charge for inbound data and a metered charge for outbound data. And of course you can still access these via the internet, and securely through a VPN gateway. So on behalf of Jeff, Sumeet, and myself, I'd like to thank you for listening to our presentation today, and we're now ready for Q&A.

>> From the SiliconANGLE Media office in Boston, Massachusetts, it's theCUBE! (upbeat electronic music) Now, here's your host, Dave Vellante. >> Hi, everybody, this is Dave Vellante, and I want to share with you some recent survey data that talks to the IBM acquisition of Red Hat, which closed today. It's always really valuable to go out, talk to practitioners, see what they're doing, and it's a hard thing to do. It's very expensive to get this type of survey data. A lot of times, it's very much out of date. You might remember. Some of you might remember a company called the InfoPro. Its founder and CEO was Ken Male, and he raised some money from Gideon Gartner, and he had this awesome survey panel. Well, somehow it failed. Well, friends of mine at ETR, Enterprise Technology Research, have basically created a modern version of the InfoPro. It's the InfoPro on steroids with a modern interface and data science behind it. They've now been at this for 10 years. They built a panel of 4,500 users, practitioners that they can go to, a lot of C level folks, a lot of VP level and then some doers down at the engineering level, and they go out and periodically survey these folks, and one of the surveys they did back in October was what do you think of the IBM-Red Hat acquisition? And then they've periodically gone out and talked to customers of both Red Hat and IBM or both to get a sense of the sentiment. So given that the acquisition closed today, we wanted to share some of that data with you, and our friends at ETR shared with us some of their drill down data with us, and we're going to share it with you. So first of all, I want to summarize something that they said. Back in October, they said, "We view this acquisition as less of an attempt "by IBM to climb into the cloud game, cloud relevance, "but rather a strategic opportunity "to reboot IBM's early 1990s IT services business strategy." I couldn't agree with that more. I've said all along this is a services play connecting OpenShift from Red Hat into the what Ginni Rometty talks about as the 80% of the install base that is still on prem with the workloads at the backend of mission critical systems that need to be modernized. That's IBM's opportunity. That's why this is a front end loaded cashflow deal 'cause IBM can immediately start doing business through it services organization and generate cash. They went on to say, ETR said, "Here, IBM could position itself "as the de facto IT services partner "for Fortune 100 to Global 2000 organizations "and their digital transformations. "Therefore, in theory, this could reinvigorate "the global services business for IBM "and their overlapping customer bases "could alow IBM to recapture and accelerate a great deal "of service revenues that they have lost "over the past few years." Again, I couldn't agree more. It's less about a cloud play. It is definitely about a multi-cloud play, which is how IBM's positioning this, but services de-risks this entire acquisition in my opinion even though it's very large, 34 billion. Okay, I'm show you some data. So pull up this slide. So what ETR does is they'll go out. So this is a survey of right after the acquisition of about 132 Global 2000 practitioners across a bunch of different industries, energy, utilities, financial services, government, healthcare, IT, telco, retail consumers, so a nice cross section of industries and largely in North America but a healthy cross section of AMIA and APAC. And again, these are large enterprises. So what this slide shows is conditioned responses, which I love conditioned responses. It sort of forces people to answer which of the following best describes. But this says, "Given IBM's intent to acquire Red Hat, "do you believe your organization will be more likely "to use this new combination "or less likely in your digital transformation?" You can see here on the left hand side, the green, 23% positive, on the right hand side, 13% negative. So, the data doesn't necessarily support ETR's original conclusions and my belief that this all about services momentum because most IT people are going to wait and see. So you can see the fat middle there is 64%. Basically you're saying, "Yeah, we're going to wait and see. "This really doesn't change anything." But nonetheless, you see a meaningfully more positive sentiment than negative sentiment. The bottom half of this slide shows, the question is, "Do you believe that this acquisition "makes or will make IBM a legitimate competitor "in the cloud wars between AWS and Microsoft Azure?" You can see on the left hand side, it says 45% positive. Very few say, all the way on the left hand side, a very legitimate player in the cloud on par with AWS and Azure. I don't believe that's the case. But a majority said, "IBM is surely better off "with Red Hat than without Red Hat in the context of cloud." Again, I would agree with that. While I think this is largely a services play, it's also, as Stu Miniman pointed out in an earlier video with me, a cloud play. And you can see it's still 38% is negative on the right hand side. 15% absolutely not, IBM is far behind AWS and Azure in cloud. I would tend to agree with that, but IBM is different. They're trying to bring together its entire software portfolio so it has a competitive approach. It's not trying to take Azure and AWS head on. So you see 38% negative, 45% positive. Now, what the survey didn't do is really didn't talk to multi-cloud. This, to me, puts IBM at the forefront of multi-cloud, right in there with VMware. You got IBM-Red Hat, Google with Anthos, Cisco coming at it from a network perspective and, of course, Microsoft leveraging its large estate of software. So, maybe next time we can poke at the multi-cloud. Now, that survey was done of about over 150, about 157 in the Global 2000. Sorry, I apologize. That was was 137. The next chart that I'm going to show you is a sentiment chart that took a pulse periodically, which was 157 IT practitioners, C level executives, VPs and IT practitioners. And what this chart shows essentially is the spending intentions for Red Hat over time. Now, the green bars are really about the adoption rates, and you can see they fluctuate, and it's kind of the percentage on left hand side and time is on the horizontal axis. The red is the replacement. We're going to replace. We're not going to buy. We're going to replace. In the middle is that fat middle, we're going to stay flat. So the yellow line is essentially what ETR calls market share. It's really an indication of mind share in my opinion. And then the blue line is spending intentions net score. So what does that mean? What that means is they basically take the gray, which is staying the same, they subtract out the red, which is we're doing less, and they add in the we're going to do more. So what does this data show? Let's focus on the blue line. So you can see, you know, slightly declining, and then pretty significantly declining last summer, maybe that's 'cause people spend less in the summer, and then really dropping coming into the announcement of the acquisition in October of 2018, IBM announced the $34 billion acquisition of Red Hat. Look at the spike post announcement. The sentiment went way up. You have a meaningful jump. Now, you see a little dip in the April survey, and again, that might've been just an attenuation of the enthusiasm. Now, July is going on right now, so that's why it's phased out, but we'll come back and check that data later. So, and then you can see this sort of similar trend with what they call market share, which, to me, is, again, really mind share and kind of sentiment. You can see the significant uptick in momentum coming out of the announcement. So people are generally pretty enthusiastic. Again, remember, these are customers of IBM, customers of Red Hat and customer of both. Now, let's see what the practitioners said. Let's go to some of the open endeds. What I love about ETR is they actually don't just do the hardcore data, they actually ask people open ended questions. So let's put this slide up and share with you some of the drill down statements that I thought were quite relevant. The first one is right on. "Assuming IBM does not try to increase subscription costs "for RHEL," Red Hat Enterprise Linux, "then its organizational issues over sales "and support should go away. "This should fix an issue where enterprises "were moving away from RHEL to lower cost alternatives "with significant movement to other vendors. "This plus IBM's purchase of SoftLayer and deployment "of CloudFoundry will make it harder "for Fortune 1000 companies to move away from IBM." So a lot implied things in there. The first thing I want to mention is IBM has a nasty habit when it buys companies, particularly software companies, to raise prices. You certainly saw this with SPSS. You saw this with other smaller acquisitions like Ustream. Cognos customers complained about that. IBM buys software companies with large install bases. It's got a lock in spec. It'll raise prices. It works because financially it's clearly worked for IBM, but it sometimes ticks off customers. So IBM has said it's going to keep Red Hat separate. Let's see what it does from a pricing standpoint. The next comment here is kind of interesting. "IBM has been trying hard to "transition to cloud-service model. "However, its transition has not been successful "even in the private-cloud domain." So basically these guys are saying something that I've just said is that IBM's cloud strategy essentially failed to meet its expectations. That's why it has to go out and spend $34 billion with Red Hat. While it's certainly transformed IBM in some respects, IBM's still largely a services company, not as competitive as cloud as it would've liked. So this guys says, "let alone in this fiercely competitive "public cloud domain." They're not number one. "One of the reasons, probably the most important one, "is IBM itself does not have a cloudOS product. "So, acquiring Red Hat will give IBM "some competitive advantage going forward." Interesting comments. Let's take a look at some of the other ones here. I think this is right on, too. "I don't think IBM's goal is to challenge AWS "or Azure directly." 100% agree. That's why they got rid of the low end intel business because it's not trying to be in the commodity businesses. They cannot compete with AWS and Azure in terms of the cost structure of cloud infrastructure. No way. "It's more to go after hybrid multi-cloud." Ginni Rometty said today at the announcement, "We're the only hybrid multi-cloud, opensource vendor out there. Now, the third piece of that opensource I think is less important than competing in hybrid and multi-cloud. Clearly Red hat gives IMB a better position to do this with CoreOS, CentOS. And so is it worth 34 billion? This individual thinks it is. So it's a vice president of a financial insurance organization, again, IBM's strong house. So you can here some of the other comments here. "For customers doing significant business "with IBM Global Services teams." Again, outsourcing, it's a 10-plus billion dollar opportunity for IBM to monetize over the next five years, in my opinion. "This acquisition could help IBM "drive some of those customers "toward a multi-cloud strategy "that also includes IBM's cloud." Yes, it's a very much of a play that will integrate services, Red Hat, Linux, OpenShift, and of course, IBM's cloud, sprinkle in a little Watson, throw in some hardware that IBM has a captive channel so the storage guys and the server guys can sell their hardware in there if the customer doesn't care. So it's a big integrated services play. "Positioning Red Hat, and empowering them "across legacy IBM silos, will determine if this works." Again, couldn't agree more. These are very insightful comments. This is a largely a services and an integration play. Hybrid cloud, multi-cloud is complex. IBM loves complexity. IBM's services organization is number one in the industry. Red Hat gives it an ingredient that it didn't have before other than as a partner. IBM now owns that intellectual property and can really go hard and lean in to that services opportunity. Okay, so thanks to our friends at Enterprise Technology Research for sharing that data, and thank you for watching theCUBE. This is Dave Vellante signing off for now. Talk to you soon. (upbeat electronic music)

>> Live from Las Vegas, it's theCube covering Dell Technologies world 2019 brought to you by Dell Technologies and its ecosystem partners. >> Good afternoon and welcome back to theCube day three of our live coverage of Dell Technologies World 2019, I'm Lisa Martin with my co-host Dave Vellante. Hey, Dave. >> Hey, Lisa, how's it going? >> Good. Day three. >> It's cold here. >> It's cold in here. I agree. But we're going to lighten it up with some really good conversation. We've got Rob Emsley back on thCube, Director of Product Marketing for data protection, Dell EMC, Rob, great to have you back. >> Great to be back. >> We got show and tell you brought Adam Schmitt network architect from customer GEI consultants. Welcome, Adam. >> Thank you-- >> Time to heat it up. >> What a great topic he's out with data protection. >> It's a hot topic. You're right. All right. So before we turn the way up on the seat, Adam, give us an overview of GEI Consultants who you guys are, what you do. >> Sure, GEI consultants is an environmental water resources, structural an engineering firm, we focus on anything and everything under the sun from structural geotechnical, bio chemical, you know, pretty much anything and everything engineering. >> So important stuff. Talk to us about before you were using working with Dell EMC, talk to us about your, your infrastructure, on prem, hybrid, what were you doing in terms of ensuring that that data was protected was accessible, so insights can be extracted from it? >> Absolutely. So GEI has 43 offices East to West Coast, and each of those offices has their own actual infrastructure that we have to protect at each site, ranging anywhere between three to 15 terabytes of size. So we're talking a lot of data and a lot of different geographical locations that I as a network architect had to worry about protecting, and one of the challenges of our older infrastructure, we were running 40 servers, just doing file level backups and restores, and we didn't have the ability to do any offline site backups in any locations. Now, we did have those in our primary data centers, and we were able to cross backup from each location to another when necessary, but it was, again, only a file level backup, it wasn't an actual full image, and we didn't have a full cloud picture yet that we could expand on going forward. >> So not a really robust data disaster recovery strategy in the event that you had to get something like that. >> It took several times and there are examples that I could give you office lost hardware in their actual infrastructure and we had to do a restore by restoring the files out an off site location, putting it on a USB hard drive and shipping it to that location, and then having to rebuild the infrastructure from the ground up and copy the data over not a timely manner of free storage. >> Or inexpensive. >> Robin, in the old days, you'd have an admin in the remote office, they load in a tape and it did recycle the tape every day, you know, you'd have it for a week, and then you'd reuse the same tape over and over again. That was the architecture, state of the art back then. >> Yeah, you probably remember something for those ads, there was a picture of a slightly undesirable individual and says, would you like this person to be your backup admin, which I thought was a little bit strange. But now I think things have moved on a little bit. >> What's the architecture look like today? >> Well, you know, one of the things in architecture is a very key word, because we have a belief in a saying that architecture matters, and when you have a distributed network, where you have lots of edge locations, and you have the requirement to protect them, and bring them back to the edge, the architecture that you deploy, really does make a difference. You know, there's a famous Star Trek line, I've heard it a few times this week that you cannot change the laws of Physics, and the amount of data that you move from the edge to the core, you want to make it as small as possible because if you don't, the amount of time that it takes to get data protected from the edge, especially you have lots of edges becomes a real constraint. So that was something which you know, GEI was able to take advantage of. >> So can you do that at speed? Doesn't that change the laws of Physics anyway? We don't go there, okay, so I wonder if you could share with us kind of how you came to this spot? What was life like before? Did you look at any other vendors, you know, paint the picture for us. >> So working with the Dell EMC technical team, as well as the DPS sales team, we were able to come up with a different strategy going forward. But it wasn't after a lot of trial and error when doing proof of concepts with other companies that, you know, made promises that they could do the backups that we needed off site at different locations geographically, but when it came down to it, we were going to have to fork up a lot of money for infrastructure being installed at every single location, whereas Dell EMC, I don't have to deploy any or any hardware, all I had to deploy was a virtual appliance at each location and we were successful in backing up remotely, we tried various technologies that claim that they could do it, and they didn't work successfully. So after a lot of trial and error, roughly, in total about a year's worth of trying, we finally got Dell EMCs technical team and the DPS came on board and we sat down in front of a whiteboard in Boston, Massachusetts, and said, this is what we're trying to paint as a picture, help me paint this as a full blown architecture and make this happen in this design fashion, and luckily, the Dell EMC team was so experienced and has so many different strategies that they can focus on, they were able to take every little thing that we needed, mark every checkbox and deliver a package with DPS for our solution in our own architecture that answered all of my questions instantly. >> You said virtual appliance it's got to run on something. So what is that actually? It's like serverless, right? >> So we have a physical infrastructure at every location, I deployed a virtual CentOS box, that's proxy that talks back to my data domain and communicates the CVT data changes back for backup. So it's not doing a full consecutive backup. That leaves a lot of headroom left over on your actual production server, so that it's not pegged while staff are using it. So I can kick off backups during the day, it takes a snapshot, and then the data gets backed up without anybody knowing. >> So this is really important as you said, Rob, you can't change the law of Physics. I imagine you got a straw and you got to put all this data through. It's like, it's like when you backup your iPhone for the first time it takes forever now. So you're talking about, you know, changed, just checking the changed data, and putting it through that straw, even though it's maybe a little bigger than a straw, so each day, it's just a smaller amount of data, okay, but what happens on a restore? >> On a restore same instance. So we'll restore that file, if we're doing the file level restore to the data domain, and then copy it wherever we need to on the network. Or if we're doing a full image based backup, we can restore that either to the cloud disaster recovery into AWS or Azure, or we can restore it to the actual data domain and Vmotion it wherever we need to after that point. >> So let's talk about business impact Sounds like there was a lot of trial and error, as you explained, really needing to work with a strategic partner who said all right, I get what you're trying to do, obviously, not easy, but you've been able to implement that. So how is GEI's business positively benefiting from this data protection strategy that you've implemented? >> Well, not just on a financial perspective, because we've eliminated the need for a completely separate off site data center, we have everything running in a cloud environment for CDR, so that we can restore instantly anytime that we need to, so we no longer needed to spend the footprint on another network architect on another infrastructure on all the different things that rely on another infrastructure at a separate location, so on top of financial savings for the company, I mean, we saved a huge amount of money, they're on infrastructure, that's only for disaster recovery, it's not doing anything, whereas we can just spend money on object storage in AWS, and use that as our cloud disaster recovery strategy. When you need it, you pay for it for your instances but otherwise, you're just paying for object storage, it's a lot cheaper than ever having to run a full separate data center. >> Specifically what is Dell's role in that equation in terms of the value chain? >> The data domain, we also got CDR, which allows us to use an appliance on premise to talk to an instance server in AWS or Azure, and it after its normal backup period, the backup completes and then shoots all the data that changed up to AWS in an S3 Bucket, and your data stored there and in a VMDK chunk data, that after need for restore can be turned into an AMI for AWS available, and then online whenever you need it. >> So this is very key, you know, on Tuesday, cloud was a big topic, hybrid cloud reality for the majority of customers and Adam and GEI the leverage of AWS is a great example of what many of our clients are looking to do from their investment in the public cloud. Certainly no GEI today is using AWS as a alternative to having to purchase a secondary disaster recovery site, or having to sign up with a managed service provider that's providing like a co-location service for disaster recovery, so using the public cloud and using the software capabilities around cloud disaster recovery, gives them a tremendous opportunity to save themselves a lot of money and do it very efficiently. >> It's like though friends don't let friends build data centers just for DR. Yeah, if you're going to build it for something that gives you a competitive advantage, okay. >> But it's interesting with some of the plans that Adam's got for the future, you know, you want to share some of those as far as what you're thinking about for the next few years. >> So future plans for GEI is definitely more cloud growth and minimizing the footprint that we have on premise, making it so that we don't have to have infrastructure at every location, consolidation of all of our data, obviously, going forward, GEI is going to continue growing with data, with videos that were modeling for different damn inspections, levy inspections, we're collecting a lot of data. But the problem is having that data geographically everywhere makes it challenging for future admins, including myself to continue to restore and backup and keep everybody happy. It's a really challenging task to continue supporting. So going forward with consolidating all that data into a central location, i.e. multi cloud environments, or Dell EMC cloud that was announced this week, we have the option for leveraging multi cloud instances, and being able to keep all of our instances alive in the cloud, rather than on premise. >> So you said put it on one location you talking physically or is it some kind of logical mapping that you're doing? >> There'll be logical mapping with some type of caching technology at the off site so that it's ready and available-- >> So a mapping that allows you to recover really fast if you need to, what about as part of that future in the roadmap, analytics on that of backup data? >> So the analytics on in terms of how much backups are going on on a nightly basis-- >> So specifically, are you using that corporate for any other reason? Well, let's see, might be looking at anomalous behavior, doing stuff with with air gaps, and you know, investigating that other DevOps activities. >> It's interesting that you say that because we were talking about a Data Domain having an air gap last night, at an event and the air gap method, making sure that your data domain is protected, it puts it in a right only mode, so that nobody can get into your data domain and actually do any damage to your data. Because you're right, you're backing out. There are anomalies that happen. If those anomalies happen to get into your infrastructure into your data backups, you could technically get ransomware or you know, locked out of your own data. Whereas Data Domain does support air gap technology, allowing you to lock down the system and require two admins before any changes are made to it. So definitely going-- >> Read only, read only. >> I think I heard that. But it's it's a good question with respect to data reuse is that, you know, the use case that Adam is currently using is to use AWS as a disaster recovery location, but the ability to spin up his data within AWS, yes, for the purpose of insurance, being able to access those production copies within AWS. But why not be able to use those for other purposes, such as interrogation of the data that was in them? That's all things that really start to evolve the conversation from what do you do for data protection to what do you do for data management? >> Yeah, so let's use some of the tool chains in live in AWS, say for example, apply some machine intelligence and machine learning and see what we find there, maybe anticipate anomalies or find some things that we didn't know. >> Absolutely, especially when users are dumping large amounts of data, we had an instance where before we started to actually seeing large data dumps when our data started to grow in the first place, we were inspecting levees and models in Colorado, and we had three engineers fill up an entire server of 4k videos, and our nightly backup all of a sudden said, Hey, you just got a huge amount of data change in an instant. Were you expecting this kind of change? If not, you should probably start knocking on someone's door, so we were able to use that analysis really quickly. >> So looking at day three of Dell Technologies World lots of announcements, Robbie, you kind of talked about some of those, you know, cloud enabled data protection becoming a big focus for you guys, I'm curious, Adam, to get your thoughts on some of the announcements. You mentioned the VMware on Dell, a cloud on Dell EMC, what are some things that really kind of piqued your interest as, hey, we're going to have more and more data coming, we've got lots of edge devices, they talked yesterday about the edges coming what did you hear that you thought, awesome, this is really going to be integral part of our strategy going forward? >> Definitely, so one thing that was mentioned was Power Protect, and that has everybody's interest right now. Because having the ability of basically an Avamar system with all flash or a Data Domain with all flash gives you obvious IO advantages in the future, that's probably going to be my next hot topic that I'm very vigorously researching everything out to see if in a couple of years or sooner that's going to fit into GEI's infrastructure and give us more benefits going forward. >> What's your biggest data protection challenge in 2019? >> Our biggest challenge up front was definitely moving from one backup strategy to a new backup strategy and that's from file level backups, only to image based backups, that was one of the biggest challenges, because anytime you lift a backup infrastructure out of production, and put a new one in, you're starting from zero, you can't really start from where you left off, you had to get all of that data, and geographically 43 offices doesn't seem like a lot, but when you're collecting data at all of those locations, that was a challenge, getting everything worked out and getting everything backed up in the first place. >> So you're knocking down that problem. If you're in a private meeting with Rob and his engineering team is there, what's the one thing that he could do to make your life easier? >> One thing he could do to make my life easier-- >> Drop prices-- >> Oh, sorry, then I have nothing else to say. (both laugh) >> Sounds like you-- >> Really, is that what you were going to say? >> So if we could enhance the performance of DD Boost, DD Boost already does a lot of performance benefits for what we do, DD Boost, in essence of what your network performance is, if there was a way of tweaking that on new servers, when you implement it, for example, we acquire companies every now and then we're implementing their strategies for their backups, and we have to start new backups, if there was a better methodology of seeding rather than having to go out physically plug in a hard drive and an NFL storage, make a clone of it and transfer it back. If there was a different method of seeding that technology or those backups, that would make things a little bit easier. >> Get on that. >> I mean, nobody can ever have enough performance and then, as Adam said, the big part of the Power Protect announcement yesterday was, you know, the introduction of, you know, the industry's first all-flash purpose built backup appliance with integrated software capabilities, and an all flash, I think, over the coming years is going to get is going to become a definite option for secondary storage workloads, not only for the straight performance of backup and restore speeds, but also for this huge opportunity around data reuse, and I think that you'll start to see more flash appearing in the data center, not just for production systems, but also for secondary workloads and where you're storing copies of production. >> At the end of the day, it sounds like you're probably quite the hero to all those folks that need making sure they have access to that data because that's what is, as we say, it's Michael Dell said it's inexhaustible, it's gold, that's what drives the business forward, that's what allows you to identify new products and new revenue streams. So we'll say congratulations on being an enabler of the business so far, we appreciate you guys sharing what GEI is doing and Rob, we appreciate your insights as well. We thank you for spending some time with us on theCube. >> Thank you very much. >> Oh, our pleasure. For Dave Vellante, I'm Lisa Martin. You're watching theCube live, Dell Technologies World 2019 day three of theCubes coverage continues in just a moment. (upbeat music)

(soft electronic music) >> Announcer: Live from Vancouver, Canada, it's theCUBE. Covering OpenStack Summit North America 2018. Brought to you by Red Hat, the OpenStack Foundation, and it's ecosystem partners. >> Welcome back, I'm Stu Miniman here with my cohost John Troyer and you're watching theCUBE's exclusive coverage of OpenStack Summit 2018 in Vancouver. Happy to welcome you back to the program, off the keynote stage this morning, Mark Shuttleworth, the founder of Canonical. Thank you so much for joining us. >> Stu, thanks for the invitation. >> Alright, so you've been involved in this OpenStack stuff for quite a bit. >> Right, since the beginning. >> I remember three years ago we were down in the other hall talking about the maturity of the platform. I think three years ago, it was like this container thing was kind of new and the basic infrastructure stuff was starting to get, in a nice term, boring. Because that meant we could go about business and be on the buzz of there's this cool new thing and we're going to kill Amazon, kill VMware, whatever else things that people thought that had a misconceived notion. So bring us forward to where we are 2018, what you're hearing from customers as you look at OpenStack and this community. >> Well, I think you pretty much called it. OpenStack very much now is about solving a real business problem, which is the automation of the data center and the cost parody of private data centers with public data centers. So I think we're at a time now where people understand the public cloud is a really good thing. It's great that you have these giant companies dueling it out to deliver better quality infrastructure at a better price. But then at the same time, having your own private infrastructure that runs cost-effectively is important. And OpenStack really is the only approach to that that exists today. And it's important to us that the conversation is increasingly about what we think really matters, which is the economics of owning it, the economics of running it, and how people can essentially keep that in line with what they get from the public cloud providers. >> Yeah, one of the barometers I use for vendors these days is in this multi-cloud world, where do you sit? Do you play with the HyperScalers? Are you a public cloud denier? Or, like most people you're, most people are somewhere in-between. In your keynote this morning, you were talking a bit about all of the HyperScalers that use your products as well as-- >> Ubuntu is at the heart of all of the major public cloud operations at multiple levels. So we see them as great drivers of innovation, great drivers of exposure of Ubuntu into the enterprise. We're still, by far, the number one platform used in public cloud by enterprises. It's hard to argue that public cloud is testing Dev now. It really, really isn't and so most of that is still Ubuntu. And now we're seeing that pendulum swing, all of those best practices, that consumption of Ubuntu, that understanding of what a leaner, meaner Enterprise Linux looks like. Bringing that back to the data center is exciting. For us, it's an opportunity to help enterprises rethink the data center to make it fully automated from the ground up. OpenStack is part of that, Kubernetes is part of that and now the cherry on top is really AI where people understand they have to be able to do it on public cloud, on private infrastructure and at the Edge. >> Mark, I wanted to talk about open source. Marketing open source, for a minute. We are obviously here, we're part of an open source community. Open source, defacto, has won the cloud technology stack wars. So there's one way of selling OpenStack where you pound on open a lot. >> I'm always a bit nervous about projects that put open. It sounds like they're sort of trying to gloss over something or wash over something or prove a point. They shouldn't have to. >> There's one about the philosophy of open source, which certainly has to stay there, right. Because that's what drove the innovation but I was kind of impressed about on the stage today, you talked about the benefits. You didn't say, well the venture's open. You said, well, we're facilitating these benefits. Speed to market, cost, et cetera. Can you talk about your approach, Canonical's approach to talking about this open source product in terms of its benefits? >> Sure, look, open source is a license. Under that license, there's room for a huge spectrum of interest and opinions and approaches. And I'd say that I certainly see an enormous amount of value in what I would call the passion-based open source story. Now, OpenStack is not that. It's too big, too complicated, to be one person's deep passion. It really isn't. But there's still a ton of innovation that happens in our world, across the full spectrum of what we see with open source, which is really experts trying to do something beautiful and elegant. And I still think that's really important in open source. You also have a new kind of dimension, which is almost like industrial trench warfare with open source. Which is huge organizations leveraging effectively their ability go get something widespread, widely adopted, quickly and efficiently by essentially publishing it as open source. And often, people get confused between these two ends of the spectrum. There's a bunch in between. What I like about OpenStack is that I think it's over the industrial trench warfare phase. You know, you just don't see a ton of people showing up here to throw parties and prove to everyone how cool they are. They've moved on to other open source projects. The people who are here are people who essentially have the real problem of I want to automate my data center, I want to have, essentially, a cloud that runs cost-effectively in my data center that I can use as part of a multi-cloud strategy. And so now I think we're in to that sort of, a more mature place with OpenStack. We're not either sort of artisan or craftsmen oriented, nor are we a guns blazing brand oriented. It's kind of now just solving the problems. >> Mark, there's still some nay-sayers out in the marketplace. Either they say that this never matured, there's a certain analyst firm that put out a report a couple of months ago that, it kind of denigrated what's happening here. And then there's others that, as you said, off chasing that next big wave of open source. What are you hearing from your customers? You've got a good footprint around the globe. >> So that report is nonsense, for a start. They're always wrong, right. If they're hyping something, they're wrong and if they're dissing something then they're usually wrong too. >> Stu: They have a cycle for that, I believe. (chuckling) >> Exactly. Selling gold at the barroom. Here's how I see it. I think that enterprises have a real problem, which is how do they create private cloud infrastructure. OpenStack had a real problem in that it had too many opinions, too many promises. Essentially a governing structure not a leadership structure. Our position on this has always been focus on the stuff that is really necessary. There was a ton of nonsense in OpenStack and that stuff is all failing. And so what? It was never essential to the mission. The mission is stand up a data center in an automated way, provide it, essentially, as resources, as a service to everybody who you think is authorized to be there, effectively. Segment and operate that efficiently. There's only a small part of OpenStack that was ever really focused on that. That's the stuff that's succeeding, that's the stuff we deliver. That's the stuff, we think very carefully about how to automate it so that, essentially, anybody can consume it at reasonable prices. Now, we have learned that it's better for us to do the operations almost. It's better for us actually to take it to people as a solution, say look, explain your requirements to us then let us architect that cloud with you then let us build that cloud then let us operate that cloud. Until it's all stable and the economics are good, then you can take over. I think what we have seen is that you ask every single different company to build OpenStack, they will make a bunch of mistakes and then they'll say OpenStack is the problem. OpenStack's not the problem. Because we do it again and again and again, because we do it in many different data centers, because we do it with many different industries, we're able to essentially put it on rails. When you consume OpenStack that way it's super cheap. These aren't my numbers, analysts have studied the costs of public infrastructure, the cost of the established, incumbent enterprise, virtualization solutions and so on. And they found that when you consume OpenStack from Canonical it is much, much cheaper than any of your other options in your own private data center. And I think that's a success that OpenStack should be proud of. >> Alright, you've always done a good job at poking at some of the discussions happening in the industry. I wouldn't say I was surprised but you were highlighting AI as something that was showing a lot of promise. People have been a little hot and cold depending on what part of the market you're at. Tell us about AI and I'd love to hear your thoughts in general. Kubernetes, Serverless, and ask you to talk about some of those new trends that are out there. >> Sure, the big problem with data science was always finding the right person to ask the right question. So you could get all the data in the world in a data lake but now you have to hire somebody who instinctively has to ask the right question that you can test out of that data. And that's a really hard problem. What machine learning does is kind of inverts the problem. It says, well, why don't we put all that data through a pattern matching system and then we'll end up with something that reflects the underlying patterns, even if we don't know what they are. Now, we can essentially say if you saw this, what would you expect? And that turns out to be a very powerful way to deal with huge amounts of data that, previously, you had to kind of have this magical intuition to kind of get to the bottom of. So I think machine learning is real, it's valuable in almost every industry, and the challenges now are really about standardizing underlying operations so that the people who focus on the business problems can, essentially, use them. So that's really what I wanted to show today is us working with, in that case it was Google, but you can generalize that. To standardize the experience for an institution who wants to hire developers, have them effectively build machine-driven models if they can then put those into production. There's a bunch of stuff I didn't show that's interesting. For example, you really want to take the learnings from machine-learning and you want to put those at the Edge. You want to react to what's happening as close to where it's happening as possible. So there's a bunch of stuff that we're working on with various companies. It's all about taking that AI outcome right to the Edge, to IOT, to Edge Cloud but we don't have time to get in to all of that today. >> Yeah, and Ubuntu is at the Edge, on the mobile platform. >> So we're in a great position that we're on the Cloud. Now you see what we're doing in the data center for enterprises, effectively recrafting the data center has a much leaner, more automated machine. Really driving down the cost of the data center. And yes, we're on the higher-end things. We're never going to be on the LightBulb. We're a full general-purpose operating system. But you can run Ubuntu on a $10 board now and that means that people are taking it everywhere. Amazon, for example, put Ubuntu on the DeepLens so that's a great example of AI at the edge. It's super exciting. >> So the Kubernetes, Serverless-type applications, what are your thinkings around there? >> Serverless is a lovely way to think about the flow of code in a distributed system. It's a really nice way to solve certain problems. What we haven't yet seen is we haven't seen a Serverless framework that you can port. We've seen great Serverless experiences being built inside the various public clouds but there's nothing consistent about them. Everything that you invest in a particular place is very useful there but you can't imagine taking that anywhere else. I think that's fine. >> Stu: Today's primarily Lando. >> And I think the other clouds have done a credible job of getting there quickly. But kudos to Amazon for kind of pioneering that. I do think we'll see generalized Serverless, it just doesn't exist at the moment and as soon as it does we'll be itching to get it into people's hands. >> Okay, yeah? >> Well, I just wanted to pull out something that you had said in case people miss it, you talked about managed OpenStack. And that, I think, managed Kubernetes has been a trend over the last year. Managed OpenStack now. Has been trans-- >> With these complex pieces of infrastructure, you could easily drown in learning it all and if you're only ever going to do one, maybe it makes sense to have somebody else do it for a while. You can always take it over later. So we're unusual in that we will essentially standup something complex like an OpenStack or a Kubernetes, operate it as long as people want and then train them to take over. So we're not exclusively managed and we're not exclusively arms-length. We're happy to start the one way and then hand over. >> I think that's an important development, though, that's been developing as the systems get more complicated. One UNIX admin needs a whole new skill set or broader skill set now that we're orchestrating a whole cloud so that's, I think that's great. And that's interesting. Anything else you're looking forward to, in terms of operation models. I guess we've said, Ubuntu everywhere from the edge to the center and now managed, as well. Anything else we're looking at in terms of operators should be looking at? >> Well, I think it just is going to stay sort of murky for a while simply because each different group inside a large institution has a boundary of their authority and to them, that's the edge. (chuckling) And so the term is heavily overloaded. But I would say, ultimately, there are a couple of underlying problems that have to be solved and if you look at the reference architectures that the various large institutions are putting out, they all show you how they're trying to attack these patterns using Ubuntu. One is physical provisioning. The one thing that's true with every Edge deployment is there are no humans there. So you can't kind of Band-Aid over the idea that when something breaks you need to completely be able to reset it from the ground up. So MAAS, Middle as a Service, shows up in the reference architectures from AT&T and from SoftBank and from Dorich Telecom and a bunch of others because it solves their problem. It's the smallest piece of software you can use to take one server or 10 servers or 100 servers and just reflash them with Windows or CentOS or whatever you need. That's one thing. The other thing that I think is consistently true in all these different H-Cloud permutations or combinations is that overhead's really toxic. If you need three nodes of overhead for a hundred node OpenStack, it's 3%. For a thousand node OpenStack, it's .3%. It's nothing, you won't notice it. If you need three nodes of OpenStack for a nine node Edge Cloud, well then that's 30% of your infrastructure costs. So really thinking through how to get the overhead down is kind of a key for us. And all the projects with telcos in particular that we're working, that's really what we bring is that underlying understanding and some of those really lightweight tools to solve those problems. On top of that, they're all different, right. Kubenetes here, Lixti there, OpenStack on the next one. AI everywhere. But those two problems, I think, are the consistent things we see as a pattern in the Edge. >> Alright, so Mark, last question I have for you. Company update. So last year we talked a little bit about focusing, where the company's going, talked a bit about the business model and you said to me, "Developers should never have to pay for anything." It's the governance people and everything like that. Give us the company update, everything from rumors from hey, maybe you're IPO-ing to what's happening, what can you share? >> Right, so the twin areas of focus, IOT and cloud infrastructure. IOT continues to be an area of R and D for us so we're still essentially underwriting an IOT investment. I'm very excited about that. I think it's the right thing to be doing at the moment. I think IOT is the next wave, effectively, and we're in a special position. We really can get down, both economically and operationally, into that sort of small itch kind of scenario. Cloud, for us, is a growth story. I talked a little bit about taking Ubuntu and Canonical into the finance sector. In one year, we closed deals with 20% of the top 20 banks in the world to build Ubuntu base and open infrastructure. That's a huge shift from the traditional dependence exclusively on VMware Red Hat. Now, suddenly, Ubuntu's in there, Canonical's in there. I think everybody understands that telcos really love Ubuntu and so that continues to grow for us. Commercially, we're expanding both in Emir and here in the Americas. I won't talk more about our corporate plans other than to say I see no reason for us to scramble to cover any other areas. I think cloud infrastructure and IOT is plenty for one company. For me, it's a privilege to combine that kind of business with what happens in the Ubuntu community. I'm still very passionate about the fact that we enable people to consume free software and innovate. And we do that without any friction. We don't have an enterprise version of Ubuntu. We don't need an enterprise version of Ubuntu, the whole thing's enterprise. Even if you're a one-person startup. >> Mark Shuttleworth, always a pleasure to catch up. Thank you so much for joining us. >> Mark: Thank you, Stu. >> For John Troyer, I'm Stu Miniman. Back with lots more coverage here from OpenStack Summit 2018 in Vancouver. Thanks for watching theCUBE. (soft electronic music)

>> Man: Live, from Boston, Massachusetts, it's The Cube, covering Red Hat Summit 2017, brought to you by Red Hat. >> Welcome back to The Cube's coverage of the Red Hat Summit, here in Boston, Massachusetts. I'm you're host Rebecca Knight along with my co-host Stu Miniman. We're joined by Ashesh Badani. He is the Vice President and General Manager of OpenShift here at Red Hat. Thanks so much, Ashesh. >> Thanks for having me on yet again. >> Yes, you are a Cube veteran, so welcome back. We're always happy to talk to you. You're also an OpenShift veteran. You've been there five years, and before the cameras are rolling you were talking about how we really are at a tipping point here with OpenShift, and we're seeing a widespread adoption and embrace of containers. Can you share the context with us. >> Sure, so I think we've spent a fair amount of time in this market talking about how important containers are, the value of containers, DevOps, microservices. I think at this Red Hat Summit, we've spent a fair amount of time trying to ensure that people understand one containers are real, in terms of, you know, adoption level that we're seeing. They're being run in production and at scale. And across a variety of industries, right. So, just at this summit we've had over 30 customers from across the world, across industries like financial services, government, transportation, tech, telco, a variety of different industries talking about how they've been deploying and using containers. At our keynotes we had Macquarie Bank from Australia, Barclay's Bank from the U.K. We had United Health slash OPTUM. All talking about, you know, mission critical applications, how their developers running applications, both new applications, right, microservice-style applications, but also existing legacy applications on the OpenShift platform. >> Ashesh, I've been watching this for a few years, we've talked to you many times, we talked about containers. Maybe I'm oversimplifying it but let me know. It feels like OpenShift is your delivery mechanism to take some things that might be hard if I tried to do them myself and made it a lot simpler. Kind of give like Red Hat did for Linux, I have containers, I have Kubernetes, I have OpenStack, and all three of those I didn't hear a ton at the show, I heard a lot about OpenShift and the OpenShift family because underneath OpenShift are those pieces. Am I gettin' it right, or there's more nuance you need-- >> Great observation, great observation, yeah, and we're seeing that from our customers, too. So, when they're making strategic choice, they're talking about, you know, how can I find the container platform to run at scale. When they make their choice, all they're thinking about well what's the existing, you know, development tools I've got. Can it integrate with the ones that I have in place. What's the underlying infrastructure they can run on. OpenStack of course is a great one, right. We have many customers, Santander, BBVA Bank are just two examples of those, but then also, can I run the OpenShift structure in a hybrid cloud, or I guess what we're calling a multi-cloud world now. Amazon, Google, Asher, and so on. But actually interestingly enough we made some announcements with Amazon as well at the show with regard to making sure some AWS service are able to be integrated into the OpenShare platform. So, we find customers today finding a lot of value in the flexibility of the deployment platforms they have in place, integration with various developer tools. I think my colleague Harry Mower was on earlier talking about OpenShift.io, again, you know, super interesting, super exciting now it's been from our perspective with regard to giving developers more choice. And in addition to that, you know, the other parts of the portfolio, right, going to your point, earlier. We're trying to attach that increasingly as options for customers around OpenShift. Storage is a great example. So we announced some work we've doing with regard to container storage with our classified system for OpenShift. >> So you're talking about simplification and that does seem to be a real theme here. Once you've solved that problem, what's next, what are some of the other customer issues that you need to resolve and help them overcome and make their lives easier? >> Yeah, so, the rate of change in technology, as you well know, you've been following this now for a while is just dramatic, right. I think it's probably faster than we've ever seen in a long, long time. I was having a conversation with a large franchise customer with regard to, you know, just as we feel like, you know, we're getting people to adopt Hadoop, everyone seems to have moved on to Spark. And now we're on Spark and people are talking about, oh, maybe Flink is next. Now that we get to Flink, now they're saying AI and ML is next. It's just like, well, where does this stop, right. So I don't think it stops. The question is, you know, at what point of time do you sort of jump in. Embrace the change, right, that's sort of what Devops all about right, continuous change, you know, embrace it, be able to evolve with it, fail fast, pick yourself up, and then have the organization be in this sort of continuous learning, this kaizen environment. >> Yeah, Ashesh, from day one of the keynote talked about the platforms and you know Red Hat Enterprise Linux was kind of the first big platform that can live a lot of environments. Seems OpenShift is a second platform, and the scope of it seems to be growing. We talked to Harry about the OpenShift.io. He alluded to the fact that we might see expansion into the family there. What is, you said that innovation, and you know change keeps growing. What's the boundaries of what OpenShift's going to cover. Where do you see it today and where's the vision go moving forward? >> Yeah, so (laughs) great question, a double-edged sword right. Because on the one hand of course we want to make sure OpenShift is a foundation for doing a lot of stuff. But then there's also the Linux philosophy. Do one thing, do it well, right. And so there's always this temptation with regard to keeping on wanting to take new things on, right, I mean for a long time people have said, hey, why aren't we in the database business? You know, why aren't you doing more? Well the question is, you know, how many things can we do well? Because anything we commit to, as you well know, Red Hat will invest significant amount of engineering effort upstream in the community to help drive it forward, right. We've done that on Linux container front. We're doing that in Kubernetes. Obviously we do that with RHEL, we've done that Jboss technologies. So, we're very, very cognizant of making sure that we provide an environment and basically an ecosystem around us that can grow and be able to attach the momentum we have in place. As a result of that we announced the container health index at this conference, right. Mostly because, you know, there's just no way for one company to provide all the services that are possible, right. So to be able to grade applications that come in, be able to sort of give customers confidence that, you know, these can be certified and work in our environment, and then be able to kind of expand out that ecosystem is going to be really important going forward. >> Yeah, Ashesh that's an interesting one, the container health index. I'm going to play with the term there. What's the health of the container industry there. We at The Cube at DockerCon a couple weeks ago had a couple of Red Hatters on the program. There was kind of a reshuffling, you know. The Moby project, open source, we've got Docker CE, Docker EE, Docker actually referenced, you know, Fedora and CentOS and RHEL as you know, something that they did similar to but, what's your take on the announcements there? >> Sure, sure, I'll probably butcher this quote tremendously, but it was Mark Twain or someone said, "The rumors of my whatever are greatly exaggerated," so. You know, there's always, you know, some amount of change that sort of happens, especially with new technology, and you've got so many players sort of jumping in, right. I mean of course there's Docker Inc. There's Red Hat but there's, you know, Google and IBM and Microsoft and Amazon, and there's a lot of companies, right, that all look at this as a way of advancing the number of workloads that come onto their platforms. You know, we've seen some of the challenges, if you will, that Docker Inc. has been facing as well as the great work it's been doing to help drive the community forward, right. Those are both interesting things. And they've got a business to run. We've announced, we've seen the changes announced with regard to some of the renaming and Moby, and I think there's still a lot more detail that need to be fleshed out. And so I, we're going to wait for the dust to settle. I think we want to make sure our customers are confident. We've had this conversation with many customers that whatever direction that, you know, we go in, we will continue supporting that technology. We will stand behind it. We will make sure we're putting upstream engineers to help drive the community that will provide the greatest value for customers. >> Ashesh, you're one of the judges for the Innovation Awards here. Can you tell us a little bit more about the secret sauce that you're looking for. First of all, how you choose these winners, and what it is you're looking for. >> Yeah, so I'm really proud of the work I do to help support the judging of the Innovation Awards. You know, I think it's a fantastic thing we do to recognize, I was telling Stu earlier, you know we could probably have done a dozen more awards, right, the entries that are coming in are just fantastic. We try to change up the categories a little bit every year to kind of match with the changes in industry, like for example, you know, DevOps, Macquarie Bank was a great example of enterprise transformation. You know, they had this great line in their keynote right, where their ambition I think really impressed a lot of the judges with regard to, hey our competition is not necessarily the other financial service companies, it's the last app you opened. That's a remarkable thing, right. Especially for an existing traditional financial services company, you see. So, I think what we look for is scope, ambition, and vision, but also how you're executing against it, and what demonstrable results do you have for that. And so, you probably saw that, as, you know, we talked about all the various innovation awards we gave, right, whether it's Macquarie Bank or, you know, British Columbia Empower Individuals, right, so the whole notion of celebrating the impact of individual, and create an exchange for them to engage with the wider civic body. That's really important for us. >> Ashesh, one of the innovation award-winners OPTUM we talked to, they're an OpenShift customer. They're really excited with the AWS announcement. We've been chewing on it, talking to a lot of people. We think it's the most significant news coming out of the show. As you said, there's certain details that need to bake out when we look at some of these things. By the time we get to AWS Reinvent we'll probably understand a little bit some of the pricing and, you know, some of the other pieces, and it'll be there, but, you know, bring us from your viewpoint, from an OpenShift standpoint what this means to kind of an extension of the product line and your customers. >> Yeah, so, we've got, at least at this show you had over 30 customers presenting about their use of OpenShift. And we typically find them deploying OpenShift in a variety of different environments including AWS. So for example Swiss Rail, right, obviously out of Switzerland, is taking advantage of, you know, running it in their own data center, taking advantage of AWS as well. When they're doing that they want to make sure that they can consume services from Amazon. Just as if they were running it on Amazon, right. They like the container platform that OpenShift provides, and they like the abstraction level that it puts in place. Of course they have different choices, right. They can choose to run it on OpenStack, they can choose to run OpenShift in some other public cloud provider, yet there are many services that Amazon's releasing that are extremely interesting and value that they provide to their customers. By being able to have relationship with Amazon, and have an almost native experience of those services with regard to OpenShift, regardless of the underlying infrastructure OpenShift runs, it is a very powerful value proposition, definitely for our customers. It's a great one for Amazon because it allows for their services to be used across a multitude of environments. And we feel good about that because we're creating value for our customers, and of course not precluding them from using other services as well. >> I'm wondering if you could shed a little light on the financials, and how you think about things. I mean, you made this great point about the banks saying our competition is the last app you opened. How do you think, with OpenShift, which is free, how do you view your competition, and how do you think about it in terms of the way companies are making their decisions about where they're putting their money in IT investments. >> Right, so OpenShift isn't free, so I'll just make sure-- (all laugh) >> OpenShift.io >> OpenShift.io, I'm sorry, I'm sorry, yes. >> So, consider OpenShift.io as a great gateway into the OpenShift experience, right. It's a cloud-based web environment allows you to develop in browsers, allows you some collaboration with other developers. There's actually a really cool part of the tech, I don't know if Harry talked about right, which is, we almost have, almost machine-learning aspect part of it, you know, that's in play with regard to, you know, if this is the code you're using, here are what other users are doing with it, making recommendations, and so on, so it's a really modern integrated, you know, development environment that we're sort of introducing. That of course doesn't mean that customers can't use existing ones that they have in place. So this is just giving customers more choice. By doing that, we're basically expanding the span of options the customers have. We introduced something called OpenShift Application Runtimes also at this conference, which is supporting existing Java languages or tools or frameworks, right, whether it's Jboss, EAP, Vortex, WildFly, Spring Boot, but also newer ones like No-JavaScript, right, so again, in the spirit of, let's give you choices, let's have you sort of use what you most want to use, and then from our perspective, right, you know, we will create value when it's been deployed at scale. >> Ashesh, before the event at the beginning of it you guys run something called OpenShift Commons. There's some deep education and a lot of it very interactive. I'm curious if there's anything that's kind of surprised you or interesting nuggets that you got from the users. Either stuff that they were further ahead or further behind, or just something that's grabbin' their attention that you could share with our users. >> Well, what I've been really happy to see with the OpenShift Commons is, well, this is a couple things, right. One is we try our best to make it literally a community event, right, so we call it OpenShift Commons but it is a community event. So in the past and even now, we have providers of technologies, even though they might compete with Red Hat and OpenShift available to talk to. Customers, users of our technology, right, so we want it to be an open, welcoming environment for various providers. Second, we're seeing more and more customers wanting to come out and share their experiences, right. So at this OpenShift Commons, I think we had maybe over 10 customers present on, you know, how they were using OpenShift, and sharing with other customers. Number three, this really attracts other customers. I just had a large financial services institution come and say, you know, we attended OpenShift Commons for the first time. This is a fantastic community. How can we become a part of this? You know, get us involved. There's no cost to join, right, it's free and open, and now our numbers are pretty significant. And then when that's in place, right, the ecosystem forms around it. Now, so we have several different ISVs, global system integrators who are all sort of, you know, coalescing, to provide additional services. >> Ashesh, thanks so much for your time, we appreciate it. It's always a pleasure to have you on the program. >> Ashesh: Thanks again, see you all next time. >> I'm Rebecca Knight for Stu Miniman. There'll be more from the Red Hat Summit after this. (relaxed digital beats)