 Live from Las Vegas, it's theCUBE, covering Dell Technologies World 2018. Brought to you by Dell EMC and its ecosystem partners. Welcome back to Vegas, everybody. We're rocking, we are rocking Dave Vellante here with Keith Townsend. This is theCUBE, the leader. Get into it. Come on, let's check the coverage. We in the club, we are in the club. The chads are here, Chad Dunn, Chad Sackage. Chad Dunn is the CEO of Product Management and Marketing at Dell EMC, and Chad Sackage needs no introduction, although, new role with Pivotal. Awesome. It's exciting, man. It's great to be back. Like, come on, you know, some things change, some things stay the same. It's always good to be on theCUBE. So tell us about the new role. Let's start there. I know you've talked a lot about it, but you haven't with me, so. Yeah, so, in a nutshell, as I was trying to think, what do I do next in my career? You know, we had built amazing things in the Converged Platform and Solutions Division, VxRail, Massive Success. Those things moving into the parts of Dell EMC for more scale and velocity, which is simple. Like, if you imagine the future of tomorrow, you'd go and say, what percentage of infrastructure is going to be hyper-converged? Answer, a lot. And it's going to need to have a velocity that's very similar to a server, because what percentage of servers are going to be HCI? Answer, a lot. And so it was a very natural kind of time to go and say, how do we optimize this thing? And then that gave me a weird, unique, once-in-a-lifetime moment where I could go and say, what do I want to do? I could, my wife said, I'm telling you a long answer and you probably want the short one. My wife said- You don't know any other kinds. Yeah, this is past deals. Chad, you've been on the road for 13 years. Your children are now 12 and 14. They're going to be here in the nest for like another four years. Take time off. I'll go out to work. You be a stay-at-home dad. That was actually like option A. Option B was there's so much cool stuff going on in the ecosystem. Join a startup, do a CEO gig, whatever. And then stay in the family and ton of support from Michael and from Jeff Clark and from Pat Gelsinger and Rob Me. And there was like, do this at Dell EMC, do this at VMware, do this at Pivotal. And what I realized was the Pivotal thing gave me the opportunity to do the startup like thing, discover some new parts of my own career. So move up the stack and do one thing that I've always done, which is be at the intersection of the companies. Because PKS is fundamentally an effort that is 50-50, VMware and Pivotal. Just like VxRail is a 50-50 VMware Dell EMC effort. So it was the obvious choice. And then I had to have that uncomfortable discussion with my wife that said, unfortunately, sweetheart, back on the road, she said, fine, but at least take one month off before you go from one thing to the other. We went to Hawaii, surfed, it was awesome. You bring the kids? Oh yeah, beautiful, it was awesome. But in any case, in the same way that when we started VxRail, we were like, how do we go from a market where we're currently not the leader and quickly accelerate, become number one in a two-year period? And that requires running fast and iterating. The same thing goes with PKS. PCF and PAS is number one for that universe, but we're not currently number one for the enterprise container distribution. So that's okay, I like that. Now I'm determined and stubborn to make sure that PKS is the best enterprise Kubernetes and container platform. And Chat D, you were talking off camera about the interest in VxRail. Sounds like it's off the charts. Absolutely, I mean, ridiculous number of customer meetings that we have here at the show this week. I think it's over 200 customer meetings just on VxRail and VxRack SDDC, the VMware-aligned hyperconverged stack. And more and more on Pivotal PCF and PKS. Yeah, so let's talk about that. You got the guys that are sort of born cloud native and the guys that are trying to transform. They need infrastructure to help them do both. They need partnerships, so lay it out for us. So Keith, you and I have gone on Twitter and talked about this. There's this nature amongst the IT ecosystem where everybody wants the answer to be A or B. Yes, we do. Right, A or B? Yes. Which bucket? This is the show. He sucks, he is awesome. He sucks. And, you know, the bait's raged about, you remember the era of Docker is going to destroy VMware? You remember that? I remember that. It seems like just yesterday. Because it was just yesterday. But what's happened now is everyone's realized that's stupid, that the reality is that VMs, kernel-mode VMs and containers are going to coexist. And in fact, the majority of containers are actually going to be deployed on kernel-mode hypervisor. Netflix's biggest story is optimizations from AWS. They're able to save tons of money by running containers inside of VMs. Yeah, absolutely. You know, I was laughed at a couple of years ago when I said, you know what? Containers and VMs go together like peanut butter and jelly, it does. It does. And so, look, does it change what people want from the kernel-mode virtualization layer? Yeah. So, you know, things like DRS that are really important if all you do is a kernel-mode VM is less important when resource management is done by something like Kubernetes. But that's a refinement. And so what we're trying to do now is now that everyone's gotten over the emotion and what I call the barfights, where you're getting into stupid arguments that are not about something that matters. And now people are getting down to the brass tacks of how do I make this go? They're realizing I'm going to use off-prem and on-prem. I'm going to have kernel-mode VMs and I'm going to have containers. How do I make that work? How do I build a hybrid model that will work for both of those scenarios? And then, frankly, our job as IT practitioners and the vendor ecosystem is to make it as easy as we can. Well, you guys know this better than I do. People want to use existing processes and procedures. They don't want to throw that stuff out. I mean, I remember big data in Hadoop that the killer application was SQL, right? I mean, even in the blockchain world now, everybody's talking about writing in JavaScript, right? You got expertise built up. You also throw that away. No, and look, I think when you look at the people who are trying to deploy containers on-premises, they don't want to worry about the infrastructure, right? They want to look at the new, play with the new cool things. They want to play with Kubernetes. They want to play with containers of service. They don't want to talk about, okay, well, what infrastructure do I need? How do I make those choices? They want something that is very much automated and very much scale out so it can react the same way that their application does. So let's talk about that. Let's talk about VxRail, Kubernetes, PKS. If I'm a cloud native guy, I don't care about infrastructure. But there has to be infrastructure. So where's the meeting of that conversation? Dell Technologies runs best on Dell Technologies. So in, again, I'm going to try to force myself to give short answers. So not natural for me. I'm sorry, fellas. When Pivotal engages with a customer, we go and we say, we give you a platform, PAS, PKS, and the function service, and they say, what should I run it on? And the first answer that comes out of someone's mouth is, it doesn't matter. You can run it on any cloud you want. Which is true on one level. But then if you look at our on-premises projects, the thing that's the biggest holdup is infrastructure that is too rigid, too slow, doesn't work right, is busted, and they're like, damn it, if I want to focus my energies elsewhere, I have to have a base stack that is just easy and done, right? So help break up the long chat answers. One argument is, you know what, just give someone a 128 gig VM, a bunch of VCPUs, and that simplifies the infrastructure. Where does that break? It breaks immediately when someone says, I need to add more total compute or storage or network or memory to my Kubernetes pod. Kubernetes goes, great, I'd like to basically make the cluster bigger because I've got this resource demand. Then it looks down and says, infrastructure, are you there? And if the answer is no, it's like womp, womp, right? So look, what we've managed to do is we've managed with VxRail to go and say we've made an easy button based off of the customer standard, which is the VMware stack. It's not only something they can count on, they can easily add it. So if they want to add raw compute storage or network, it also adds in small increments so you don't have to have a giant block of infrastructure to go in, so you can grow your Kubernetes cluster, you can grow your physical infrastructure. Simple, easy, done. And the biggest part is that Kubernetes makes deploying containers easy. However, PKS makes deploying and versioning Kubernetes easy. VxRail makes deploying and versioning the vSphere stack easy. Easy plus easy plus easy equals easy. So it's like a quasi elastic beanstalk here? Plastic beanstalk, okay. Is that fair or maybe a plastic beanstalk? You can hold its shape. Elastic beanstalk is a pass, right? But the long and short of it is that if you get the abstraction that you need, kernel mode VM or container, the container is in a VM, if the whole stack is prescriptive and easy and works, then you can redeploy time, money, and resources on the things that matter. And that pivotal ready architecture, which is PCF on VxRail is that easy button on-prem. So Chad, the production staff may regret me asking this question. But I have to know this. You're known in the industry for these blog posts talking about face melting technology. What is face melting about PKS and VxRail? Give me some classic Chad. I'll give you face melting. Face melting to someone who's looking at a container platform and you're looking at Kubernetes, is that without them knowing, without them knowing or doing anything, the Bosch part of what PKS does is basically doing updates like four times a day, blowing up the entire environment and recreating it, and no one has touched a damn thing. Step one, the next thing that's face melting is that their ability to update the infrastructure can be done at tens of thousands of sites via API calls. So like I'll give you another fascinating example, Kubernetes is generally thought of as mostly a data center thing. We've had fascinating interest from retail and other use cases where they're like, look, I get it, I want a Kubernetes that I could deploy in a store. And then you go and say, well, do you have a great DevOps practice in the store in Topeka, Kansas? The answer is no. But if I say I can basically drive all of the platform updates, including the infrastructure at thousands of stores around the globe, that's pretty face melting. No one else can do that. Exactly, and look, we see lots of pockets of cloud native popping up in accounts and a lot of times IT doesn't even know where they're at. These are things that are going to go from a line of business, all of a sudden become production, have to become production and IT needs a way to manage that. Rail gives them a way to go in and manage that infrastructure at a scalable way and move it from a line of business into production. I'll give you another face melting. Do you mind? I'm not calling the shots. Is your face okay? Yeah, my face is getting there. I want to see it like melt at me and just melt it. People have asked me, is that a good thing? And yeah, it's a great thing. So we're talking about a particular customer. I don't know if we can name them. Can we name them? I don't think we could, I haven't asked. Okay, so we'll leave them in there. Financial services. Financial services. And basically they use the PCF stack on VxRail and they're currently using it for pre-prod. Exactly, so they're building all the testing applications to test their classic applications that are running on VxBlock. So they've got a production environment that's like big classic VxBlock, also my former baby. And so, and I love all my children equally, right? What they are finding is that the simplicity of the PCF on the VxRail model is so wonderful and fast and great. But when they want to try to do a capacity add on a VxBlock or to do an update like an RCM, it's a lot harder here than it is over here, right? I guarantee at that customer what they're eventually going to discover is this has been awesome. We're going to keep using VxBlock for something else but we're not going to deploy PCF, Paz, and PKS on a VxBlock. Exactly, and this is going to trigger refactoring of all those workloads to say, can I refactor these to be cloud native, right? If I can iterate my testing that quickly, can I iterate my production applications that quickly? And the ROI on that refactoring is blank. Like, no, no, it is like a thousand to one. So again, this is a very hard thing to imagine. Talk about business impact. So I'll give you, I'll give you. Not financial, but. I'll give you one example that I'm so happy that they actually posted this to YouTube because the customer's voice in this is incredible. If you YouTube from zero to 12 million, T-Mobile, okay? So this is not me saying it. You can go and you can see it themselves. T-Mobile basically, and to all your T-Mobile subscribers out there, anyone you guys are using T-Mobile? I use T-Mobile, so in any case. They have a single giant Java app that has a thousand functions in it, right? So just imagine one app sitting on a app server, like WebSphere or whatever, and inside that app, there's a thousand API calls, functions and purposes, right? And because it's so big and monolithic, but this is critical. This is the thing that like runs their ordering systems and like subscriber functions. Like it's the heart of the business that any time that they needed to update it to do like a patch would take seven months. If they wanted to scale it, so like the iPhone launch is coming up, we need to get like three times as much capacity to handle all these iPhone orders. In September, it would take them seven months of planning, work, et cetera, et cetera. Everyone goes like, I can visualize that, right? They took one function, just one and pulled it out and they said, we're gonna do a project, we're gonna take this function called get usage, which as you can imagine basically pulls up the subscriber's usage data and we're gonna make it into a small microservice and we're gonna run it on a pass, okay? Within five months, that function was getting used 12 million times a day and they were able to do three CVE updates. So in other words, a critical vulnerability patch comes out, they were able to do it in real time. They have eight platform operators, just eight that are supporting 5,000 developers, sorry, 500 developers, eight, 500. Now, if you look at that and go, what does it mean for them? Well, they reduced the number of outages by almost 90%. The time for an outage went down by 63%. The developers and the DevOps team are now happy because this thing auto-scales itself. Ching-ching. Ching-ching-ching, right? All right, dudes, we gotta go. Chad Squared, thank you so much for coming on, you guys. You okay? I'm good. Your face is melting. Your face melted? I have water. You're gonna splash it on your face to bring you back. Really, always great seeing you guys, thanks so much. Thanks, David, it's always gonna be up to you. Thanks very much. All right, keep right there, buddy. We'll be back to wrap right after this short break.