 Okay, we have a packed agenda, no, packed panel, with 25 minutes. So one question each and no questions from the audience, right? So the title is Will It Blend, Plot Foundry and Kubernetes. Not an interesting topic at all given how full this room is at the end of the day, last session of a long day, first day, a long day. So let me quickly just read through the names and maybe one line each. Introduction, Cornelia, please start us off. Hi everyone, I am Cornelia Davis with Pivotal. Have been with Pivotal since the very beginning and I work from a technical perspective, driving new products into market. And the new product that I'm working on right now is Pivotal Container Service. Jeff Hobbs, I'm at Sousa and I've been working with Cloud Foundry since it was open sourced through ActiveState, HPE and now at Sousa. Hi, I'm Megan, I'm a software engineer at Google. Up until last week, I worked on a team that did integrations between Google Cloud and Cloud Foundry and I worked on Cloud Foundry Container Runtime. And last week I switched to the GKE team, so now I'm working on Kubernetes. So I'm Bernd Kranig from SAP Cloud Platform, working for SAP for close to 20 years, meanwhile. So we're working on bringing Cloud Foundry to overall SAP Cloud Platform and integrating Kubernetes into that as well. I'm Gaman Roy, I came over to Microsoft about a year ago as part of the dais acquisition. I'm head of product for Azure Containers, including Kubernetes service, a bunch of other stuff. I also represent Microsoft on the board of the Cloud Native Computing Foundation. All right, and Simon Moser. I'm the lead architect for the Cloud Foundry service on the IBM Cloud. Been with the community for, I don't know, five years or so by now. Have both a product role as well as a contributor role in the open source. Fantastic. And I'm Svarnath, the foundation, I'm with the Cloud Foundry Foundation. Let's kick off the panel discussion with the software for a smaller question. I don't know why this keeps. I will turn it off. So let's kick it off with a softer question, maybe a slow, not curveballs yet. What do you think? I will let any of you pick the question, but what do you think is the kind of integration points or the kind of potential merge points for Cloud Foundry and Kubernetes, as you see today, use cases, maybe Megan kick us off. Sure. So I've seen a couple of different projects being worked on, I think. One is deploying Cloud Foundry components onto Kubernetes, and the other would be deploying applications from Cloud Foundry on Kubernetes, which I saw a talk earlier today, some of you might have seen. I think both of those are good and probably an ideal state would be something that uses both of those. So you could deploy Cloud Foundry components onto Kubernetes and then also use Kubernetes as the runtime for containers. Something like that would probably be ideal, I think. Yeah, I'd agree that from the point of view that Cloud Foundry is really more about UX and developer workflow and Kubernetes has come to represent a great just container management platform with a lot of extra richness. That Cloud Foundry doesn't yet always take advantage of that richness, but could grow also into that. All right, yeah, so I mean, I can totally second the stuff that has been said by both Megan and Jeff. That's exactly how we see it as well, right? So we see, from an IBM perspective, we see Kubernetes as an IS plus, which could both be an underlying layer where Cloud Foundry runs top on top of, similar to any VMs today, as well as a replacement for the backend or at least an alternative to the backend where applications get deployed to. And that's kind of like the vision that we were heading. On top of that, I actually do see even more integration potential outside of that, which is not so much in the guts of the system or in the core of the system, but more around the surroundings, like having shared service catalogs, having a common authorization and authentication model, that level of integration, that is also certainly something that is achievable. Yeah, I like both of the themes that you just talked about on. You referred to it as IS plus. And so one of the things that I usually like to point out is that Kubernetes is much more of an abstraction sitting above IS or sitting above virtualized infrastructure in general. It's more of an infrastructure dial tone than it is an application dial tone, which is sometimes counterintuitive because people think of containers and they think containers apps, especially in this community where we've been doing apps for four or five years, but it really is more of an infrastructure abstraction. And so when we think about the big A application, when we deploy software, it's not made up of just microservices that we've used the application runtime to rapidly deploy and develop and have our pipelines and so on. It always has integrations to other systems as well. And where are those other systems running today? Well, by and large, they're running on infrastructure as a service. Well, virtualized infrastructure, most of the time virtualized. I think the enterprise is like 80% virtualized or something on average. But there's a certain amount of pain that happens in halting to go all the way down to a very low level infrastructure dial tone. And so what we can do is we can think of our software as there's parts of it that can land on the application runtime and other parts that aren't suitable for the application runtime. But we can get some value add by putting it into a layer. So one of those value adds is multi-cloud, right? So putting it in a layer and putting it against Kubernetes as opposed to a very specific infrastructure as a service. So I think one of the reasons why it's important to, over time, unify the application runtime with the Kubernetes runtime is if you think about what a pass is, it's really a set of developer abstractions, guardrails that are designed to help you do the right thing. Those are great until they're not. And when you hit the walls of those things, the question is how far are you going to fall? In the case of a typical Cloud Foundry installation, you're going to fall all the way down to IaaS. And that fall is painful. When you get down there, you can't see anything else. You've got to get to configuration management. I mean, you're completely lost at that point. If you're plotting your container, your pass on top of container orchestration and on top of Kubernetes specifically, the fall is a lot easier to tolerate. You fall down to Kubernetes, you can see everything that was deployed on Kubernetes. You have service discovery, intercontainer communication, things like service mesh are going to work in a uniform way. And what that allows you to do is that allows you to take more experiments with your abstractions. You can feel confident betting on the abstractions you have and feel confident that you're also betting on a runtime that's going to provide you the abstractions of the future. So maybe building on top of what Gabe said and also Simon, then like in a microservice world or in a distributed world, the next question is like, am I going to fall down to that layer for all of my stuff? Or am I like for most of the stuff staying on the Cloud Foundry platform as a service layer? And then for the cases where I need it, actually I fall down. And like then we are at that integration level of I want to have the same authorization. I want to be able to have network connectivity between stuff that is running on Kubernetes natively and on Cloud Foundry. I want to have policies on top that similar to how container networking is today governing communication inside Cloud Foundry, I want to be able to expand that over to Kubernetes clusters that are running my services for example. So I think like there's a whole lot of integration points that actually even came up when like we as Cloud Foundry introduced that notion of you have Cloud Foundry application runtime and then you have Cloud Foundry container runtime slash Kubernetes just sitting next to it. And you know there's far more value in the Cloud Foundry application runtime than just the developer guardrails. So for example, the fact that the application runtime takes care of building the container for you isn't just a developer convenience that you don't have to build your own pipelines because you know we can build our own pipelines. It's the fact that the application runtime can now take it takes responsibility for the building and maintenance of that container. And so if there's a vulnerability in the JDK the build pack takes care of that for you. You don't have to go in and figure out oh where is that vulnerability of the JDK? To some extent you're back to configuration management if you've done those containers yourself and are deploying them onto something like Kubernetes directly. So this is one of the areas that I think we as a community need to finesse and really need to understand truly what are all of the value ads that the application runtime gives because what I just described is a much stronger security posture than we have in the container runtime. That's a good point from a security perspective as well and also kind of separating out the abstraction layers. Kind of going onto the application runtime I know Cornelius you've worked on application runtime now on Pivotal Container Services for a while. How can you tell us, I know you touched upon that a little bit that it's more than a developer guardrail but how is it application runtime, how is Diego in application runtime kind of different or adding value when compared to the Kubernetes orchestration system? Yeah, so the first thing I'm gonna answer slightly different question first because I think it's very much related to the question that you ask which is frankly, sometimes people will say, well, are you gonna replace Diego with Kubernetes? And my answer is to what end? Because we've had Diego and before that somebody remind me I'm having a brain DA, yes, thank you. Before that, we've had exactly the patterns that exist in Kubernetes, this declarative actual state versus desired state and control loop that's constantly bringing things into convergence and all of that stuff has been in the application runtime for four or five years. It's been there all along. And what's interesting is that we've, and the reason I say to what end is that if we replaced Diego with Kubernetes how would that change your experience with the application runtime? Kusig, not at all because that's not, it's been an implementation detail under the covers. It really doesn't matter. You're interacting with apps. You're providing your jar file or your tar ball or whatever. So that's one thing. But the interesting and the part that I wanted to add onto that that you didn't ask directly is the thing that I like about Kubernetes is that four years ago, we were teaching people about declarative models, actual state versus desired state. And now with this huge energy around the Kubernetes community, we don't have to teach that anymore. People are getting that. And so that gives us maybe the bandwidth to do creative things around, maybe it's less that we bring Kubernetes to Diego with Kubernetes. And more it gives us the bandwidth to start thinking creatively about how we bring some of the services that are in PaaS over into what does an app abstraction look like on top of Kubernetes? So one of the things I just wanna sort of disagree on is this point about what do you get by replacing Kubernetes from a runtime standpoint? You get zero. Well, from the standpoint of just purely deploying an application, yes, agreed. But the past, present, and future of IT is heterogeneous. There's lots of different systems that we have to interact with. And with the consolidation around Kubernetes as sort of this de facto orchestration layer where you're gonna have all these different things and frankly, lots of different types of passes. We think about 12 factor paths and the Cloud Foundry application runtime is just the gold standard. We need that, the industry, the world needs that to exist. But there's also gonna be passes developed for folks who are doing data science with TensorFlow, running on top of Kubernetes. And that's gonna need to interact with the video rendering stuff that's happening and the facial recognition stuff that's happening, all ideally on the same compute substrate. So for me, I think about this as commoditization that's happening in the industry from the bottom up. And though feature functionality standpoint of the CFAR doesn't change directly, it's that interaction with the rest of the stuff where you actually get the value added. And I would view that as part of the overall user experience. Yeah, I'm totally gonna echo that what Gabe has been saying. So from a developer, like depending on when you say what's the value add, it really is a question on the road. From a developer perspective, I wanna be able to build mix and match on a given infrastructure applications that have been built in a 12 factor fashion with an easy developer experience, alongside with maybe some stateful stuff that I have as a legacy application, I wanna have the same experience. Like you said earlier, Gabe, the fallback is exactly down to that level and not deeper, right? That's how it should be. One aspect that you didn't touch on that hasn't been touched on in this discussion yet is also the operator experience, which hasn't been touched. And I think this is where yet another big value would come in when we are talking about replacing or at least offering Kubernetes as an alternative backend to Diego. Because many of the companies out there from an IS level are standardizing on Kubernetes today. I think we can agree on that. That's just the fact of the market. That being said is if I start training an IT department running these kind of things and now I wanna have a development department in the same organization, in the same company, moving in and then now they have to manage a wholly different stack. That's just yet another investment, yet another learning experience that I have to make. And granted, if everything is based on Bosch and for some of the open source stuff that is the true statement, so maybe that learning curve is not that steep, but truth of the matter is many companies out there have stuff where they run their container runtime, not on Bosch, right? It's also a reality. And all of a sudden once you get into that state, all of a sudden you have two learning experiences, two learning curves. And that is when push comes to shove, really makes some companies go the path of not deciding that their productivity, the developer productivity is their most important thing, but their operational model is the most important thing. And that is kind of like a death sentence for CloudHoundry unless we start blending on that level as well. I mean, I'd agree with that, though. The support, the Cornelius point, yes, it does nothing to the developer experience. That's actually a value add of the CloudHoundry experience that you can still have that entire level of richness while replacing what is practically the heart of the platform that exists there, but it's always behind the covers. Now we could put Kubernetes behind the covers and that's great to the overall architecture. And another aspect though of, yes, it also helps the operator experience. One of the other things that you can potentially assist with there is the resource utilization. If you are running these things, you can, you don't have to have overweight Diego cells taking up space while you already have a Kubernetes substrate that could be directly layered onto. And I'd key in to see, I have a talk next month already at OpenStack where I'll talk about, well, what does it look like when you run a containerized CloudHoundry versus a classic VM CloudHoundry? And people say I was cheating a bit because my Kubernetes CloudHoundry happens to run on bare metal. I've taken an entire layer of virtualization out. It's not cheating. That's the new operator experience that some companies are looking for when they're doing Kubernetes. They're like, hey, I'm gonna run this in a bare metal commoditized hardware and I know how to manage all that. So I wanna just layer directly on top of that to get the highest performance out of my bare metal possible. And when we can put just that, again, a thinner layer that gives you the entire CloudHoundry experience on that bare metal, then that's another value. So let me ask you, probably start with Bern. Is that even the right question since you picked the panel topic? I will go on you first. Will it blend? Is that even the right question? If not, why not? And if so, why do you think it is? I mean, I kind of provocatively picked that metaphor. Like for those of you who don't know, there is this YouTube series to put all kinds of strange things in a blender, press the button and see what comes out. Chip wanted me to also. Chip wanted to ask, like, will it blend better than an iPhone? I would say yes because the result of blending an iPhone is just like a pile of ashes and smoke. So I hope, yes, it will blend. And what the result is, hopefully, is like a much nicer experience for both communities, ultimately. So like for the CloudHoundry community, this, like you don't need to fall down to the IS layer to do things. And for the Kubernetes community, this notion of, no, it's not all about Q-Control and then a bunch of YAML files and like it's your own container. You have to do the security yourself, et cetera, et cetera. But there is value in saying, here is my code, run it in the Cloud for me, I don't care how. And I believe like many people in the Kubernetes community also see that as a goal that's worthwhile pursuing on bare Kubernetes, essentially. And bringing over Cloud Foundry is one important ingredient because that's like mixing the defecto platform as a service standard with the defecto. And now we can like talk about the terminology but like one layer above the plain infrastructure level standard. So, Megan, I'm sorry, good. I was just gonna say, I mean, if you look at even like the talk sessions and topics that we've had at this CF Summit, I feel like there is a lot of interest in using both Cloud Foundry and Kubernetes. And so if we can make it easier for people to learn both tools or even make them almost seem like one tool, I think there is benefit in that just in like overhead of learning multiple platforms. Yeah, the, I'm not concerned in taking the will it blend idea a little further. It will blend, but you know, sometimes there's more or less success in that. And I think that, I mean, working with some of the people here on trying to make it blend, we don't know what kind of bitter brew it might taste like in the end. There's emulation of a lot of things that are being done right now, but it's going to get, we're gonna get over the initial hump and some of the great demos that we've seen that are prototypes once they reach maturity. Then you're gonna start looking at some of the more interesting areas, like do these network security models really mesh well? Or am I actually going to have to ask a question, will I have to modify the CF API to get best use out of this particular Kubernetes feature? And where is the community going to push? Because the stuff that we've been talking about, it's blending in a computerly optional sense. You can deploy VM still or you can deploy on Kubernetes. Those options both exist. We saw the also deploying without Diego directly on and that will be an option. What's gonna happen when we bring the first really awesome feature, but it binds you to Kubernetes? That's gonna be the interesting part. Yeah, but I mean, just to add to that, I mean, this may be a question to the audience actually from us, at least for me, is one of the things that we haven't really talked about that is that what is the role that particular aspects of that blending are addressed with? Like when you think about, I would like to do a show of hands, like who thinks that Kube CTL or doing anything with Kube CTL today is actually a great developer experience. Is there anyone in the room who actually thinks like that? I would like to learn about that. All right, cool. So we all... I actually, for, I happen to be at that conference and I can tell you, I can tell you what's interesting is that The meme at the last KubeCon was that Kubernetes is too hard to use for developers. That's actually why this is so important, is because you have these two communities that were kind of spinning off, one of them just absolutely nailing the developer experience. And one of them, I would argue, absolutely nailing the operations and sort of a lower level experience. And sort of two different niches, but really honestly the perfect potential marriage. And so that's why I feel so passionately about this is because I've built past systems in my career. I know, I've lived these abstractions. I've seen people have to break out of them. I want nothing more than to see the CF application runtime running natively on Kubernetes. One other thing that was brought up that I just want to point out is when you get the commoditization at the Kubernetes layer, there's something else that's happening. And I know because I'm part of this over at Azure, but the type of things that we're doing to make Kubernetes operable at hyperscale is pretty intense, right? There's some deep, deep engineering going on. I know at Azure, I know at Google as well, to make Kubernetes run amazingly, right? And one of the reasons why is because I think a really smart move when the CNCF came out with the conformance program for Kubernetes, unlike some other conformance programs, they made it semantic, which means that when you test the Kubernetes cluster, if the API looks like Kubernetes, speaks like Kubernetes, it is Kubernetes and it is going to be deemed Kubernetes. You can use the trademark, right? Versus saying you have to be shipping the exact bits. Now what that means is that you get to do things like optimize what the Kubernetes bits actually are. So we're actually experimenting with serverless containers, things like Azure Container Instances, which are, you know, hypervisor wrap, sort of cloud provider container instances, delivering this VM-less Kubernetes experience, right? Imagine a world where you could just press a button, get a Kubernetes API, no VMs on it, and then go install the cloud foundry application runtime and go, you know, digitally transform your enterprise. I mean, that's a future I'd love to sign up for and I think a lot of other folks have talked to feel the same way. I love how you pointed out that it's all about the contract. It's not about the implementation, it's about the contract. And you're right, it's the Kubernetes implementation is great and it's the open source and it's getting a lot of innovation from a very broad community and we know from the last 10 years of experience that open source projects with engagement yield really great results. But the implementation is actually secondary, it's the contracts and when we have those contracts, as some of you were arguing very well earlier, some of those contracts are contracts that even go to the operability and the management and all of those types of things and having that standardized layer is great. The other thing that I would add is that you also touched upon it as well, which is nailing the developer experience, which is that Kubernetes has so many knobs and dials, even though it's an up-leveling of IaaS, it still has maybe even arguably more knobs and dials in some ways and so coming up with what the right opinionated and not necessarily all the way up to the application developer experience but all of these other passes, what are the right abstractions, what are the right simplifications that will take it to being consumable by the developer or whoever the user is that wants to use the layer above it, that's the fun work. I wish I could keep going, but we are already one minute over. One question from the audience? I don't know until we get kicked out. All right, audience gets one question. Keeping me from the bar too, by the way. That's why the audience gets one question. Who wants to go? Sorry? One question, anyone? No questions? I see him. I hope I didn't waste this one question. Sorry, audience. So Gabe, you kind of talked about a great operating experience from Kubernetes, but I kind of feel like that that's something that I kind of felt like that was something that the Cloud Foundry Foundation was bringing to Kubernetes in that Bosch allows us a much better operational experience, but can you kind of expound just a little bit? Maybe the panel, even, on what makes Kubernetes so great to operate. Yeah, actually, this is interesting. I think the beauty here is this idea of semantic conformance, where the best operations experience depends on the operator, right? And so I was actually talking to someone and advising them because they had so much familiarity with Bosch, I was advising them to go all in on the Cloud Foundry Container Runtime because their teams are set up to be successful with that. Their compliance regimes are all kicked in and they're like, yeah, but you're the Azure guy, you're the AKS guy, I'm like, yeah, but you guys are set up to win with this runtime, right? So I think all these answers are contextual, right? And that said, there are some things that the hyperscale cloud providers are gonna be able to do in the future that I think is gonna level up the operations experience and really get us to a place where you don't have to worry about it at all. And I think the reality is that today, for a lot of these systems, there is still demand on operations folks even in a managed Kubernetes sense. And I think over time, what you're gonna see is that is gonna sort of decrease. But again, I think it goes back to the context. Operations experience depends on who the operators are and what they're familiar with. Thank you. I will just would like to close this out with each of you just giving one key takeaway or one thing that you wanna leave the audience with, either question or your comments, anything? I'll just start and keep it very, very brief. So I like the topic, thank you again for coming up with the metaphor of blending. It really just all depends on what blending means. And there are ways that we can blend it today by actually just gluing things kind of side by side because there's value and then moving towards a more advanced way of blending. Yeah, I'd leave a comment then for the audience as well because there are a lot of efforts already going on to blend it. We've seen here, there's running it on Kubernetes, which you can try, there's the SUSE open source project. IBM has the open source project around then the Diego alternative. And then there's the services project which blends beyond Oz Bappy into blending the services. So wherever your interest might be, play in them. They're all open source and they only get better through more contribution. Yeah, I would echo that. I'm pretty excited to see all of these different projects already going on for blending the two platforms in different ways. And I think that's one of the benefits of having two open source communities, kind of two open source projects kind of coming together because we can just try out all of these different things and see which ones work. Yeah, so maybe to add on what Cornelia and Jeff said, kind of a marketing announcement to make there. So basically Chip Childers from the Cloud Foundry Foundation has called to set up a regular community call around all those topics because I think so far, different members of the community have been working on different aspects of that blending and then it depends on which companies have an interest in which particular aspects, but in order to get a better overview and also stay up to date with what's happening overall, there will be a regular community call. I think the first one will be scheduled and I think the announcement will go out via the Cloud Foundry mailing list for April 25th. So everybody who is interested in joining the effort or even hearing what's going on in more detail than what we were able to do now in 25 minutes should actually join those calls. So obviously the Kubernetes and Container guy, but coming to the conference here and hearing these stories and being witness to what Cloud Foundry has been able to do regarding digital transformation in modern enterprise is nothing short of amazing. And I'm just really thankful that this project exists and is working and things are happening. So I just wanna make sure that whatever we do with the blending here, we just make sure that we don't lose sight of the goal here, which is empowering people and empowering developers at modern enterprise. And that's almost a perfect transition to what I was about to say. So I mean, just echoing, yes, the blending is going on and if you are not already part of that in some way or form, you're all welcome to contribute and participate into whatever blending you think is the right set of blending. I would like to close with a sentence that basically says when, the sooner we get the blending done, right? The faster we can actually focus on higher levels of innovation that is really, really more important for the Cloud Foundry community or for the developer community that we all participate in. Because when you look at the lower level, like the lower we get in the stack, the more things will be getting commoditized, right? And that's not a negative thing. I actually think that's a positive thing that this is happening, but the value that we as a community will give out to the people, to empower the people, to empower productivity, the value is higher up the stack and that's what we need to get to and everything that keeps us, like every blending discussion that we're having that keeps us from getting up to those levels is not a waste of time, but certainly not ideally used time. So, thanks. Yeah, thank you. And as Bern mentioned, Chip will be sending out a note to the CFDAB mailing list about the special interest group that we're gonna start. Have a regular cadence, of course. Thank you so much for letting us know. If you have any thoughts or ideas or if you wanna participate in this whole blending process and if you have, this is how a community gets better and we're bringing two communities together and we're making it even better so we need the community's input. So, please do look for his email and join the special interest group. Thank you. Thank you, everyone. Thank you.