 All right. How many of you here have been in this whole blending discussion over the last two summits? Let's start with Basil. How many of you were in Basil? Boston? OK, so most of you are pretty brand new to the blending discussion. Wow. That's impressive. Just to give a quick heads up, the blending was, it started as Bern's idea of starting the discussion or the conversation between mainly Kubernetes and Cloud Foundry blending. I don't know if you all are familiar with the Will It Blend series. If you are not, then please go to youtube.com and look up Will It Blend series. It's phenomenal, fascinating, very entertaining. This is not like that. We are not blending anyone's iPhones or anyone's iPads in the blender. But it started as a discussion like that. And we did it in Boston. It was pretty interesting. And there was a lot of interest. So we continued to do it in Basil. Again, got a lot of interest. So Bern did, OK, third time's a charm. We'll do it again. So we are here again. I'm not going to go through introductions or anything because that will take pretty much half the time. I'll start with Cornelia. She had a really great question. So I'm going to go with you first. Over the years, at least for the past year and a half or something, what have we learned from all this blending? Yeah. I mean, I think that's a really great question. I love that. And then the follow-on question, I think, is even more interesting, which is what have we learned that we need to learn still? So I mean, I think that there are a few things that I would say that are quite obvious. And that is that container scheduling has commoditized, that we've learned. And that the idea of switching out the Diego container scheduler is with something like Kubernetes, sure, that makes sense. And that's something that we can do. The other thing I think that we've learned not only through the exercise of having tried out things like Irene, but another thing that I think that we've learned in the community is that there is an absolute driving need for what we've been doing in the Cloud Foundry community for the last five or six years. Yeah, without question. And I actually noticed that significantly at KubeCon in Seattle in December, because I started hearing people in the hallways and in the sessions talk about developer abstraction. And I think for a long time, there was this perception that Kubernetes was for the developer. And developers do love it because they love to play with technology. But I think there is really now this acknowledgement that Kubernetes is not a developer abstraction. It's an infrastructure abstraction. And I think that's one of the biggest things that we've learned. And when I started to reflect on the panel today, my biggest takeaway was that what we've done in Cloud Foundry in providing a set of outcomes around an abstraction that really makes all of the infrastructure concerns go away, that's been proven. And so now, how do we bring that together with the Kubernetes community? Irene is one experiment, but I think that there's other ways as well. Absolutely. So did you find in those conversations with Kubernetes users that they had maybe a preconceived notion of what Cloud Foundry was about and that they didn't really understand that the projects that are happening in the Kubernetes community to build developer abstractions are basically work that's already done. What I found with those similar conversations was like, we've been doing this since 2011. Like, all of these lessons we've learned seem to be being ignored, or not by everyone, but there's a certain component of people in the Kube community that just don't realize that some of the things that they're doing in a few different places are actually solved problem. Yeah, no, I totally agree. I don't think it's that they're ignoring what we're doing. I think it's that they weren't aware of it. Cloud Foundry is a relatively small community, especially when you compare it to the vastness of the Kubernetes community. And so I also think that a fair number of the Kubernetes community come from an infrastructure background. So they don't know what they don't know. They don't know this is kind of new for them, this idea that there's a higher level abstraction, even higher than what Kubernetes offers. I agree. And I think that's exactly the thing that's worrying. I completely agree, right? You ask around here, who understands what Kubernetes is? Most hands will go up. But you do the same thing at a Kubernetes conference. What's Cloud Foundry? A few hands will go up. And the dangers that I see for Cloud Foundry is that they are understanding the need for what we've built. And they are duplicating the same thing over and over again in several different spots, several different initiatives, not understanding what we have. And I think I'm not sure how to do this, but I think we need to somehow tell them, look, we've done a lot of this. And as a matter of fact, with projects like Ireney, it fits nicely, complements what you've already built over here. I was going to keep this question until the end. But since we are here, we've always thought of these kind of things, right? What are the different things with Kubernetes that we can integrate with? Or how can we blend Kubernetes and Cloud Foundry? But how about the other way? Like, how can we take Cloud Foundry into the Kubernetes community? What are the specific things that maybe we'll start with you since you started it? What are the specific things that would be beneficial or would be the starting points for us to make it more resonating with the Kubernetes community? Well, as a platform provider, one of the things I think that we're thinking about is how do we make Cloud Foundry discoverable out of the Kubernetes experience? We have plenty of people coming to us to instantiate Kubernetes as a service. And there's Cloud Foundry sitting on the side, but they don't know what that is. So why not expose something like Cloud Foundry as a plug-in, as an added experience, as a layer on top of premium experience on top of Kubernetes, and try to even make people aware that this actually exists? So I think we somehow have to make Cloud Foundry discoverable by people who are already using Kubernetes. The whole fact that CF is boring and invisible is not working. And in a sense, it seems like gaining that mind share comes, at least in part, from adopting components of Kubernetes. And I think a question I had was, and you were, I think, alluding to this in your question, Sorna, we're looking at things in Kubernetes to bring in to the CF world. Are there things in CF that could be brought in to the Kubernetes world, and that gaining mind share seems like the right way to do that? And it's more than just messaging. It seems like embracing technologies and building trust. Bingo. I think it doesn't serve us well if we take the feeling of, okay, well, we've got the Cloud Foundry community. Why don't we just bring, I think we have to bring ourselves to the Kubernetes community bigger than we are. Yeah. And for me, it really starts with Cloud Foundry needs to be available for the Kubernetes community in the very same way that other components on top of Kubernetes exist, like the same way how I get an Istio to Kubernetes cluster, I need to be able to do that with Cloud Foundry as well. What if you could kubectl Cloud Foundry? Yeah. Right? What a great idea. I think going back to the first question of what's been learned, I think one of the things we can learn is hype-driven development is a problem. And hype-driven development is a problem. And what I'm hearing here is, let's take the since 2011 learnings of Cloud Foundry and bring that to the hype, right? Because the reality is we're here customers, they want to know about Kubernetes, they want to know about how Cloud Foundry is, or how a Cloud Foundry customer is going to live in a Kubernetes world. And as soon as those customers realize everything you've been talking about here that Kubernetes doesn't provide anything like Cloud Foundry does, the customer starts asking for a different thing and you got close to it. They initially, I think the reaction was, let's jam these things together. I mean, this whole, does it blend? If you haven't watched the blending series, it's what it originally was. The initial arguments over Diego versus Kubernetes or even outside of this ecosystem, Mesaus versus Swarm and Kubernetes. You know, all these are old arguments now. And the whole Diego versus Kubernetes will be an old argument soon too. Because customers are starting to move into production at scale. And funnily enough, Cloud Foundry has been doing that for a long time. Yep. And so let's avoid hype-driven development. That for me is the number one lesson. And let's focus on customer-driven development. There's a lot of customers in this space that can tell us what we should be doing. Yep. Wouldn't that be awesome? Beren, you mentioned about Istio. So tell me a little more. We see a lot of these kind of concepts, right? But Istio in the resource labeling and the routing tier, et cetera. So how do folks, both within our Cloud Foundry community and outside, like within the Istio community or the Kubernetes community, see this happening? How do they see this unraveling? Yeah, I mean, Istio is another technology that definitely stems from the Kubernetes space. And I think primarily, initially folks at Pivotal said, can we look at that component and use it for the benefit of Cloud Foundry? I think we are now at a place where one thing that you could do is take Istio and bring that into the Cloud Foundry world, like build a Bosch release for it, et cetera, et cetera. That might be one possible path. I think the other thing that we see on the other hand is like, do we even need to do that or can we just use Kubernetes and Istio as the Kubernetes community would provide it and kind of leverage that for the benefit of Cloud Foundry? Yep. So kind of, this thinking makes, like, mutual reuse of components easier. Like, you don't need to always pull something out of its native ecosystem and bring it over, but you could basically keep certain aspects where they live and where they natively live and then just put Cloud Foundry concepts on top of that. And Istio is definitely one example where this applies. Yep. And I think Istio, as it relates to Knative, is a particularly interesting area where it's a little bit higher level of an abstraction on Kubernetes that aligns more closely with what Cloud Foundry generally does well. So I'm curious to see where we have opportunities to mesh there in the future. You know, there's one thing that I find it interesting that you bring up Istio as well is there, the technologies and even Knative, the technologies that we're talking about here are all things where we as the community have started to build other capabilities all around the central construct of the value of a container. And the fact that we've been doing containers in the Cloud Foundry community for longer than it's been done in the industry, sure Google was doing it, but doing it behind closed doors, the fact that we've been doing it in a platform for a long time, but that's just been a hidden implementation detail, was great. But now that the world is enamored and is starting to understand what the primitive of a container can bring for them, the types of things that they can do because they now have containers to play with as opposed to processes that are running on some machine abstractly somewhere. I think that as we bring our IP over into the Kubernetes community, doing so and saying, yep, containers are awesome. Instead of hiding that away as an implementation detail, leveraging the fact that everybody's enamored by containers, because they're not enamored by containers just because of a hype cycle, it's because it brings real value. Troy, you're closely involved with Irene as well, right? So how will Irene and Diego evolve in application on time for us? I don't know. IBM had a wonderful talk, just, I think it was here, or no, next door, just before this on Diego or Irene, which do you choose? And it was very, very well, it was fantastic, fantastic rationales for why you would choose one or the other at this point in time. So that wasn't when I was talking about this with you earlier. I wasn't actually what I was thinking. I'm thinking about down the road, if and when we prove out Irene as the best container scheduling for Cloud Foundry, do we retire Diego? Do we take out a portion that we, then we save the effort, because it takes a lot of effort to maintain these big pieces of code that were developed for a very real need. Now that they're commoditized, maybe at some point we can look at taking out pieces that we will no longer have to maintain as a community and start building new value. And that's the thing, because this is a big project. There's a lot of coding Cloud Foundry, and especially for vendors who are maintaining distributions of this, there's a lot of work to do just to keep the customers happy and supported long term over longer cycles than our tip of trunk releases. Keeping that maintained is gonna be a challenge as we add functionality. I mean we can keep adding people to the foundation and that could be great, but at some point the project might get too big to manage. If we can consume these components from elsewhere in the ecosystem discreetly using their public APIs, using the APIs that they're meant to be used with, we can lower our cost as a community for maintaining the software code base and focus on adding new value and new features. What is that value? Like what if 80% could be offloaded to existing components in the Kubernetes community? What could we deliver with the reallocation of the resources that we're maintaining that? Is it making the developer experience even better? I'm curious what you think. I can't, I have a couple of ideas. I don't have all the ideas, but I mean we have been touching on serverless and function as a service throughout this, throughout this, in much the same way that a couple of years ago we were touching on the idea of Kubernetes. Now we're talking about Knative. Now we're talking about function as a service frameworks that can plug into Cloud Foundry. How do we expose function as a service within Cloud Foundry in a way that people who are already using it can take best advantage of? Or do we bring in a really popular function as a service open source project and just make that the function as a service that we all agree to use? And that obviously might be Knative. That might be Knative bringing that in. And then all sudden you're going to have a, Cloud Foundry CLI allow scale to zero true and then all sudden you're functionless. You're using serverless. And we've had the first conversations about that is what would that look like if your Cloud Foundry app worked like a function. And we're discoverable like functions are with a function as a service platform. So those are the kinds of things we can start looking at. Yeah, I wanna build on that a little bit. You mentioned APIs and standardizing across APIs. What that does is it unlocks a whole load of things that we don't know about today. So for example, Cloud Foundry today, you're not gonna be running this on edge computing devices. It's just not gonna happen. Kubernetes isn't ideally suited to edge computing devices the way it is today. What are we gonna unlock by bringing the scale that something like Cloud Foundry has proven with those standardized APIs that we can then leverage in new places such as the edge. So I think the question is really, really important. And the reason we don't have the answers is because we're talking about technologies that have been opened up by this activity. We were really only starting to play with Irene very recently. And one of the things that Irene is based on is the orchestrator provider interface. And that was conceived as something that could allow you to connect to any orchestrator. So maybe we find an orchestrator that can install things on edge devices for a certain class of applications. I mean, I'm just throwing crazy things out there. Yeah, you said maybe. But... I guess another intriguing thought is obviously like the way how people run Cloud Foundry today is that like if you run a globally distributed system you have different foundations being deployed across the globe. How about having one Cloud Foundry control plane and then Kubernetes cluster sitting in all places around the globe and kind of using that control plane to distribute and harmonize things, harmonize deployments, roll things out in one cluster, test them there and then kind of open up to the whole world. Which obviously brings up the question of are these still separated deployments or do you need to have kind of globally available and accessible backing services next to it? What about global routing, et cetera, et cetera. But like that is at least a step in the direction of saying you don't have completely separate local deployments of Cloud Foundry running. Or we could put all those people that are freed up onto the V3 API on that. And there's another category as well. I think that there's certain use cases that every single one of our customers have that we haven't been touching upon. So for example, offloading from legacy databases or connectivity and domain frames or something like that, what does the developer API look like for that? It's not SOA, right? And but we as a community have done a remarkable job and made a lot of people successful with this very simple developer API around cloud native applications. What does the developer API look like when we start to expand into a broader set of use cases? I think it's really interesting. I think we started out talking about adopting some Kubernetes concepts as a mechanism to gain mind share in the Kubernetes community, which is valuable. But there's this other angle here, which is by addressing the undifferentiated heavy lifting and offloading that to existing things. We open up the capabilities, the capability to explore into edge computing, global routing and all of these other, and I think that it's really good to have those two motivations, you know, a community alignment, but forwarding the technology in a really meaningful way. And I think one of the possible directions is we have to keep moving up the stack, right? I mean, we've always been about the developer experience. So as things below commoditize, we move up the stack, brainstorming here. How about something like the spring framework? What if we take something like the spring framework, which is something that sort of gives a developer these primitives that they need over and over and over again, and taking building blocks like this, maybe making them language independent or something like that, and sort of making developers more productive in that way, building something like that into the platform, right? But I think we have to move up the stack, make the developer experience even better while things below us commoditize. Ross, you mentioned earlier, customer driven development would be a lot better than head driven development. So kind of picking back on that question, I was making a note, how does a Cloud Foundry user benefit from bringing Kubernetes into the ecosystem? Like what are the things that they would find it? I think there's a short term and there's a long term answer to that. And for me, the short term isn't a great deal in all honesty, because Diego works, right? And it works at scale. Why replace it for no immediate benefit? The long term, though, is where the real value lies. By doing this short term work with no real benefit that we can see, we open up the things we were just talking about. There's a whole load of things that we as a community here aren't necessarily going to address because we're dealing with existing customers, we're dealing with existing style things, but we all want to move forward. And there's an awful lot of momentum behind that hype, right? And you're absolutely right to call it out. It's not just hype. There is a lot of reality inside of that as well. And so what the customer benefits from is an unlocking of that activity. You refer to the emerging or the bringing together of the ideas in the two communities and so on. That's what open source is about. It's about innovating across different teams, across different goals. And that, again, is the benefit that we bring in the medium to long term thing to customers. We as engineers and product designers and all the different titles we have in the room, we can deliver solutions that customers don't even know they want yet. And if we don't do this, we might not be able to do that because we're not able to bring that integration across different solutions. And Baron, kind of a corollary question. How does a Kubernetes user, I think it's already been discussed, but how would a Kubernetes user find it valuable to bring Cloud Foundry into their ecosystem? I mean, Cornelia mentioned that already. Like there's many people in the Kubernetes ecosystem who seemingly are kind of reinventing concepts that are already established in the Cloud Foundry world. And I guess my standard question to people saying, I can just use plain Kubernetes is, like, do you really want to deal with those low level constructs? Like, do you really want to deal with operating system updates, rolling updates, blue-green updates, et cetera, et cetera? Or do you want to focus on developing your business logic, your business application, your business services? So if they're building everything that's already existing or that has already been built by Cloud Foundry ecosystem, are they, is it resume-driven development now? Like, has it become, has it come to that? Maybe a bit. And yeah, that's kind of a controversial question, I guess. But yeah. I have to ask. Referring back to that hype-driven development, you definitely also see that in the resumes, right? Like, certain keywords. I won't lie. I'm glad I can put Kubernetes on my resume. I'm not looking. I'm not looking. But I'm glad that I have Kubernetes on my list of skill sets. I mean, none of us in this room would argue against that. But it's because it's a, not only because of the hype, but it's a very valuable skill set to have because you can do so much. And something I saw several times last year was this hype-driven development has led to FOMO-driven adoption. Where if you're making this, this big, and I feel so good that I can use it. I like that. I'm gonna steal that one. But I mean, it is this conscious recognition of we're choosing to undergo a digital transformation. We're not a technology company. And we know that Cloud Foundry solves its problems for us, but we can hire Kubernetes people. It's everywhere that the community is so big and so we feel like we don't know that Kubernetes will give us what we need, but we're gonna place our bets there because it just seems to have momentum. No one was ever fired for buying Kubernetes. It's the new thing. Is that the new thing? That means, at least now. It's the safe choice now. As of now. We're all gonna tweet it. How far will this blending go? We will start with you. How far, like, what will, I think it was, just to give a little more context. I think Jules once tweeted that Cloud Foundry is like this massive ship where there's different parts and individual elements can be replaced or can be made more pluggable. So how far will this blending go and what will see Cloud Foundry remain as? That's an interesting question. I think it could go several ways. So first of all, I don't like the term blending that much. It's more like a well-constructed layer cake. Burnt? Yes. Blending sounds very messy, right? It's your fault. I know, I take the blame. We are renaming this panel from next time. So I think what we're seeing sort of is as new technologies mature, we're taking them in after they become production-ready, and now it's Istio, it's Kubernetes, I'm sure we're gonna be looking at Knative and things like this next. And then I think the question remains, what do we do with that freed up developer resource? Either we can move up the stack. I think that's one option. The other option is that Cloud Foundry sort of becomes this curated set of open-source technology that work well together. A lot of customers that we talk to tell us, we look at this gigantic chart of all these open-source projects. Oh my God, which ones are the right ones? Should we get some of each? Help us. And Cloud Foundry is an opinionated way, just like we have guardrails for developers. We have sort of an opinionated way of these are the projects that go well together. These are mature. This is how you put them together. This is how you deploy apps onto them, right? That might be the other thing that Cloud Foundry is gonna become over time. I hope it's gonna be more than that. I hope that we're moving up the stack and making the developer experience even better. But I think the danger is that that's where Cloud Foundry is gonna remain at some point because it's gonna get hollowed out more and more as we're adopting these things. Yeah, but what's interesting about that, I completely 100% agree. The way that we've expressed that opinionated stack is through code. That's what we've done up until now is that expression of the opinionated stack was in GitHub, in CF release. And all of the pieces were there. And now as we express what that looks like, it's actually in many ways a much harder problem if we don't own all of the components that make up the Cloud Foundry stack because now what we're talking about is we express that opinion through some form of integration. It's not a white paper because white papers aren't something that somebody can just download and issue a few commands. But what does that look like? Cloud Foundry becomes an integration and we probably, well, almost certainly need to invest in some tools that are glue tools, that are integration tools, where before we just expressed it all in the same code base. And this also brings up an interesting question about certification. Certification until now has been you ship these bits because the Cloud Foundry bits. Now if we're starting to sub out components, and this is starting to come up now, we're just having these discussions. What qualifies a Cloud Foundry system as being certified Cloud Foundry if it's using different backend components? And I think the answer is API conformance and tests of those APIs through a really robust and extensive test framework. More than just cats, you know, something that really tests everything a developer or an operator can do with this system. And that's a lot of work. I admit that's a lot of work. It's in fact easier to say just ship this code that we've all agreed and that we're all working on. But if now we've got two things, two components that do the same thing, how do we ensure that they do exactly the same thing and that a customer who goes from one distribution to another or from one Cloud provider to another is gonna have the same experience? Because that's the huge value that we bring against all of these upstart passes in the Kubernetes community which are well conceived but there's a lot of them. And there's a lot of people working together on Cloud Foundry and that's a huge thing. And we wanna keep that consistency while allowing us to use these commoditized components and to do exploratory work moving up the stack which is gonna bring in different technologies either from CNCF or from even elsewhere. Yep, great. Okay, you're exactly on the dot 410. I was hoping to leave at least enough time for a question or two but since we have a huge panel I will let the rest of the folks kind of connect with each of them individually if you have a specific question to any of them. I'm pretty sure we can, the folks will be here for a few minutes. Yeah, for a little bit, sure. So, thank you very much. I really appreciate this. This has been the third time and it has really worked. We will probably start working on the renaming maybe call it cross community collaboration or something like that. Or cross collaboration. Like the layer casing. The layer casing. Layer cake is good. Layer cake. Okay, layer cake is good. I know when layer cake is good. What comes out of the blender? Smoothie. Smoothie. Smoothie. All right, thank you so much, y'all. Thank you so much. Thanks for joining us.