>> Announcer: From Boston, Massachusetts, it's the Cube. Covering Cloud Foundry Summit 2018. Brought to you by The Cloud Foundry Foundation, >> Hi I'm Stu Miniman and this is the Cube's coverage of the Cloud Foundry Summit 2018 here in Boston, Massachusetts. Happy to welcome back one of our earliest and favorite guests of the Cube Chad Sakac 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, my first CF summit. So it's interesting, you and I have talked together at Dell Technologies World, Dell EMC World, and EMC World for years. >> Stu: VMWorld. >> And VMWorld. This is a different scene. >> Alright Chad, this is my third time doing this show. I was at the first one back in 2014, last year we did the Cube there; every year it's like 'oh wait, there's this cool new technology; containers, maybe, how's Pivotal going to deal with that? This year, wait, Kubernetes, cloud natives everywhere. Maybe give us your point of view, as to how this fits in. >> So I feel like I'm a kid in a candy store. My job inside Pivotal is to drive PKS. 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 going to take over the world, not correct. What turned out to be correct is Docker would become the container standard, right? >> It's Mobi now, right? >> Right. Then, we went in to the battles of different cluster container managers. It's Swarm, it's Mesos 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 PaaS-World, right? The structured platform opinionated, versus the little more wild west and open eco system 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, 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 days ago, we released PKS 1.O.2 and 1.1, which we haven't announced the date but we've always said that we're going to be in constant compatibility with GKE, and the core Kubernetes. 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 steady still and neither is the ecosystem. And you can see that there's a lot of discussion over what is 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 going to occur over years. Not in a heartbeat. >> And even, I've been at the Kubernetes show and have 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 Kub-Con, there's so many different projects there, I mean Istio was all the buzz, talk about the service national, there's all these little pieces there. And at this show, we're talking about Zip Car came and talked about they love everything in this eco system. They don't use some of the core components, but they use all these other pieces. As you and I've talked many times, Chad, people go read, Chad writes a little bit about some of these things to give you all the details there, but this stuff's pretty complicated. There's some in the Kubernetes community that's like it's never going to 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 at Amazon, than it is to buy a Dell server these days. Because there's more options out there. Look, customers need options, many of them 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 at 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 to that. >> I've already been doing Star Wars quotes this week. >> I wear it with pride. 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 key note, I actually did an interview with T-Mobile. Had an interview with US Air Force. >> The Air Force One is amazing. >> Awesome. >> 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. I'll leave the, no, I won't leave the customer name out of it. So in 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 PaaS, 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 going to 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 firm up, right? It's going to be loose. But it will start to align more over time. >> Yeah our research team actually calls it, we need to get to a place where it's plastic. It should be not just scalable up and down but side to side a little bit more too. Once you have it, you can be able to go. >> Figuring out over time, and helping, with customers, figure out 'Hey, this is a Kafka or Crunchy data.' Post grass instance, or it's an ISV stack, or it's an application they've home grown, but they don't want it fully compartmentalized 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, turn it into sets of small micro services, and then it's better fit for the PaaS part of PCF. Figuring out that formula over the next few years is going to be really cool. >> You mentioned culture. And that's been something you and I, Chad, lived through. It was the server vs the storage vs the network and the virtualization admin, and then the cloud admin. I talked to the US Air Force guy, and he was like, 'We actually have the people take off their uniforms, because rank would have a certain meaning inside there.' But you've got the Devs, you've got OPS, you've got still the infrastructure pieces on tub, 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 fast, fast, fast, agile, inter-operable, wonderful times? >> How do I answer that one? That's a loaded question, brother. The biggest impediment is human nature. It's these damn humans, if we could just get all the humans out. >> Well everybody's mine, mine, mine. >> We'll go to low code, no code, eliminate all the humans, it'll be dreamy. >> I did one of those interviews today, too. Absolutely, you don't need all programmers, the business people can do it. >> The human tendency for control, and the need for control, I think it's probably 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 want to 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. That's not new, the word's changed, like you said. Used to be server people vs storage people. Then it was virtualization teams vs the silo teams. And now it's the intersection of the DEV team and the DevOps 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 I wrote a blog on this which was a synthesis of all the customer dialogues I've been having over the last few years. And the pattern I've seen that is most successful, is actually to recognize that there are stacks, and the stacks, I don't mean 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, and just so it doesn't sound like I'm describing something that's nonsensical, a stack can be in big enterprises, there's a main frame based app, that's running on a main frame, that's being supported by a main frame 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 IAS they just need to run on a kernel mode VM abstraction. And then under that you've got the team that supports. Then you've got the workload that can be containerized, and don't need a full blown PaaS. And then you've got 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. Yes you should move as much as you can to the highest order abstraction you can. That's goodness 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 server-less. >> By the way, I should have said that's another abstraction even to the right of the application service model. So the thing I've found, is a key kind of pattern of good, is that between the stacks, people and process are not allowed to transverse them, because the process is linked to how you operate. The only thing that goes between them, because in the end, for any customer, the stuff that touches all of those, is to become religious about one thing, which is that API's and data, and how those transit, those different stacks, that you have to be very clear on. Do you know what I mean? 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. Sound's like you've got your hands full. Lots of us read the S1, so Pivotal's marching towards an IPO. You've only been there a very short time, you've know Pivotal since the beginning and all the pieces since Greenplum's part of the MC, Cloud Foundry part of VMware. Anything that you've learned since you've been inside Pivotal now that 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. >> 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 data's at the core of it. And that was the trigger for the Greenplum acquisition. And several of the people who are the senior leaders of Pivotal now came in through that. And then Paul Maritz was the CEO of VMware at the time, hey, I'm seeing people build new apps in new ways, 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 its core. >> Yeah it was a Cloud native peg in a VM square. >> And at the time, VMware isn't what they are now too. And then people forget this but I wrote a blog about it, so it's on the internet permanently. There was a Greenplum 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 Greenplum which was called Chorus. And the Chorus project was completely sideways. And they were like we don't know how we're going to get this thing on track on time, and they asked around the Valley, and people said hey, you should go talk to these guys, Pivotal Labs, up in San Francisco. What they do is they help people when they're stuck. They went, and I remember when Bill Cook and Scott Yara came back to Hoppington 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 Maritz said 'Spring is available.' it's like the most widely used modern JAVA framework, and that was also stuff in Spring Rif. All of these weird bits, in essence became the essence of Pivotal. You know what I've learned through that? Is these journeys are not in a straight line. Everyone's. >> Like our careers, Chad. >> Like our careers man. That's the first part, the second thing is, and this is going to be a challenge for Pivotal, honest, 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 are 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. But across the vast majority of the company it is something understood that it is an imperative for us. If we want to help the customers and the world build better software, we've got to do it for stuff that fits into PaaS, 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. >> Alright, 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 for his blog, virtualgeek.io instead of the previous one. Chad, always a pleasure. Got the Cube here at Cloud Foundry Summit, I'm Stu Miniman, thanks for watching the Cube. (upbeat tempo)