 So, I have the pleasure of trying to summarize the work of over 130 people working full-time on the various Cloud Foundry projects, the thousands of contributors who've contributed software over the course of the project's lifetime, and to try to give a pulse on, give you a sense of what's happening in all these various projects and what that actually means. So, this is going to be a fairly dense presentation. We're going to move a little fast, because I've got a really red clock here that's telling me I have 19 minutes and 46 seconds to talk about all the good work everybody's doing. But let's start here. Let's start at this wonderful moment, those of you that use Cloud Foundry, this wonderful moment of anticipation, this wonderful moment where there's a lot of potential behind this. But it's not simple. As much as we love Anci's Haiku, and if you don't know Anci from Pivotal, he leads their Cloud Foundry engineering and product efforts. It's a wonderful Haiku. I use this in all my presentations. Here's my source code, run it on the Cloud for me, and I do not care how. There's a lot of power behind that promise. But it takes a lot to actually make this real. Because when we go out and we speak to non-Cloud Foundry knowledgeable audiences about what is Cloud Foundry, why does it matter, why do we have a sold-out audience here? We talk a lot about how platforms make promises. And the good platforms are able to keep them. And Cloud Foundry is an outstanding platform. So let's dive deep. And we're going to kind of start a little bit lower than the CLI. Let's talk about the API. So we have a V2 API. It's been around for a long time. It's evolving. But we've kind of slowed down at evolution. And it's time to rethink that API experience. So there's a very general goal here, which is for those that interact with it, have better consistency and discoverability in the way that it works. We need to be able to actually improve the application owner experience significantly as well. Because this API can use the same basic functionality inside the platform. But for example, instead of that CF push operation occurring and taking the current system offline and you having to use CLI plugins to avoid that little blip and outage, the platform should just naturally be able to go through the staging process and deploy and start the new system. So lots of work occurring there. They're going to be doing the release incrementally. A lot of this work has occurred already. But it's time to accelerate. And it's time to start getting each individual function out to the user. So the first one that's going to be marked for GA is going to be the tasks capability. Really simple concept. You have an application, sometimes it's nice to be able to do something within the context of that application. Think database migrations. They're a great use case example. Now let's talk about our secret weapon, build packs. Well, not so secret. They're really the heart of that promise of just take the source code and run it. And they're really, really important. We, of course, have lots of build packs that exist within the foundation. We have lots of build packs that are being created by the community in general. But one of the problems we've had is that we have a lot of forking of build packs. Because that's the way that build packs and the build pack process is customized. So I'm just going to point to the second bullet there, multi-build packs. And say that that right there is the forking killer. It's going to eliminate all the risk that companies have if they've forked a build pack like, let's say, I'll pick on the PHP community, right? Fork the upstream PHP build pack. You tweak it. Because you want to have some additional steps occur during the build process. That puts you at risk, because now you're out of sync with the wonderful job that the build pack project does to make sure that the community has access to the latest and greatest PHP software, especially when it relates to vulnerabilities. So with this multi-build pack capability, you can start thinking about the core platform operations as being pipelines. Very simple pipelines, but pipelines. So we can do something like, for example, do a static code analysis for the purpose of compliance. I can do that as an option through a multi-build pack or think about what happens when that becomes mandatory. Starts really making the whole compliance process a lot easier and it improves the experience of the developers. So let's dig a little bit deeper now. Let's talk about Diego. And I'm going to give you a quick preview about what I'm going to be talking about. Diego is, in fact, at the point where you should be migrating to it. So why is that, right? Let's talk about what Diego was. Re-architecture, the core elastic runtime, and related components. That's what it was. We graduated this time last year as an active project. It was shipping commercially then. We're approaching the scale of 250,000 application instances, that's containers, running within a single Diego cluster. And talking with the engineering teams, they say that that's just the scale that we're going to test to. But if we, for example, take the same environment, add additional cells to it, they think they could at least quadruple it. Used commercially in most distributions today, I want to hammer this point home. When you're buying Cloud Foundry from someone, I hope you're getting Diego. And if you aren't, ask for it. Last, it's going to be required. All of those 11, I guess it's the happy 11 now, Sam, all of those 11 to get the 2017 certification, they will offer you Diego. So make no mistake, Diego's here. The older architecture will be end of life after a period of about six months. That means no updates of any kind. All right, so I just wanted to hammer that message home for that team. But why does that matter, right? So why do we spend all the time to rewrite? Well, we actually spend a lot of time to rewrite because there's a lot of innovation that we can now do with the new architecture. So let's first start with Garden. Garden, we're going really deep now. This is the wrapper around Linux kernel features that support containerization functions. The Garden project has just released what they call Garden Run C. Now Run C is at the heart of the Docker engine as well. So Cloud Foundry is adopting industry standards that exist in neutral places that are now proven to be robust. And I think most importantly, we're focused on securing it for multi-tenants and tenant environments. If you talk to the Garden team, I love this team, if you talk to them and you ask them, what's the goal? They made it very simple. The Garden team intends to always be the most out-of-the-box secure container runtime for large-scale multi-tenant workloads. That's a lot of words, but that's their promise to you. And they're backing it up with a lot of work. In addition, there's some exciting activity going on around how we think about the root FS and aligning that with the OCI's container image standard. Hopefully, that'll get us some better portability in the industry. Okay, so we've got Garden and that's great. We've got Diego. It's orchestrating a lot of garden cells. So what are we gonna do with it? Well, we can do things like volume services. For years, we've talked about the 12-factor application. One of the core tenants of 12-factors is that the apps are stateless. Now, that's still the ideal, but sometimes it's good to have a little bit of wiggle room, right? So, as of today, actually as of version 242 of CF release, volume services are included. So you can work with any company who wants to create a volume service, service broker, and have persistence in your applications. Networking, we all love networking, right? Everybody raise your hand if you enjoy configuring switches. Yeah, yeah. Okay, so let's talk about networking. So today, with networking, we have multiple microservices. These microservices have to talk to each other. Now, they can, and CF lets them do that, but there's an awful lot of North-South traffic that's occurring, right? Things are going up to the go-router back down again. It's suboptimal. We also really don't have fine-grained access controls and policy-driven control about how these various applications are talking to each other. There's ways to make it work, but we can do better. So the future is very policy-driven, and so the project team that's working on this is starting with the premise that the Cloud Founder software, the upstream open source, should always be batteries included, because what we don't wanna do is put it in a position where you get locked into a particular type of infrastructure. You can't use a particular function because you're not able to deal with the hardware itself because you're on a public cloud. So batteries included, all the containers, they get a single, they're on a single system-wide L3 network, and they're actually using flannel and IP tables for those of you that like Linux networking. That's the batteries-included approach that Cloud Founder has implemented. But it's also bring your own. This is another place where standardization really matters for Cloud Founder and your adoption of it. A lot of you use different software-defined networking stacks. They'll be supported. They can be supported today by adding a CNI-based interface. That's another API spec. I told you this is dense, right? So you have everybody with me still. So next up, hardening, scalability, testing. There's a lot of hardening that goes on. It's a great project. I think it's gonna bring a lot of capabilities to your application teams. Let's talk more networking. This is routing, a couple of key things that's happening in the routing world. So first, there's this notion of route services. This slide doesn't do it justice. This is perhaps, to me, one of the most interesting capabilities that CF has added in the last, I'd say, half a year. The idea of route services is that in the data path from the browser, or the end device that's gonna talk to the application, we come into the network and CF knows how to route you to the various applications. But more interestingly is, instead of routing directly to the application, we can now pass you off to various other capabilities. Think API management functions. Think application or protocol-aware firewalls. A lot of functionality that allows you to extend the way that you manage APIs and all these microservices. You know, the next thing though, of course, is that we've, this has been out there for a while, but it's starting to pick up steam. I'm starting to see people use TCP-based routing in anger previously before this function was released. This was an entirely web-based stack. So now we can support anything that rides on top of TCP. And the pattern exists to add additional protocols. So what's next for routing? I'll highlight two things. One, I'll point to Zipkin-compatible tracing, right? The routers in the data path of the application, for those of you that are familiar with Zipkin, Zipkin's a distributed tracing system. It's used in a microservices environment to be able to get really detailed traceability across a complex networked application. Well, our router's part of that. So it should actually be able to emit logs and you should be able to track your application transactions through it. The other one that's interesting, of course, is the multiple application ports. Think about this as kind of opening up a little bit more flexibility. I'm gonna give a shout out to the IBM team that's based here in Germany. They've started the process of disaggregating a few of the functions that exist within our cloud controller. This is the type of heavy lifting that's occurring on your behalf. This is not something that is end user facing, but it's gonna allow us to continue to scale the platform to higher levels. Another interesting bit of work is isolation segments. This was previously known as elastic clusters and members of the community, Pivotal, IBM got together and they iterated on the idea a bit, found a way to make it a little bit more incremental for delivery and now we're starting to get delivery of it. So isolation segments are a very, very simple, and a very, very simple description, is the ability to take that cluster that you've been deploying applications to and slice off parts of it, maybe for compliance reasons, maybe for tenant isolation reasons, but you should be able to slice off parts of it and then place applications into them. So we started with compute, these of course label-based administration steps that need to occur in the cloud controller, they're gonna move into networking and they'll move into logging and they actually have a pretty robust backlog well beyond that. Also, Abacus, this is a great project. Not part of Cloud Foundry Core, but it's a really interesting project that both IBM and SAP are collaborating on. It is a metering and usage aggregation service. It's been out for quite some time. This is how Bluemix builds people. So it's really, really important and we know that it works at scale. They've been working quite hard to make sure that the Abacus software itself has been hardened, SAP has been doing a lot of vulnerability scanning along with IBM to improve the surface area. But what's really coming up next is gonna be interesting. So UI for the onboarding of service providers. So we're gonna start to see user interfaces now coming into foundation upstream projects and then Abacus is a service, which is an interesting idea. So you take this component of the Cloud Foundry runtime, an optional component, you re-express it as a service. Okay, so sorry, that was runtime. Let's quickly go down through the Bosch layer for you because Bosch make no mistake about this. Bosch is the Cloud Foundry multi-cloud story. It is what allows us to quickly and easily deploy Cloud Foundry on any public cloud, any of the private cloud platforms that exist. So it is that story for us. It's incredibly important. You may have been hearing things about Bosch 2.0. So 2.0 isn't actually a version number. This is what I love about continuous delivery of upstream software. What we're actually talking about is a set of capabilities that are released as a version 255.4 and up. Bosch 2.0. This feature narrative did a wonderful job of beginning to simplify the operational experience of creating Bosch deployments. Very, very important. There's still a lot of work to do to continue to make it easier to consume and manage Bosch, but it's an incredible platform that given all of these improvements is just continuing to get better and better. Let's actually just highlight one of the CPI teams. This happens to be a team not very far from here based in Waldorf at SAP with SUSE engineers participating. They care for the open stack integration that Bosch has. They care for it. They love it. They fix it, but they also support the community. One of the common questions that they got, I mean, how many of you have used open stack? Yeah, looks like a few, right? So here's the thing about open stack. Love it. It's open source. That's great, but there are no two open stacks of the same. Lots of configuration variants, lots of ways you can like recombine it. So you get this question, does it work on my open stack? Well, the answer to that had been, well, that's a good question. And then you'd get this checklist of about 50 things you'd have to go look at. Now, of course, any good product owner, Marko, realized that that's totally inappropriate. Why don't we automate this for you? So if you're using open stack, if you're deploying Cloud Foundry in open stack, I highly recommend you take a look at the CFO open stack validator. They hit, I guess, 1.0 a few weeks back. It works great. It simplifies the manual process of making sure that open stacks working effectively for you. So with that, I can breathe deep. That was kind of deep, kind of dense. So let's just reflect on how simple this looks now. All of the work of all of the engineers and all of the product managers that work constantly together, cross companies, pairing, they're building a platform for you so that the digital transformation stories that we're hearing here at the conference, the two that led into me, are actually able to focus on their business. Because building a complex system like Cloud Foundry isn't a joke. It's very hard. It requires serious engineering commitment, but it also requires executing your software engineering in the same way that we preach you should develop business applications. So with that, thank you very much. And I hope you enjoy the rest of the conference. Thank you.