 So this is the part of the day two keynotes where I'm supposed to look out in the audience and count you, and then point out that half of you left your buddies at the bar last night, I think. For those of you that made it, welcome, good morning, thank you. Before I get started, I wanted to take a moment to remind you to please, you know, go visit the sponsors that are out there. They make this event possible. This is not something that we make any money on. So we are really thankful for everything that they do for us, for you. They allow the community to get together. They allow you to have the learning experiences that you're having today that you had yesterday. So please, just take a minute, talk to the sponsors, let them know you appreciate it. So today, what I'm going to talk about is a little bit of a history lesson, as well as a little bit of a view into the future of the Cloud Foundry platform, the Cloud Foundry family of projects, and talk a little bit about some of the philosophies that the project teams have embodied for years now, and how they relate to a lot of the newer more, the newer open source projects that are part of the larger Cloud Native open source ecosystem. And I titled the Talk Building Bridges, and we'll come back to that. So history lesson. Can anybody see that? Yeah, 2009. Not that long ago, right? Nine years. But there were some interesting things happening in the technology space back then. Netbooks were the rage. Anybody here have a netbook? Yeah, a couple of you. They were the rage. Also, our mobile phones started to do things like have maps in them. That's pretty cool. Anybody here not actually walk around Basil with the phone out trying to go, I think we're going this way, right? Become a very different part of our life. The app store became very important. It wasn't just the Apple app store. There was a number of different app stores for different device platforms. That became the new way to think about software delivery for consumers, for individuals. But also, at VMware, we managed to find the oldest logo we could possibly find for VMware. At VMware, a project started that was called B29. This is the beginnings of the idea of creating the Cloud Foundry platform as a service product that we know today, the project that we know today that's been incorporated into Pivotal Cloud Foundry, SAP Cloud Platform, IBM's product. Everybody's product is based on this original idea from back in 2009. That's not really that long ago if we're talking about history, but I guess in tech industry, it's like a month is the equivalent of a decade these days. We really do have a very long history as a community, as a project. Even before it became open source, there's a deep rich history behind the project. Fast forward to today, Abby yesterday was talking a bit about the challenge that the enterprise has today. We're at an inflection point. We know that most organizations now are focused on adopting Cloud, adopting Cloud native technologies, whether it's on-prem, off-prem, public Cloud, mixing and matching. It's a bit of a mess for them. It's really hard, actually, because you have to get things from your vendors. I love all of the vendors in the room. Clearly you're trying to solve these problems for your customers. But it is very difficult because you also have internal team pressure. You also have third-party open source projects that are confusing. There's a lot of things going on. We have tried, as the Cloud Foundry community, to help at least make the part that we touch a little bit easier. This isn't me. These are the contributors. These are the committers. These are the project leads that actually build the software. They spend a lot of time thinking about, what does it mean to create enterprise-ready software that's pretty close to productization? The downstream distributions are able to productize, that someone can use directly as open source and get a lot of value from. They focus on things like security, scaling, integration, ease of use. Really ease of use is about that developer experience. That's the haiku. Here's my source code. I'm on the cloud for me. I don't care how. The other thing that the community focuses on are these three areas of, I guess, philosophy. We're a super-fast project. Abby talked about that. We release frequently. Large amount of code change constantly happening. The architecture evolves constantly, and we'll talk a bit more about that. There's a lot of interoperability. There's two different ways to think about interoperability. One of them is to say, does it conform to standards? Does it use CNI, the container networking interface? Does it use different standards that are applicable to the architecture? The other way to think about it, though, is is it able to be well-integrated into the traditional enterprise environment? Because the way to think about software or any technology that's been deployed inside of a large enterprise is that you're probably never going to turn it off. We need to be able to integrate these things well together. The last is innovation. Innovation is something that you don't design innovation into a process. I think what you do is you design the opportunity to take advantage of moments of innovation that occur. Those are to me the three ethos that the community of contributors, community of committers have across all of the projects within the Cloud Foundry Foundation. The title of my talk is Building Bridges, not in a literal way. Everybody knows what this bridge is, right? Yeah, the Golden Gate Bridge. Golden Gate Bridge is interesting for me. I don't live in the San Francisco area, I live on the East Coast, and so I've kind of been learning the San Francisco geography. It's an interesting bridge for me because it connects two really different communities. One of them is the city of San Francisco, and then across the bridge is Marin County. And for quite some time, there was no connection between the two. You had to go all the way around this enormous bay to kind of get from one of these communities to the other. But when they agreed to build that bridge, the economy started to grow a bit more between the two. And it's a powerful thing connecting two different communities. Now that applies to the open source world as well. We don't have to talk about physical bridges, we can talk about metaphorical bridges. We can talk about collaboration amongst communities, amongst projects, amongst teams. And it's something that is key to the Cloud Foundry Foundation's community and how we've evolved since 2015, and even before that. So here's a little bit of a history lesson. Before the Cloud Foundry Foundation existed, I was not involved in this project, this community. I think I had written a service broker back in about early 2014. Before you could do asynchronous, it was a little difficult, but I got involved. And when I joined in 2015, there were a few integrations that had already occurred. Let's call them bridges. One of them was that, of course, it was using Linux containers way back in 2011. Remember before Docker even existed as a word. So 2014, the idea of being able to push a Docker image into the application runtime, or what we just called Cloud Foundry back then, was a key part of the system. We were starting to explore what it meant to move beyond just the CF push experience of code. So fast forward a little bit. Let's talk about some of the, I guess, the last two years worth of bridges that have been built. So for those of you that are familiar with the Open Container Initiative, it was an effort that was created inside the Linux Foundation in order to try to rationalize some of the tension in the tech industry around Linux containers between Docker, CoreOS had their rocket runtime, there were debates about what process was going to start, what process and who was in charge of watching, what PID. And so the Open Container Initiative was really about hosting this core library called Run C, which was at the heart of the Docker engine. And also to create an image specification. So Cloud Foundry has the distinction and the honor of being the second platform to adopt Run C after Docker. So we were basically the first ones to say, you know what? That's a great standard. Let's adopt it. Fast forward a little further, November 16. We start supporting the container networking interface. This is an early standard, but we realize that, yeah, we're running applications in containers and we need to find ways to work with underlying software-defined networking systems. And CNI seemed like the right approach. Little further, we spin out the Open Service Broker API, open that up so that the Kubernetes community or any other community, all the public cloud providers can begin to take advantage of that abstraction that's been so powerful for Cloud Foundry over the years, we open that up. And you've probably seen demos of whether it's Microsoft showing off their service broker and how you can consume it from Kubernetes using the service catalog extension or whether you can consume it from Cloud Foundry application runtime. Other providers have also demoed similar things. It's become very powerful. So that was a bridge that we built. In May of 17, there was a project called Kubo that was announced. It was a joint project between VMware, Pivotal, and Google, which was how do we use the power of Bosch to actually deploy Kubernetes, manage it, upgrade it. That became the Cloud Foundry container runtime. Another bridge was built. That was our first step as a community in actually adopting or embracing Kubernetes. I'm going to kind of go a little bit faster through some of these, but we've done a lot of different things. So you're going to see a demo from the project teams that are focused on the Windows technology stack, the Microsoft technology stack. But one of the things that they did was they worked on WinC, which is how do you take RunC and bring it to the Windows platform. We also have already integrated Envoy Proxy, Istio integrations currently being tested. Our community is helping with use cases that the Istio ecosystem needs to understand around scalability. And then Kubernetes is starting to get a little hotter. You saw two announcements yesterday. Abby talked a little bit about two of the incubating projects. I'll explain them a little bit further in a few minutes, but clearly Kubernetes has become the standard for the container abstraction, right? Infrastructure as Linux containers. And so it's really important that we continue to explore different avenues for integrating with, working with, and allowing Cloud Foundry to consume that infrastructure. Little further, container deintegration has begun. And then more recently, if you haven't seen the news, I think this is perhaps was a bit underplayed. It's perhaps one of the biggest moments in the platform as a service space in quite some time. Buildpacks, which was originally an idea from Heroku, were incorporated into Cloud Foundry. They're part of the power of that CF push experience. That CF push experience, though, started to diverge from the Heroku experience since we had this forking of the Buildpack community. With the Cloud Native Buildpacks project, we're bringing Heroku and Cloud Foundry ecosystems back together, and we're doing it in a way that's going to allow the power of Buildpacks to work in any OCI-compatible platform. Now that's an amazing combination. And I say we. I'm talking about the broader Cloud Native community. That's an amazing combination to see happen. It's a great moment in time for those of us that understand the power of the platform as a service model. So we do this, though, and I spend a lot of time in different regions around the world. I do different enterprises. I talk to press. I talk to analysts. And there's always this kind of this nudge they want to give you. Hey, there's a new project. Why haven't you incorporated that yet? And then I'm talking to the analysts and press right down here. You should already have it done. And we say, well, you know what? Let me explain. It's a balancing act. We have enormous corporations that run their payment processing systems on the Cloud Foundry platform. We have so many different businesses that have chosen the platform and the technology to help reinvent their business, to build the new version of their business on top of, that they expect this to be an evolution. Not a gut-wrenching revolution every time there's a new capability or a new project that starts in the broader open source community. So what our committers have done, what our contributors have done is they've been very thoughtful about that balancing act between we need to embrace innovation throughout the ecosystem. But on the other hand, we need to do it carefully, right? I mentioned Istio earlier, but it's a good example. It's an amazing project. It has some amazing ideas behind it. But we need to do a couple things. One, figure out what that developer experience is going to look like, because it can't be the raw Istio experience. The second is that it actually needs to be mature enough that we can run it in production at a large scale. And so our community needs to lean in there and help. So that's the balancing act that we're constantly struggling with, right? On one side is the, hey, new and shiny, and the other is responsibility for all of you that actually use the software. And I think we do it particularly well. Now, there's a book that talks about some of this, Innovator's Dilemma. Most of you have probably at least heard of it, if you haven't read it yourselves. And frequently people discuss the dilemma itself, which is you get stuck, you don't want to change, and the dilemma is a very hard dilemma. But Clayton Christensen, the author, he actually offered the answer to this dilemma, which is that you don't focus on making a plan, you focus on learning, right? The more you can be a learning team, or in our case a learning community, the more exploration that you can have, the more likely it is that you can continue to evolve successfully and respond to changes in your environment. And we do that particularly well. But I think we embody that as a community. We do that through lots of different methods, right? We have our extensions projects, we have lots of different experiments. These happen maybe as a formal effort, or sometimes we just have a pair of developers that we're working on, let's say, the cloud controller that step aside and they spike out an idea. That happens all the time. But we also have a much broader ecosystem that we're part of. All of the interesting projects that exist across this ecosystem represent opportunities for the Cloud Foundry community to draw in innovation, to make sure that it's ready and well integrated. And then to provide that through all the downstream distributions and to all the end users. It's a pretty powerful model. And it really does require that all of the committers or the maintainers and the project leads spend a lot of time listening to users. So for those of you that are users, I have a request. If you don't spend time talking to the project teams, talking to the project leads, please do. Because they love to get information from users. It's critical. If you're buying it from a vendor, buying some Cloud Foundry technology from a vendor, absolutely have conversations with the vendor. But get involved in the upstream. And you could do that simply by paying attention to new feature proposals and giving us your real opinions. Anybody know where this is? I guess this is a difficult Q&A spot, right? La Sagrada Familia in Barcelona. I love this picture because it's a shot straight up into one of the craziest cathedrals on the planet. The reason why I have this photo up here is that there's a saying in open source. It goes way back to the beginning of the open source movement that was, there's the cathedral, which is the world of proprietary. And the bizarre, which is the world of open source. And it's kind of set up by the originator as a bit of a choice. You have to choose the cathedral route for proprietary software or you could choose the bizarre route. And the bizarre route's gonna have a lot of innovation and be crazy and exciting. I think actually that you can combine the two. You can be thoughtful about what becomes ready for production, what's released to the collective at the same time. That you can allow for innovation, that you can allow for experiments, that you can allow for the larger open source ecosystem to provide you with inspiration. And that's what we try to do. And I think that La Sagrada Familia is a great example of some crazy ideas coming together in a way that also becomes a cathedral. So we do this thinking about different personas generally. And if you talk to anyone who helps build the Cloud Foundry software, they're really thinking about two different types of people. And maybe I'm oversimplifying it, but that's okay. I'm on the stage, they're not right now. So I'm gonna oversimplify. You have application developers who build applications. And I also include what I call application operators. The people that get software from someone else like an ISV and have to deploy and manage it. Because there are some similar and highly overlapping use cases there. On the other side, we have platform operators. These are the people that actually deploy and manage the platform. Now, if you're using Cloud Foundry from a managed service provider, those teams work for them. But they both matter. They both matter quite a bit to our community of contributors and developers. The other thing that is really, really apparent is that if you haven't already figured this out, we live in a multi-obstraction world, right? VMs serve use cases, container is a service, or Kubernetes serves a use case. Platform as a service is exceptionally valuable. We're starting to see a lot more functions as a service. This is the world that our users live in. And there are some problems that have to be solved because of all of these platforms, all of these abstractions. And last year we did a survey of the Cloud Foundry users. It's an imperfect, it's a user survey. But it was clear that the overwhelming percentage, the overwhelming majority of Cloud Foundry users were either already saying, yeah, I want the Cloud Foundry PaaS, and I either already have or want to use Kubernetes with it. Now, there's lots of different ways that we could stack these two technologies, but the fact that we want to integrate them, I think, is particularly important. Now, today, or I'd say actually last year on this stage, we had integrated the Cloud Foundry container runtime or the Kubo project into the foundation. We announced it, we said, hey, this is important. This is the first embrace of Kubernetes. It's how you can deploy and manage Kubernetes. It's been now commercialized by Pivotal, VMware, I think Swisscom's now commercializing it. So great progress there, it continues to evolve. That project continues to support each new version of Kubernetes as it comes out, provide zero downtime upgrades of it. It became a certified distribution as an open source distribution of Kubernetes. And it became a pretty powerful tool that our community has available to it. But there's other ways that you can think about stacking the architecture. And so when Abby talked about some of the new projects, that's really what we're referring to. So if we focus on that application runtime, the CF push experience, inside of it, there is a container scheduler. Now, one of the options that has now been opened up or that's going to be opened up as the Irini project evolves is to have the option to use Kubernetes as the underlying container scheduler. That's what that project is all about. We also have this powerful tool called Bosch, does amazing things. And then we've got Kubernetes. And we talked about how Bosch can deploy Kubernetes. But maybe we could take some of the software that's being developed with Bosch deployment in mind, run it through a process of containerizing it, and deploy it into Kubernetes using Docker images and Helm. That's what the CF containerization project is all about. It takes release, manifests, builds Docker images, Helm charts, and deploys it into Kube. But I focus on developers predominantly. Who I think about most frequently. Those two projects really are, they're very interesting. They're very important. But they're predominantly for either the platform operator or the vendor that's packaging the product. Because it has to do with how you want to stack these different technologies. And as long as both the platform as a service and the Kubernetes experience are both exposed, that's a really powerful combination. And so the developers or application operators, what they want is they want to see this be particularly well integrated. And there are a lot of efforts that aren't being announced. Because they're just simply efforts that are occurring within existing projects that are dealing with the question of, can we do shared networking? That's sort of the initial Istio integration. If we get Istio integrated, that starts to work. Then there's an x step, which we need to say, OK. Let's get Istio running on the Kubernetes side. And let's make sure that we're sharing policy and traffic and flow. But also there's synchronized service catalog, which we saw a demo yesterday on this stage. The purpley project that SAP introduced and has gotten a lot of industry support around is all about synchronizing service catalogs. Not just having a shared spec for how backing services are communicated with, but actually having the same service catalog and same awareness of different services that have been initiated. Aggregate telemetry, logging and metrics pipelines, common identity. These are all really basic things, but our community is digging into them. And they're taking the right steps, the right initial steps, and the right future steps to be able to provide that consistent experience for a developer that wants to work with the two different abstractions together. I think that's really important to the whole industry. So you saw this slide yesterday from Abby. This is just a sampling of today some of the projects that are embedded inside of the Cloud Foundry platform or collection of technologies. They represent some of the most interesting projects that exist in the Cloud Native landscape today. But in the end, they're components of a bigger system that needs to be built. And that bigger system is what Cloud Foundry is providing. So I like to say that we're on a journey as an ecosystem, as a community. We've been on that journey for a number of years. New projects are going to show up. We need to embrace them when they're useful. We need to integrate them when they're ready. And we need to help get them ready. That's our responsibility as users, as contributors, and as committers in the Cloud Foundry ecosystem. Let's take this journey together and really focus on building bridges between different parts of this broader ecosystem. Because that's how the end users in the end get the most benefit. That's how we get to take advantage of the innovation across this broader landscape. And that's how I think we get to really continue to evolve and solve the problem that the CF community has been so focused on solving, making it easy for businesses and other organizations to be good at software. So with that, I want to say thank you very much. Yesterday, Abby walked through a couple of bits and news. There was some really fascinating stuff, a few more bits and news. So I'm going to go through a couple of items. So the first is a couple of years ago, we launched our developer training and certification program. We've been blessed by being able to be involved with about 17,000 people worldwide so far. Very proud of that. Lots of education happening out in the market. And this doesn't include all the amazing training programs that a lot of the systems integrators and other providers are actually doing on a regular basis. This is just purely the foundation's ability to touch people. And so that's grown really well. But Pivotal announced, and it was in the press release yesterday, and we're particularly happy to see this, that the work that we, as well as some of the systems integrators and the volunteers that have helped produce this content, Pivotal will be adopting that as kind of step one in the learning path and step one in the certification path for the Pivotal Cloud Foundry suite of educational materials. So we want to thank them for that. Second thing, Any9s, amazing community member that's been around in the community for quite some time. They, of course, work with Cloud Foundry Open Source, but they've got a great partnership with Pivotal. And they wanted me to let you know that they've recently released a new version of the Any9s data services with the latest Pivotal tiles, or they've redesigned the Pivotal tiles. So support on-demand provisioning. They're now using the PCF ops director. It's supposed to install much faster now. So go talk to them. They've got a booth down there. The third announcement that we wanted to help support here was from GrapeUp. So what I'd like to do is I'd like to introduce Daniel Heckman, who's the head of Enterprise Business Development for the Americas for GrapeUp. So Daniel, come on up. Good deal. Thanks for coming. So you said you have an announcement of some sort, right? I do. OK. You want to talk about it? Definitely, definitely. All right, cool. I'm going to put your slide up. Awesome, awesome. OK. So yeah, Cloud Booster. Maybe some of you already had the pleasure of having a Cloud Booster vanilla latte at booth number 15. So the announcement is that from yesterday, technically, GrapeUp is offering its own distribution of Cloud Foundry in the form of Cloud Booster. So Cloud Booster is an open cloud platform that allows enterprise companies to build, run, operate any workload in the cloud. That's our ambition. So our goal is to help mid-sized companies embrace open source technology and have a curated experience and be supported by, in this case, GrapeUp and our 10-plus years experience of supporting cloud-native software. As you can see here, we've integrated leading open source technologies and fused them together with what we call Cloud Booster Glue to have a platform that will be able to run 12-factor applications, Cots software, and so on, and so on. That's what we're doing. Outstanding. Well, thank you very much for coming up here and letting us know about that. Thank you, Chip. Cool. All right. Do stop by booth number 15. Go visit their booth.