 All right, thanks everyone for your patience. We're going to get started. And it is a distinct honor and privilege to introduce Cornelia. We've been working together with Cornelia and Pivotal, and they've been great friends of Comcast. So it's a really special moment to be able to introduce and turn it over to Cornelia. Thank you. And it is likewise a privilege to be introduced by Greg. And you'll see in just a moment that Greg actually plays prominently in my presentation. So thank you all for coming this afternoon and spending the next half hour with me and with all the rest of us in the room. I really, really appreciate that. Let me just very briefly introduce myself and then also just put a shameless plug up there. My name is Cornelia Davis. I work for Pivotal. I've been with Pivotal since the Pivotal spin-off. I came from the EMC side of the business as a part of the spin-off where I worked in the corporate CTO office doing architecture and emerging tech. And to a large extent, I still do architecture and emerging tech for Pivotal now. But really, the area that I focus on is taking emerging tech, new shiny, fancy objects, whether it be Paz from five or six years ago to cloud caching, to Kubernetes, to Knative, to Serverless. And really try to figure out together with our customers how to tie that to business value. Because tech is fun for tech's sake, but when it really, when it generates business value, that's when it gets really exciting for me. I've been working in web architectures for probably closer to 15 years now. Been working with Cloud Foundry for more than six years, almost seven years in Cloud Native. And I am just literally, I have literally yesterday did the final approvals on the copy edits, the last copy edits for my book. So we are in the production process. I've been writing a book with Manning. It's an architecture book around cloud-native applications. So what are the patterns that you need to apply? So that when you do something like run it on Cloud Foundry or run it on a container-based platform, that we can do all sorts of cool things, like some of the things that I'm going to show you here. If you don't follow those practices, well, we might not be able to do some of those things. So the title of the talk was P to V to C. So let me tell you where that came from. As Greg said, we've been working with Comcast for quite a number of years, four or five years. And I've known Greg for probably that whole time. And they have been very successful with PAS, with the Pivotal Cloud Foundry platform. And you've heard Greg talk about that success that Comcast has achieved. And about a year ago, maybe a little more than a year ago, Greg and I started talking about what we were doing with PKS, with Pivotal Container Service, bringing Kubernetes to the platform. And it was Greg. And it says their major US telco provider. It was Greg. And Greg has given me the OK to attribute this directly to him. So that's why I'm sharing that with you. And he said, hey, listen, Cordelia, what I want to do is I want to move all workloads from V to C, so from running directly on virtual machines to running in containers that doesn't get rid of virtual machines. You'll see how that plays prominently in just a moment. But I want to move all workloads from V to C so that I no longer have to worry about things like patching operating systems. Now, Greg knew about patching operating systems because of the experience that he's had with Cloud Foundry. And we're going to talk about that. For those of you who maybe are a little bit newer to running things in containers, maybe this is going to be news for you. And we'll talk about patching operating systems in a moment in a number of other things. So again, we'll cover those things. But there's another interesting part of this quote. And Greg went on to say that he drew the parallel between where we are today with containers and where we were as an industry 15 or 20 years ago with virtualization. Now, there's a couple of very interesting parallels. We spend a lot of time at the Cloud Foundry Summit talking about the developer, about developer value, developer efficiency, developer gains, and those types of things. And so I want to go back to infrastructure as a service. And VMware just celebrated their 20-year anniversary or the 20-year birthday. I actually was one of the very first people to use virtualization technology because I'm a developer. That's my background. And before virtualization technology, I had my laptop, it was quite a bit thicker than the Mac that I have now, but I ran around or when I was at home, I had two hard drives. Anybody else? Yep, I see a couple of emphatic nods. I had one that booted to Windows. And if I was doing email or PowerPoint or Word, I booted that one up. And then I had another one that booted to Linux. And so what happened was when VMware workstation came along, I didn't have to carry around two hard drives anymore, which was way cool for me as the developer. Now, I can tell you this, VMware did not build a business, a $10 billion business, by making it easy for me to have multiple operating systems on my laptop to save me the trouble of running around with two hard drives. They built a $10 billion business when virtualization hit the data center. It's when it started being adopted to realize not just developer productivity, but actually realize all sorts of other efficiencies that were bringing value to the enterprise, that that's when it really took off. And that's when we generated a ton of value for businesses. Now, when Greg went on and took this quote a little bit further, that was really insightful because on the container front, I suggest that we are in a very similar spot now. Containers have captured the imagination of developers. And developers are leveraging them. They started leveraging them whatever four or five years ago first in their deployment pipelines and things like that. But we are at the stage now. Cloud Foundry has allowed us to do it all along for quite a number of years. Kubernetes more recently, we're at the stage now where we can actually accelerate. We can go beyond developer productivity and we can actually realize just unimaginable things that we can do around generating value around containers. So that is what's even more interesting than maybe even more interesting than these very specific things that I'm gonna talk about. So let's start with why containers in the first place. So arguably, one of the first values that we saw out of containers was this. What we have here is the operator on the left-hand side who looks understandably angry and says to the developer on the right-hand side, your code doesn't work. And what does the developer say? It works on my machine, right? And so, yes, the first thing that, the first value that we could get around containers was that we were able to take what was often done very late in the deployment process, very late in the promotion to upper environments as some customers call it. And we were able to do that shift-left, do the proverbial shift-left and do that earlier so that we then had that done once and all we needed now was a container runtime that we could instantiate those containers in, those container images in. So there's no question that this brought value. Now, it also brought with it all sorts of very interesting problems that we needed to solve in that who's gonna build those containers? And we'll talk about that more a little bit later. I'll tell you, I remember very distinctly having a conversation with a prospective customer four years ago who said, eh, I don't need your pass because I'm doing everything with Docker and my developers are just gonna ship me images and I'm just gonna run those images, no problem. And I said, really? Your developers that don't know the first thing about regulatory compliance, that barely know what you need to know about security, you're gonna let them take these container images, you're gonna run them on your production systems, no questions asked. And he was like, okay, good point. So we've matured a lot in the last four or five years and that's some of what we're gonna talk about. So I wanna turn back to Greg's quote and really drill in on the like, worry about things like patching operating systems. So let's talk about that first one. What do we mean? For those of you who maybe aren't as familiar with container environments, how on earth does a container help me actually patch an operating system? So here of course is just our very simple picture. We have a host that host is a virtual machine. It could be a physical machine, but it turns out that when it comes time to realize value in enterprises in data centers that the virtual machine still plays a very significant role. I won't have a lot of time to go into those details, find me afterward and we can certainly riff on that. So we've got the virtual machine host which is running the kernel operating system and then we have container and in this picture I'm only showing a single container but generally you're gonna have multiple containers that are running on that host and inside of the container you bring in more of the operating system. So you bring in the kernel just has the fundamentals, the things that you need to be able to communicate with the hardware, kind of if you will, what you would think of as the BIOS. It's just the core kernel operating system. What we bring in into the container is we bring a little bit more of the operating systems, things like OpenSSH or something like that that is going to give you support for the things that you wanna run in that container. You wanna bring enough of that root file system, that operating system to support those applications but no more because every single one of those processes has a potential attack surface or has a way of being vulnerable and so you wanna minimize your attack surface. So you bring in the OS image then you bring in the runtime layer like the JDK or something like that and then you bring in the application layer. So everything is running fine, everything's humming along just fine and then you know what, there's a vulnerability and what happens is on a Friday afternoon, Ubuntu canonical is gonna say, we've got a patch for you and we're keeping this under embargo, we're not announcing it to the world just yet here's the patch, you the customer or you Pivotal, so a vendor that bundles the operating system, they make the patch available and they say on Monday we're gonna announce it to the world. So right now there's some hackers who probably know some small number of hackers who probably know about that vulnerability but on Monday every hacker is gonna know about that vulnerability and they're gonna start running their bots. They're gonna very quickly write some software that's gonna look for a way of exploiting that vulnerability. So as of Monday or Tuesday, we've got bots out there that are attacking your system. So you have this short window of opportunity where you can patch the operating system and in the pre-container world and I still talk to a lot of customers, I spend a fair bit of my time out with customers, they still concede to me that it often takes them three, four, five, six months to ensure that an operating system patch has been applied to all of their machines. That's still the reality. So if I have my stuff in containers, how can I automate that? Well, it's actually pretty simple. I've got that container, I've done all that work of building the container image ahead of time. So what I'm gonna do is I'm gonna stand up a new machine. And on that new machine, I'm gonna install the new operating system, the patched operating system. And then I simply start up a new app instance and I take the old one offline and then for goodness sake, let's get rid of that machine so that no other workloads end up landing on it. Now, what I've showed here seems super simple like awesome, I can do that, that's really easy. Now here's the thing, what happens when I need to do it at scale? So I'm showing nine hosts here. What happens if you have 9,000 hosts or 90,000 hosts? I need to do this at scale. And so the process, if you watch it very quickly, it goes by very quickly, it's that same process that I showed you a moment ago, but it's at scale. So I'm going to stand up three new hosts, I'm gonna move some workloads over, I'm gonna check, make sure everything's cool, and then I'm gonna keep cycling through that, three at a time, three at a time, and so on. So you can see how that goes. Now everything that I described here by the way is not something that you're just gonna get because you've created a container image. You need a platform to be able to do this. How many people in here are already running Cloud Foundry in production? You have a platform that does this for you, okay? That's how Greg knew that containers were a way that he no longer had to worry about patching operating systems, is because he's been running a container platform in production for years. So this is something that you are already, you already have available. Now of course there's all sorts of interesting things like the workloads themselves can they be moved that easily? And all sorts of elements, like are you running cloud native applications and all of those types of things? But you have a platform that already implements this. So let's look at some other things that your platform might implement as well. So that was patching operating systems. What about another security concern? What about malware? And one of our, and I'm looking and I don't see Lance in the room, but Lance from Wells Fargo has talked about this. So I'm gonna be telling the same story that he has told. And it's not just Lance who's doing this. Many of our customers are doing this. The idea here is that with malware, it's not like a known vulnerability in an operating system. The way it works is some bad actor comes along and installs malware on inside of the container or on the host and then disappears because it's actually much easier to detect in an intruder while they're there than it is to detect the malware. So they disappear. Many of the breaches that we've heard, many of them actually fell into the first category. They didn't patch their operating system. They didn't patch some runtime dependency. But another set of vulnerabilities that we hear about are something that breaks into a point of sale system through the, oh, let's say the HVAC system. That's what happened to Target. And they drop some malware on there and it sits there for months, just collecting information, looking for additional vulnerabilities. So you might say that the way to solve this problem is to do a better job detecting malware. And yeah, you should probably do, try to do a better job detecting malware, but are you gonna depend on that? The answer is you don't have to. You don't have to depend on getting good at detecting malware. You can do this. Imagine the process that I showed you just a moment ago where I can just stand up another host and move my workloads over. What if I just do this? What if I just preemptively, even if there's not malware on there, I just throw out the container and I stand up a new one. If it didn't have malware on it, no problem, it still doesn't have malware on it. But if it had malware on it, it doesn't anymore because you're starting from scratch. Now, containers support this because we have an environment where we can do this. They also support it because again, all of that work was done shifting left. We've built the container image. Now we've built the container image with discipline. You have to have a trusted container pipeline. We'll talk about that more in just a moment. Now notice that there's still malware on the host and it just so happens that this pattern that allows you to recreate these containers, which is in the past, Diego, and in Kubernetes, in CFCR is Kubernetes, we have that same pattern built into what? Bosh, right? So we can also throw away the VMs and stand up new. Does that make sense? So you see how containers lend support? It gives us a brand new primitive with which we can start to solve problems a different way and that's pretty darn cool. All right, and so we actually at Pivotal, we call this repaving. The first scenario we call repair. We call this repaving and I am suggesting that you do it proactively very often, like every few days. Lance, if you chat with Lance and he's here, I encourage you to seek him out. He's doing this every three days right now on his platform. He wants to move it up to every day. So I'll tell you that I actually came, as I mentioned to Pivotal from EMC, I came to EMC from Documentum. Any Documentum folks out there? Just a few Documentum content management systems. We used to, back in those days, it was all about stability. We kept our machines up and we kept a count, like a safety count. Like the number of days since I had to reboot my server was 185, we're doing great. Now, if you've kept a server around for 185 days, ooh, mm, little skittish there. You're keeping containers around for sometimes just days or maybe even hours. Okay, so I think I just accidentally went backwards. Sorry about that. All right, let's look at one more scenario and I'm gonna check my time. Okay, cool. And this is another one, something like load balancer configuration. Now, I realize that many of you, because most of you raised your hand and said that you're doing some cloud foundry, but I do know that we also have a track for new folks. So bear with me, those of you who already know this, bear with me, I'm just gonna go through this very quickly. Where do containers help me with that? Now, there is one other tidbit that I wanna share with you here. So the way that we did things before, before we had kind of a container and a container platform was a typical deployment looked a little bit like this. It was very workflow related. So, and by the way, I work with customers that have, they still have these pretty heavy duty processes where they're promoting code into upper environments. Oh my gosh, I'm so glad it's not my job. I'm remembering one individual with one of our customers where I was somewhat involved with that project and we got together every week. And when I say we, it was myself, the project manager Rodney and about 70 other people on a weekly basis to go over a spreadsheet of 300 or so lines which were all the things that needed to be checked off before you could actually run this in production. So what I'm talking about here still lives is still very much alive and well in the enterprise. And so this is greatly simplified. It says okay, well at the top of that list was do we provision machines and we do that maybe with some tickets and we install the operating system. Then we file a ticket to install the app. I skipped a whole bunch of steps there. Then I file a ticket to configure the firewall or the load balancer or something like that and I do more things dot, dot, dot and then I'm done. Now there's two things. Remember that shifting left thing that I keep talking about? Well that's where the container comes in. A lot of that again can be done very much earlier. So that allows me not to have to do that with each deploy. That's what allows me to not only be able to deploy software every 185 days but to actually do it every single day is because I've already done this and I've done it in an immutable and signed binary and I have all sorts of things like harbor that is checking to make sure that the signatures are right and all of that. Now the other thing that I wanna emphasize with you here and if you were to read my book you would probably get tired of this by the end of the book or hopefully not is that I define cloud native software as that which is highly distributed and constantly changing. That constantly changing part means that there is no such thing as done anymore. So if you ever find yourself thinking, okay I've done all of this and now I'm done with my deployment, my voice is gonna come into your head and say, nope, you are never done. Done is a fallacy in the cloud. Super, super important. So what does that look like? Here we've got, let's say I've got two instances and the way that this is driven is the desired state in the actual state. Now I've drawn this picture here and it's labeled with Kubernetes and it has things like Kubernetes master replica set. Of course those same basic DNA exists in the cloud foundry in the application runtime as well. Our desired state is I want two instances of this app running, my actual state is that I have two instances running and my load balancer is configured, I'm done. Except I'm not. So the first thing is that I've lost an instance, maybe because I'm doing a rolling upgrade or maybe I had an out of memory error but I've lost an instance. And the first thing that I need to do is I need to have the load balancer automatically update itself. There's a control loop that does that. How is it that I can deal with things if I'm never done? Well I will tell you that Kubernetes is a system of a whole bunch of infinite loops. Cloud Foundry has those infinite loops too. So Cloud Foundry has a loop that's constantly updating the load balancer. It has a loop that's constantly updating the deployments. So we've got all these control loops that are constantly running bringing things into the actual state. So then, of course, I deploy the new application instance that came from the replica set controller in the scheduler and now that control loop that updates the load balancer that happens as well. So these are the types of things that we can do because we have this primitive of a container. All right, so we did start just a few minutes late so I'm gonna go over a few minutes and keep my 30 minutes because I have 30 minutes worth of content but I am almost done. So there are a whole host of other things that those are the things that are going to allow us to realize that business value that we did with virtual machines over the last 15 or 20 years and really up it from just being a developer productivity tool to being something that's generating tons and tons of business value. So there's a whole host of other things. Now the question that remains is, all right, everything that I've talked about was around containers. The question that remains now is which abstraction do I use to touch containers? You're all doing containers but for the most part your application teams, the ones that are building the apps and operating the apps aren't touching those containers at all. And so one of the things that's really interesting and somewhat dangerous is that with the rise in popularity of Kubernetes we have this feeling like, oh, we all need to touch those containers ourselves and of course we don't necessarily need to. So let's talk about that and I only have a couple of slides here. What I wanna show you are two different specific things when we look at that contrast. On the left hand side we have the notion that's a little bit closer to Kubernetes. And in that notion, what we have is that the app team is providing the container image. Okay, and so the container image isn't managed by the platform, it's actually managed out of band, out of the platform. The platform here being Kubernetes. On the other side, we have however, and that's the developer on the left hand side, we have the people who are responsible for security, compliance, and all of resilience, cost, and all of that stuff, we'll call them the platform team on the right hand side. And they say, hang on a second, I actually want to control parts of that. I want to provide some of those things so that the application team is only providing that layer at the top. Now, developer efficiency is far stronger on the left hand side. I'll talk about that more in just a moment. But your security posture on that, remember I showed you how you could roll the kernel operating system? Well, on the right hand side of this picture, and by the way, I used the term trusted container pipeline. In this case, the trusted container pipeline is built into the platform. It's built into PaaS. And because it's built into PaaS, I can now, on the right hand side, do things like repair on a far greater part of what is running in my infrastructure. On the left hand side, I can do it for the kernel operating system. Now, you could potentially do it on other layers depending, but now you have to build the trusted container pipeline and all the processes around that yourself. All right. And then finally, here's the contrast between developer efficiency. On the left hand side, we have the developer who is now like, maybe saying a little bit more like, what the heck, what the WTH, the PG version of that. This is all the stuff that I need to do. I need to create my container image. I need to stick it in a repository. I need to build a wall of YAML, all just so that I can touch the container and use it on Kubernetes. On the right hand side, we have a little bit of YAML too. It's the YAML you know and love. It's what's in your Cloud Foundry manifest. So you can see that there's a big contrast. So there is absolutely no reason that you should, oh, I thought I hid that slide. There's no reason that you should feel like you have to use to touch the container yourself. Now, where do you touch the container? Well, here is at a very high level. These are the workloads that run really well on Paz. NetNU, CloudNative, applications, microservices. A lot of your existing application portfolio can get there with relative ease. And then of course, using Bosch, we have some data services as well. The ones that you have on the bottom, things that are already containerized, things that you don't have the software for, like ISV software, Kot software, existing, more of your existing application portfolio that isn't worth putting any effort to refactor because you're going to retire it next year anyway, or you don't have any developers that know the code anymore. And some more stateful applications, those are really well suited where you need the additional control to use a different platform. In either case, you have the ability to take advantage of containers. And that is what I mean by P to V to C, the value of bringing everything to containers. We are now roughly 80, 90% virtualized in most IT environments. I don't think it's going to take us 15 years. I think five years from now, we're going to be 50% maybe containerized, and we'll get to 70 or 80% pretty quickly over the next few years. With that, I think that there was just a summary slide. Is it coming up? And I will of course post these. This just summarizes everything that I talked about. And with that, I thank you so much for your attention and I'll stick around for a few minutes for any other questions. So thank you so much.