 Hello. I feel like Britney Spears. So I put up this slide back in Boston because how many of you here were in Boston for this panel? So only a few of you, not most of you. Okay, so back in Boston we did this panel and this is a sequel for the panel. First, a quick show of hands. How many of you here are familiar with the Will It Blend series on YouTube? Wow, good. Good one-third of the room. So Will It Blend is like a crazy, I guess, series where they literally put anything in a blender and try to blend. There's an iPhone edition, there's an iPad edition, there's literally anything. Any type of gadget, they put it in a blender and do it. So Byrne came up with this idea of let's see if Cloud Foundry and Kubernetes can live up to that kind of statement of Will It Blend? So we did it back in Boston and quick recap of that Boston panel. We kind of came to the conclusion after the panel discussion that it was more of an and a discussion, not or discussion like Cloud Foundry and Kubernetes, not Cloud Foundry or Kubernetes. And we also talked about like Cornelia also mentioned about the kind of where we came from, where we are today and how do we see this evolution, it's going to look like in the future. And I think Gabe, pretty much everyone, Cornelia, Jeff, Simon, we all talked about the importance of the experience, the developer experience, why it matters and how sometimes it really doesn't matter what the backend orchestrator is as long as the developer experience matters. There are certain cases where it does matter, but for most part it's the experience that makes a huge difference. And Megan, back when she was here also in Boston panel, she talked about how the community can benefit without having to learn two tools as two separate entities. She was talking about how the community can probably benefit a whole lot by having both the tools, both Kubernetes and Cloud Foundry having a shared goal. So today we have a slightly different panel where I'm going to change the slide. I don't have a clicker, sorry. So we have a slightly different panel. We have two folks that are new to this time. So we have, I'll start from here, Bernd, Simon, Chris, Cornelia, Ulrich. Ulrich, much easier. Ulrich, okay. And Jeff. So we have most of them as the same panel. Because the panel was Bernd's idea, I will pick on you first, and then I will have the rest of the panel share their thoughts. So this whole collaboration and our focus on interoperability and cross-community collaboration, it has been, it only has deepened since Boston. Like we have increased the efforts as a community. And even today our announcements of Project Irini and CF Containerization, I think there are proof points that we are doing that. And then we also have the Project Purpley that was also in the keynote and then Kibosh. So all of these things, what do you think? Did it blend? And if so, how did it blend? Was that a good thing or not? So yes, definitely it did blend and it did blend quite rapidly. Like even back in Boston, I did not imagine things to kick off that quickly. Like the projects that we have started together with IBM and SUSE, delivering already first results that quickly. But then also like other teams and individuals kicking in and kind of completing the pictures, the pieces that were still missing, the pieces where we pointed out, there needs to be some work done in the area of UAA. There needs to be some work done in the area of routing and networking, etc. So like if you look back now, half a year later, you essentially see that the whole Cloud Foundry ecosystem started working on individual aspects of that whole blending. And you already can imagine what next steps will be, how to combine those so far separate projects and what value that will create for the Cloud Foundry community. So yes, it blended very rapidly. I agree with you. The pace was something that I did not expect even so. Cornelia? So it's interesting. One of the first things that I'll say is that I don't view Cloud Foundry as the application platform. I view Cloud Foundry as this broader platform. And for those of you who don't know me, I've been working on Cloud Foundry for six years now. So before Pivotal, before I was formerly part of the product organization. But one of the things that I was reflecting on recently was the fact that when we began Cloud Foundry, and I say that in the Royal Wii because I wasn't part of VMware, but when Cloud Foundry began, it really began with this application abstraction. And everything else was an implementation detail under the covers. That's really the way that the product started. And so there, going back to my comment about, I don't see Cloud Foundry as only the application abstraction. I see that even though it started there, I see that it has this opportunity to be much broader than that. And when I think about these things blending, I think about it from that perspective. So it's a little bit different now because we have Kubernetes, gives a set of primitives where rather than starting with an abstraction like an application abstraction and making everything else an implementation detail, which, so two years ago, didn't matter that it was Diego because that was just an implementation detail. What we're doing now is we're broadening the applicability of Cloud Foundry to a broader set of workloads, not just the net new cloud-native applications. And so the way that I view it here is that Kubernetes, first of all, container orchestration is getting commoditized. I think that's very clear. And so Kubernetes being one of the options for container orchestration in the application platform, in CFAR, right? Did I get the acronym right? Makes all the sense in the world. And that was something where I agree that happened very, very quickly and I think that's great there. But now if we take Kubernetes and we say, what other workloads can we build on top of that and what are the patterns, we're coming at it from a building blocks perspective instead of everything's an implementation detail. And so there I think that for me, the blending of Cloud Foundry is an expansion of Cloud Foundry into maybe different abstractions layered over the top of a commodity container orchestration. That's a great perspective. Lily? Ralph and Cornelia already said a lot of good things that I would agree with. The one thing that I would add to it is I think the Cloud Foundry community has already, how do I say this, shared with the rest of the orchestrator community things like service broker architectures and now the Kubernetes Service Catalog effort is very styled after some of the constructs already in Cloud Foundry. So from my perspective, it's not just taking the raw Cloud Foundry effort and let's say the application runtime and making it work on Kubernetes but also making Kubernetes and possibly other communities to Cornelia's point really benefit from the experiences because at the end of the day it's all about apps. So I agree with that and the orchestrator is a very, very useful part of that and again thinking through how these emerging efforts around networking, native efforts and so forth are going to help the applications become more interesting I think is the trick to the whole conversation. Yeah, I would actually agree. I mean, what Cornelia has been saying is right. I think we're on a path, so going back to your question whether did it blend, the answer is absolutely yes, it did blend. And I would even go further and I would say still it continues to blend, right, because at this point in time we have like everybody of the previous speakers just lined out, we have some of the building blocks in place and some of them are coming together really nicely and there are some others where they're still room to improvement and when we're taking a look at what will happen as we move on forward, I would actually even go beyond the point of saying it's a question about Kubernetes and Cloud Foundry only. I would even go to the point where we're saying at one point in time and this is maybe a year out this is maybe just half a year out, I don't know what the pace, right? But it's not only just about the applications when you look at cloud native programming models when you look at functions, when you look at applications when you look at containers, why wouldn't we want to have a platform at the end of the day that spans from a programming model perspective that entire stack on a common set of technologies, right? And of course for us as a Cloud Foundry community it's going to be a challenge to some extent because now we have to watch out and we have to, you know even work more closely together with the Kubernetes community with the functions people that are out there in order to build that unified platform in order to build these unified building blocks such that we can deliver that kind of developer experience because what we and what Cloud Foundry does extra-extra-ordinarily well it's not that we created the best schedule for container schedule in the world, right? That's not what happened, but we're still creating the best developer experience in the world and that's the thing that we have to carry forward and we have to make sure that we are laying this out across these entire programming model paradigms. Very true, Chris. Well, one of the questions I have and kind of following up on your point is what else goes in the Blender? So maybe I'll be the one to talk about the Blender. K-Native, Istio obviously is already in the Blender and there have been talks today on that. K-Native comes along and adds a new programming paradigm and Cloud Functions. So it's going to be an ongoing question as to how these things are going to grow together and work together and that's one of the things that fascinates me is what we're going to see come together. And I think that goes to the point of Simon's that it continues to blend and to the expansion of the Cloud Foundry platform itself. Jeff, saving you for the last. Well, I'd like to echo that. I was pleasantly surprised how quickly things moved with bringing the teams together and the ideas, presenting them inside the foundation, getting them incubated. And so that initial step, those initial steps for blending worked really well and we're seeing some of the fruits of that labor at this conference. I like the CFEE in terms of production, OneDotto and other efforts around that. It is about what comes next. Yes, an Irene. Stick around for Irene next. It is interesting. I think K-Native is a great point and I think it addresses also some of what Simon was mentioning that it was interesting. So pulling off the services piece of Cloud Foundry, making that a multi-distribution, multi-platform effort was kind of picking maybe some low-hanging fruit and making it easy. The effort then on our side to become more Kubernetes-native is important. I think K-Native, we don't know what the K stands for, is a reaction. Well, the efforts from the Kubernetes side, hey, we need to actually think more about application deployment. And those of us that have been in Cloud Foundry for a while think, we actually have a really good solution here. Now, if we could blend these two well together in a native sense, so those that are very comfortable, hey, I need to think of Kubernetes as my base layer, but I still need to think of application abstractions and long-term lifecycle management of applications. I think kind of the next steps for us are, it behooves us to get more into the other communities to extol what we've known for many years so that we're not all reinventing the wheels all in different places that we can all bring together and play together. So there are some keywords I've been noting down here that each of you mentioned that kind of made me feel better about where we are headed, but also kind of brought me a little heartburn. So you mentioned about the pace that we didn't expect and the expansion continuing to blend, what else to put in the blender and that the initial steps of blending worked really well. So kind of taking this to a slightly different angle, is there something that we as a community need to keep in mind as the challenges? What should we be aware of as we go down the path of blending or expanding those capabilities of the platform and at the pace that we are headed with? Courtney Lee, I'll start with you. Yeah, so I feel your heartburn there a little bit because if we just take a look at all of those things that are going on and you mentioned many of them, at the beginning, I was just sketching out the other day a number of pictures of what, forgive me, propeller head here, of what the, if you will, the architecture would end up looking like. And if you just look at these different projects, there is the, okay, so we've got Cloud Foundry layered on top of Bosch, layered on top of IaaS and we've got different CPIs that go there. Oh, and one of those CPIs could be Kubernetes. Now, then who's managing the Kubernetes infrastructure? And then, oh yeah, that's right. Cloud Foundry could now either have Diego or it could have Kubernetes as the container orchestrator and so on. And so it became, there were, literally by the time you went through all those permutations, there were so many potential ways that Cloud Foundry, if you will, broader Cloud Foundry platform could be instantiated. And so that brings with it a tremendous amount of complexity. What is the right model for that? And so I'm a little worried about that. The other thing that really, I think we need to stay very, very, very focused on is that before we started blending even more in, it was relatively straightforward for us to break out the responsibilities of the people who interact with Cloud Foundry into two categories. It was pretty clear that there was a team that was managing the platform and a team or multiple teams that were using the platform, so the app team and the platform team. And as I see us becoming, see the architecture evolving in a potential way where it's a little bit of self-referential, I want to make sure that we as a community stay focused on the personas. What are the surface areas? What are the APIs? What are the contracts that those various personas use because a tremendous amount of the value of Cloud Foundry was the ability to create separate swim lanes for different parts of the organization. Let's not lose that as we start to blend this. Well said. Well, I was thinking, when we talk about application down and infrastructure up, and you made a good point, there's a lot of experience in the Cloud Foundry community to do things right for the application community, but the communities community or other infrastructure communities have also learned a lot of things and are bringing them together. So the blending also has to be not just a technical blending, also what are the new things we can do against serverless is just one of the paradigms that we have to incorporate. There's a new structure layer that would improve what Cloud Foundry can do. Again, we all know that Cloud Foundry is not the lightest weight environment, whereas Kubernetes and so forth can run on smaller environments. And so what can we do to effectively combine those also for the goodness of Cloud Foundry to improve based upon what Kubernetes or other orchestrators can bring. And that's the one thing which I don't hear a lot. I hear a lot of, we're going to take Cloud Foundry goodness off the Kubernetes thing. And I don't think that's the right attitude. I think what are the elements which can really help us bring the optimal things together. Josh knows, I've been harassing him for a while saying, okay, what's my edge model with Cloud Foundry? How do I build edge application? I don't think I'm going to build them on the current incarnation of Cloud Foundry. A bit too heavy, 50 VMs or whatever it takes, that's not going to happen on an edge. I think there's opportunities for us to work with the Kubernetes guys and bring application thinking to him. I like the idea or I like the point you make around the separation of concerns and making sure we don't lose these communities. But we also should embrace some of the lightness and flexibility that our friends from Kubernetes are bringing on many levels. Again, K-native applications or Kubernetes-native applications or Kubernetes-native will emerge and are emerging and so Cloud Foundry apps and Kubernetes-native apps need to communicate with each other and not through a very complicated, slow level it needs to happen naturally, for example. And so there's a bunch of those things where I think we need to think through a modular approach that allows really people to dive into the level they want to and not being forced to be, yep, this is just another orchestrator of the right model, given where we are. And if I could pile on very quickly there, I love the fact that you brought up the edge because one of the things that we talk about Cloud Foundry is we spend a lot of time talking about developer productivity and the developer and the developer. Some of us, even in the first round of questions, talked about the developer. Other people talked about the app. And I think that if you take the edge case that you just mentioned, for example, there's no need for developer productivity tools in the Starbucks location. There's no developers pushing code into the Starbucks location. But we do need, yeah, let's hope not, but we do need orchestration, we need resilience, we need all of those things, kind of those operation, you know, operational things. So yeah, I think that's very important. I totally agree. I mean, to one extent it would be the total wrong approach just saying, hey, here's what we have and we're just going to dump it on something else. And I don't think the Cloud Foundry community is actually doing that. I mean, when you look at just the discussion around the go-router versus Istio, the stuff that Irene does with changing Geego for Kubernetes, I think it is not like a, well, like lift and shift kind of architectural thinking that we're doing here. On the other hand, what I really want to point out, this is going back to what Cornelia has been saying, besides how we are building the stack, and I totally agree, there's room for optimization and room for making this more lightweight and room for making this more slim and more effective. We have to, one of the things and I just had this experience today or a few days back when I was trying to set up a container, container networking stuff on Cloud Foundry versus on Kubernetes and the developer experience, of course, and I was kind of like having two hats on when I was doing that. On the Kubernetes hats, I had to go and I had to do a bunch of YAML files in order to make sure which container can talk to what container and do these kind of things. It was more like, I felt more like a network engineer in a traditional operational role than a developer. Then I tried to do the same thing on Cloud Foundry and I got to the CLI and I was doing a CF networking allow command and it was doing the same thing which felt way more intuitive but again less control. So the value and the strength if I do not need that level of control down to the latest bits and to the whatever legacy operation teams, firewall policies we might want to support on the down layer of Kubernetes, if we are doing this stack right we allow progressive disclosure and I think that's what we have to get to. I agree with that. Another interesting aspect, we are getting smaller in terms of the work, the blending work is making Cloud Foundry able to be lighter weight mixed with Irene, it can be really lightweight and very very native feeling in the Kubernetes experience. There is still more work to do along with that but it's getting very close and when we are there it is the next steps and figuring out how to blend the communities but we have actually seen this already work well in between Cloud Foundry and CNCF with Istio because that was a give and take when Istio and the Go Router teams work together there was an influencing on both sides of the code bases because there was stuff to be learned on both sides and that's what I'm hoping is that in next steps around the app developer experience, the application management experience, we'll be able to share the same way. There will be things that will probably influence Cloud Foundry still but we can also then bring to the Kubernetes community more of that app experience. Maybe to add to that slightly different twist on things so on the one hand as a person working with technology I'm obviously excited in all the blending and the speed etc but then I think on this stage here there's people that are also operators of those systems at the same time and also for the developer sitting on top of the platform, one thing is of utmost importance which is keep their business going IBM as well as SAP are in that business for quite some time and so all the blending and exchange of technology components happening one important question is how to keep developers doing their stuff and keep applications up and running all the time and I think that is definitely a stretch that we will also face because yes at some point in time we could say hey this Kubernetes thing is all cool and let's just throw away important pieces of what we have today and kind of spin up something new but that means downtime and this is something that business applications won't be able to allow so going back to your discussion of the architecture I'd love to see your diagrams someday but one of the things that strikes me we've all been around the technology space for a long time when you have all these pieces that can be added together and layered one of the things that customers frequently ask is okay but tell me the right answer I don't want to know that I can twiddle this knob and flip that just tell me the answer so one of the things we should look at is what's the blueprint or maybe there are multiples maybe for an edge it's a simple one and maybe for a large set of applications it's a more complex one but again customers want a simple answer and the people that do want the knobs want the knobs and the other people just want to know just tell me yeah I mean we've heard Kelsey Obeda say kubernetes is a platform for building platforms we don't want to just give people a whole bunch of Legos and have them build their own platforms that's part of our challenge is to figure out CF in the traditional sense the PAS is one of those platforms functions is another one of those platforms and so what are those additional ones that provide value to the industry and our customers in this setting I'm not sure in Boston we did questions from the audience but I'm not sure here I do have one last question before we see if we have time left and we can maybe ask someone to yell a question out between now and our next summit in April in Philadelphia where do you see things going like where do you see this whole progress going and what should the community I know we already talked about what should we be wary of but where do each of you see this progress headed towards as we get closer to Philly so definitely I think we will see the projects that have been kicked of evolving and that won't slow down that will accelerate I think we will also see more of the impact of things like Istio and Knative will have to the overall discussion in terms of how important will those pieces be for a future evolution of Cloud Foundry and I think they will be very important so I think as time progresses all the people that are working in the ecosystem will learn many things about those systems that we are about to build and those will be good and bad and it's about continuously correcting the course as we go so I think we will kind of end up at the next summit in a slightly different place than we would project if we kind of forecast today. I like the continuous iteration aspect I think that's extremely important as we figure things out as we go also as we head to the next summit not just where we are headed but also where should we be headed from a technology or community perspective or both or both so I mean from a technology perspective I burned probably covered it at least from my point I mean we have we're boating the platform together and we're now about to tighten the screws wherever that's needed such as become something stable at the end of the day I think what we need to pay attention to as we go forward in the upcoming months is really from a community perspective to make sure that we are I mean not saying we're not open but we have to be even more open to watch other communities engage in them, collaborate with them and make sure that we are also getting a blending not only on the technology side like hey there's this great technology that Community A-Builds let's pick this up and bolt this into our platform somehow but make the community level engagement really pay focus to that I think that's one of the things where I would think between now and next April where the focus has to be. That's a very important point I think it's not the technology it's not just the technology the people aspect as well that have to be more transparent about the initiatives that are within the community and across the communities. Chris? Actually I would just echo the things that these two gentlemen put out the first is on the technology side both Knative and Istio and specifically on Istio we're seeing real deployments now customers playing with those and seeing how they operate Knative is newer but then just again looking at what the customers are doing how they're using these projects that are coming out and gaining that knowledge and let it help us decide where to go. I think that one of the things that I will become very important to add to the blender that is being added to the blender is the ISV ecosystem. In the past it has been all about providing services to the PAS user so the service brokers and being able to say oh I'm building a net new application and I need a database or I need a message queue. What's happening now is with Kubernetes being a platform that is going to host many other workloads it brings a different angle to that marketplace. I think more and more ISVs are going to start to run their applications on top of the platform I would like it to be the expanded Cloud Foundry platform what does that mean and what are the patterns that we're going to emerge from that. I want to actually pick up something that you said I think it would be really useful to think through what the developer experience of the blender is and what the operator experience of the blender is at these various levels that Simon kind of pointed out. People will need knobs for certain scenarios but you want to hide them from the developer so how does that really work. What can we do to preserve some of the elegance that Cloud Foundry has brought but still bring the power of the Kubernetes interface or environment into the system and make that blend as well while keeping it separate which is going to be a fascinating little thing but I think that's an important one. I mean just to agree with a lot of what was said but thinking concretely just six months from now it would be nice to see there's a lot of stuff that we've seen today people with real depth of knowledge are able to stand up and create production workloads with this. In six months I'd love to be able to say a hobbyist or innovative thinker in a large org that only has a little bit of resources can set up their own production confidently set it up with just a few lines and be comfortable that what they have they can then advocate it within their organization. I think is a concrete next step. I'd like to reach. The timer is flashing that we're out so I'm pretty sure all the panels will be around at least for a little bit after the session so if you have any question or follow on thoughts please feel free to walk up to them and ask them. Thank you very much for joining us and thank you very much for joining us. Thank you.