(electronic music) >> Announcer: From Boston, Massachusetts, it's theCUBE. Covering Cloud Foundry Summit 2018. Brought to you by the Cloud Foundry Foundation. >> I'm Stu Miniman, and this is theCUBE's coverage of Cloud Foundry Summit 2018, here in beautiful Boston, Massachusetts. Happy to welcome to the program first-time guest, Dr. Nic Williams, CEO of Stark and Wayne. Dr. Nic, thanks for joining me >> Thank you very much. I think you must've come to the conference from a different direction than I came. >> I'm a local, and I'm trying to get more people to come to the Boston area. We've been doing theCUBE now for, coming up on our ninth year of doing it, and it's only the third time I've done something in this convention center, so please, more tech shows to this area, Boston, the Hynes Convention Center, and things like that. >> There's plenty of tech people. I was at the Nero Cafe, everyone seemed like they were a tech person. >> Oh no, the Seaport region here is exploding. I've done two interviews today with companies here in Boston or Cambridge. There's a great tech scene. For some reason, you and I were joking, it's like, do we really need another conference in Vegas? I mean really. >> Dr. Nic: Right, no, I like the regional. >> But yeah, the weather here is unseasonably cold. It was snowing and sleeting this morning, which is not the Spring weather. >> It is April, it is mid-April, and it's almost snowing outside. >> Alright, so Dr. Nic, first of all, you get props for the T-shirt. You've got Iron Man and Doctor Doom, and we're saying that there is a connection between the superheroes and Stark and Wayne. >> Right, so Stark and Wayne is founded by two fictional superheroes. The best founders are the fictional ones, they don't go to meetings, they're too busy making, you know, films. >> Yes, but everybody knows that Tony Stark is Iron Man, but nobody's supposed to know that Bruce Wayne was Batman. >> Nic: Right, right. >> But I've heard Stark and Wayne mentioned a number of times by customers here at the conference. So, for our audience that doesn't know, what does Stark and Wayne do, and how are you involved in the Cloud Foundry ecosystem? >> So Stark and Wayne, I first found Bosh, I founded Stark and Wayne. Earlier than that I discovered Bosh, six years ago, when it was first released, became like, I claimed to be the world's first evangelist for Bosh, and still probably the number one evangelist. And so Stark and Wayne came out of that. I was VMWare Pivotal's go-to person for standing things up and then customers grew, and you know. Yeah, people want to know who to go to, and when it comes to running Cloud Foundry, that's us. >> Yeah well, there's always that discussion, right? We've got all these wonderful platforms and these things that go together, but a lot of times there's services and people that help to get those up. Pivotal, just had a great discussion with a Pivotal person, talking about the reason they bought Pivotal Labs originally was like, wow, when people got stuck, that's what Pivotal Labs helps with that whole application development, so you're doing similar things with Bosh? >> Correct. No it's, we have our mental model around what it is to run operations of a platform, where you're running complex software, but you have an end user who expects everything just to work. And they never want to talk to you, and you don't want to talk to them. So it's this new world of IT where they get what they want instantly, that's the platform and it has to keep working. >> Dr Nic, is it an unreasonable thing for people to say that, yeah I want the things to work, and it shouldn't go down, and you know-- >> What is shadow IT? Shadow IT is the rebellion against corporate IT, so we want to bring back, well, we want to bring the wonders of public services to corporate environments. >> Okay, so-- >> That's the Cloud Foundry's story. >> Yeah, so talk to me a little bit about your users. We've watched this ecosystem mature since the early days, you know, things are more mature, but what's working well? What are the challenges? What are some of the prime things that have people calling up your team? >> So our scope, our users, or our customers, are people, they're the GEs and the Fords of the world running either as a service or internally large Cloud Foundry installations. And whilst Cloud Foundry is getting better and better, the security model is better, the upgrades seem to be flawless, it does keep getting more complex. You know, you can't just add container to container networking and it not get more complicated, right? So, yeah, trying to keep up-to-date with not just the core, but even the community of projects going on is part of the novelty, but also it's trying to bring it to customers and be successful. >> Yeah, I go to a number of these shows that are open source and every time you come there, it's like, "Well, here's the main things we're talking about "but here's six other projects that come up." How's that impact some of what you were just talking about? But, maybe elaborate as to how you deal with the pace of change, and those big companies, how are they help integrate those into what they're doing, or do they, you know-- >> So my Twitter is different from your Twitter. So my Twitter is 10 years worth of collecting of people who talk about interesting things, putting in a URL, just referencing an idea they're having, so they tend to be the thought leaders. They might be wrong, or like, let's put Docker into production, like, it doesn't make it wrong, but you've got to be wary of people who are too early. And you just start to peace a picture of what's being built, and you start to know which groups and which individuals are machines, and make great stuff, and you sort of track their work. Like HashiCorp, Mitchell Hashimoto, I knew him before HashiCorp, and he is a monster, and so you tend to track their work. >> So your Twitter and my Twitter might be more alike than you think. >> Nic: No maybe, right. >> I interviewed Armon at the Cube-Con show last year. My Twitter blowing up the show was a bunch of people arguing about whether Serverless was going to eradicate this whole ecosystem. >> Well, we can argue about that if you like, I guess. >> But love, one of the things coming into this show, was, you know, how does the whole Kubernetes discussion fit into Cloud Foundry? We've heard at this show, Microsoft, Google, many others, talking about, look, open source communities, they're going to work together. >> Well Windows is going to track things 'cause they think they need to sell them, right? But then Microsoft has Service Fabric, which they've owned and operated internally for 10 years, and so, I think some really interesting products may be built on top of Service Fabric, because of what it is. Whereas, you know, Kubernetes will run things, Service Fabric may build net new projects. And then Cloud Foundry's a different experience altogether, so some people, it's what problems they experienced, comes to the solution they find, and unless you've tried to run a platform for people, you might not think the solution's a platform. You might think it's Kubernetes, but-- >> Yeah, so one of the things we always look at when we talk about platforms, is what do they get stood up for? How many applications do you get to stand up there? What don't they work for? Maybe you could help give us a little bit of color as to what you see? >> I'm pretty good at jamming anything into Cloud Foundry, so I have a pretty small scope of what doesn't fit, but typically the idea of Cloud Foundry is the assumption the user is a developer who has 10 iterations a day. Alright, so they want to deploy, test, deploy, test, and then layer pipelines on top of that. You also get, you're going to get the backend of long, stable apps, but the value is, for many people, is that the deploy experience. And then, you know, but whilst, you're going to get those apps that live forever, we still get to replace the underlying core of it. So you still maintain a security model even for the things that are relatively unloved. Andthis is really valuable, like the nice, clean separation of the security, the package, CVEs, and the base OS, then the apps is part of the-- >> Yeah, absolutely, there's been an interesting kind of push and pull lately. We need to take some of those old applications, and we may need to lift and shift them. It doesn't mean that I can necessarily take advantage of all the cool stuff, and there are some things that I can't do with them when I get them on to that new platform. But absolutely, you need to worry about security, you know, data's like the center of everything. >> If you're lifting and shifting, there probably is no developer looking after it, so it's more of an operator function, and they can put it anywhere they like. They're looking after it now, whereas the Cloud Foundry experience is that developer-led experience that has an operations backend. If you're lifting and shifting, if it fits in Cloud Foundry, great, if it fits in Kubernetes, great. It's your responsibility. >> Yeah, what interaction do you have with your clients, with some of the kind of cultural and operational changes that they need to go through? So thinking specifically, you've go the developers doing things, you know, the operators, whether they're involved, whether that be devops or not, but I'm curious-- >> So the biggest change when it comes to helping people who are running platforms. And I know many people want to talk about the cloud transformation, but let's talk about the operations transformation, is to become a service-orientated group who are there to provide a service. Yes you're internal, yes they all have the same email address that you do, but you're a service-orientated organization, and that is not technology, that is a mental mode. And if you're not service-orientated, shadow IT occurs, because they can go to Amazon and get a support organization that will respond to them, and so you're competing with Amazon, and Google, and you need to be pretty good. >> Yeah, you mentioned that, you know, your typical client is kind of a large, maybe I'm putting words in your mouth, the Fortune 1000 type companies, does this sort of-- >> We haven't got Berkshire. We haven't got Berkshire, and so if we're going to go Fortune 5, you know, we'd like, I've read my Warren Buffett biography, I reckon the FA are here to meet him I reckon. >> Right, so one of the questions, is this only for the enterprise? Can it be used for smaller businesses, for newer businesses? >> What's interesting is people think about Cloud Foundry as like, "Oh you run it on your infrastructure." Like, I did a talk in 2014, 15, when Docker was starting to be frothy, was, before you think you want to build your own pass, ring me on the hotline. Like, argue with me about why you wouldn't just use Heroku, or Pivotal Web Services, or IBM Cloud, like a public pass. Please, I beg of you, before you go down any path of running on-prem anything, answer solidly the question of why you just wouldn't use a public service. And yeah, so it really starts at that point. It's like, use someone else's, and then if you have to run your own. So, who's really going to have all these rules? It's large organization that have these, "Oh, no, no, we have to run our own." >> Well doctor, one of the things we've said for a while, is there's lots of things that enterprise suck at, that they need to realize that they shouldn't be doing. So start at the most basic level, there's like five companies in the world that are good at building data centers, nobody else should build data centers, if you're using somebody else that can do that. So as you go up and up the stack, you want to get rid of the undifferentiated lifting, things like that, so-- >> I like to joke that every CIO, the moment they get that job, like that's their ticket to get to build their own data center. It's like, what else was the point of becoming a CIO? I want to build my own data center. >> No, not anymore, please-- >> Not anymore, but you know, plus they've been around a little longer than-- >> So, what is that line? What should companies be able to consume a platform, versus where do they add the value, and do you help customers kind of understand that that-- >> By the time they're talking to us, they're pretty far along having convinced themselves about what they're doing. And they have their rules. They have their isolation rules, their data-ownership rules, and they'll have their level of comfort. So they might be comfortable on Amazon, Google, Azure, or they might still not be comfortable with public cloud, and they want the vSphere, but they still have that notion of we're going to run this ourselves. And most of them it's not running one, because that idea of we need our own, propagates throughout the entire organization, and they'll start wanting their own Cloud Foundry-- >> Look, I find that when I talk to users, we, the vendors, and those that watch the industry, always try to come up with these multi-cloud hybrid cloud-type discussion. Users, have a cloud strategy, and it's usually often siloed just like everything else, and right, they're using-- >> Developers-- >> I have some data service, and it's running on Google-- >> Developers just want to have a nice life. >> Microsoft apps. >> They just want to get their work done. They want to feel like, "Alright this is a great job, "like, I'm respected, I get interesting work, "we get to ship it, it actually goes into production." I think if you haven't ever had a project you've worked on that didn't go into production, you haven't worked long enough. Many of us work on something for it not to be shipped. Get it into production as quick as possible and-- >> So, do you have your, you know, utopian ideal world though as to, this is the step-- >> Oh, absolutely-- >> And this is how it'll be simple. >> Tell developers what the business problems are. Get them as close to the business problems, and give them responsibility to solve them. Don't put them behind layers of product managers, and IT support-- >> But Dr. Nic, the developers, they don't have the budget-- >> Speak for utopian-- >> How do we sort through that, because, right, the developer says they want to do this, but they're not tied to the person that has the budget, or they're not working with the operators, I mean, how do we sort through that? >> How do we get to utopia? >> Stu: Yeah. Well, Facebook, Google, Microsoft, they all solved utopia, right? So, this is, think more like them, and perhaps the CEO of the company shouldn't come from sales, perhaps it should be an IT person. >> Well, yeah, what's the T-shirt for the show? It was like running at scale, when you reach a certain point of scale, you either need to solve some of these things, or you will break? >> Right, alright look, hire great sales organizations, but if you don't have empathy for what your company needs to look like in five years time, you're probably not going to allow your organization to become that. The power games, alright? If everyone assumes that the marketing department becomes the top of the organization, or the, you know, then the good people are going to leave to go to organizations where they might be become CEO one day. >> Alright, Dr. Nic, want to give you the final word. For the people that haven't been able to come to the sessions, check out the environment, what are they missing at this show? What is exciting you the most in this ecosystem? >> Like any conference you go to, you come, the learning is all put online. Your show is put online, or every session is put online. You don't come just to learn. You get the energy. I live in Australia, I work from a coffee shop, my staff are all in America, and so to come and just to get the energy that you're doing the right thing, that you get surrounded by a group of people, and certainly no one walks away from a CF Summit feeling like they're in the wrong career. >> Excellent. Well, Dr. Nic, appreciate you helping us understand the infinity wars of cloud environments here. Stark and Wayne, thanks so much for joining us. I'm Stu Miniman, and you're watching theCUBE. >> Dr. Nic: Thanks Stu. (electronic music)

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

