 From Boston, Massachusetts, it's theCUBE. Covering Cloud Foundry Summit 2018. Brought to you by the Cloud Foundry Foundation. Hi, I'm Stu Miniman and this is theCUBE's coverage of the Cloud Foundry Summit 2018 here in Boston, Massachusetts. Happy to welcome back one of our earliest and favorite guests of theCUBE, Pat Sackage, who's at Pivotal now and he handles PKS and Dell Technologies. Chad, great to see you. Thanks for joining us. Welcome to the Boston area. You come through this area a lot, but it's great to see you. It's good to see you too. This is by the way, it's my first CF summit. So it's interesting, you and I have talked together at Dell Technologies World, Dell EMC World and Dell and EMC World for years. VM World. And VM World, it's a different scene. All right, so Chad, this is my third time doing this show. I was at the first one back in 2014. Last year we did theCUBE there. And every year it's like, oh wait, there's this cool new technology containers. Maybe, how's Pivotal gonna deal with that? Oh, we're gonna do that. Did this year, wait, Kubernetes and all cloud natives everywhere. So maybe give us your point of view as to how this fits in. Yeah, so I feel like I'm a kid in a candy store. My job inside Pivotal is to drive PKS, so Pivotal Container Service that's built on top of Kubernetes. And there's a lot of Kubernetes action occurring here. If I had to net it out, I'd say a couple things. Number one, we've moved past the early hype cycle and actually went through several hype cycles that blew up. So Docker is gonna take over the world. Not correct. What turned out to be correct is Docker would become the container standard, right? Yeah, it's Moby now, right? Right. Then we went into the battles of different cluster container managers. So it's Swarm, it's Mizo's Marathon, it's Kubernetes and there were lots of others. And then you get through that early hype period and things settle down to the point where they're actually productive. And everyone now kind of agrees that Kubernetes is the standard container cluster manager for broad sets of workloads. Great. Now the debate is Cloud Foundry, the structured Paz world, right? The structured platform opinionated versus the little more Wild West and open ecosystem of Kubernetes and then early stage Kubernetes projects like Istio and others, right? I think this has two chapters now in front of us. Number one, chapter number one, and this is my focus I think for the next few years is how do we make Kubernetes simple enough, easy enough and frankly, enterprise ready. Not that it's not ready today, but a lot of Kubernetes projects that our customers are all over the map, difficult to sustain. We want to bring a lot of the lessons learned over the years of Cloud Foundry to Kubernetes. And I'm happy to say that just a couple of days ago we released PKS 1.0.2 and 1.1, which we haven't announced the date, but we've always said that we're gonna be in constant compatibility with GKE and the core Kubernetes. So since GKE shortly will have Kubernetes 1.10 support, you can expect a 1.1 of PKS. So mission number one is make Kubernetes a great platform and I am determined and stubborn and will make PKS the best enterprise platform for customers that are putting workloads on Kubernetes. That said, Kubernetes isn't standing still and neither is the ecosystem. And you can see that there's a lot of discussion over what's the intersection between Cloud Foundry and Kubernetes. I think that over time it's inevitable that these things come together more. But again, I think that's gonna occur over years, not in a heartbeat. And even, I've been at the Kubernetes show now for a bit and I've been at this show a few times. It's not a monolithic stack. We're building distributed lots of different pieces. You go to the Cloud Foundry, I'm sorry, the show that's KubeCon. There's so many different projects there. I mean, Istio was all the buzz, talk about the service mesh and all those pieces. There's all these little pieces there. At this show, we're talking about, Zipcar came and talked about, oh, they love everything in this ecosystem. They don't use some of the core components, but they use all these other pieces. So it's not like, as you and I talk many times, to Chad, if people go read, Chad writes a little bit about some of these things to give you all the details there, but stuff's pretty complicated. There are some of the Kubernetes community that's like it's never gonna get simple. Remember when we thought Cloud Computing was simple and if you've been to any Amazon show and you go through, it is more complicated to configure a compute instance in Amazon than it is to buy a Dell server these days because there's more options out there. So look, customers need options, customers, many of them will want things to be packaged and serviced and buy it as a service, but some love to put those pieces together and it's a spectrum and I loved it this show. Google and Microsoft up on stage, talking, hey, open communities collaborating together, maybe not merging everything, but working together, understanding where things fit and it's not one or the other, it's many customers will choose both. You and I are both nerds at heart, I hope you don't take offense. I've already been doing Star Wars quotes this week. So I wear it with pride, right? I'm always fascinated by the technology itself, but one thing that's been really cool about my experience alongside and now inside Pivotal, and you can see it here at the CF Summit, is that the Pivotal Obsession is about the customer and the outcome. We build a platform that is an essential part of that, but teaching the world how to build better software is a noble mission and the thing that's the most exciting for me is actually when the customers talk. So if you went to any of the customer discussions, did you see any of them? Did you see the T-Mobile one? I saw T-Mobile up on the keynote, actually did an interview with T-Mobile, had an interview with US Air Force. The Air Force one is amazing, right? So it's fascinating from a technological standpoint to say how do you use these tools? But it's the story of what you do with it that actually matters so much more. And again, I won't leave the customer name out of it. So talking with the T-Mobile crew, they love the Pivotal application service. So they are using it, it's an essential part of how T-Mobile works. They talked about it on stage, that's why I don't mind talking about it. And if you ask them, it's not an or, they also have massive projects, massive application workloads that don't fit in PAS, but are docker images. They're currently doing some strange stuff with Swarm and blah, blah, and they're like, man, if you guys can basically deliver a great platform that we can consume instead of trying to construct and maintain, we trust you, you iterate with us, you work with us, we'll be able to focus more on the outcome. The thing that I'm actually gonna be the most curious to hear feedback from customers over the next couple of years is how do they navigate what workloads are best put into Kubernetes? How does Kubernetes sets of ecosystems start to not calcify, but like firm up, right? It's going to be loose, right? But it will start to align more over time. Our research team actually calls it, we need to get to a place where it's more, it's plastic, so it should be not just scalable, you know, kind of up and down, but side to side a little bit more too, and once you have it, you can be able to go. Figuring out over time and helping with customers figure out, hey, this is a, this is a, you know, Kafka or Crunchy, you know, data, Postgres instance, or it's an ISV stack, or it's an application that they've homegrown, but they don't want to fully compartmentalize and put on paths, and they decide that they want to put it on Kubernetes, awesome. What is the value and the return of doing further work on that app to really make it cloud native, pull out all config, you know, turn it into a set of small microservices, and then it's better fit for the past part of PCF. Figuring out that formula over the next few years is going to be really cool. Yeah, you mentioned culture. Yeah. And that's been something you and I had lived through. It was like, you know, the server versus the storage versus the network, and the virtualization admin, and then the cloud admin. I loved, I talked to the U.S. Air Force guy. Yeah. And he was like, we actually take off, we're going to have the people take off their uniforms because rank would have a certain meaning inside there. But you've got, you know, the devs, you've got ops, you've got still the infrastructure pieces on top. What are you seeing from the customers you're talking to? What are some of the big challenges that are slowing people back from reaching this utopia of, you know, fast, fast, agile, interoperable, wonderful times? Well, how do I answer that one? That's a loaded question, brother. The biggest impediment is human nature. You know, it's these damn humans. If we could just get all the humans out. Everybody's mine, mine, mine. We'll go to low code, no code, eliminate all the humans. I did run on those interviews today too, yeah, absolutely. You don't need all programmers, it's, you know, however the business people can do it. The human tendency for control, and the need for control, I think it's probably pretty deep seated in our, we're living in a world where we know intellectually that we don't have control over everything, but we hate that because we wanna create control in our lives. That basically is the thing that sets up boundaries between people and they get really hung up on their function, right? That's not new. The words change, like you said. Used to be like server people versus storage people. And then it was virtualization teams versus the silo teams. And then, you know, now it's the intersection of the dev team and the dev ops team, the operations team. How do they intersect? The places where they're the most successful is that they don't get hung up on that and the people blend the roles. Now the trick is, how do you do that in a big company? I wrote a blog, I'm not trying to advertise virtualgeek.io, but I wrote a blog on this which was a synthesis of all of the customer dialogues I've been having over the last few years. And the pattern that I've seen that is most successful is actually to recognize that there are stacks and the stacks, I don't mean like this particular technology choice, but the way that the whole stack driven by the business and the application and then the abstraction it sits on and then you have to build your actual operations team underneath that, that creates a whole operational model which in itself is a stack, right? And just so it doesn't sound like I'm describing something that's nonsensical, you know, a stack can be in big enterprises. There's a mainframe based app that's running on a mainframe that's being supported by a mainframe operations team. And then right beside it, there's another stack which is all x86 workloads that are static. So they don't need an IaaS, they just need to run on a kernel mode VM abstraction. And then underneath that you have the team that supports and then you've got the workloads that can be containerized and don't need a full blown pass. And then you have another one which is a full blown application service model. Each one of those stacks ends up with different people processes and tools because they're mapped to the cultural operational model of that stack. And the thing that I'm trying to guide customers when I'm talking to them is don't reject that. That's actually reality, right? Yes, you should move as much as you can to the highest order abstraction you can. That's goodness, right? And it pays dividends all the way down the stack. But don't go and say that this workload by definition has to go there or because you operate this way in this stack and this group operates this way that by definition you're stupid and they're smart. The other rule is that- Chad, the answer to everything is serverless. By the way, I should've said that's another abstraction even to the right of the application service model, right? So the thing that I found is a key kind of pattern of good is that between the stacks people and process are not allowed to transverse them, right? Because the process is linked to how you operate. The only thing that goes between them because in the end for any customer they have stuff that touches all of those is to become religious about one thing which is that APIs and data and how those transit, those different stacks, that you have to be very clear on. Do you know what I mean? I wrote, on the blog I drew a picture but it was terrible. It was a terrible drawing. I've done whiteboards with you Chad, I understand. Great, so sounds like you've got your hands full. Yeah. Lots of us read the S1, so Pivotals, margin towards an IPO. I guess you've only been there over a short time, you've known Pivotals since the beginning and all the pieces since Green Plum was part of EMC, Cloud Founder was part of VMware. Anything that you've learned since you've been inside Pivotal now that just, there's misconceptions. One of the things I always find is we always learn about something the first time and then don't think it changes, so you know. It's funny actually, that's an insightful question. Having joined the team, it's weird because to many of them I'm new, I'm a new Pivot, but to many of them they know that I've always been there and I was reminding some of the originals the crazy tortured path that we've taken to get to today. The original effort was, hey people are doing new things and it's data's at the core of it and that was the trigger for the Green Plum acquisition and several of the people who are the senior leaders of Pivotal now came in through that and then Paul Moritz was the CEO of VMware at the time and he's like, hey I'm seeing people build new apps and new ways and by the way there's this crazy team inside VMware working on this thing called Cloud Foundry and they were like a red-headed stepchild that's not PC but like a black sheep or I don't know what metaphor you want to use but basically they were working on something that had nothing to do with kernel mode virtualization at it's core. It was a cloud native peg in a VM square. Oh right and at the time VMware isn't what they are now too, right? And then people forget this but I wrote a blog about it so it's on the internet permanently, right? There was a Green Plum project which was a great idea that says people want to collaborate with data sets and data scientists want to work together and it's really hard, let's build a thing which is like a social media portal for Green Plum which was called Chorus and the Chorus project was completely sideways and they were like we don't know how we're gonna get this thing on track on time, they asked around the valley and people said hey you should go talk to these guys at Pivotal Labs up in San Francisco. What they do is they help people when they're stuck, right? And they went and I remember when Bill Cook and Scott Yarra came back to Hopkinson and said this was awesome. They've changed the way we think about how we build software. We think we should buy them and that got added. I remember when Paul Merritt said spring is available. It's like the most widely used modern Java framework and now there's all sorts of stuff in Spring Rift. All of these weird bits, you know, in essence became the essence of Pivotal. You know what I've learned through that? Is these journeys are not in a straight line, right? Like, everyone's, right is- Like our careers. Yeah, like our careers, man. That's the first part. The second thing is that, and this is gonna be a challenge for Pivotal, honest, you know, if we're very transparent as always, is Pivotal's brand is now so linked with Pivotal Cloud Foundry. And that's a good thing. Like those customers raving about the business outcomes that they're getting. But inside Pivotal, the strategic change, the strategic pivot, ha ha ha, to do a full embrace of Kubernetes versus the traditional opinionated versus plastic debates. I wouldn't say that we have 100% of the company fully embracing it yet because companies are themselves organic, right? But across the vast majority of the company it is something understood that it's an imperative for us. Like if we want to help the customers and the world build better software, we've got to do it for stuff that fits into Paz and stuff that doesn't. And so I've learned over the last few weeks about how many people share that passion that I have and I think we can make something awesome with PKS. All right, well with that Chad, we'll have to leave it there for now. Looking forward to seeing you at more events. Congrats on the new role. I'm sure if people haven't already, Chad does have a new site. First blog, virtualgeek.io instead of the previous one. Chad, always a pleasure, thanks so much. Got the cube here at Cloud Foundry Summit. I'm Stu Miniman, thanks for watching the cube.