 We wanted to share some perspectives on kind of what we've learned in this journey together through OpenStack. What are we doing with our clients and kind of specifically some of the areas within OpenStack where we'll be trying to contribute and help everyone kind of move the cause forward. There's a couple of people I just wanted to single out because I probably will fall asleep. Dave, Dave Lindquist over here is going to present part of the presentation with me. He's an IBM Fellow at the CTO for Cloud for all of IBM. And Todd Moore is our board member. You probably know him already. So if you've got any problems with the way OpenStack has behaved, just go to Todd. He'll sort it all out. And I'm IBM's vice president for all of our software standards in open source as well as our high performance cloud development labs in Silicon Valley. So if you guys want to meet up out there in San Jose, let's do it. Let's start. All right. So let me get started. So I'd like to break this presentation into kind of maybe four moments or four sections. Okay. You know, I get asked, you know, to talk about what is, you know, what is IBM's interests in OpenStack? Why did you kind of, you know, team up with a bunch of folks and help create this foundation? What are you trying to do? How are you trying to make money? Okay. I'll tell you a little bit about that. It's not my thing. I'm not a sales guy. You know, I can give you some sense of strategy. But, you know, I'd like to step back for a second and just take a moment for all of us to feel real good about where we are, right? If you think about this. And for those of you who've been doing OpenStack for a long time, I've been watching the community from a far, for a while. Certainly got quite engaged when we helped start the foundation. If you just look back at, you know, the November Design Summit with 250 or so attendees, okay? I think maybe there was barely, you know, coffee was always kind of, you know, not enough coffee, you know, not as well, not as glamorous as this event, right? You look at the, I don't know, look at the cactus release with 100,000 lines of code, right? If you want these slides, I can get you the slides. You can take pictures too, but I can get you the slides. You know, 100, and then you fast forward to today, right? We've got this event, Todd, what, 3,000, 4,000 or so people attending, right? We've got Grizzly with 800,000 lines of code, and this is just in two years, right? And it's really, it's really, really special that we've been able, as a community, to kind of accelerate this path, to kind of move forward. And specifically in Grizzly. I mean, Grizzly is just an amazing accomplishment in itself. I mean, 480 contributions, 45% increase from the fall release, and you look at the contributors, the wealth of contributors from us all. You know, IBM, you know, I always like to ask the teams, you know, Todd runs our cross-IBM kind of open-stack team, the folks who focus internally in development or products, but also the community-facing stuff, right? So that we're consistent when we interact with everybody. I say, well, how are we doing, you know, things going well, how are we interacting? And so we're number two in code reviews. So I guess we like to complain a lot or comment a lot. That's pretty difficult. But also number three in contributions, and I'm really proud of that, because that, you know, that doesn't work when you try to just plop yourself in and say, hey, take this code. That works when you collaborate, when you have an open and kind of accepting and technical dialogue. That works. That's something that Jonathan has always talked about as the open-stack way, right? So I like to challenge you as we continue to get bigger, because we will. I never dreamed it would be this big, but as we continue to get more folks involved, you've got to remember that. You've got to remember, don't forget the open-stack way, because that's what makes this community unique and that's what makes it succeed. I mean, just today, I saw that Juniper and Erickson signed up as two more gold members. It's exciting. Those are big companies. Exciting, doing interesting things, right? So it's a really good time to be in this particular space and a really good time to be involved in open-stack. You know, another really good chart, if you want. If you send me a note, I'll send you this chart that we use a lot as we compare the growth of open-stack to that of Linux. And the early days, we always used to like to compare ourselves to Linux. Well, we've actually overtaken Linux in terms of how many active developers and how big the ecosystem is. And the growth has just been amazing, right? So it's kind of becoming an entity in itself. So the second point I want to make is to kind of step back for a moment and think, well, why is interoperability or why is having kind of a de facto infrastructure as a service platform important to our clients? How we view things. And I think you'll view this in a very similar way. And it's pretty simple, right? I mean, do you guys remember kind of the first time you... I think a lot of you do, you know, look that young. You know, when you kind of opened up a web browser and you, you know, Mozilla or whatever, you're like, wow, check this out. There's a picture with text around it and you can click it, oh, it goes forward. And when I hit back, it kind of goes back to where I was. This is interesting, right? And then, and what happened? Why did that work, right? Why did that all of that work, right? It didn't work because IBM was trying to make products or anyone else. That's not the reason that worked, right? It worked because it was a combination of good open source and standards, right? And the fact that the communities were open and that vendors realized that you needed to have interoperability at the right places, right? Every web server today, whether it's IBMs or whoever else, ships with the Apache HTTP code in it. It does, to this day. So now you don't have to worry about when you click, you know, give me a page, HTTP, colon, you know, whatever dot com. It's the same code. And that's the effect we want to have in cloud. And what happened, right, when we did that? The markets grew. Our clients didn't feel like anyone was trying to lock them in. They had the ability to integrate heterogeneous sets of web application servers as they deliver stuff to their clients. This is the same kinds of things. As markets grow faster, skills become more, you know, relevant, more easy to obtain. I know right now everyone wants to open SAC skill and, you know, it's crazy where you get to open SACs. This is just going to continue, okay? And it's going to be as pervasive as it is with CSS or JavaScript, right? You guys ever write CSS? I hope, yes. I hope write that spec. It will become pervasive as that. Now, another thing that we do is we also do a lot of survey of our clients. We ask them, you know, what are some of the things that are important for you as you look at your businesses? And there's two points I want to make real quick. The first one is that CEOs found that technology, for the first time ever, is going to play the number one role in their business. That's pretty cool. So we should, as, you know, as fellow developers or like to call ourselves nerds, we should feel pretty good about that. Number two is people skills. This is interesting because these things typically don't come hand in hand. It's true, right? So, but this isn't important. And this is important for us how we behave in open SAC, how we behave in organizations, and how we behave holistically. Think about it, right? You all might be an expert in, you know, Swift, Nova, Cinder, whatever, right? You know your thing, you're doing your stuff. But you also need to understand how you fit into the context of the larger open SAC kind of deployment. And within your companies, you need to understand, you know, whatever it is you do, you're developing on a product or working on a solution for the client. You understand, what does your company try to do? So what's happening is that I think that developers who build these so-called T-shaped skills, the ability to know their thing, your network got great. God bless you. You know, that's great. You know, you're a database person. Wonderful. But you need to step up and understand the context of what you live. If we don't do that as a community in open SAC, right? We won't be able to have all these components working together. And you won't be a successful in your own companies. And by the way, the same thing holds for folks who run businesses, right? So for those of you here who are looking to kind of understand how to use open SAC from a commercial perspective, you got to understand the technology, right? And how it applies to what it is you're trying to do, right? Not just to buzzword. And for IBM, you know, the reason that cloud and cloud interoperability is so important is really simple. I mean, think about the markets that we're in, right? If you happen to hold IBM stock, probably a lot of you do without even knowing it, right? You know, we focus on big data. We focus on mobile. Lots of different social, all of these market segments put huge strains on our infrastructure. All of the mobile devices, all of the transactions that are occurring, you know, 60,000, they say, cyber security threats happen a day or something like this. We have to manage them all. All of this, well, you know, there's not enough compute power in the world to handle all of this at all times. You need to be able to be flexible in how you manage these situations. So cloud is a very fundamental technology for that. And no single vendor, I mean, I'm certainly not arrogant enough to think that we can supply this to everybody, right? No single vendor can do that. You need to be able to allow folks to be able to handle whether they're running a cloud in their private environment, whether they're using a public cloud, or whether they have some integrated system or some kind of combination of these things to give them the ability to move around. And that is why I think, frankly, that OpenStack and what we're doing in cloud has the ability to be much more impactful than, say, the internet was in the e-business days, back when we were doing that stuff. And it's very different. It's very, very different. Back then, it was a bunch of us sitting in a room, writing specs, writing code, not really interacting with users that much. Does anyone know what the use case was for XML? Does everybody know what XML is? Yes. Well, it was the mathematical markup language. I co-chaired that. It's a great use case, dude. I love math. I love computing. It's wonderful. And by the way, for distributed systems, let me tell you, that's a great use case. Doing some ball computation and lots of machines. You need lots of machines for that, right? Not the best use case for config files, would you say? Probably not. But that's different about OpenSec and that's different about what's happening today. End users are really involved in the definition of what we all do. So as a community, we need to continue to embrace end users. And that's something that OpenSec has always done, something that we IBM thought was very attractive when we kind of started to kind of get even more involved. And it's something that we must continue to do. And this technology impacts, you know, more than what you all think, right? A lot of you, you know, kind of, may you spend your time with people calling a platform engineering department or data center department, whatever you want to call it, right? We spend time in those areas. You know, this technology impacts the real world. I'll give you kind of a real example that I kind of ran across. And that is, I'll give you one. And that's a hospital in Canada where they work with essentially, you know, really, really sick children, okay? And these kids go in there and basically their vital signs can change within the day and have the possibility of dying the next day. So you have basically a 24-hour window of correlating all this stuff, understanding what's happening, and then do some action so they don't die. That's basically it. It's a huge analytics problem, right? And by the way, they can't solve it, you know, a human can't solve it, right? It's just too much for any human to understand all these vital signs, right? And by the way, no single hospital has enough compute power to handle all of what they need to be doing. So they use the cloud, right? To manage and be able to scale their infrastructure. But guess what? You know, these guys are saying, you know, I need to have interrompability to be able to run my application, my workloads, in different clouds. What if someone goes down, right? Or what if, you know, I can't afford this cloud? I need to move to another, right? That's a real example of where, and by the way, of course, I'm looking at OpenStack and other things, right? You know, so this is just a real example of how this stuff touches us. So you should always think about kind of the art of possible. Now, moving to reality, though, the clients that we serve and certainly the clients that you serve probably spend 70% of the time managing their existing systems and their money. So they've got about 30% to handle new applications. So where does, like, the innovation come in? You know, where do I start playing with OpenStack and sort of, you know, stand this thing up and start doing DevOps and, you know, continuous delivery, and all that stuff? You know, where does that happen, right? How do you manage that? So as a community, we also need to be very cognizant, you know, cognizant of, you know, where our clients, where the reality is, how their current operating environment, right? So that when we think about introducing OpenStack, we do that in a way that allows it as easy as possible for them to introduce that technology, to wrap what they have, whether it's KBM, VM, whatever, right, which we do, right, with as least pain as possible. And the most advantage, that they can. All right. So that's your gentle kind of introduction. Is that good? I saw some guy sleeping over here, so wake up. I don't know who it was. I'd better not be in my team. Let's take notes. Who's sleeping? So, what's our strategy with OpenStack? You guys ready? Write the tweet, you know. Here we go. IBM strategy. We want OpenStack to be the ubiquitous infrastructure as a service platform. Period. That's it. There it is in a nutshell. Why? For all the things I just told you about, that's our objective, right? When we got in all together and we were working with a small group of us talking about, you know, establishing a foundation and how do we kind of get both. I was real up front. That's what we want. Why do we want it? Because I want the e-business effect for cloud, right? It is about peace, love, and OpenStack to a certain degree. It's also about peace, love, and I guess we can make more money. That works too. I like nice cars. So, that's what we want. It's very clear. So, how do we do that? And I'm going to take a moment to talk about some of the things that we're doing. I'll get into specifics with Dave. We'll help him here. Around development, some of the code, areas, some of the areas that we contributed to. Grizzly, some of the areas that we think are important as you look at Havana, right? Also, it's important what we do with clients. I'll talk a little bit about some of our product offerings and how we think the OpenStack references will start to increase dramatically soon as well. We'll help that from our perspective. Also, ecosystem. The ecosystem and users is a real big part of this. We'll talk a little bit about that. And let's not forget this. As much as I started this conversation as we should feel good, right? You can't stop training. You can't stop evangelizing. You cannot stop showing the value you get from OpenStack and getting input and more things, right? So being active, all of us in the press and the analysts and helping folks understand that is incredibly important. You can't rest because something else might happen, right? We all have a vested interest in OpenStack. So let's start on the development side. Dave, can you just maybe tell us a little bit about kind of what we've been doing here? Sure. Just a couple of comments. Thanks, Angel. First of all, as Angel mentioned, our objective strategically is really to do anything it takes in this community to make OpenStack a de facto infrastructure as a service. That's what we're focused on. It's a great community. It's been very exciting for all the folks in our organizations to be participating in this community. It's been very collaborative, extremely productive. As you can imagine, we have a large number of developers working across the breadth of projects in OpenStack. And one of the questions that we frequently get with large numbers of enterprises and service providers are what are some of the contributions that you're working on from an IBM perspective? What are some of the things and priorities in the community? Is it ready? Is it ready for my data center? Is it ready for an enterprise deployment? And a few things that always come up in those types of deployments are one is post-deployment. How do I take care of the system? How do I upgrade the system? How do I patch the system? How robust is it? How well is it going to scale? How well is it going to recover? What's the security model like? What's the logging like? What's the auditing like? Those are many of the core things that enterprises and providers are like. Push, push, push hard. So I can't emphasize enough, I think as a community, how important it is for us to focus on these areas to really accelerate and drive the adoption and to drive this as a de facto open infrastructure service. A couple of the areas that I just wanted to highlight some of the things that we've been working together in the community on, in particular, are upgrading the system. How can we make this less and less obtrusive, more and more of a very seamless, live upgrade in particular? Security, security and authentication. This comes up everywhere. How do we fit with a lot of the existing security models, a lot of the authentication models? How do we bring in things like LDAP more appropriately into the security systems within OpenStack? Member services. This to me is just the beginning of how we instill more and more of the critical engineering aspects of a distributed system into OpenStack and what OpenStack is. In particular, how we understand state, how we sync up the distributed components, how we can then start moving more and more to a more recoverable oriented model within that system. A couple other areas that I want to emphasize and it's a worldwide deployment, obviously globalization is critical. That's an area where we use extensive reach in our labs to really get more and more of the translation going for OpenStack. And also quality. Quality is critical. The use case is what we drive through this system and how we can get it, how we can just keep accelerating the level of quality of OpenStack. So those are some of the core areas that we as an organization have been participating in. There are many, many areas, but those are the ones I wanted to highlight. Moving forward, a couple of areas come to mind that in particular, I'd like to see a little more emphasis from our organization and from the community. One is in the whole area of metering and monitoring. One of the things that many of you I'm sure recognize, but so important after a deployment of a cloud-like environment is really how you deal with it through its life cycle. How do you bring in many of the management systems into this environment to keep the system running healthy so you can see how it's running, you can take actions, you can run it through various change-release management type updates. So that's a very critical area. Another critical area that you're seeing a lot of focus across the industry is in this broad term that's often referred to as orchestration. I encourage you to think about orchestration at three different layers. Think about orchestration at a resource layer. How do I rapidly pull together the resources and the topologies and the configurations I need to support the workload, the application I'm deploying down? The second area is in the workload orchestration. How do I understand the workload? How do I understand what are the right optimization points to this workload as I orchestrate laying that down? So that's the workload orchestration. And the third area is really in what's often referred to as a service orchestration. Really think about how do you manage the applications and the services through their life cycle. From deployment to activation to change, release, problem management, all the pieces you have to do to keep the system running through the life cycle. So those are core areas, in addition to the other ones that I spoke about, that we as a community and as the developers and IBM continue to focus on. Really in support of that objective, how do we make this enterprise ready, provider ready, robust, de facto infrastructure as a service? Angel? So let's talk about ecosystem now. I have a little demo too, so that should wake you up. Angel, is Andrew here? Any questions, by the way, on all things go to Andrew. None of us. We're not allowed questions. My handlers won't allow that. I wish I had handlers, like an entourage. So ecosystem. End user input and feedback into what we do is real important. I think increasingly so in the user committees to start to do that. There's a variety of end user organizations out there. We should go in and interlock with them. Take this one, it's cloud standards, customer accounts. We've got 400 end users involved. They've been writing use cases for interoperability or infrastructure as a service or on platforms in lots of different areas. These are people who use this stuff. I've got to tell you, when you have someone like say Kroger, this is a supermarket chain or something like that. And then Boeing, airplanes. Together, talking about SLAs or security, it's mind-numbing. Because talk about use cases from opposite ends, etc. But they come together and they kind of carve out what they think really matters in kind of more generic form. Understanding that as you all in your project, that's an area I think we've got to continue to do more work on. All of us should be doing as much as we can around outreach to media, press, and all of us in our own companies have ways of doing that. All of you and your blogs and your tweets, I encourage you to do more. Because the more you do, the more people get awareness. The more they feel connected, the more they understand how to get connected. A couple of months ago, IBM did an open architecture for cloud that kind of said that look all of our products and offerings, which I'll talk about here in a moment, are based kind of on open cloud architecture. Obviously OpenStack is a big part of that. There's other things, which I'll talk to a little bit later, but OpenStack is a huge part of that. To me, it was somewhat obvious that we were doing that. That generated a lot of buzz into media, which I guess is good. And it's certainly good for OpenStack. And that's the kinds of things that I think you guys should encourage your folks to go do when you go do that. Let me talk a little bit about our offerings and then kind of, how do we sell or how do we try to make money and how do we help our clients with OpenStack? Let me just start here for a moment. I think I should have reversed this. There's really three ways to do this. We don't have an OpenStack distribution. We're not like a red hat or something like that. That's not our business. We want to very much do kind of what we did with the business days, which is take the code and put it inside of our offering. So that we have interoperability at the infrastructure as a service layer. That's what we do. When it comes to cloud, there's really three ways that our clients have the ability to get cloud technology. They can have a private cloud. So we call this our smart cloud foundation. It's a software we do and install it. In fact, our first installment, our first payment on this vision will be announced that the smart cloud orchestrator, which is now in beta, you can go get a shift with OpenStack. It will be released any day now, right Andrew? Any day now. Very good. My team is helping them. They say it's any day now. The other product offering is our integrated system. We call it pure systems. It's the combination of hardware and software. That runs our smart cloud foundation. So as you can imagine, when we update that to the latest version of smart cloud foundation, there will be OpenStack in there as well. And of course our public cloud, smart cloud enterprises for large enterprises. That has our smart cloud foundation on it as well. Our private cloud, our smart cloud foundation has about 5,000 or so clients right now. They're not all using OpenStack. So don't say Angel said there's 5,000. But when they start to upgrade, which they all do, you'll start to get OpenStack embedded in more and more places. Which is great. The more user stories we can have, the better. So specifically, and Dave talked about this, orchestration at the resource layer, at the workload, at the service layer. This is kind of what we're doing with the smart cloud orchestrator. I'm going to give you a little demo. It's a movie, but it's real. They actually recorded it live almost Friday. So it's not entirely clean here, but I think it will give you a taste. If you want to go deeper, Andrew and the guys are at our little booth and they can kind of go into all of the details and show you this. First of all, when you think about orchestration, there's lots of ways, whether it's deploying OpenStack, setting up clouds, whether it's dispensing the workloads that run on those particular VMs, or whether it's integrating your tools, your ticket management systems, all the things that happen when you really deploy this stuff. There's lots of ways of doing it. You can write scripts, you can use Chef, you do all kinds of things. At the end of the day, you want to be able to understand those workflows and to be able to have patterns of those things that you use across all of these different layers. And that's what we allow folks to do. We allow them to start to define these kind of workflows so they can start to easily provision things. And this happens to be one around provisioning an OpenStack cluster. So the user's going to go over and do a provisioning request. They're going to select an operating system. They're going to say Red Hat and do some VMware. They should be pretty familiar that it's going to be a large kind of a node that we need. And it's going to say, poof, please create one of these for me. We also kind of had it use one of these patterns. And I'll get more into the patterns in a second, but it says you're going to create two VMs. And on each VM, you're going to have some different softwares that can get laid out on it. So we go off and we say, yeah, can you please put this software on here as well? And you submit. And they'll say, yeah, we did that. There's different ways of getting kind of notified when stuff happens. It can send you an email, text to your phone, stream, whatever. There's lots of different ways of getting notified. This is an important point we'll make later. So when you kind of peer into this, what you actually do is you'll see, I'm going to go back here, you'll see what's actually running. So it looks better here than it does. I can't see the way it looks on my screen. Here you have on one, you have a Java run. You've got ZooKeeper and you've got 10. 10 is to the endpoint manager. On this other one here, you've got Java, Tomcat, and some 10 as well. There's a pattern that was deployed into these images. So it was pretty easy to do. Certainly, if you think about what you go through doing this, if you don't have a visual composition tool, it's kind of painful. And we also think about the robustness of kind of trying to manage and maintain all these different scripts behind here. It becomes a little hard to manage. So we're trying to make it easier for folks to stand up their environments and kind of get going. So if you have these things deployed, add more servers, more resources. So in this case here, the guys said, look, I need another node. They're actually going to add a KBM based one on this case here just so you can show KBM and VMware kind of working side by side. And then I think you kind of get this little standard screen. Here it sends an email, but when you click on the link, you get a screen that shows you the two servers running. And let's look at actually how these patterns were created. I'm going to walk through the creation of one of these little patterns. So that runs the workload that sits on top of the OpenStack deployed images. So what we're going to do is we're going to go to ops code here and download a Chef recipe. It could be anything. It could be any other of your favorite type of way of doing this. We're going to download the Apache HTTP recipe. So we go, we download it, we save it, and we go into the tool and say, let's create a new pattern. And this pattern is going to use the Chef recipe. So we import it into the pattern machine and we kind of then say, okay, let's execute this pattern. And before we do that, we got to associate or bind, as you can see, the Chef recipe into the pattern. So we just do a little drag and drop and it plops in. And then we say deploy. And when we deploy it, it's going to ask you because the Chef recipe requires some configuration to stand up. The Apache HTTP and these important numbers and all kinds of interesting things. After you kind of put that information in, which kind of happens right around here, you go and you're happy. You have your Chef guy. I went through it quickly, but you get a taste. You get a layer with open stack at the layer of the workload and the layer of the services integrating into your existing environment. And then the ability to kind of create these recipes on your own. And it's just, you know, the fact that we're building this on open stack and the fact that we're trying to make it easier for clients to leverage and use open stack in their existing environments, like I said before. It's something that really kind of resonates with a lot of the clients that we talked to. And now I'm going to hand it back to Dave because I want us now, so that's been, you know, the good news, right? Kind of what IBM's doing and trying to help and kind of where we're headed. Now let's kind of take a moment. I want you to open your minds a little bit, right? Kind of go down the open stack way. And let's take it, let's think about where the industry's headed from an open cloud architecture. What are other things we might want to think about even further down the line? I'm not sure how far in the future much of what I'm going to go through is. But let's talk it through. We're seeing a lot of this occurring today. You saw glimpses of it, I think, this morning at the keynote. I'm talking about is a few layers that appear to be naturally emerging to patterns that we're seeing across a wide variety of industries from retail to insurance to financial services to banking to telcos healthcare etc. I see this going on. And what I'm talking about is from a business perspective from a line of business from a business unit from a business cloud cloud computing being used to drive revenue, to close gaps and drive revenue. A lot of these businesses call really driving their innovation. What you see going on you saw some examples of it from the speakers this morning from Comcast from Bloomberg from Best Buy and there are many, many examples targeted pieces of coming almost from an app dev team and a business unit. What we're trying to do is really accelerate the rate and pace with which you can close gaps and drive new opportunities to market new applications, new business models new business processes. The approach that this is often taking is one in which using mobile devices for reach using social for a very compelling using big data business analytics to really begin to target to better understand our customers to better understand what products make sense services for those customers how to extend that base. Also how to better interact with your partners also along with employees. And the methodology behind this in this rapid creation is one in which you're starting to see how the environment of what's often referred to as a PAS layer is dynamically composed. You're composing what development tools you want to use like repositories and testing tools and build tools. You're composing what the application container is going to be whether they're scripting languages, Python, Ruby, etc. with messaging systems with data persistence systems with operational management systems for visibility into how this application is running. All that then deployed on an infrastructure as a service. What this affords is a very rapid environment for a rapid creation of this application and incremental continuous delivery. This is what businesses across all industries are driving towards. Then what this composition is occurring is the composition of the services that I mentioned across dev, app, data a lot of business services in there a lot of backend transactional systems in there data sources. That middle layer the focus is on how do I support these services in a manner managing services in a manner to support this composition in this rapid and high scale delivery into this mobile social environment with this big data. So there a lot of the energy is on this orchestration technologies. In particular this managing it through its surface service, managing this life cycle and that workload layer. How can I model the workloads? How can I become aware that I should be monitoring and getting visibility into that workload? How do I optimize how that workload is running? So that's that middle layer. Then that lowest layer is how do I drive this these workloads on a softer defined environment. In particular in infrastructure as a service. How do I run this against the softer defined environments of compute storage and networking? So when you map that back through a lot of the initiatives in the industry you see a couple of things servicing very rapidly. Obviously at that lowest layer the core is open stack. And we'll see more and more industry momentum and how more and more of these core projects increasingly become service level abstractions increasingly have more and more interfaces to recognize what are the policies and configuration and operational management of those underlying abstractions. That middle layer, a lot of focus in the industry now on specifications to how to understand how to model what that workload is. That's where we're seeing a lot of work in OASIS around things like TOSCA. A lot of work starting to merge in the projects here in heat and basically almost the resource level orchestration. So that's the area that we're going to see a lot more standards filling in. That top layer this composition of services this continuous delivery this how do I pull together my dev tools with my operational tools with my run times of app data messaging. Here what we're seeing is a lot of focus on how you properly represent these services and what it means to configure and manage these services and bring them together in the life cycle. I encourage if you haven't done to look at some of the architectures and the standards and linked data something Tim Berners-Lee has been pushing in W3C where it really opens up the data and the interfaces and capabilities across systems and they basically using web protocols. And then what us and many others are doing within a community referred to as OSLC open services for life cycle collaboration is how do you take that architecture that linked data architecture and apply it to the different domains of automation, problem management request management etc. So that you can begin to federate tools to manage that composition of services that rapid composition that's occurring in support of that business objective of really driving new services, new apps, new data to market. Okay. So that's how the layers we see evolving the patterns and so when we talk about an open cloud architecture what we're really referring to is those three layers of that underlying infrastructure with OpenStack the workload modeling a lot of that work going in OASIS and of that upper layer with W3C and the OSLC community and managing through the life cycle. So as I mentioned in OASIS one of the key standards that we're looking at is this goes by the acronym of TOSCA which is really topology and orchestration specification. Here's where you model the workload the topology the nodes and relationships and then you create plans that correspond with that workload. How do I deploy it? How do I activate it? How do I add and move nodes? How do I put it into high availability mode? Backup recovery, security etc. So think about that as a workload layer orchestration with an open specification that'll create a level of portability really enabling hybrid clouds to interact from a customer perspective putting down workloads. And then the third area I mentioned was with linked data and OSLC to me we're really just beginning to see the power of this type of technology this type of architecture in particular and how it begins to open up access to data in these systems how I can betterate information across these systems if you've ever put together complex management systems you quickly recognize that the data integration problem is quite daunting it's true in most application architecture designs is that data integration becomes quite daunting in this approach rather than trying to coalesce on comma schemas or moving large amounts of data or doing API level integration you're really federating just the way the web works access into information and various capabilities and it allows you to create a very loosely coupled system that can very rapidly compose the services across and take care of that integration that type of a loose coupling that federation approach and so that's what we're driving in communities is how do we appropriately use linked data in these various demands Angel great thanks Dave so let me just close out with a couple of thoughts I think we're up to the hour so first of all this is going to be an interesting ride we're just at the beginning cloud is really frankly open stack is still at infancy for those of us who have been with open stack for the past couple of years or even longer it seems like a hiking trip you know how when you're on a hiking trip you're excited the first kind of 10 minutes and then 10 minutes in your backpack gets heavy it's not so exciting right but then you reach the top of the hill and it's exciting again right but then 10 minutes later it's no longer exciting that's the way it's going to be so just get ready for that it's going to be ups and downs but you know we'll get there together right so there's a couple of takeaways so if you're a user of open stack in here you know you all really will determine our destiny I mean that's been the open stack way and I think we'll continue so get involved in the open stack user committee get involved in user advocacy groups and start getting those use cases well understood help us understand how we can do the right thing for you all as we continue if you're a developer especially those who've been here a while developing right continue to be open minded and inclusive there's lots and lots of new blood here I've met so many new folks who kind of want to be contributors and kind of excited right continue to hug those new people and bring them in because the power of innovation that we all have when we work together is just amazing to change that bring your power bars as I said you're going to need that for your hike and look we work with all of you in so many different ways and if there's a way where we're not working with you and you like to work with us you can reach out to us just call me call any of us and we're happy to have a dialogue on how we can work together in the community to do good stuff so thank you very much peace, love and open stack