[lively music] >> Man: Live from Santa Clara, in the heart of Silicon Valley, it's theCube, covering Cloud Foundry Summit 2017. Brought to you by the Cloud Foundry Foundation and Pivotal. >> Welcome back, I'm Stu Miniman with my cohost, John Troyer. Happy to welcome back to the program, actually a former colleague of mine, Cornelia Davis, Senior Director of Technology at Pivotal. Cornelia, it's great to see you. >> Thank you, thank you for having me. >> All right, so why don't you fill in our audience a little bit about your role at Pivotal, you've been involved since before the foundation in early days of everything happening. >> Yeah, and in fact I have been working with Cloud Foundry for longer than the Pivotal Company's existed. As you know, Stu, you and I used to work together at EMC in the corporate CTO office. >> Yeah, I remember a company named EMC. [Laughing] >> Yep. And I worked in the architecture group and we did architecture in emerging tech. And about five years ago, my boss, who you know, Tom McGuire, said, "You know, this platform as a service thing, I think is going to be pretty disruptive, and I want you to start looking at it. And so naturally we were EMC, VMware was incubating Cloud Foundry already, so I started playing with Cloud Foundry. So that was way back in the days of Cloud Foundry version 1.0. I'm one of those people who got to raise my hand and say, "Yes, I've been to every single Cloud Foundry Summit." [Stu Laughing] But fast forward then we had the Pivotal spin-off, and since the Pivotal spin-off, I joined the Cloud Foundry team proper, and I've been in a role working the product organization, working with James Waters, who I know you spoke to earlier today, and helping our customers kind of get their arms wrapped around what this...this isn't just the next application platform. How really, it's radically different, and how the applications, it enables a completely different style of application. And so really helping customers grok the differences about that. >> Yeah, Cornelia, I want you to help us dig into this a little bit, because when we look at any of these massive changes, a lot of times we say, you know, the technology is the easy part. It's really the change in mindset, the change in the structure, new skillsets. What are you seeing, what's different now than it was, say, three or five years ago, and what are those customer discussions that you're having? >> Yeah, and that's a great question, and I will say, and thanks for the opportunity to say this, is that the technology isn't always the easy part. [Stu laughs] So let me give you an example. So just earlier today I was on a call where somebody was talking about some user interviews that they had done with some programmers, and what they concluded at the end of that was that programmers really weren't comfortable with the "asynch" model for this particular API, and that they really wanted to just deal with the synchronous stuff. And the answer there is not that we say, "Oh, okay, we'll let you keep doing synchronous." The answer is that yes, there's a technology thing here that's hard, which is starting to think asynchronously and changing the way that we design our applications. So the technology's not always easy, but we have to go there, because in the cloud, where things are so extraordinarily distributed in a way, and the cloud is constantly changing in ways that it never did before, we have to adopt new technology models. So that's the first thing I'll say, is that we definitely, the technology parts are sometimes hard. That said, certainly over the course of the last four years, as I've worked with those customers, in the beginning, I spent a lot of time, as you know, I'm a technologist, so I spent a lot of time at the whiteboard, and sketching out architectures and talking about changes in the architecture of the platform or changes in the architecture of the application, but then I very quickly found myself talking to customers about the other things that are going to need to change around the edges. So if, for example, you want to start deploying software multiple times a day, you're going to have to change your processes, because you can't have the security office have to do a full audit of every change before it goes into production if it's going to happen three or four times a day. And if you do that, then does that imply organizational changes? So I spend a great deal of my time really talking about the whole DevOps and the people and process side of the equation as well. So last week, I was just - I'm part of the programming committee of the DevOps Enterprise Summit, and we just held that last week in London. And there we spent a lot of time talking about those elements as well. >> I spoke with somebody who was at that conference, and they said it was a little bit sobering, because there are people who have adopted a lot of these practices, and then there are people who are trying and then probably people who have not started yet. >> Cornelia: Yeah. >> As Coté calls them "the donkeys without the unicorn horns yet. >> Cornelia: Ah. >> But as you go out to the customer base, obviously part of what Pivotal is doing is really this huge Pivotal Apps push about showing people the culture. I mean, do you feel like it's a push or a pull, does the technology come first, and then the culture, does the CIO yell, or do the developers say, "We want this"? >> So we definitely get a little bit of both. I would say that I have had the great opportunity to work with a great number of these customers, so Allstate, for example, we've seen Allstate here at CF Summit year after year, and Opal spoke about Andy Zitney talking about this three or four years ago. Well, that was IT saying, "Hey," and that was more from the operations side saying, "Hey, we're going to build you a new platform," and then will they come? Now, they of course had to couple that together with, "Okay, we're not just going to build the platform, we have to put things in place to enable people to use it properly. So there's certainly- and that came a little bit more from Andy Zitney's vision. So it was a little bit more from the top, "Hey, we understand there's a better way, we're going to start making this available to you, and we'll teach you along the way." We absolutely see the opposite as well, though. Where we see the groundswell, which sometimes comes from a bunch of really smart people starting to play with the open source things. And saying, "Hey, there's got to be a better way," or the shadow IT. They're frustrated with the three-month cycles, and those things. So it isn't one answer, it's really both. It comes from both sides. >> All right. So Cornelia, you're good at understanding some of those next generation things. One of the terms that we've been talking about for the last couple of years is "cloud-native." Could you help us really kind of tease apart what that means in your customer base, and the way you approach and explain that? >> Yeah. So the term "cloud-native" is brilliant from the perspective of having a term for it that has really taken ahold. Because I would say that three years ago, I used to say to people, "Hey, cloud is not about where you're computing, it's about how you're computing." But in fact, that's not exactly accurate. And so, now that cloud-native is a term that's taken hold, I have modified my statement. And the statement that I like to make now is that, cloud, in fact, is where you compute. It could be a public cloud, it could be a private cloud, but it is more of a location. Cloud-native is the how. So I like to also characterize the cloud and cloud-native, really cloud-native applications, as two fundamental things. One is that cloud-native has reached levels of distribution that we have not seen before. We've been dealing with distributed systems and heck, in universities, there have been courses on distributed systems for 40 years. But even when I started my career 30 years ago, I started my career in aerospace doing embedded systems, and I remember working on a system where we had three processors. You know, that was as distributed as we got. And we actually mapped out on a whiteboard, okay, we're going to run this on this process and parallel with this on this process, and the point there is it was distributed, but we knew exactly what we had, and we could count on that being there. Now, it's reached a completely different, many many orders of magnitude more, in terms of the number of distributed components, as we go to microservices and those types of things. So that's one of the things that I characterize cloud and cloud-native, is highly distributed like we've never seen before. Couple that together with the other thing I just talked about with the embedded systems, that's very different from that, is constantly changing. Always changing. And whether that change is happening because of some catastrophe or that change is happening because we are doing an upgrade, a planned upgrade, it's constantly in flux. And so we have to do things differently for that. And so that, I think really, is what cloud-native is about, is the how, and like I said, highly distributed, constantly changing. >> All right. And what about the role of data, when we talk about that? Distributed architectures, storage is really tough in that kind of environment. >> Cornelia: Yep. >> And therefore, how does data play into it? >> Cornelia: Yeah, so cloud-native apps were really, as an industry starting, and here at CF Summit, people are really kind of grokking what that means. Highly distributed, small, loosely coupled components that we've put together, we'll talk about that collective in just a moment. But they're generally stateless and so on. So we understand cloud-native apps, but cloud-native involves data as well, as you said, now most of our customers that have, as you said, some of them are a little bit further along whether it's DevOps or it's cloud-native architectures, they're a little further along. And those that are quite far along, have a lot of microservices, and so you look at them, and if you look just at the microservices, you think, "Ah, beautiful. Loosely coupled, independent teams, and so on," and then you pull back the curtain, and you realize that those microservices are all tied to a shared database. There's this monolithic Oracle database or SQL server, something at the back end, that they're all tied to. And so in fact, when a team wants to make a rev on a microservice, they might still have to go through some of that planning and lockstep with lots of other teams, because, "Hey, I want to change something in the data." So the data, remember we just talked about highly distributed? Well, on the data side, it's not so highly distributed. Yes, we've got multi data centers, but we have, again, a predictable number of nodes. We know what we've got deployed. We have very rigid architectures and configurations and so on. So when we start to apply cloud-native to data, we look at the same goals we had with cloud-native applications, which is autonomy, so being able to have the different cloud-native components evolve independently, resilience, so that we have bulkheads and air gaps between them, all of those same goals, let's start to apply those to data. >> And you feel that that's not happening today yet. We're earlier in the process yet? >> It hasn't been happening. That's right. We're far far far earlier in the process. And so what we want to start to do is take that monolith that's sitting behind the curtain and we want to start breaking it apart. Now, the industry has definitely gotten to the point where they're starting to tackle this. And that was, I kind of had an epiphany about a year ago, I was working with a customer, talking to them about DevOps, talking about all these cloud-native patterns and practices, and the punch line was it was the data team of this organization. So they didn't understand the solutions, but they were understanding that they had pain points that were very reminiscent of the pain points that their colleagues in the application server teams had had, had been tackling for three or four years. So the types of technologies that we're starting to see emerge and the types of patterns we're starting to see emerge are things like unified logs, like applying Kafka to that problem of having a unified log and that be the source of record. And event-driven systems and those types of things. Every microservice gets its own database, which, yeah, we'll get some of that, but that's a kind of purist and not pragmatic way of looking at things. Caching plays a pretty big role in that, so caching in the past has been all about performance, but now when we start to look at patterns, how can we use caches to help us create those bulkheads and those air gaps so we get additional resilience in our microservices architecture? If we can put caches and there are companies like Netflix, like Twitter, who have done that, who have embedded caching deeply through their entire architecture. >> Well, do you think these technologies will come from the database or, well, let's call it the database projects and vendors themselves, or is that something, those patterns can get built into a platform, say, like Cloud Foundry? >> I think it's going to probably come more from the platform community, which is not to say that database vendors aren't thinking about that, but again, they are keeping the lights on with their existing product, so they have those quintessential business school constraints that are holding them back. >> A quick question on nomenclature. So a few years back as cloud-native was being coined, you also heard about 12-Factor apps, and that was one particular manifesto, and certainly the ops folks, I would call it at the time, said, "Well, wait a minute, that's great for your front end, but where are you storing your state?" >> Cornelia: Exactly. And so I love this conversation about >> Yep. cloud-native data. So that is what we're talking about here? >> That's exactly what we're talking about, is doing that. And so it allows us, it's interesting, because as soon as we take a model where we say, "Okay, every microservice gets its own microdatabase," then of course everybody in any large enterprise says, "Wait a minute, what about my data compliance, my data governance, how do I keep a customer that's stored in this database over here from diverging from the customer record that's stored in this other database?" I mean, we've spent decades talking about the 360 view of customers, because we've already been somewhat more fragmented than we wanted, and our knee-jerk reaction over the last several decades was, let's consolidate everything into one database. But with that comes slowness. It's the proverbial large, large ship that's hard to turn and hard to move. But what's different now is that we're starting to come up with some different patterns of doing that, what we call master data management in the past, we're applying completely different patterns now, where those individual microservice databases are really just seen as a materialized view of some source of record, and that source of record is just a time series of events, and you can always rebuild. You know, it's very interesting, because databases have had a log as a part of their architecture forever. For a very, very long time. And in fact, the log, arguably, is more important than any of the database tables that are stored on disk, because you can always recreate the database tables from the log. Now take that concept and distribute it. That's what cloud-native data is all about. To take what has been a single fabric, and now create a highly distributed, constantly changing fabric for data. And figuring out what those patterns are. >> Cornelia, I want to give you the final word. You've been to all the Cloud Foundry Summits. Either the customers or the event itself, what are some of the things that are kind of new and changing, that people that aren't at the show should know about? >> You know, I was walking down the hallway this afternoon, one thing I'll note that has changed, like I said, I was walking down the hallway with a colleague of mine, and he said, "I have 12 people from a single one of my customers here. 12 people." I spoke with somebody else who said, "Yep, another customer - not a vendor, but a customer - sent 30 people here." So we have- Cloud Foundry Summit in the beginning was a whole bunch of people who were the hobbyists, if you will. So I think we've reached that inflection point where we have the users, not just the hobbyists, but the true users that are going to leverage the platform. That's one thing that's changed. Some of the things- the other interesting thing I think that is really brilliant is the touch that the Cloud Foundry Foundation has. So I'll tell you, I submitted several papers here three years ago, when it was still the Pivotal Show. I could talk about whatever I wanted. I don't always get my papers accepted here now. And that is a good thing. That's a really good thing, so we have really democratized the community, so it truly is a community event. I think that's another thing that's happened, is kind of the democratization of Cloud Foundry, and I love that. >> Cornelia Davis, it's a pleasure to catch up with you, thank you so much for joining us. And John and I will be back with a couple of customers, actually, here at the Cloud Foundry Summit. So stay tuned and thanks for watching theCube. [lively music]

