 Happy to welcome all of you here. It's relatively early. People have to fight the Google-generated traffic. What is it? The Google traffic. But thank you, the group that made it by 9 AM. Thank you for being here early. Well, it's a distinct pleasure to have this conference because what's happening in the open cloud ecosystem is that the speed with which we're moving is just incredible. I mean, it feels that way when you're inside. And we're used to two large conferences that happen in the two summits. And it feels like between the two summits, so much is happening that there is a huge demand to kind of share it with all. And this event is becoming somewhat of a mid-cycle business meetup and technical meetup that we're having. And I just want to thank the foundation for allowing us at Mirantis to help put this whole thing together. So this is wonderful. So the theme of this conference is kind of akin to the times. So what's happening is we all saw the report from Forrester that actually talks about OpenStack being ready and OpenStack being viewed by the customer community as the fifth platform that people can use in their cloud journey. And so when you look at the other four, we have three public cloud platforms that people take very seriously. Clearly Amazon, Google Compute Engine, and Microsoft Azure. And on-prem, people are looking at VMware and now OpenStack. So OpenStack in the five years that has been alive, and some of us are wearing the letter five here, the five-year t-shirt. So it's a little toddler, I guess, at five-year-old. There you go, that's the t-shirt. So at the age of five, OpenStack has become one of the most important platforms by mindshare in one of the most important journeys that technology is conducting, which is migration of the world into the cloud. So this is a great accomplishment for us. But also, not only it's a great accomplishment, it's also a great responsibility. Because when people look at you as a viable alternative for something or a first-class platform and that important to journey, it's no longer about just the infrastructure or just the thing that we've been talking about. It's about making this a compelling customer experience for the whole stack. And for customers to be able to use this platform to make sure it continues to innovate, make sure that it stays competitive over time with the other alternatives. And this is not just the inner OpenStack community anymore, it's about OpenStack movement opening up and bringing partners from every walk and every technology direction that's happening in the industry to really enable OpenCloud. And so the theme of this conference is what are those partnerships? How do we bring them together? And how do we harness the mindshare that OpenStack has garnished in the idea of OpenCloud to build the platform that becomes not just the fifth platform, but really the preferred platform and the number one open platform that customers can really use and count on for years to come? So that's the theme of this conference. And I'm happy to welcome Joe Weinman, who many of you know, who is going to be the emcee of this event. So please have fun and we'll see you during these two days. Joe? Hi, everyone. It's a pleasure to be here at Structure again. I'm sorry, at the OpenStack Silicon Valley Conference. I have to tell you, I was asked to do this and I thought, OK, well, that sounds interesting. And then as I saw the agenda build, it's just a superb lineup of speakers. Everyone, anyone, everyone, the entire world of cloud computing, thought leadership, and the people that are making it really happen are here. There is one vendor absent for some reason, but for the most part, the lineup of speakers, it's the people that have been defining cloud over the last decade. So it's really just going to be an amazing event. I have some housekeeping items. There are restrooms and they're somewhere out there. OK, so it's a pleasure to be here also at the Computer History Museum. I've flown by 101, kind of doing 80 miles an hour or so. No, not really. That's obviously a fake story that couldn't possibly happen. But I've been up and down 101 lots of times and never swung by. So I was talking with Lou Tucker earlier who actually, before cloud computing, invented or helped construct an engineer, one of the first thinking machines, which is here. So that should be pretty cool. And it's interesting that OpenStack is here at the Computer History Museum because some people would say that OpenStack has made history. So it's appropriate. On the other hand, other people would say it's the future of computing. So I'm not sure why we're here. But in any event, it'll be a great event. Thanks in part to all of you and also, of course, to our sponsors, which include IBM, Google, NetApp, Rackspace, and Intel. So let's maybe do a big round of applause for them. OK, so I'd like to review the roadmap for the day. There's a cocktail party at 5.30. OK, thank you. Oh, wait. Before the cocktail party, basically this morning, everything will be in here, except for the breaks and a few sponsor moments. We've got a great morning set of keynotes to kick things off. We've got James Staten from Forrester, who is now at Microsoft, but probably is the single greatest analyst on cloud computing and has been for a long time. So that's an interesting shift. We've got Craig McLucky from Google. And we're going to kick things off with Jonathan Bryce, Executive Director of OpenStack Foundation, as you know. And he's got a special guest customer, which is Amitank, from basically what was Direct TV and is now the Direct TV unit of AT&T. And so this morning, they're mostly going to be focusing on the state of OpenStack, the relationship of OpenStack with containers, what those companies are doing, and also what it all means for DevOps. And then we'll have a break. And then we'll bring them all back on stage. And I will be moderating them in the first panel discussion. So if you have any pithy, evil questions that you want me to ask them, come grab me at a break. Otherwise, I've got some good things to get things kicked off. So without further ado, I know it's really a lot of fun listening to an MC Yameron rather than actual content. But that said, we'll just make a quick switch and bring out our first speakers, which are Jonathan Bryce and his guest star, Amitank. So please join me in welcoming them. Thank you, Joe. Thanks, everyone, for coming. It's good to see everyone here at this event again. It's growing as most OpenStack events do. It's really cool. One of the things that I love about the OpenStack community is how global it is. And it's really cool to see these kinds of events happening all over the world. Since the last summit, we've had them in Germany and Hungary. We had the first one ever in Istanbul in June, about 500 people there in Turkey. We just had a couple. One was in India. One was in Taiwan. I think there were around 1,700 attendees in Taipei. So you guys are a part of something that is great to see happening here in Silicon Valley, but it's also happening all over the world. And it's much bigger than any of us or even this event today. To start off with, I actually have something that is a pretty exciting announcement for the foundation and for me personally. As many of you know, we started the OpenStack Foundation three years ago as a nonprofit that would be dedicated to the long-term care and management of the OpenStack project and the community around it. And we just received word that after a very long and intricate back and forth with the Internal Revenue Service. I don't know if any of you guys have ever had to go through it, but they're thorough. We are now recognized as a tax-exempt nonprofit. Yeah, and it's great because that's a recognition of what our community and our foundation is doing for the cloud computing industry as a whole. That's the only way you get that designation. And from a practical perspective, it's awesome because we're going to be able to have more resources to invest into the community over the long term. So very excited that we have achieved that. So to start with today, one of the things that we always talk about is how critical software is to every organization today. They have to make use of it. They have to build it. And that's what's driving so many of these technology shifts, whether it's cloud, whether it's containers, it's the application of the entire economy. And we talk about that as the driving force behind a lot of it. In OpenStack, especially in the last year, we've seen dozens and dozens of companies who've come out and talked about how they are using OpenStack to really capitalize on the opportunities that the software to find economy brings to them. And these are some of the companies that spoke about their usage at our most recent OpenStack summit in Vancouver. You can go to opensack.org. We have videos. Every video from all of our summits is posted there. And you can go hear straight from them. We've done a lot of summits, and we have had a lot of speakers, so there's tens of thousands of hours of video content up there. And it would take a lot of time and effort to get through all of that. So one of the things that I wanted to do to kick the day off is to take a bunch of the knowledge, a bunch of the wisdom that these users have shared with the community and have shared with us as we've talked to them, and present four patterns that we've seen that have helped companies take the path to production with OpenStack. And when you look at some of the companies that are doing this now, these are companies of all sizes, deployments of all sizes, but there are some things that are in common across it. And just looking at some of the names up here that are using OpenStack in production, you have companies like FICO. They're part of, I think, 97% of the credit decisions that get made. And that's powered by OpenStack now. You have Walmart. They ran 100% of their holiday traffic last year on top of OpenStack. You have PayPal. 100% of their front-end production traffic is running on OpenStack. So real usage happening with real companies at scale, big piece of our economy, and tools that we interact with every day. So how do they get there? Four patterns to run through quickly. The first one, no matter what size they end up with, all of these companies that I've talked to that have had a successful OpenStack deployment have started with a very specific focus. And I think that this is really a critical pattern anytime that you're adopting a new technology. When a new technology comes out, it could be really exciting to think about the possibilities. But also, there are always challenges with it. And everybody knows that the first version of a piece of software, the first version of a piece of hardware, it has glitches, and you have to work through those. These companies, what they did is they found specific users that, within their organization, that were going to benefit from the advantages that OpenStack could bring, agility, time to market, speed of development. And they worked with those users almost like VIP beta customers, internal customers. They talked to them about, what do they need? What's working? How do we fix this so that it's really valuable for you? And then what you see is those internal customers turn into internal promoters. And all of a sudden, companies or users across the organization are really demanding that they have access to this infrastructure. One of the really interesting organizations that came and talked about this a couple of years ago was the NSA, the National Security Administration. And you don't necessarily think of them kind of taking that small team startup approach inside of an organization like that, but they did. And they were very successful. I mentioned Walmart a little earlier. Walmart is a massive company. They have massive scale. This is a graph of their path to production with OpenStack. And you'll notice that, obviously, a lot of buildup, especially to this last holiday season, but back there in 2013, they were running select workloads and production on OpenStack already, but at a tenth of the scale of what they run now. They had users internally that wanted that agility, that wanted to be able to move faster, that wanted to be able to self-service their own infrastructure. And so that was where they started. They worked out the kinks there and they moved on. So once you've found those critical early adopters who are going to be your promoters, who are going to help you tune the product, then you start thinking about how do I take this to larger scale? And that's when the team really comes into play. So the second pattern that we've seen is that companies who are successfully deploying OpenStack, they look for experience operating horizontal services. This isn't just about can I take some kind of monolithic application and vertically scale it and tune it and make it perform. That's a very valuable skill. But OpenStack is a collection of services. Sometimes people call it a framework. And so you're going to have a number of different services. They're going to scale independently. They're going to have different failure modes. They're going to have different areas of optimization and configuration. And that's a skill set that's out there, but may not be something that you have on your team right now or that you have a lot of experience with. This isn't just an app server, a database server, a storage system. And so finding someone with the experience of operating horizontal services, distributed services, at scale is really important. And I think one of the really key things to remember with a cloud environment, when you get into elastic workloads and self-service, people are running, it's much more arbitrary about what's going to be running in your environment. You're not going to have as much insight and control over exactly what's on this machine. So you need to have people that think almost like a service provider. And you can hire them. You may already employ them. But what a lot of successful users do is they work with some of the different organizations in the OpenStack ecosystem. You can go to the opensack.org slash marketplace and find a variety of companies who provide different models. And you're going to hear about that through the next couple of days, but different models for delivering OpenStack. And it's really, really key to consider how you find that experience. Some of the users that we talk about that are running at huge scale, they have small teams internally. But they found really good experts in the community, really good experts in the ecosystem. So once you have found your early adopters and started to scale it, it's time to take it all the way across the organization. And that first step is really about creating the carrot and finding the people who want that carrot. But eventually, if you really want it to be something that takes hold everywhere, then you may need a little stick. And so this is when organizations start to think about, what is their policy going to be for infrastructure? And people say cloud first, or I said cloud preferred here. The idea is really that at some point, you're going to have to put a stake at the ground and say, going forward, our preferred deployment model for new resources, for new applications, is on the cloud. And you may need to think about writing applications a little differently. You may need to think about provisioning resources on a different timeline. Those are all things that end up taking place. We had another user who spoke about this in Vancouver from TD Bank Graham Peacock. And this was a quote from his session in Vancouver. He said, if they can't build it on cloud, they need to get my permission to obtain a physical server, which is pretty hard to get. This is TD Bank. They're a massive organization. They are in the financial services industry. They have lots of legacy workloads. But this is the strategy that they are really getting behind. And so they have the policies that are going to help them be successful there. And Graham is not just an administrator. He's not the BOFH who is just grumpy and doesn't want people to do things that he doesn't like. He's VP of engineering. But that's how important it is to their organization overall. It's strategic for them over the long term to change the way that they manage IT. And there are other things that they do in concert with this. It's not just about saying no. They have trained thousands of their developers on how to get the most out of cloud. Because when their developers understand the benefits, then they want to go to cloud. And this policy that Graham has put in place, doesn't become a problem. It just reinforces their path to production and their strategy for infrastructure overall. And the final pattern, which you could say this one should come first, but it's that you have to do cloud for a good reason. When I was here last year, I spoke. And how many of you were here last year, actually? OK, so a lot of new people. That's good. So I had a slide that had a bunch of random things on there, like a jet pack and a lie detector and just all these random things. And the question is, what do they all have in common? And what they all had in common is they were things that the professor invented on Gilligan's Island, instead of plugging two holes in a boat. And if you watch that series, he always had some amazing thing that he made. But there were still holes in the boat, and they were still stuck on the island. And the point is that you have to do things for the right reason. You can't just go build a cloud, especially go build a private cloud for just because it's cool technology and you think you want to do it. And companies that have done that, a lot of times have run into trouble, and there are a lot of failed private cloud projects out there. But the companies that are really successful with it, they have good reasons. And there are a lot of good reasons, whether it's public cloud or private cloud, to go out and build your cloud strategy. And it could be things like cost cutting. It could be things like time to market and speeding up product development cycles. It could be about breaking down silos and getting rid of islands in your technology. But it's something that there are a lot of reasons. And you need to find it, make sure that it's very clear to your teams, to your executives, to the organization overall why you're doing this, and then all of those other patterns, much easier to implement. A couple of examples here. One is a car company that they are one of the top auto manufacturers in the world. They collect data from all of their vehicles, from all of their dealerships, from social media. They have a big data analytics platform that analyzes all of this. And I think since they've rolled this out, they've collected multiple petabytes just from the sensors in their cars that's going into this environment. So it's something that is a really cool use case. And it allows them to have better insight into the experience of their drivers. But the other thing that's really key to it and why they implemented OpenStack is because they had an appliance, one of these big vertical systems, that they were trying to do this process on. And it could not handle all the data that was coming in. They built an OpenStack environment, used some modern big data tools, and were able to run all of these jobs. And that new environment they built was at 10th the cost of the old environment. That's a great reason. And we heard from another user, Tapjoy in Paris. Similar thing. They were all public cloud user. They do tons of data science. They have half a billion monthly users to their mobile analytics platform. If you ever get an ad on your phone from a game or anything like that, there's a good chance that Tapjoy is involved in that somehow. They moved specific data science workloads from public cloud to private cloud. And they were able to get 5 to 10x the capacity for the same price. So if you are having trouble justifying cloud, if you're having trouble understanding why it makes sense, these are a couple of examples of people who have found really good reasons. When you can say we're going to save 10x, or we're going to get 5x the capacity, it suddenly becomes a much easier sell. So those are four patterns. These are all things that we hear from our users all the time. And like I said earlier, you can go hear a lot of this content directly from them on our website. We've got a bonus one here, which is use OpenStack to build a platform for innovation. And this, I think, is not something that has necessarily happened everywhere in all of these use cases yet, but that I'm starting to hear people doing. And that's what I wanted to touch on here for just a couple of minutes. All of these things that we're talking about, they get back to compute storage and networking. Processing data, storing data, moving data. And that's what OpenStack provides is a framework for compute storage and networking. And it does that in this plug-in model with dozens of drivers across all of those different technology components, whether you're talking about virtualization, whether you're talking about storage. There are commercial options. There are open source options. And it's really powerful to be able to plug all of those different technology components in. And be able to take advantage of all this technology. So that's a really key benefit that people find with OpenStack. What it points to, though, is really that underneath all of it, OpenStack operates as an integration engine. It's a layer that takes different kinds of hardware, different types of systems, integrates them into a unified platform that your developers and your users can access on top of it. And so to talk a little bit about that, I want to bring up my special guest. We're really fortunate to have a user here today. Help me welcome Amit Tank. So thanks for joining us today, Amit. Amit. Hey, Jonathan. Thanks for having me. Could you start out just by telling everybody a little bit about what you're doing with OpenStack? Sure, yeah. So a little bit of prolog. There are traffic loads. And then there is NFL traffic load. There are load spikes. And then there is load spike that results from Pacquiao Mayweather paper view event. So at Direct TV, our team is chartered with this directive to bring some really tough, but really interesting problems like auto scaling, demand response, load spike scaling, some of these kind of problems. To solve these problems, how can we bring OpenStack in production and solve some of these business problems? And also achieve other innovations that come along. So that's our charter. Right, yeah. And so we've talked a couple of times, and you've talked about the various environments that you have to integrate, and legacy, and existing virtualization, and then where you want to get to to be more agile and be able to handle those traffic spikes better. Can you talk a little bit about how you are putting the strategy together around all of those different scenarios? Sure, great question. So I think it goes back to the slide that you showed earlier about you have this ability to work with different blocks of technology. And I'm sure that the business audience here can relate to this idea that if you're going to build a cloud technology, you're not going to be able to necessarily build it in vacuum. You have to take your existing workload, and you have to answer the question about how are you going to integrate it nicely with your existing infrastructure. And that's where I think OpenStack really shines. We see a lot of value proposition in terms of, if you want to take it to the end productions level, there are stages that you'll probably end up having to travel, which is probably, you'll start with something like CI CD DevOps environment, which is more catering towards your internal development cycle. And as you said earlier, you build some brand ambassadors within your own organization. Take it to something like a partner integration environment, which is a slightly more elevated form of, involved form of environment where different third party components are now integrated there. And from there on, the next leap is end-to-end test environment, which is pretty much going to be mimicking your production environment. If you can prove within your organization, your management of a management executive leadership and your technology audience that it works nicely in end-to-end environment, it's pretty much then ready for production. So Alex was introducing earlier today, and he was saying that we're going to talk a lot about other technologies and technologies that are on the horizon. How do you see OpenStack playing into your adoption of some of these emerging technologies, like containers and container management frameworks? Sure, very good question. So I think the answer to that question goes through the concept of being able to solve some of the business problems that we talked about earlier in a vendor-agnostic multi-hypervisor hybrid cloud format. So think of it as hypervisor is if you can have multiple hypervisors, and you want to be able to have a cloud, OpenStack cloud, that can integrate with, say, a virtual F5, being able to on the fly create, whip, and add things to the pool. OpenStack is probably the only game where it gives you this part to production to solve problems like your load times using containers. Down the line, let's say you have an amazing load balancer as a service product coming from a startup. And you want to integrate that in your environment. OpenStack is probably the only platform that allows you to pick and choose the best of the breed and make it work with your existing infrastructure. And we see that as our real way to basically bring all of these containers, as well as other emerging technologies into our production, like our path to production. Great, I love that phrase, path to production. Well, thank you for joining us. And Amit's going to be around today, and is happy to talk to anyone who may have other questions. So thank you, Amit. Thank you for having me. May I make a small point? Oh, yes, absolutely. So I'm really fortunate. Direct TV is now a proud member of AT&T family. And I work for my VP, my directors. They are amazing business leaders. And for any technologists out here, if they want to impact on how America consumes NFL video or how America consumes content, they should definitely consider Direct TV as a great place to work and bring their innovations. Always recruiting, yes. Thank you. That's the OpenStack Recruiting as a Service Project that we did. So Amit was talking about the path to production. And I want to wrap up with just the last few minutes that I have here, talking a little bit about how that fits into OpenStack. And I think that as you look at all of the technologies that are part of OpenStack, all of the technologies that are really exciting, they have a lot of potential that are emerging right now, there are a few ways to sort of, I think, kind of chart them out. And this is something that we started talking about a few months ago as we specifically looked at the OpenStack ecosystem of projects. I don't know how many of you follow it closely, but there are many, many OpenStack projects now. It started out as just a couple, and now there are dozens. And that can be confusing sometimes when you look at it. But it's sort of a right tool for the right job thing. And I think that most technology, you can kind of chart it on this quadrant of maturity and adoption. And the things that are not widely adopted and that are not very mature, those are the experiments. The things that are not very mature, really widely adopted, those are unicorns. And unicorns don't really exist. Even things that seem like they are overnight successes, like Uber or whatever. They've been around for years, and they have the hockey stick effect. You've got the top left corner here, which those are the mature but not very widely adopted technologies. That's the niche. That's the things that are important to people that don't necessarily really build out broadly across a platform. And then you have the things that are the winners that widely adopted, very mature, and go on to be really important pieces of the technology infrastructure. And so one of the things that we think in the OpenStack community, this reflects the way we build projects and kind of bring them into the community, is that experimentation really is something that leads to breakthroughs. And that's how you get into the winners circle. So if you look around and you look back when we started OpenStack in 2010, there were some existing technologies that were really close to making that breakthrough. Virtualization was starting to become widely adopted, widely accepted as a technology. The OpenStack component that managed virtualization, NOVA, was a super early experiment. I think it was 12,000 lines of code or something like that at the time, so very early on. But you move forward to where we are now. And you see five years later, virtualization, extremely widely adopted. And OpenStack Compute is also extremely widely adopted. I was looking at some of our user survey data recently, and we have over 1,000 deployments in our deployment database, our often deployment database at the foundation now of OpenStack Compute. And there are many others that are not tracked in that. But this is something where it's achieved that. If you expand this out, though, and you look at kind of OpenStack overall, what you'll see is that various projects are in various stages of adoption and advancement of the technology. And I think this is a really important concept to keep in mind as you look at OpenStack or as you really look at any potential technologies. And you'll notice that the projects that are kind of the pieces that have become part of the core interoperability guidelines, those ones are all up at the top right. But there are companies who are running some of these other projects in production today. Doesn't mean that you can't use them. But I think this is an interesting way to chart it and important to think about. If you go up to the top right, it's going to be more stable, more well-tested. People have more experience running it. If you go down to the bottom left, you might still get a huge value out of it. Again, going back to pattern number four, if you're doing it for the right reason. But you might have to put more effort into it. And I think that if we think about today, what's happening is we see tons of experimentation happening. We see a lot of things happening down in that bottom quadrant with software-defined networking, with containers, with things like Kubernetes. Craig from Google is going to talk in just a few minutes. And all of that is awesome, tons of potential. But we have to really think about how do we adopt it? And as Amit said, how do we find the path to production for those technologies? I think that one of the things that we're starting to see some open-stack deployments do is they go back to this, compute storage and networking. These are the pillars of everything. Every application, every workload, they run on top of this. And open-stack provides a framework that lets them tie that into existing systems, existing enterprise storage systems, existing identity systems, but also bring in those experiments in a way where they're able to adopt them and make use of them sometimes faster than they would without open-stack. And I think that's a huge value that open-stack is starting to bring to people. When people start out in open-stack deployment, a lot of times it looks like this. It's a set of physical machines, with a bunch of hypervisors on it. But over time, they may need a workload that runs directly on top of bare metal. And so they can make use of the ironic service to provision some workloads straight onto bare metal machines and get full performance, take advantage of specific hardware. They may bring in containers. And one of the patterns with containers is when you're first starting out with containers, when you're not sure about how an application is going to perform or the kind of isolation it needs, you may run them inside of a virtual machine to use the hypervisor to provide that isolation. But over time, you may want the ultimate performance and the ultimate density out of it. And so you put those containers directly on bare metal. And open-stack is really the only platform that supports all of these technologies and all of these deployment methodologies. And that is why I think it's so valuable and so exciting to people. Alan Waite is an analyst at Gartner. And they had a conference a couple weeks ago in San Diego that I was at. And he said that he thought that open-stack was the best candidate for a cross-platform API in the data center to take on all these technologies. And he's also, he's very into open-stack, so he knows where the issues are and the pitfalls. But he thinks, going forward, this is a huge opportunity and potential for us. And the thing that's great about it that we always talk about is you can get this in so many different form factors. You can get this in a public cloud, paying by the hour, or you can get it in a private cloud that's customized to your workload. Or you can get 5 to 10x the capacity for the same price. And it's all open-stack powered, all making use of the same APIs and the same code. So one last thing that I wanted to mention. The reason that you build out this kind of infrastructure is ultimately to run applications on top of it, and a lot of times to build software on top of it. And we actually just launched this morning a new application developer section on our website. And it's got a bunch of content in there to help app developers make better use of open-stack clouds, API documentation, different white papers. We actually have a white paper here this week that we're going to be handing out that is pretty long about containers in open-stack. It was put together with the help of a lot of different members of the community. And so we're going to have copies of those here. So definitely check out this new section, check out the container white paper. And after this event, as Alex said, this is kind of midway between the summits. We're getting the community together in Tokyo in October. Hopefully some of you guys will be there. It's going to be a great event. It's a little bit of a smaller venue than we had in Vancouver. So don't wait until the last minute to register in book hotels, or you might be sad when you arrive in Tokyo. Following that, if the Tokyo trip is too far, we're going to be in Austin, Texas at the end of April next year. And that's going to be a fun event to go back to. We kicked all of this off in Austin in 2010, going back there. We had 75 then, and it will have at least 100 times that next year. So it's going to be cool to see how that works. And then at the end of next year, in Barcelona, Spain. So yes, somebody like Spain. So thank you guys very much for coming today and for being part of the community. And I hope that you guys really get a lot out of the next two days and have a good time. So that was great. It's nice to have heard from Amit about what a real global company is doing. But we thought OpenStack is so pervasive that it would make sense to just try and grab someone at random from just a local company down the street here. So we were lucky enough to get Craig Mclucky from Google, which is, I'm not sure what they do, but they're evidently right here. So thanks for stopping by, sir. These are all OpenStack people, which is a compute thing that you'll just try and pick it. Okay, pleasure to have you. Thank you so much, Amit. Right, so I'm Craig. I'm a product guy at Google. I've been doing the cloud thing for a little bit over there. I've bought a product called Google Compute Engine, which is an infrastructure service product. And then more recently have become really fascinated with the idea of bringing some of the capabilities that were previously only available to PaaS customers. And they were really very well represented by the way that big internet companies like Google or Facebook or Twitter run their applications. And so for this conversation, I'd like to start with the assumption that OpenStack is happening. Like OpenStack is actively in the process of democratizing infrastructure to service. It's making it available to everyone everywhere. And it's solving a very real problem for the enterprise customer, which is resource management, resource provisioning, and creating a set of virtual constructs that are very accessible and easy to get up and running to access and to use and to deploy your code into. So that's really the starting point. Now, when you look at what I've been working on for a little while, I kind of started there too. So I started by building a traditional virtual machine computing product at Google because I knew that the world needed virtual computing constructs. I knew that we needed to reach the developers where they are and that this type one cloud, this infrastructure service cloud, was a critical staging point to do some other interesting things. But at the same time, I've been involved at Google, and we have had other cloud products. So we had Google Compute Engine, which it was just now worked on. But we also had Google App Engine, which was what I call a generation one platform as a service product. And a very successful one. And what I started really becoming fascinated by was the huge gulf that existed between Compute Engine and App Engine. The fact that at one end of the spectrum, you could provide your code and everything would just happen for you. And at the other end of the spectrum, you would have a piece of infrastructure that you could SSH into and deploy things on and run. But there was nothing in between. And I certainly saw some shortcomings in the PADS space that were getting adoption and getting the success and getting developers' ability to really just embrace something that was going to run their code for them. So I started thinking, what's wrong with PADS? Why are people having these experiences? And what it came down to me was really this idea that in PADS, you encounter these things we call an experiential cliff. So you start off and you have this wonderful love affair with your platform. And it does everything for you. And it just takes care of you in this beautiful way. But eventually, you get to a point where you want to do something that your platform can't do. And then there's a cliff. And then you're looking over this cliff. And you're wondering where to go from there. So on the upside, you got this effortless scaling, effortless management, ease of use. You could go from nothing to running code to internet scale very quickly. But you had to give up flexibility to do it. You had to accept a relatively closed and opinionated operating environments to do that. And that meant you had to give up things like having a lot of options around how you'd manage state. So let's say you wanted to run post-square SQL because you wanted to do some specific sort of geobase querying or something. You would struggle to get to a point where you could do that. So you'd have to figure out some other option. And generally, that meant going back to VMs. So hey, I was in pass. I was having this love affair with my technology. And all of a sudden, I'm back in the world of VMs. And I always saw this as kind of a leaky bucket problem. You'd have to poke holes in the bucket. And you'd have to actually start running parts of your applications in virtual machines. And you'd have to start investing and infrastructure to manage your applications in virtual machines. You'd have to build multiple discrete environments. And no one wants to do that. No one wants to manage two discrete tool chains. No one wants to be in a world where you have to train your developers with two discrete paradigms of operations. And so eventually, all the water will run out of the bucket and you're back in the VM world. Unless you happen to have a workload that fit perfectly in the pass space. And we certainly encountered a lot of that, particularly for the internet scaling scenarios. There's some workloads that work just really well in that environment. And so I started really thinking about this. What is it that pass brings to the world? What is it that pass represents? And how do we take that and extricate it and sort of tease it apart into its constituent pieces? And who's already doing this? Because this is already happening in many ways. And I'll get into that. And so the first thing that I think about with pass is providing this kind of deterministic and resource efficient deployment model. So I provided my code. It puts it into some kind of package. And then it will take it out and deploy it in much infrastructure as I need on a very efficient basis. So the modern sort of the generation one pass is we're actually pretty efficient at resource allocation. We had a lot of customers running a small amount of code very efficiently in App Engine. And the same is true of any of the other platforms and service offerings. And that's a very powerful thing. The next thing is that they offered up a natural orchestration pattern. So hey, it would take my code. And what a reason about how to do an update. So hey, I need to go from A to B. I can do that deterministically without interruption, without disruption. That's very powerful. It would monitor my application. It would manage the health of my application. These are all very good things that reduce the pressure on your operations team. And it would also offer up a set of curated application environments and a build process. So I could say, hey, here's my code. And it would provide all the other pieces I need in terms of my user land dependencies and offer it up to me in a way that was really nicely curated. And then I could just press a button. It would be built and deployed. So all great stuff, all relevant to engineers, but not necessarily sensible to tie together into a monolithic thing. And so looking back, I don't know if anyone remembers this company. They were just another past platform back in the day. And like a lot of the other past platforms, they had some interesting technologies. They were certainly on my radar. But they never gained that critical mass of adoption. But they did something that was really neat. They took one component of past, something that they had had to solve for their own customers, which was packaging and distribution. So they took the essence of the platforms of service packaging and distribution model, and they turned it into something else, which I think most of you probably heard about by now, which is Docker. Docker has had quite an impact on the developer and operations world out there. They've done some very impressive things. And when I look at Docker, I really think of it as being magic in three parts. I think that Solomon's put lightning in a bottle. And there's three things that they do just remarkably well, and that I'm very impressed with. And I don't think, like, I'd certainly been thinking about containers for a long time. I didn't necessarily see Docker coming until they'd actually accomplished some remarkable things. And I don't think many other people could have done this, which is they recognized that the Linux Cisco layer was just an incredibly stable interface between your infrastructure world and your application world. So the Linux Cisco layer that exists in Red Hat Enterprise Linux is very like the Cisco layer that exists in Ubuntu. And it's largely compatible from version to version to version. So if you take that as your starting point and say, this is how my application is going to interface with my environment, you have a very stable and ubiquitous interface that offers up legitimate portability. So I can actually take my application, develop it here in one environment, and then move it to a variety of other variants, which is very powerful. I think they recognize the value proposition of a stackable file system. So being able to take a base image, extend it, add your own code, package it up as a numerically sealed unit, and then redeploy it out. So off it up, a remarkable amount of reuse and extensibility, and really major first few hours, just wonderful. Because, hey, I can just go grab something. It's so medically sealed. It's perfectly packaged. It just works. I can add my code, and now I can reseal it. I can just deploy it, and it's great. And they also did an amazing job of just creating a really clean and accessible developer experience. So Docker's done super work. And as a result of it, it's hugely successful as an open source project. It's garnered a tremendous amount of attention. And developers get some of the essence of pass, right? Like a few of the things that pass used to do. But they get it on their terms. They get it in an unopened fashion. They get it in an open fashion, and they can take it where they want to go. And that's a very powerful thing, medically sealed application environments, this portability, and then an efficient resource isolation metaphor. So I don't actually think of, just for the record, I don't think of containers as being an effective security isolation domain just yet by itself. I think we'll get there as a community. I still think that you really want to use virtual machines to do tenant isolation. But containers do offer efficient resource isolation. They do let you pack a lot of stuff next to each other and use up every part of your computational resource in a very effective way. So isn't that enough? Aren't we done? Like Docker, woo-hoo, it's done, right? And it's created a really amazing first five hours. So you're getting this, like, things just work. It's a profound paradigm shift. I really worry about the next five years, right? So now you've built the application, you've had the party, how are you going to operate it, right? Like, you need to be able to take these containers, and you need to be able to map them into your open stack operating environment, right? So I have my computational resources. Do I do just one container per resource? Probably not. Container shouldn't be a VM. It's really more of an executable. So how do I actually map a lot of them into a VM boundary? How do I schedule them in such a way that they're using every part of my infrastructure in a remarkable way? How do I wire them into the internet? How do I attach them to my storage properties? I want to use block storage. I want to, like, wire it into Cinder, or I want to wire it into Swift or any of the other properties. How do I do that in an efficient fashion so it just feels natural? And then how do I deal with operations? My engineers should be writing code. They should be really focused on solving my business problems. I really don't want them to spend an inordinate amount of time focused on some of the nitty-gritty operational components. So I need an operational framework. And you might have heard about this microservices thing. It turns out it's a really neat way to start thinking about factoring your production applications. And we really would like to make sure that as part of this transition, this disruption, we don't just reproduce a lot of the mistakes we made previously in terms of the way that applications are architected. We have an opportunity to rethink that. And we have an opportunity to actually bring this microservice onto the technology market. So inner Kubernetes, which is an open source technology project built by Google and really embraced by the community. So it's not just a Google project. It's also a Red Hat project. And it's an alloy that's stronger by the open source community that's actually helped build it. And it's something that we're very interested in, obviously, working with the OpenStack community to bring to this infrastructure service world. And for me, in a nutshell, Kubernetes extracts the best of Platform as a Service orchestration and management. And it does it as Docker has done for packaging, deployment, and the development environment. Kubernetes is doing for the operational experience. So you get orchestration and management. And it just works nicely for you. And so if you've ever had trouble with any of these kind of operational realities of making sure you have a very cleanly matched development and production environment, that goes beyond just the code you're running, the set of common services you use, the tools you use to actually do the deployment, the way that you reason about scaling your application. If you want to be able to test that in development and production environment, if you want to transition your code from one environment to the other and make sure that you have an incredibly consistent set of experiences across these environments, Kubernetes might be for you. If you think a lot about if updating your application in production makes you apprehensive and makes your blood pressure go up by, like, 30% and if that keeps you awake at night, you might want to think about one of these platforms because they really do distill out a much better way of thinking about operations by providing intelligent systems that will do it for you. If you care about efficiency, these technologies were really born of the internet companies. This is the way that Google runs or Facebook runs or Netflix runs. And it's led us to get so much more out of our basic infrastructure, achieve several integer multiples, higher levels of efficiency. So if you actually care about the amount of infrastructure you're spending and you want to consolidate and you want to reduce your capital expenditure for infrastructure, these technologies will help you. And if you also care about agility, if you want to be able to start creating applications that grow with your business where each of your business functions are sort of discreetly represented through these microservices architectures, where you can easily just wire things in and make them accessible and where your applications aren't bound together and coupled to the physical infrastructure primitives they're running on, these technologies might be for you. And so I like to kind of use analogies as a way to explain this, just to kind of help people really conceptualize what it is. And one of the analogies I'm very fond of using is this analogy around model airplanes. So I don't know if you've ever had a model airplane. I used to have one as a child. It was great. We'd do loops and had a lot of fun. And then one day it was 10,000 pieces of balsa wood spread across the sports field, because they're hard to fly. It turns out, if you think about it, the way that we run our applications is very similar. We give it to an operator and they build the thing, they set it up, and then they try to, they run it off, and it's not. Sure, they will add autonomous subsystems to help deal with load balancing. But often those are based on very weak heuristics. Turns out, if you think about what's happened with drones now, we've moved to a generationally different thing, because one of the things that computers do better than people is fly these little model airplanes. But it's not just better at it, it's not the same thing that just flies a little bit better. It's a fundamentally different thing. By adding dynamic control systems to this little model airplane type metaphor, we've created a profoundly different piece of technology that is able to do things that you could not possibly have done with the best pilot in the world of one of those little model airplanes. Because it turns out there's some things that machines just do better than people. And one of those things is using autonomous control systems to achieve an intent-based objective you have. So I can tell my drone, hey, go into the corner of the room and it will go there. Why isn't application management like that? Why aren't we relying on intelligent systems that can observe the operating properties of your application and make informed decisions using these control loops? So inside Google, we use this for pretty much everything. We've been using containers for around, I think, 11 years. And a lot of the work that the community's been doing is around technologies that we originally contributed to the open source community. And what it's given us is a higher level of abstraction. We're operating at the Linux Viscord layer. We can actually see what's going on with our applications. We have far higher fidelity data. And as a result of that, we can do clever things with machine learning. We can watch something. And we can see, ah, you know what? This thing's call signature has changed. There's a decent chance someone's exploited it. And I can make an informed operational decision to do that. Find one system administrator who's going to actually sit there and watch in real time what's going through on millions of systems. People can't do that. Machines can. And we need to bring this kind of capability to the world of application management so that our developers focus on solving problems, that they are good at solving. And the machines themselves can solve problems that they're good at solving. And that's all about the operational piece. And so, ah, you know, obviously I'm here today because, you know, we look at OpenStack and we Google are very impressed with the way that this technology's moved forwards. It's becoming ubiquitous. It's achieving far better semantic consistency across the deployment set. And I think there's a real legitimacy to the community. And what we would like to do, what Google would like to do, and how we'd like to operate, is we'd like to meet OpenStack where it is. And we'd like to start bringing a lot more of these kind of cloud native paradigms. So contribute our expertise, contribute technology to the OpenStack community to help it move forwards and get over the energy curve so that every OpenStack developer can be running cloud native. So every OpenStack developer is benefiting from this new class of management. They're able to focus on their code rather than operations. They're able to get remarkably higher efficiencies without sacrificing the fundamental robustness and reliability of their subsystems. And we're very excited that this is already happening. The community's already rallied around this. We see Magnum adding a native Kubernetes API to OpenStack through a Python head on the project. We see Murano as an easy way to get these technologies up and running. And what you'll start to see from us over the next couple of months as we really focus our attention on this is hopefully far more natural integration across the OpenStack. So I think about things like really working together to create this part of cloud native. And as a community addressing some of the obvious kind of cognitive gaps that exist, I create a really nice microservices model that makes it very natural to find, discover, and consume a piece of technology. Realistically, I know that almost every customer who's running a real deployment isn't going to have their entire application, insofar as everything it touches, packaged up into one of these kind of whiz-bang cloud native environments. The reality is they still have to interface with a lot of their existing work. So we need to make that integration model very natural. We should make it completely transparent, whether you're accessing something that's a cloud native component from outside a cluster or from inside a cluster if you're accessing something that's running in a vertically scalable VM, we need to create a consistency of experience. We need better integration with a lot of the basic subsystems. Our friends in the OpenStack community have already done a lot of work to make sure that these things work. But I think there's a lot of opportunity as we think about applications becoming far more network or storage centric to actually get deep integration with properties like Neutron. And I think we should be thinking about a solution to actually bring on the metal execution to the OpenStack community. I think that VMs have a very bright and vibrant future, and they're the only way to achieve legitimate security isolation right now. But for a lot of people that don't need that, there's a very efficient story around just scheduling containers on bare metal. And we should be thinking about that as a community. And so I'm really excited about this. I thank you for your time. And if you want to sort of ask me questions, you can find me sort of drifting around this afternoon. And with that, I'll hand it off to you. Thank you. Thanks, Craig. So that's interesting. Craig, you were at Microsoft, right? And James is now at Microsoft from Forrester. So I think I see a solution to this problem with fewer transitions. I'm going to write up a quick paper for you. Right, without further ado, we've got James Staten, who was basically a VP and principal analyst at Forrester up until recently, where he found an opportunity that was too good to resist. He is now the chief strategist for the Cloud and Enterprise Division at Microsoft. Super knowledgeable about, obviously, the entire industry, so it's a pleasure to have him. So please join me in welcoming James Staten. Thank you, sir. Thank you. Great. Thanks so much for having me. It's great to be back here and participating with you guys. I was at the Jonathan talked about the very first Open Stack Summit. I was at that one at the end of the second one. So it's good to see that this section over here, you guys were the attendees of the first one. And we've grown it quite a bit, which is fantastic. Now, I love the way Jonathan started this out, because one of the things he talked about when he talked about sort of the best practices to do with your Open Stack implementation, he talked very much about have an idea about what you're doing and why you're doing it. Understand what the developers are actually looking for and treat it as an opportunity for innovation. Those are all really important things to say. And what's common about all the things he said? They have nothing to do with configure the technology this way. Choose this hardware. Do this type of study. It has nothing to do with the technology. And that is really important, because the biggest challenge where you continue to see when it comes to private cloud implementations is that the focus needs to be on organizational psychology more than on the technology. And most of you wouldn't be here in this room if you felt that Open Stack wasn't ready for implementation. The challenge is most IT departments aren't ready. And part of this comes down to the relationship that IT departments have with developers. More often than not, they really don't have a very strong knowledge about what developers are looking for, why they consume the public cloud services that they do. And they also don't have really good relationships with the line of business, who more often than not are the ones who are trying to drive the innovation. And therefore are the people that are going out and using SaaS services, public cloud services, and circumventing IT with their shadow IT initiatives take advantage of this. So the first thing all the IT administration teams should do is concentrate on understanding why your company's employees are circumventing what you provide. And when you look at surveys from Forrester, from Gartner, from other organizations, you tend to see the same thing. You tend to see this list of the reasons they go out and use the public cloud. And these are all pretty straightforward. We're all pretty familiar with these. But what's not on this list? This is what's not on this list. Developers in line of business are not looking to IT any longer to say, where should I deploy this? They are not waiting for IT to confirm that it is compatible and it works to the things that IT is running in the data center. They're frankly not going to the cloud because it's cheaper. So those in IT who feel like that's what I've got to do, I've got to be the cheapest solution out there, no. If you looked at the previous list, it's about speed. It's about innovation. It's about empowering and productivity of developers at the skill sets that they have. That's what's really most important. And notice the last one, they actually don't care whether IT supports that solution. Now you might read that and then you say to yourself, well, wait a second, if they don't want my support, then what's going on here? Did I do something wrong? Am I not relevant to the business going forward? Well, that's something we all have to pay attention to because the old definition of IT is under pressure from the changes that are coming into the organization. IT is still held responsible for the security and the privacy, managing our assets, ensuring that people are not taking our assets and sending them out into the public. They're not taking our intellectual property or patents and tweeting them out so everybody can read them. All of that's still really important. But IT is no longer in charge of the services and capabilities that are being leveraged by the business. And as much as IT wants to be back in charge, you no longer are in a position where you can say, they'll shout not public cloud. So when you're not in a position in which you can stop people from doing things, you have to rethink your role. And you also have to think about your relevance too, because if you sort of say, well, fine, they want to use all the services that are out there, let them go for it. When they screw up and they get our intellectual property in trouble or they share some information about our customers and that gets in trouble, well, they're the ones who are going to get fired. No. Because again, IT's role is to protect the assets, which means you have to be on board with how technology is being used in your company. And you have to shift the role of IT away from the role of we make the technology to we help our company use the technology. Now when we look at private clouds, IT departments typically look at a private cloud as a linear progression upward from the things they already do. They've already run the operating system and the infrastructure. Now they've put virtualization on top of it. A private cloud to them is more standardization, more automation of the environment. And usually about that point is when they say done, private cloud. Now that's probably a pretty big mistake, because as we talked about at the beginning, you need to understand what your developers want. And developers look at a private cloud from the top down. They will look and they will say, is it self-service? Does it allow me to tap into these resources myself, not fill out a form, wait six weeks, and then you give me some VMs? Does it allow me at my skill set to be able to drop applications in here and scale them out horizontally? Can I take advantage of this platform like I would take advantage of the public cloud services? So if IT declares victory, our private cloud is automated and they do not provide self-service, they do not provide the ability to scale it horizontally, it's going to get rejected. And if you saw Tom Bitman's recent survey, he's an analyst at Gartner where he talked to a whole audience of people at a Gartner conference about their private cloud initiatives, what did that survey show? He asked how successful your cloud is. How much is your private cloud being used? And the response that came back, 95% of the respondents said our private cloud is failing. This is the reason. So it's not that OpenStack was the wrong stack. It's not that they chose the wrong technology to do this. It's that they didn't understand the value proposition and build the product to the requirements of the organization. And that means that they are running the risk of being circumvented yet again. And if you build a private cloud and no one comes to use it, it's not a field of dreams, unless you like nightmares. So we have to really say IT needs to change its role, its point of view, how it interacts with the organization going forward. And most importantly, it's been a really long time since I ran into an IT professional who said, when I got out of college and I decided to join IT, I was dying to run that 1995 SAP system. I just love working on yesterday's technology. That's awesome. Unfortunately, some of those do exist. They're usually about a year away from retirement. But for the rest of us, the reason we got into IT was because we wanted to do this. We wanted to bring new ideas. We wanted to evangelize technology for our companies. We wanted to help the company innovate. We wanted to help the company transform. So let's do that. Let's step up. It's time to do that. The technologies are here. But in order for us to do this, we have to look at the IT department differently. We have to recognize that some of the skill sets, some of the focuses, some of the roles, some of the responsibilities have to change. And this is exactly what happened in Microsoft. When Sacha came in and said to our IT department, we were going to be a mobile first and a cloud first organization. We are going to allow our employees to bring Macs into the office. We're going to put all of our applications on iOS and on Android. We're going to be wherever our customers and wherever our employees are. And we're going to make sure they're productive in all of those environments. And you guys in IT, you're going to have to empower that. So that was a little bit of a shock to an IT department that was 100% on one platform and ran things out of their own data center. And they knew this thing was going on over in the cloud division, this thing called Azure. But they weren't really sure how to tap into it and take advantage of it. And so they started paying attention to that. So when they did that, they looked inside and they said, we've got a series of skills and architectures around our traditional data center architecture today. And when we say we're going to move to a cloud first model, there's some changes we've got to make. Yes, we still need technical people. But what they manage, how they're organized, what they pay attention to, that changed. So we don't need, in this new cloud first world, people who necessarily own Pacific parts of infrastructure. We don't need the handshake that goes between the server guy, the networking guy, and the storage guy in order to get things done. We need to actually think about we are the managers of services that we provide and managers of services that our employees are going to tap into. And that means that we have to change what we focus on. And biggest change overall was instead of working on and managing commodity technologies, we now have to engage the business and understand how they're using these services and how we can empower them to use the services more effectively. And that was the biggest part of the change in our IT department. And we're not done by any means. This takes a long time because you'll run into people who say, well, I've always defined my role this way. I have all these skills. I have these certifications. I know these tools incredibly well. What do you mean I have to change? Well, as part of that, it's important that IT leaders take an active role in helping their employees see what is that career path? Where are their skills applicable in the new world? And that's a big part of what Microsoft IT has been focusing on as well. So we had a series of roles that you see at the top of the board here. You've probably seen these same roles inside your organization, and they found that there were a series of new roles that you see at the bottom of this page that they needed to move people into. In some cases, like the last one up there, the DBA, well, when you are tapping into cloud-based SQL database, you don't set up and configure the database, nor do you set up and configure the database cluster. That's done. So if you're a DBA, what's your future? Well, think about the skills a DBA has. Think about what he's really good at. He may be really good at information learning.