 You know, he doesn't just do live demos, he does crazy live demos, it's awesome. So we go from Space Traveler to an individual that was involved in NASA along with a number of others when we first launched OpenStack. Next up we have Chris Kemp along with a special guest for our next keynote. So Chris Kemp. So this is so cool having all of you guys here. This is actually another room I just saw a video of. We've got about 250 people in a breakout room. It couldn't fit into this room. So before I get started, I just wanted to welcome a special guest. I think a lot of you followed the news this week. We've actually got a really exciting new member in the OpenStack community. And I wanted to welcome Chris Pinkham, the inventor and advocate that created EC2 over at Amazon. I'm going to grab him up here and have him say a few words. Chris Pinkham, everyone. Good morning, everybody. It's always awesome to get on stage after a fellow South African giving such an eloquent presentation. Mark and I both went to a UCT, I think me a little bit before he did. And so thank you very much for being here. Thank you very much for building OpenStack. A huge thank you to Chris for both inviting me on stage as well as being a key lever in getting Nimbula involved in the OpenStack community. I promised I wouldn't take too many of his cycles away from talking, but I would just like to sort of reflect on the fundamental question of why we are here. And I'm sure for most of you, at a certain level, it's about standards and interfaces and implementations and building really great product. And we have several of our engineering team at Nimbula here this week to explore how we can bring our own learning, our own code, some of the tricks we have in our own tool bag, as well as how we can build a great Nimbula product set around a core OpenStack platform. So to a certain level, that's why we're here. At a very much higher level, you're kind of on your own, I have no idea. Somewhere in the middle, though, why I've been working on what I've been working on for the last 10 years, it's really about innovation, as Mark said. It's fundamentally about developer agility and how do we extract cost, time and effort from the business of building infrastructure and apply that to the development and improvement of new applications. So for me, it's all about innovation. It's been a consistent theme for the last 10 years, EC2, Nimbula, and now in the OpenStack community. Whatever level we're talking about, it is very good to be here. And I greatly appreciate the influence Chris had in getting us here today. So with that, I'll restore you to your schedule programming and look forward to speaking to you this week. Cool, thanks, Chris. Welcome to OpenStack. These guys have a great team and a great product that's actually been deployed in a lot of large scale deployments and they're gonna be participating in a lot of the sessions here listening to you all trying to figure out what technology from their stack can be included in OpenStack and also how they can complement and productize OpenStack and deliver it to new classic customers that operate extreme scale. So I wanted to talk to you guys today. I've got a couple of slides here. For those of you who don't know me, I was the CTO at NASA for a number of years and while there I had the great opportunity to partner with Lou Mormon and Jim Curry and the team over at Rackspace to really advocate for OpenStack on day zero. And it was a real honor to be able to see this evolve from 20 people to the thousands of people that it is today. So what I'm not gonna talk about today, isn't that an awesome logo slide, is the number of companies that are represented by the individual members because there's almost a thousand companies here. There's a equally impressive list of companies that have affiliated or affiliated with the members of the foundation. And each of those is actually an individual logo of a member. I'm not gonna talk about that, I'm not gonna talk about all the public supporters that have come out and put their logos, the companies that have said we are behind OpenStack. These are the logos you'll find on the website. We're not gonna talk about all of you guys. If you upload your pictures, you'll be in the next keynote. We're not gonna talk about all the folks that have invested. There's a bunch of corporate members, gold members, platinum members. There's a bunch of folks that have really stepped up and contributed code to OpenStack. I wish we weren't in the top three. I'd really like to have a closer correlation between the companies that have lots of members and the companies that make lots of code contributions in the future. I'm not gonna flash a logo slide of companies that haven't contributed. But I wish there were more contributors. I'm not gonna talk about Nebula either. I'm not gonna talk about OpenStack. I'm not gonna talk about where it came from. I'm not gonna talk about who's using it. I'm not gonna talk about who's building stuff on it. What are we gonna talk about? I'm gonna talk about why we're all here. And as we all go into the 237 different sessions that have been organized by you, what I think we're all here to do. And that's to serve customers and to build applications on this platform. And so I wanna talk a little bit about the platform that we've built and the platform that we're building and how it needs to evolve. So, my goodness, that was ridiculous. You guys get a preview. So, I wanna start here. That's just wrong. That's what I get for using Windows. That one's for you, Mark. So, one of the ways we look at the stack that we're building is applications running on platforms, Juju, OpenShift, what have you. Running on top of infrastructure services that are often virtualized but can run on bare metal. Running on top of infrastructure. And I think that while this is a compelling and simple way to view the world, and you can even make this slightly more interesting and rational by saying, well, some applications are gonna run directly on infrastructure services. And some applications will run on platform services. And then some applications are gonna run on some mixture of platform services and infrastructure services that are fundamentally running on the same infrastructure. I argue, my goodness, yeah, I would argue that this is kind of a fiction. I'm gonna go pass that really quickly. My goodness, I clearly needed more Red Bull this morning. So, Jesus, all right, this is ridiculous. You're gonna remember this presentation. You're gonna see it five times before it's over. But that stack where we have applications, neatly running on top of platform and infrastructure services, running on top of one infrastructure, I would argue, is fiction. And I might argue that again a few more times before this is over. So much fun. Yeah, we all know that. I think it actually just broke. I think I killed the battery in this, trying to, there we go. So what I'd like to kind of argue is that applications in the real world are actually running on top of much more complex service architectures and infrastructures. Most enterprises today don't have just one infrastructure that they're building clouds on. They have multiple. And whether these infrastructure layers are provided by one or more different platforms, they're typically running on more than one different generation of infrastructure. And I think the differences in infrastructure are going to be even more profound over the years to come. If we look at right now, we're replacing all of the last generation of Intel X86 infrastructure with new Sandy Bridge Romley infrastructure. This is, are you gonna take all of the old stuff and just decommission it? Or are you gonna try to run in this environment where you have both new and old infrastructure? When ARM becomes more prolific, are we gonna start to see a hybrid infrastructure layer that provides both ARM and X86? I think the reality is we're gonna see a heterogeneous environment at the infrastructure layer. And I also see having more heterogeneity in the platform layer as well. I think that the whole idea that there is a single platform to rule them all is the fiction here. I think that as we start to see the way people build applications on the cloud, each application will have unique characteristics that will lend itself to running well on certain platform services. And some of those platform services will lend themselves well to running on infrastructure services. And some of those platform services will need to run on bare metal. Database services are a great example. Having direct access to disk architectures that provide much faster read-write performance, more IOPS. I think as we start to look at the way we view storage, there won't just be block storage and object storage. There will be many tiers of block storage and object storage. And I think that these different platform layers will be exposed to an application, that's a single application on top. And what developers want is they want to be able to take advantage of all the innovation, not just in this room and this community, but all the innovation occurring across different in different ecosystems, different platform layers, and different platform services. You just saw Mark Schuller talk about a bunch of charms that had been developed for Juju. There wouldn't be hundreds of charms if there weren't hundreds of compelling infrastructure services that people were using to build applications. And if any of you built an application and have chosen the wrong database to run that application on, or the wrong architecture, or the wrong infrastructure to run it on, and had to rewrite the application, you'll appreciate why this starts to make sense. So if you're an enterprise or a large service provider that has hundreds of thousands of customers, you might have many more of these infrastructures and many more of these platform services to meet the varied needs of tens or hundreds of thousands of applications. I'm going to click this button again. Magic. So I'd like to propose, I'm going to click this less as a function of time here. But I'm going to propose a slightly different way of thinking about the stack. We've often thought about the stack as this linear thing where things are built on top of other components. But if you put the application at the center of the stack, and you start to think of an application often needing to consume different platform services from different infrastructure providers, perhaps even running on different bare metal infrastructure, you start to have a much richer view of what we need to do as a community here. If you think about the attributes of cloud computing, on-demand elastic shared, metered, accessible software and services, you start to appreciate how if you just have one platform layer that attempts to abstract everything, how it's difficult to achieve what you're trying to achieve in the cloud. So as we think about our stack right now with Horizon and Keystone, Nova Glance, Swift and Quantum, we've often talked about moving this, wow. So I want to end on one slide, because if I keep pressing this button, it's going to drive me crazy. This is crazy. That, stay. There, I'm done. So I wanted you to think about this and think about as we look at all the different applications that people are running on top of OpenStack, the different core services that will be required to run those applications at scale. If you go back to Nimbula and you go back to pre-Nimbula, the days at Amazon, when S3 had first come out, there was a queuing service that actually preceded S3, which is interesting, because it didn't have any place to store or a system to operate on data, but it was a queuing service. The queuing service was there to manage tasks that had a lot of different elements in them and large workloads that needed to run over a long period of time, where you could count on elements within those workloads being executed reliably. We don't really have that in OpenStack. You have to run that in an application on the infrastructure layer. And if you need to make that reliable, that's your problem. There is no DNS service in OpenStack today. There is no way that we all agree, as a community, as we assign names to instances. And this is all, frankly, it came out of NASA, because NASA was a pain to deal with DNS people. And that's why it didn't get into NOVA. This wasn't a strategic thing. This was an arbitrary thing that just came out of the organization. And one of the problems with a project that's only two years old is often a lot of the issues that were part of the original project still manifest themselves today. And what I don't want is the 50% of new people in the room to look at OpenStack as it is today as the right, perfect architecture for private cloud. In fact, it's the wrong architecture. And if I can leave you with anything, because I'm not touching that button again, it's that there's a lot of work to do here. And in order to successfully run applications at scale in a public cloud or in a private cloud powered by OpenStack, there are a lot of core services that we need to build into OpenStack. And if we do this right, Juju will continue to work as a layer on top of this. And developers will still get to experience a lot of it. In fact, Juju could tap into some of these core services and make those services available to developers using the Juju framework. This is where Cloud Foundry could fit in. This is where other, as we start to look at ways to enable people to solve problems on OpenStack, we have to start thinking about the foundation and what should be in the foundation and what should not be in the foundation. And what I'd like to encourage you all to do is you go into the hundreds of sessions that follow. Remember, you've seen this presentation five times, so you have no reason not to remember it. But as you have conversations about what is OpenStack and what should be a core project, think about solving problems, think about running applications at cloud scale. And think about what's missing. Think about what every single person needs to get running in OpenStack to get a cloud application running. If we don't go down this path, we will build VMware. And I don't think that's where anybody in this room wants to go, no offense to VMware. I think there's 25 years of software that shouldn't run anywhere else. But I think the next 25 years of software need to have a foundation that allows us to all have a common way. I was listening to some large enterprise CIOs that we talked about, the challenges they have with public cloud and private cloud. And if OpenStack gets it right, the same underlying core technology will power public clouds and private clouds. And we'll see true workload portability, true interoperability with management tools, true common views on how we view security and compliance across these systems. And if we get it right, you can't just treat public cloud infrastructures as black boxes anymore, Amazon. You have to expose what's happening, because if you have a certain level of visibility, if you achieve compliance in your private cloud and you move an application into the public cloud and you lose a lot of those core elements of logs and auditability and what's happening, you can no longer envision using for a lot of workloads a public cloud. And so I think what we have an opportunity in OpenStack to do, if you look at this in the list of services on the left, monitoring, accounting, auto scaling, basic orchestration, if we can get these into the architecture successfully, we have an opportunity to define what Amazon does next. You can do that. You have that opportunity today. And the opportunity is HP and other public cloud providers will implement these things if they're an OpenStack, and then the private cloud providers, the Ubuntu's and the Red Hats out there, will expose these things, and then people will start building security policy that requires common view across public and private cloud infrastructures. This is the key to making this work, is getting this core technology into OpenStack, so regardless of whether you're dealing with a public cloud or a private cloud, the APIs are talking the same language. And then we'll start to see Amazon implement what we're doing and not the other way around. And we'll start to see whole new applications for workloads. I've often said that IT is a $3 trillion industry. Amazon has around $10 billion by rough estimates based on their filings with the SEC. So even if they were $100 billion, that is a small fraction of what people invest and spend on IT every year. And so I just want you to realize that that logo slide you saw 15 times, there are a lot of companies here because they see an opportunity for their products and their services to fit into this ecosystem. And the question you should ask yourself is, if my whole company were an API, what would it expose? What methods would it expose? What could I do with my company's API? And then ask yourself, is that an application? And if it is, in order to run that application on OpenStack, what do I need under the covers? To ensure regulatory compliance, to ensure customers are happy with the performance of the application, whatever. And so as we start to, I just like to propose this because the other things I'm going to propose, I don't want to mess with this thing. Scary, scary, scares me. And I think if we all start to have this conversation over the next three or four days, I'm really excited about what's going to happen. And I'm just going to say thank you, I think. There we go. There we go. Thank you very much. All right, so Chris proves that you don't have to do a demo to run into crazy technical glitches. So that concludes the keynote session for today. There are a number of sessions that are going on. Lunch is going to be at 12.30. We're actually going to be taking the back of the room and turning it into Manchester E and F. So there are a couple of sessions that are going to be going there. They may start a few minutes late if you were going to go to those. But other than that, thank you all. We'll see you around the halls and see you tomorrow morning.