>> Announcer: Live from Santa Clara, in the heart of Silicon Valley, it's theCUBE. Covering Cloud Foundry Summit 2017. Brought to you by the Cloud Foundry Foundation and Pivotal. >> Welcome back. I'm Stu Miniman, joined by my cohost John Troyer. Happy to welcome back to the program, friend of theCUBE, James Watters SVP of Product at Pivotal. James, great to see you, and thanks for helping to get theCUBE to Cloud Foundry Summit. >> Yeah, I was just saying, this is the first time theCUBE is at CF Summit, so we're official now. We're all grown up. We're out in the daylight and you know you made it when theCUBE shows up, so excited to have you here. >> Absolutely. So a lot of things going on. We had Chip on talking about some of the big announcements. >> James: Yeah. >> From Pivotal's standpoint, what's some of the important milestones in releases happening. >> Yeah, I think in the simplest terms, the big new thing came out of our collaboration with Google is called Kubo, which is Kubernetes on BOSH. And I think that was a big move that got a lot of applause in the keynote when it was announced yesterday. And I think it shows two things. One is that Cloud Foundry really is going to embrace multiple ways of deploying artifacts and managing things, and that we're really the cloud native platform and willing to embrace container abstractions, app abstractions, data abstractions pretty uniquely, which is, there hasn't been another platform out there that embraces those with specialized ways of doing them. And I'm really excited about the customer response to that approach. >> Yeah, James, help us unpack that a little bit. So we look at the term seems this year, everybody, it's multi-cloud, we're all talking back-- >> James: Yeah. >> I think back to the days when we talked about platform as a service. One of the pieces was, oh, well, I should be able to have my application and move lots of places. That's what I heard when I talked about Cloud Foundry. When Docker came out everybody was like, oh PAS's dead, Docker's going to do this. When Kubernetes came out, oh wait, this takes the core value of what platform as a service has done. And today you're saying Kubo, Cloud Foundry, and Kubernetes with some BOSH, pulling it all together. Walk us through, 'cause it's nuanced. And there's pieces of that. So help us understand. >> Yeah, I like to say that even though sometimes you have open source communities have their own sense of identity, there's really not a god abstraction in cloud programming. Like there's not one abstraction that does it all. The simplest way you can see that is that people are interested in function as a service today. They're also interested in container as a service. Well, those two are not, they're not compatible. Right, like you don't deploy your whole Docker image to Amazon Lambda, but people are interested in both of those. And then, at the same time, there's this hyper growth of Spring Boot, which is, I think, the most efficient way of doing Java programming in the cloud, which is really at the core of our app abstraction. And so we see people, there's hyper growth, and function as a service, app as a service, especially with Spring Boot, and then also container. And I think the approach that we've had is beause there's not one god abstraction, that our platform needs to embrace all of those. And that actually, it's pretty intuitive, once you start using them, and you get beyond the slides and the buzz words. When to use one versus the other. And I think that's what users have been really excited about, is that Pivotal and Cloud Foundry communities embraced kind of that breadth, in terms of, different approaches to cloud native. Does that make sense to you, John? >> Yeah it's starting to, right? A lot of people like to do all or nothing about everything, right? >> James: Yeah. >> It's all going to be, we're going to be serverless by next year. And that doesn't make any sense at all. >> James: That's right. >> And so you have multiple programming models, like you said, multiple different kinds of abstractions, so when would somebody want to use, say containers, as a service, or container orchestration, versus some of the other application models. >> Yeah, it's a really, really great question. And I just had a really productive customer meeting this morning, where we went through that. They had some no-JS developers, that they said, look, these developers just want to get their code to production. They don't want to think about systems, they don't want to think about operating systems, they don't want to think about clusters. They're just like, here's my app, run it for me. And that's the core trick that Cloud Foundry's done the best of any platform in the world, which is CF Push, and so, for a no-JS developer, here's my app, run it for me, load balance it, health management, log aggregate it, give me quotas on my memory usage, everything. That's a good example of that. Then, they also had a team that was deploying Elasticsearch and some packaged applications. And they needed the level of control that Kubernetes in terms of pods, co-location, full control of a system image, the ability to do networking in certain ways, the ability to control storage. And you don't just take Elasticsearch and say here's my Elasticsearch tarball, run it for me. You actually start to set up a system, and that's where Kubernetes container as a service is perfect. Then the other question is how do you stitch those together, and you've seen the Kubernetes community adopt the Service broker API, the open Service Broker API out of Cloud Foundry, as a common way of saying, oh, I have an Elasticsearch over here, but I want to bind it to an application. Well, they use the CF services API. I think it's early days, but there's actually a coherent fabric forming across these different approaches, and it's also immediately intuitive. Like we didn't know, when we first conceived of adding Kubo to the mix, we didn't know what the educational level of education we have to provide, but it's been intuitive to every client I've talked so far, so that's fun for me to watch you say a few words like, oh, we get it. Yeah, we use that for this and this for this. >> All right, James, I have to up-level it a little bit, there. >> James: Little deep? >> You travel way more than I do. We kind of watch on social media. Prove me wrong, but i can't imagine when you're talking in the C-suite of a Fortune 100, pick your financial, or insurance company, that they are immersed in the languages and platform discussions that the hoodie crowd is. So where are you having those discussions? >> James: Yeah. >> One of the things, I come into the show and say Pivotal and Cloud Foundry are helping customers with that whole digital transformation. >> James: We are. >> And making that reality. So help us with that disconnect of, I'm down in the weeds trying to build this very complex stack, and the C-suite says, I want to be faster. >> I'll tell you what the C-suite has to solve. They've got to solve two things. One is they've got to deliver faster and more efficiently than ever before. That's their language, and our core app abstraction has been killer for digital transformation. Deliver apps faster, find your value line, and approach problems that way. They get that. That's why we've been succeeding economically, that's been a bit hit. But they also have another problem is, they want to retain talent, and when they're trying to retain talent some of those times, those folks are saying, well, we want little bit more control. We want to be able to use a container if we want, or think about something like Spring Cloud Data Flow to do high-end pipelines. And so they do care about having a partner in Pivotal and in Cloud Foundry, they can embrace those new trends. Because they've got to be able to not be completely top down in how they're enabling their organizations, while also encouraging efficiency. And so that's where the message of multiple abstractions really hits home for them, because they don't always want to referee some of the emerging trends and tech, and telling their team what they have to use. So by providing function, app, container, and data service, we can be the one partner that doesn't force that a priori in the discussion. Does that make sense? >> Is there friction ever, when saying, okay here, we've got this platform that actually is rather opinionated versus, hey, go choose everything open source and do whatever you want. I think that there's political boundaries between different parts of organization, this is a lot of what DevOps, I think, as a movement has been so important. Which is saying actually, you need to blur the political boundaries in the organization to get to faster end-to-end throughput and collaboration. So I think that's definitely a reality. At the same time, the ability that we've had to embrace these different approaches allows the level of empowerment that I think is appropriate. Like I think what we've been trying to do is not necessarily cater to a free-for-all, we've been saying, what are the right tools in the tool chest that people need to get their job done. So I think that's been very warmly received. So I guess I'd say that hasn't been a big problem for us. >> I want to ask you about the ecosystem. I think back when the ecosystem started, IBM, HPE, Cisco were big players. I come in this week, and it's Google Cloud, Microsoft Cloud, and Pivotal still is, last time I checked it was what, 70% of the code base created by Pivotal. >> James: I think it's 60 or 55 now. >> The change in the ecosystem what that means, and what that means to kind of open source, open core. >> Yeah, so I think in addition to the Kubo work that we've done, the other big news this week is that Microsoft joined the Cloud Foundry Foundation. So, essentially the largest software company in the world-- >> Wait, wait, Microsoft loves open source, I hear. Did you hear that one? >> They do. >> I know, it's still shocking for a lot of us that have known Microsoft for a long time, don't you think? And I'm not trying to be facetious, they totally are involved, I've talked to lots of Microsoft people. Kudos to them, they're doing a really good job. Even if I look at the big cloud guys and throw in VMware in there, Microsoft is one of the leaders in participating and embracing open source. >> They are and I think Corey Sanders, who got on stage, announced this, he leads the Azure virtual machine service, and a lot of the other Azure services for them, I think that their strategy is they want to run every workload. Like if you talk to Corey about it, he's like, you got workload, we want to be your partner. And I think that's been the change at Microsoft, is once you go into cloud, it's sort of like Pivotal embracing multiple program abstractions, right, once you have a platform you want as much critical mass on it as you can. And I think that's really helped Microsoft embrace the open source community in a very pragmatic way. Because they are a business, a company, right? And I think open source is required to do business in software these days, right, like in a way that it wasn't 10 years ago. As you look at your customer set and multi-cloud, right? From the very beginning multi-cloud was baked into the concept of Cloud Foundry. Like you said, just push, right? >> James: Yeah. >> So what do you see as common patterns? We've talked to folks already who, on-prem. Obviously, you all are running your CF service in partnership, your main one, your partnership with Google, You work with Amazon, what do you see in customer base, right? >> Yeah, so, let me just share a little bit from a good customer. This is a prospect conversation more, like someone who's starting the journey. They were currently running on-prem, on an OpenStack environment, which had some cost of maintenance for them. They were considering also using their vServer environment, to maybe not have to do as much customization of OpenStack. But there were certain geographies that they wanted to get into. They didn't want to build data centers. And what they were confronting was, they'd have to go learn networking and app management on a couple different clouds they wanted to use. And what they liked about our CF Fabric, across that, was that they said, oh, this is one operating model for any of those clouds. And that's the pattern that we see is that companies want to have one cloud operating model while there's five major cloud players today. So like how do those two forces in the market combine? And I think that's where multi-cloud becomes powerful. It's not necessarily multi-cloud for it's own sake, but it is the idea that you can engage and use multiple resources from these different data center providers without having to completely change your whole organization around it. Because taking on, how you run vServer versus OpenStack is different, as you know, right? >> Right, right, and talking about change, right? You and I were together at VMware when you launched this thing. >> James: Yeah. >> And there was a profound kind of conceptual chasm to leap for the VMware operators to figure out what was going on here. >> James: Yeah. >> So in this new world of services operation in multi-cloud, how are you seeing people, how's the adoption going, you just launched, or the foundation's launched its new certification stuff, can you talk a little bit about the new skill set needed, or how you're seeing people, the people formerly known as sys admins are now actually doing cloud operations. >> Well, I'm not sure if you saw Pat Gelsinger's announcement at Dell World, Dell EMC World, about developer-ready infrastructure. And I think this is a critical evolution that our partnership with VMware is more important than ever. Which is they're now saying all of these people that have been doing traditional system administration, you need to now offer developer-ready infrastructure. And this is an infrastructure that all the networking and network micro segmentation rules need to be there, all of the great things that the VMware admins have provided before needs to be there, but it needs to be turnkey for a developer. That developer shouldn't just get what we had and 2009, when you and I were working there together, which is like, here's a virtual machine, go build the rest of the environment. It should look more like, here's my application, run it for me. Here's my container, run it for me. And so what we're seeing is a lot of people upping their game now. To say, oh, the new thing is providing these services for developers 'cause that ties into digital transformation, ties into what the business is doing, ties into productivity. So I'm seeing a Renaissance of sys admins having a whole new set of tools. So that makes me excited. And one of the cool things we're seeing, I'd love to get your opinion on this is, this cool operating ratio of, we've had our clients present. Their administers of Cloud Foundry instances are able to run tens of thousands of apps in containers with two to four to five people. And so now they've got this super power, which is like, hey bring as many of the applications as the business needs to me. I can go run 10,000 app containers with a small team of people with a good lifestyle. To me, that's actually kind of incredible to see that leverage. >> Yeah, I think it's a huge shift, right? 'Cause you aren't setting up the VLANs and the micro segmentation and the rest of the stuff. >> Yeah, it's not all by hand, and so now the idea with our NSX partnership, is I'm really excited about, fun to talk to you about it. We used to work in Building E and have lunch out there, is that when you provision a CF app, we're working with the NSX team that all the segmentation will align with the app permissions. And this is a big deal, because it used to be that the network team and the app team didn't really have a good conduit of communication. So now it's like, okay I'm going to bind my app to this data service. I want NSX to make sure that permission is followed. To me, that's going to be a revolution of getting the app, and the DevOps teams and the networking teams to work together, clearly. So I'm pumped about that. >> Running low on time. A couple of quick questions about Pivotal. Number one is, now that you're doing Kubo, could we expect to see Pivotal join the CNCF? So EMC is is joining the CNCF. We have friendly relations with the CNCF, I don't think that's at all out of the cards. I just know current, I don't have any news on that today. But we've been very friendly with them, and we started working with Google on that, so no immediate plans there, but we'd be open to that, I believe. >> Okay, and secondly, my understanding, the last announcement on revenue, you can't speak to the IPO or anything, James, above your pay grade, but $275 million in billing on PCF, did I get that right? What do you see is kind of the mix of how you're revenued, are you a software company, a services company? The big data versus the cloud piece. How do we look at Pivotal going forward? >> Yeah, what'd I say is I primarily oversee the Cloud Foundry portion of what we do. And services are an incredibly important part of our mix, Pivotal labs. When you think about this developer-ready infrastructure tend, like a lot of the way you organize your developers can change too. So we talked about how the sys admins jobs change. They gets this platform scale, well the developer's job has changed now, too. They have to learn how to do CICD, they've got to learn how to potentially turn around agile requirements from the business on a weekly basis versus every six months. So Pivotal labs has certainly been critical to that mix for us. But PCF in and of itself, has been a very successful software business. And I think, I believe can grow into the billions of dollars a year in software, and that's what kind of keeps me excited about every day. >> All right, James, I want to give you the final word. You speak to so many customers. >> James: A few. >> The whole digital transformation thing, what are you seeing? How do we help customers along that moving faster. >> That's a, it's a big topic. And the thing that's really interesting about what PCF does is, that it helps people change their organizations, not just their technology. And this has certainly happened in the vServer environment, right? Like it would change your organization, but we're even going higher, which is like, how are your developers organized? How operating teams organize. How you think about security. How you think about patching. Like the reason why I agree that it's transformative, is that it's not just a change of technology, it's these new technologies allow you to rebuild your organization end-to-end, of how it delivers business results. And that makes it both a humbling and an exciting time to be in the industry, because I personally, don't have all the answers every time. People ask about organizations and what to do there. Those are complex issues, but I think we've tried to partner with them to go on that journey together. >> Unfortunately, James, we're going to have to leave it there. We will definitely catch up with you at many more events later this year. And we'll be back with more coverage here from the Cloud Foundry Summit 2017. You're watching theCUBE. (techno music)