 We have one more keynote, and this one is from Red Hat. And I got a little peek at it earlier today while they were running through it, and I noticed that a lot of you actually make an appearance in it. So this is gonna be really great. So at this time, I wanna go ahead and bring up CTO and VP of Global Engineering from Red Hat, Brian Stevens. Hi, everybody. You know, I've been to probably three or four of these, and I gotta say that every one of these things gets monstrously bigger, as you guys have seen, and spent a lot of time back there in other parts, but with Jonathan and on the board. I gotta say that Jonathan, Laura, and Mark, this thing just like exploding in scale, not just like the cloud, but just this event. And these guys handle it just like we just saw with like grace and calmness that I've never seen before. So we're in good hands. So I wanna talk to you about a couple of things. Obviously we wanna talk a lot about what Red Hat's doing today around OpenStack, but I think before we get into what we're doing today, we wanna back up in time a little bit. So all the way back to, as everybody was talking about in 2010, for us it started with a phone call from Jim Curry Rackspace, right? And so what he said was the dream, right? He says, we wanna build this ubiquitous cloud computing platform with the community. We wanna be able to make it meet all the needs, not some of the needs, all the needs of the public cloud, all the needs of the private cloud. It's gonna be really simple to install, and it's just gonna scale forever. And we're like, I'm just sitting on the end of the phone. You know, we've heard this before. Red Hat, it might have been like, we're gonna create the new database, might be able to create a new system X, Y, Z. It didn't really matter. We've heard it a million times before, and we said, yeah, it's an awesome vision, but we can appreciate in open source how hard it is to catalyze a community and bring it up. So it took us a while. So 2011 rolled around, we joined the summits, but we didn't really get that actively involved until 2011, it was in August, and we assigned a first developer to start working on OpenStack. And he's here, his name's Mark McLaughlin, and he had a mission. His mission was first just start small, one developer, and we have an open distribution that we get in the hands of millions of users called Fedora. And so, you know, Fedora was a great place for us to put OpenStack inside. So that was what Mark's mission was by joining. And this is actually his first patch. And so his first patch was really simple because we've got this weird model, we've got this upstream model inside of Red Hat. Instead of just like taking OpenStack, hacking it into Fedora, making changes there on your local copy, we really work upstream first. And so there's some things that Mark needed to change to make OpenStack fit inside of Fedora. And he did it on the public mailing list, and this was signed off by Josh McKenty on August 24th of 2011. And so that was our Red Hat's first involvement. The very next day, I sent out this memo inside of Red Hat, and it really was, you know, obviously it's not confidential anymore, but it was really just this recognition that everything that Jim in Rackspace had said to us 10 months earlier was coming true. It's a recognition that this brand now had global awareness, and it was a mission, it was about, it wasn't just about what they were doing, it was how they were doing it. They were doing it in the open way with this vibrant community. And for Red Hat, it was like, this wasn't a marketing statement. It was like, we've got to be all into this thing. This is like how we operate, how can we not be a part of it? So we began, and the response to that memo was huge because there's all these people saying, hey, there's this great thing happening out there in OpenStores, and we're not really a part of it. So the response was really huge. You know, the best one was just like, first thought, wow, let's do this thing. And so we did. So we started, we joined the first, luckily the first design summit that we participated was in our backyard in Boston. So our headquarters for engineering's in about 30 miles outside of Boston. So we joined that design summit. And then not long after that Rack Space started about spinning out the foundation, and I was just scratching my head like these guys got this great brand. They got a tiger by the tail. They got, you know, all this code coming up. Everybody loves it. They're the leading developer, and they just want to federate it. And I have to say I was just so impressed by the fact that they were, you know, because you just, there's very few times that you've ever seen something like that happen, and they pushed it away. And so we were all in right from the beginning. I mean, they just wanted to see how do we raise an industry and not just raise a company. So, you know, 2012 comes along in Essex ships. That's the first time that we actually had some Red Hat contributed code inside of an OpenStack distribution. The foundation, you know, was up and running, as we said, it's been up for about six months. Red Hat joined on a platinum level. We thought about it from two things. We usually just sort of show up with code, but we said, you know what? I think it's important that we make a statement by joining the foundation. And that was for, in part, two parts. It's just as Jonathan and others talk about, it's like, how do we protect this great thing? And we worry about it, we want to protect it, but then I also have this other dimension that I really worry about, the foundation gets too much in the way that developers. So my concern is like, so how do we do just enough but not get in the way? Because they've already proven that they can go fast and furious and really do great things. Then later in 2012 was the Folsom release. So Red Hat hadn't been involved that long at that point in time, just over a year, but we, at that point, had become the number two developer to Folsom, so we were pretty proud of that. And this is what the team looked like back in 2012. This was in October 2012, so this is the main leadership for the OpenStack team back then. And instead of meeting in Boston, and these guys go to Dublin, I think they plan better when there's a great city with great beer. And that's here we are now. So now Grizzly's out, right? And so we're pretty proud of this stat as well. So these guys just sort of, it's actually, at Red Hat, it's hard to keep people away from OpenStack because it is such an interesting and hot project that a lot of people naturally grab it to it. Whether their manager assigns them to it or not, they want to be a part of it. And so this wasn't like some corporate mission, like we want to be a top developer of OpenStack. It really wasn't about that. It was just sort of the natural proclivity of the engineers to want to be on this cool community thing. And so we're proud that we sort of lead in the contributions. That'll change. The best part about it though, is that, as you've heard, is that if this chart fanned all the way out and included the others category, you'll see the others category is one of the largest contributors to OpenStack. And that's just a really great thing. But again, the goal isn't to be the top developer. The goal is just really how we write software at Red Hat. So we want to talk a little bit about that model. We've got a little bit different model than most. I don't think there's a right model for how you think about OpenStores if you're a software vendor. Obviously Intel and others get involved enough to sort of optimize their hardware. Others believe in the open core model where they get a common core out there and then you upsell proprietary. Others, you see this a lot with Quantum. There's particular areas of OpenStores that they want to get an invest in because then they can enable great things with maybe their existing portfolio. And you see that in spades with Quantum and everything around networking with Juniper's and others' involvement. And others really don't do a lot of upstream contribution, but they take the product, they take the body of works and support it for customers. But then there's some and like us, we just go all in. So we don't really make that separation with sort of 100% OpenStores and it's not just a commitment of supplying OpenStores to our customers. OpenStores has become our development model. So when we look at sort of like what the trunk is, the trunk for us for our software products is externally. We don't keep shadow trees and develop first inside and then decide when to release code. Really the lifecycle of software development at Red Hat starts first and foremost upstream. And it works. So when I joined Red Hat 11, 12 years ago, if anybody told me that you can make money selling free software, I mean it's a pretty hard thing to do for sales people, but we broke the billion dollar barrier a year ago and now our latest fiscal results were somewhere north of 1.3 billion all on OpenStores. But that said, it's not a business model. So I think a lot of people get fooled into OpenStores, put it in our tagline and it's a business model, it's not. It's just simply the best development model on the planet because it enables that collaboration of developers and the more developers that have great diversity are just gonna develop better software. There's just no other way around it. And users win because all of a sudden the users are the ones that are in the control. They can consume technology sort of on their path, the modules that they want and at the cadence they want and that just never really happens in the proprietary software world. So before we got involved in OpenStack, we actually got involved in another project. And that was really because we were saying that big unicorn was out there and our developers were all starting to use it. So our developers in the past, just like a normal organization we're always waiting on as our business grew, waiting on hardware resources. So they just quickly, they didn't wait for permission, they just gravitated to Amazon. And so we had hundreds and hundreds of developers using Amazon and what we found was though these guys are all becoming cloud experts. So that wasn't their mission, but they all became cloud experts saying I understand the interfaces, the terms of service, how to stand up workload on and on and on and on. And that felt kind of broken to us. So we didn't know there was a category back then called Platforms of Service. It wasn't that Red Hat says we need to have a Platforms of Service product. But what we did know is that there was a lot we could do to substantially change the development, ease of development that our developers could have when using a public infrastructure cloud. And that was really what OpenShift became. It was a service that we built on top of Amazon really for ourselves. And then it just got bigger than that. And the idea is it's just a polyglot system that you can develop in the language that you care about, PHP, Ruby, Java, whatever. And we just package these things up and the community packages up in modules, whether that's a, could be a database, could be a language. And the best part about it though is the developer doesn't know about the infrastructure cloud anymore. They just have no awareness that it's even there. So really this presentation itself was written in Git. And I never once logged into Amazon Cloud or even looked at Amazon. I just developed in Git on my local sandbox. And then what happens is when you wanna push your changes, the changes, OpenShift takes your changes and it deals with pushing them up to the public cloud. It deals with packaging them and continuous integration. There's thousands of RHEL servers actually up running on top of Amazon Cloud. And so what the OpenShift, the service does is decide where to put your application. Because it compacts it on a RHEL server along with a lot of other applications. And it deals with plumbing the DNS and load balancers and all of those other things that developers just don't need to worry about. And all that happens in about a 10 second interval from the time you actually change your code to actually push it up. And the best part about it is, as a systems vendor, you know, predominantly known for Linux, we're constantly looking at the road up to all these things that we need to put in Linux because our customers care. And three of those things that for the first time we're like a recipient of, we're a consumer of them on the OpenShift cloud. And what that means is, because so if you're thinking about it, you don't want one app per VM on just a waste of money and a waste of resources. So what that means is you gotta consolidate lots of apps on a small number of VMs and things like Linux containers, SC Linux for security, and then all of the QOS stuff that's coming in C groups is really making that happen. So now you can actually, we'll have hundreds and hundreds of apps on a single rel instance running on the Amazon cloud. All, you know, with great performance. So today there's about a quarter of a million apps up and running on Amazon. And the best part is, so we started there saying we wanna change developers' lives. And now all of a sudden, you know, come along OpenStack. And now what's happening is now that OpenShift is actually an enterprise product, the deploys we're doing inside of our customer environments now are typically OpenShift on top of OpenStack. Because with that all of a sudden OpenShift, the service is able to deliver elasticity at the application level. So I wanted to show you what that looks like. My name is Luke Meyer and I work as an engineer on OpenShift Enterprise by Red Hat. So I'm gonna be demonstrating a quick installation of OpenShift using the OpenStack infrastructure. Starting with an empty OpenStack project, I'm going to create two instances for my initial OpenShift Enterprise installation. OpenShift requires hosts for two major purposes. First, it requires a broker which provides the user interface and manages the interaction with the applications. There are actually multiple components to the broker which can be separated out into multiple hosts. But for simplicity, we're just gonna install everything on one host. Secondly, OpenShift requires one or more OpenShift node hosts. These are where applications actually live and run. Each application consists of one or more gears which are sort of like pseudo virtual machines within the host. But instead of each gear running its own operating system with all the overhead that entails, each gear uses host resources directly, but it's contained in overhead enterprise Linux system features like SE Linux and C groups so that its resources are limited and it can't interact with other gears in the same host. We like to use external storage for gears so that they can survive in the case of a node failure or administrator error. OpenStack lets us easily create a storage volume for this and associate it with the node host. Once the hosts are up and running, we need to actually run the installation. After subscribing the hosts, we run an install script on each. This installs a lot of packages via YUM and then configures them to work together as an OpenShift installation. We're gonna fast forward this a bit, but it's really just a few tens of minutes. You can definitely finish this before launch. With the installation complete, I'm gonna snapshot the node host in OpenStack and use it as a template for adding more nodes later. I'm going to add on some proof of concept code that will enable us to scale automatically with OpenStack. I need to install Cloud in it and some code that will initialize the hosts when it boots from the image. And I'll do a little cleanup first to make the installation go smoothly. Then I'll just snapshot the node host and wait for it to show up as an available image. Now I'm gonna create some applications which can be done in several ways. We'll start with the command line tool RHC. First, I need to get set up with my new OpenShift installation. And now I'll just create a PHP application. Then we'll go visit the webpage and you'll see that it has the initial demo content. Next, I'll use the web console to create a scaled application. With the scaled application, as traffic increases, OpenShift can increase application resources by adding extra gears to the application and low balancing the traffic between the gears. I'm going to use this scaled app to demonstrate scaling up OpenShift itself. I'm going to enable the OpenShift broker to access the OpenStack API in order to instantiate more node hosts. First, I'll install the Nova client. Now I'm gonna sync over some proof of concept code for monitoring resources and using Nova to request new nodes. Finally, I'll check the OpenStack credentials I synced over are working and it looks good. So I'm ready to start scaling. I'm going to watch the current status of node hosts in the top window and I'm going to watch the capacity checker logs in the middle window. So let's say I deploy the BackhandRest API for a really addictive mobile app on that scaled app and it's gone viral. Traffic is pouring in. As it detects load, the application requests more gears with its OpenShift supplies. As you can see, I've limited the nodes to only six gears per node. In a real installation, you would probably want a lot more and adding a node would be a pretty rare event but I wanted to see it over the span of a few minutes. So we'll just fast forward a bit. Now, we're past the 80% capacity threshold, I said. So OpenShift is going to request a new node host from OpenStack. Here, let's watch the node creation finish. The node joins the OpenShift message bus and is added to a resource pool we call a district. We can also see the node in its volume have been added in OpenStack. We add some more traffic, the gear numbers go up, and we're adding a third node. More traffic, more gears, and a fourth node. In case you're wondering, you can set limits on your scaled apps so they don't automatically fill your infrastructure. So you just saw how we can install OpenShift Enterprise using OpenStack as the infrastructure layer and then set up OpenShift to request additional resources as needed from OpenStack, hands-free with no administrator involved. So it's actually a pretty good marriage. There's a lot of stuff on customers with OpenStack and OpenShift together. I mean, customers are just sort of going all in on this OpenStack from infrastructure as a service to platforms as a service. I wanted to show you just a couple of stats of what's happening online at Amazon right now on OpenShift. Typically, on a daily basis, there's about 1,000 new applications that users actually create on OpenShift. And that means that we actually have to burst and we have to add typically about a node a day, actually 1,000 applications per day about a node a day to handle that capacity. And then when you look at the aggregate traffic that those applications are actually serving, it's, you know, 690 million pages per month. And then we're talking about gear hours. That's how we do the math if we think about how much computation resources that an app is using. And that all sort of this one OpenShift tier uses about 13 million Amazon minutes each and every month. So I want to shift gears a little bit and talk about what we announced yesterday, which was RDO. And so the whole point of RDO is it's a free, community-supported distribution from Red Hat that Red Hat's leading. And the whole point of it was is that what we wanted to do is we wanted to hear a lot about sort of continuous deployment. What we wanted to do is we wanted to be able to track upstream really quickly. All the technology work that's happening inside of OpenStack at OpenStack.org, how do we actually, on a really fast cadence, on a daily basis, actually package that up, put it into a distribution that installs neatly on top of Fedora, Red Hat Enterprise Linux, all the Enterprise Linux derivatives that are out there. So when you sort of look at the timeline of OpenStack releases, the horizontal bar is, you know, as you move from Grizzly to Havana and all the milestones. And then as the major releases come out, they're stable branches. Those are the up and to the right arrows. So even after Grizzly's out, now they've become a stable branch. So what RDO will do is RDO will track all of that. So anytime there's milestones or interim drops. But actually in sort of the world, continuous deployment, it's actually probably going to get a lot better than that. There's no reason that any sort of feature or bug fix anywhere along the path that we won't be able to release. So it's a new landing page at Red Hat right now, OpenStack.RedHat.com, and that's where you go to find RDO. And so on the customer side, you know, it was no surprise. Once we started putting developers on OpenStack and once we joined the foundation that, you know, the model for us is a subscription. And what that means for us is beyond just the bits. Like how do we bring the customers full-on certifications? How do we create certifications that all of our partners, Hardware and Software works together with OpenStack? Everything from support and training and all the other things that customers have been known to expect. The case of extended life is often the bane of our existence. You know, from Linux alone, often customers lock it down for 10 years on just one implementation, and you have to maintain that. That's going to happen less, obviously, in the early days of OpenStack, and that's what we're very proud of. On the other side of OpenStack, our initial release was based on S6 for our subscription product. And then it was right before Folsom came out and then that was updated to Folsom. That went into what we call a preview mode. So it was basically up on the website. Customers and users could come and fill out a form and download a preview version. But what we also did is, like other companies, we started working and hand-holding shoulder-to-shoulder with companies that were going to be very aggressive on OpenStack and there's about 23 of those today. And that's sort of just how the enterprise subscription sort of tears off. This is the upstream-first model what we talk about a lot. We can't get something into the product if we're not shadowing and tied tightly with what's happening in RDO and upstream. So now, as of this week, though, we've gone to the next phase of our OpenStack product offering. And so what happens is now all of a sudden inside of Red Hat's nearly 6,000 people, the whole organization is really up and running on OpenStack. So what that means is now we can widen sort of the customer landscape. So now we're actually, sales are actually able to nominate up to 200 customers to bring them through a support relationship through OpenStack. But as John was talking about, to us it's all about the ecosystem. Nobody really wants one vendor's OpenStack product and just deploying it in their data center. It's all about how it works with everything else. And OpenStack has probably as we've talked about, it's very pluggable, but there's integrations that need to happen at both the compute and hardware tier, at the storage tier, network tier, management ISPs and whatnot. So for us that meant that we need to have a formal program for how do we actually work with all of the other partners in the ecosystem. And that was launched this week with Intel and Cisco coming at the alliance level. This is how it really sort of fits into the Red Hat stack. And what's interesting about this is that it's a core stone for all platform development is Red Hat Enterprise Lengths with KVM inside. That's how we deal with hardware certification and that's where applications land. And what the interesting study that we saw yesterday or Sunday, and I think was presented yesterday as well was sort of the user study on who's using OpenStack of over 400 people that were deploying OpenStack. I think it was 72% of them so Red Hat supporting Swift and Cinder, the storage solutions for block and object that are part of OpenStack but as well as adding we had Gluster to that package for scale-out storage. The OpenController should be a wireframe because it's not a filled-in box yet. We partner with people that make great network controllers whether they're hardware and software but we think the industry needs and a really open software based controller. We joined Open Daylight as did many other people and that's our, we want to have a place to throw down developers on an open source network controller. And then OpenStack for infrastructure service and OpenShift for platforms of service and then up with CloudForms that was found its way in through an acquisition recently and that's how you actually go to the last mile for Cloud for us, everything from sort of metering, billing and orchestration. So as Jonathan said, I wanted to do a little bit of a shout-out as much as we talk a lot about companies and foundations. You know it's really people that have built there's 517 people so it's growing really fast but rather than just sort of look at stats and say you know is it going to be 600 next month, we wanted to actually we looked at some of the people that we thought made a really great contribution to Grizzly and we wanted to recognize them right now. I mean we're changing the face of IT and we're doing it in the open source way and you know at this conference seeing the number of people here and the energy around the project I think it's pretty fascinating and we're going places so people need to see it and watch what we're doing. Right so I've been working at OpenStack almost ever since the first birthday party in July 2010, I was one of the first hires at Rackspace, a community manager and a technical writer so that was amazing to see that right off the bat an open source project wanted to make sure documentation was a priority. So my general focus on OpenStack is on the Nova side. I really jump all over the place there wherever help is needed. The CI team and we're also trying to call ourselves the infrastructure team because it turns out we do more than CI these days but we run all of the developer tools and automation that the OpenStack project uses to land the massive amount of changes that it does. So a lot of people might think I'm going to say that the thing I'm most proud of in Grizzly was the operations manual, the operations guide but in reality one of the things I'm most proud of is that we got started with an internship program at OpenStack so there's a program called the GNOME Outreach Program for Women and they tend to encourage women to apply for these open source internships. Well the obvious answer to that is that Solometer graduated from incubation and is now an integrated project but I think even more important than that is the fact that the community developed the process for allowing new projects to join the foundation and be in integrated projects. It's about having everyone on the same rhythm because people come from very different backgrounds and companies and we actually want them on the same schedule with our deadlines whether they're internal deadlines so my role is to make sure that they all share the same rhythm and we are a single group of people working to where they come and go. So I joined Red Hat late in 2011 and that happened to be when Red Hat was getting involved in OpenStack as a company. I started working on Nova and since have become more and more involved and I was recently elected as the Project Technical Lead or the PTL of the Nova Project. Grizzly has a lot of new exciting features I'm especially interested in the Google's feature for Nova and the improvements that have come along in OpenStack Networking. Mark McClain is another dream host employee he's the new PTL for the OpenStack Networking Project and they're doing a lot of incredible work there bringing new features in and a lot of good collaboration with a lot of very different interests. During the Grizzly cycle I'm really most proud of getting the sales code in John. We have been talking about it for a couple different releases and finally made it happen. The crazy thing we did during the Grizzly release was we finally were able to pull people into a room gather together and work on the operators guide. I'm proud of the project in general. I think the growth itself is outstanding just looking at the development community that the number of contributors has grown earlier this morning someone said we had 550 technical contributors to our last release over a six month time frame. So it's about enabling the collaboration across the some odd companies that we've got all trying to hack on this thing. The collaboration space we've been enabling between multiple companies to work on the same thing rather than reinvent separately those things that's where one aspect what Open Source actually shines is by enabling that to happen into those common collaboration spaces between companies. We can do this in a way that still allows people to have companies and to be successful but we can do that without hamstringing the users so we can actually make the world a better place for trying out loud. So last couple of things. Look at these projects. Linux, OpenStack, Hadoop, Rails, Mongo, Git, Cassandra. They've got three core things in common. I know you guys all know the first one is they're all Open Source. But interesting enough they're also examples of what we call redefining IT. Open Source has gone past the days of where it's just trying to replace and get free in Open Source. These things are all creating new capability for customers that they just didn't have before. And the third thing which I think is perhaps the most interesting of all is none of these were started by vendors. Every one of these was started by either end users or developers and I think that's sort of the turning point that we've entered in sort of the Open Source community and IT. And so I think it's really clear to say that without Open Source in general that cloud as we know it wouldn't exist in these shadows of what they are today. And while perhaps we can't say that about OpenStack yet today, I think if we start to look out two or three years from now, I think it'll be really hard to imagine what the industry would be like without OpenStack. So thanks for your time. Thank you, Brian. So that brings us to the end of our morning session here. Sorry, we ran a little long. Again, everything is going to be starting later downstairs. Some great additional users. We have some scientists doing high-energy physics and we have the NSA and we have additional keynotes coming. So I hope you guys had a good morning and go have a good remainder of the day.