 Ladies and gentlemen, welcome to DevOps in the Enterprise and now for your host, Scott Sanchez of Cisco. Wow, that was impressive. I know. Well, thanks everyone for coming out. As the introducer said, I'm Scott Sanchez from Cisco. The MetaCloud shirt is in remembrance of our former product name. We were acquired by Cisco back in September and do all kinds of awesome private cloud things with OpenStack. Today, we have a completely different panel than all of you saw in the schedule. The only thing that is the same, I think, is me. But we have a fantastic group of panelists that have stepped in to talk about DevOps in the Enterprise. And so I would love if our panelists could briefly introduce yourselves. Twenty, thirty minutes. Briefly introduce yourselves and tell us who you are, where you're from and what you are passionate about right now. All right. Well, I'll start. I'm Chip. I'm from the Cloud Foundry Foundation, which is just over a hundred days old right now. I'll be playing the part of Josh McKenzie today, or at least attempting to. And before that, I would say I did not come from the vendor side of things. I spent a brief year at a startup. But before that, about 15 years worth of living the problem that we're here to talk about. Excellent. Welcome. I'm Grant Shipley. I'm director at Red Hat, where I manage a good portion of the OpenShift platform as a service product. I'm also the Red Hat DevOps thought leader. So there you go. And can anyone in remembrance of his shirt, does anyone know what this shirt is? That was the original Twitter logo. No. It's the New Zealand All Blacks rugby team. Welcome, Grant. Yeah. Keith. Hey. So my name is Keith Chambers. I work at Cisco Systems. I work for our CTO in Cisco Cloud Services, Ken Owens. And unfortunately, he can't be here, but he really wanted to be. I've worked in Cisco for 15 years, quite a while. I started in our technical support for seven years. So I have a lot of operations experience. From there, I went into product management and worked on virtualization and then moved to become the platform architect for a few different services that we have at WebEx. So I've kind of been doing microservices before they were microservices and DevOps before it was DevOps. And I'm really passionate about enabling enterprise developers to deliver software quicker and help all these enterprise companies stay in business. Awesome. Well, thank you all for being here. How many open stack summits have you been to? Half of one. Half of one? Second day. Second day. Five minutes. But that's good because we don't have the biased perspective on what open stack was or could be. We have fresh perspective and that's good. This is my ninth summit, so not as many as some of you in the audience, but I have a very different perspective on open stack. So that's good. And my first question really is, I'm kind of flipping the story on its side here. Let's start with an example of a company, enterprise-y kind of company that you think is doing DevOps well and why. So who's your favorite? I'll start in the middle. Thanks a lot. Who in your mind from a big company perspective is doing that as well? You have to define what DevOps really is, right? Because if you ask 10 people what DevOps is, you get 15 different answers. And so to me, DevOps is more about a culture of collaboration and utilizing open source tools to automate most things. And if you think about just the automation side, I would say the big golden boy out there is probably Netflix, right? Because they automate every part of their infrastructure. And then another aspect of DevOps is continuous delivery, and they do really well at that. But we can't all be Netflix, right? And so I would actually think internally at Red Hat, we do a pretty good job. We don't continuously deliver every five minutes, like the Amazons or the Netflix of the world. But those are probably the two biggest ones that people strive to achieve to be like. I think their question is a little bit too difficult, because when you talk about a large company, there's no large company doing DevOps well across the whole organization. So you're saying it might be a loaded question? I think it might be a loaded question. But I'll give you an example of a company that should be doing well, or at least is headed the right direction. There's a lot of them. So Cloud Foundry had a summit last week, and we had all kinds of great big companies talking about their process of changing and transforming and trying to deal with the challenges that DevOps is really meant to help with. But I think that all state insurance stood out, because if anybody is familiar with the insurance industry, heavily regulated, purposefully you end up with organizational silos dealing with each one of the lines of business. And even within each line of business, you tend to have a lot of siloing occurring based on the geographies that they're servicing. And so all state at this point is taking a step back, and they're looking at how do they create the appropriate platforms and practices so that they can take advantage of things that they do in a particular market, or for a particular service line, and then quickly repurpose that and deploy that maybe in a new geography that they've never serviced. So they're putting the ball back in the hands of the business. Good answer. Thank you. Yeah, so I know of a couple companies that are doing DevOps really well that I can't talk about. Industries, geographies. Some major, so... This is all off the record. Yeah, not recorded. And we do not know these questions ahead of time, so we are thinking. There was a lot of prep. We spent absolutely zero minutes discussing everything. So this is all off the top of our heads here. That's cool. Thanks for reminding me. Yeah, so I guess there's a theme that I see, and some really large Cisco customers have come to us and said kind of provocative things about how they're trying to disrupt themselves, and they're taking very, very aggressive steps to disrupt themselves. And so we've had some Cisco account teams come to us and say, my customer is saying they're going to do X, Y, Z. This sounds crazy. Can you help me to understand what's motivating them to do this and why they're doing this change? So across the industry, I guess I'm seeing customers really understanding that they need to move quicker and taking pretty dramatic steps to make that change. So there's a little bit of lag time in the DevOps story, but it's really happening and people are understanding. If you go back to the Puppet Labs survey from 2014, they have real business metrics that companies that apply DevOps practices, their market cap after three years or something like that is 40% higher. They have real numbers behind it. So people understand that they're disrupting themselves. Who do I like that's doing it? I like the story around Nordstroms. I mean, they're obviously seeing a lot of competition in the retail space. They have to move quicker. They've been very pragmatic about it. They took one product, started doing that, showed measurable results, moving on to the next one. So any large company that isn't born on the web that's taking the first steps are doing the right thing. So what's interesting about Nordstrom is that Target's another example that I'd bring up. If anybody's watched any of the talks that they've given at the DevOps days, it's actually amazing when a particular industry starts kind of getting the bug because then they realize, oh, wait a minute, they're going to start moving faster than us. Right. We'll be left behind. Right. And you might not think of Nordstroms and Target as being direct competitors because I think they're segments that they target might be slightly under, not overlapping that much, but... I shop at both. Absolutely. Yeah, people start to see what's possible. And as soon as they see that somebody else did it, why can't we do it? And now they believe it and now that helps them to do that. Yeah. So we'll stick with you, Keith. Okay. I think that one of the trends I've seen, we've been talking about DevOps as an industry for a long time and we were doing DevOps, I don't know if Sean's in the crowd here, wrote a good piece recently about how we were all actually doing DevOps, those of us that operated things long before it was given a savvy name. Right. But the initial thought for DevOps was this is great for automating my infrastructure and the deployment of my infrastructure using my cloud APIs to spin up my stack that I'll then put my app in. And it's moved to be more about the app. Certainly Cloud Foundry is much more about extracting away that thing. OpenStack is doing a lot of what we used to do with DevOps tools. Now OpenStack does, and we put our app on top of that. How much traction are you seeing in the larger organizations of using the DevOps tools and mindsets at the app layer versus the infrastructure deployment? I don't fully understand the question. How much are the developers using the tools? How much are the developers actually building DevOps mentalities and using the tools into their apps versus just using it to deploy the stack the app runs on? I guess I don't know if the right answer is here, but I don't see them building deployment tools into their applications at all. So there should be kind of a clean abstraction of what's going on there but I don't see the developers doing any direct integration with tools like Puppet or things like that. I think development has always had a software-driven mentality. Your change comes in through source control. Then you do a build and then that needs to get deployed out. So I think that's always been there for the developers. Just the tools haven't been there for them to do it. So the ecosystem is catching up around it and either the operations teams are enabling them and helping them to deliver it or they're saying, hey, this is code. I kind of know how to do this. I can do it myself. You agree, Grant? Somewhat. I see all the benefits. I think all the benefits we saw with automating the infrastructure has moved up to the application tier to where developers are now wanting to use systems like OpenShift and Cloud Foundry to automate their application runtime deployments, database deployments. And at Red Hat, we've actually seen really good... That's the word I'm looking for here. So our CEO, Jim White-Earth, was on Mad Money a couple of months ago, maybe last month, said our two fastest growing products are OpenShift and OpenStack because of this automation at both the infrastructure tier and the application tier. So we're seeing a lot of people move in that direction. That's Cloud Foundry's view of the world. Is it about the app? Well, actually, I'd say that it's actually more about business value. So then the question is, what's the unit of value that the business cares about? That manifests itself typically in an application deployment or a new feature that's being pushed out because that's a direct representation of something the business needs. It's either a touch point with a customer or improvement in fulfillment or a better way to handle the telemetry data coming from a wind farm. And so, yeah, we are, of course, very absentric. Now, I'd actually back up a little bit and say, look, you can do DevOps on a mainframe with just a terminal. You don't need the tools. But what we get out of agile infrastructure is a lot of possibility for how you can think about getting rid of the roadblocks and the typical delays that you'd have if you'd have to go buy a new server every time you want to add something. That's a very simple way. But the application layer is, to us, very fundamental to the point of all of this. I mean, I'm going to reuse this from my talk earlier, but Michael Cote recently had this great quote I'm one of his folks where he said, how many CIOs have you ever heard that it's a great job provisioning that server? I mean, that's not the point of IT. We don't buy infrastructure because it's fun. We buy infrastructure to run applications and we write applications and run applications to deliver for the business. And that's why we're all here. Makes sense? I would agree with that. Customer value is really what we're all trying to do here and cycle time is what people are trying to reduce. Yep. And all these things, DevOps, continuous delivery, Cloud, all of these. Has anybody seen the elephant picture with a bunch of people touching different parts of the elephant and they're saying, oh, this is continuous delivery, this is DevOps. It's a pretty good comic, so you should look it up. We'll add that to the show notes, right? But I think that's right because there's a lot of things we're talking about. We're on a panel talking about DevOps. We're here at the OpenStack conference where it's all about cloud services. We could talk about configuration management. We could go deal with application delivery pipelines. All of these things are kind of revolving around the bigger trend that technology is no longer an inhibitor and starting to become an enabler. So let's talk enablement. The path to actually becoming good at DevOps generally involves breaking glass in a large organization, changing a lot of mindsets of people who used to do things with runbooks and human beings, and now you're going to take away that model and replace it. How are you seeing your customers, your partners, your folks you're working with, how are you seeing them start to be successful? What's the magic secret sauce that the people that are being all states or the other folks we mentioned, what are they doing different? I thought the TD Bank keynote was pretty good and kind of went through what they're doing to think different and to change culture, but from the technology side, what are you saying? I want to go first. From the technology side, so you started talking about breaking glass. I think that most of the glass breaking is actually organizational in nature. So I think you need, there's most success stories that I've seen tend to start with a combination of kind of a grassroots realization that there's a better way. This is crazy. We're waiting for the change control board to actually make it worse. So there's a grassroots thing that happens. Who actually has the capacity to remove barriers and needs to take notice and decide this is the path we're going to head down. So all the successful case studies that I've seen have that similar type of story where there's a deeper to desire within the practitioners and then the executive team actually decides it's a thing they're going to support and make happen. Is it happening? I think it is. I think it's happening depends on the place that's happening at different speeds. I was down in Austin, I think you're from Austin now, right? So I was down in Austin having hot dogs with some IT teams from two different... What else did you have in Austin but hot dogs? Yeah, I've never heard... Let's go have some hot dogs. Well, this is what I said to the sales guy who told me to come talk to his two customers. Why are we going to have hot dogs? But they were delicious. But what we were doing was we were talking with two different airlines, some teams that were in IT because I've sort of been through some of these transformations myself and they were spending a ton of time trying to explain exactly why they couldn't... They couldn't figure out how to explain the use of multiple languages to their executives, right? Multiple programming languages. I mean, this is the type of burden right now that traditional IT is putting on practitioners. It's just blocking their ability to move forward. How do they take a new platform, whether we're talking about an infrastructure as a service platform, an application layer platform, how do you actually get that deployed in an environment where you have to coordinate maybe 30 or 40 different departments, each of which has the right to veto your decision? That's completely unacceptable. Yeah, you don't. Yet it's what happens, right? It is what happens, yeah. And so from a platform as a service perspective, and Grant, I'll let you answer this one, that coordination across all those groups, you could argue that DevOps or even Platform as a Service or even OpenStack by itself is a threat, a challenge, and an opportunity for those teams all at the same time, because it starts to take away the control that they used to have and automate it through technology, DevOps tools or other stacks. So I disagree with that. I don't think Platform as a Service or Infrastructure as a Service takes any control away. Actually, I think it gives more control, actually, right? Because the real benefits of Platform as a Service is that the operations team still maintains all the control, but they just don't have to deal with it on a daily basis, right? And developers can self-provision a certain number of servers based on what the operations team allowed them to do. If we, as a company, went in and said, let's bring Platform as a Service in, you're going to lose some control, that would never work, right? No one would buy into that, I don't think. Well, if the way I used to do it was that someone would call me or open a ticket and I would take the request and I would answer it and I would do the work for them and tell them it was done, and now I just maybe set a policy and hope they follow it. Isn't that taking away control? So if you're setting a policy and hoping they follow it, the policy is probably wrong, right? Or the platforms are wrong. But if I'm just playing CIO advocate here, isn't that what a lot of people are afraid of when they move to automation, is that I'm going to give my developers too much control, take off too many rungs of the handcuffs here, and now all of a sudden I get crazy town? Oh, you're going to get to release software? I think that people are concerned about that, but I like, there's a company DTO Solutions and they approach DevOps through Lean principles and part of the Lean principles are that it's not that the people's job go away, it's that they're going to have higher value work to do. And I'm going to be honest, operating systems is really difficult and operators' jobs are not going to go away. I mean, honestly, a developer cannot know every possible piece of how to operate the system, how to secure it, all that stuff. I mean, you have sharp developers out there, but it's a huge problem space and if you're a very good developer with some very innovative new IoT technology, the odds are that you don't also know how to debug the kernel at this level, it's just not reality. So people's jobs are not going to go away, what they're going to enable themselves to do is to deliver higher value work. Yeah, and you know, that's the first fear that I hear when I go into a large company and start talking about platform and services, the SysAdmands initial reaction is you're automating my job away, right? And it couldn't be further from the truth because SysAdmands, you know, they have real problems. They don't want to be spending all of their time doing what you were saying, you know, getting a request and fulfilling that request for a new development environment. They got production issues and servers and security, Arata, to apply and things like that. And developer environments are last on their priority list as it probably should be. But they still need to have this good relationship with developers, so having a system to where they can maintain control but allow developers to self-provision in the end is a big benefit for them. And once they understand that, they don't want to be in the business of, hey, I need a new VM, let me open up my spreadsheet, here's an IP address, let me put your name down to it, and I have no idea when you're done with it. I think a key thing also, so platform as a service, I think for both of you, since you guys are both, you know, building platform as a service, I think it's really critical that there's a perception that developers are going to be locked out or not just developers, that operators are going to be locked out. I think that's, I think that has kind of tainted some of the platform as a service, I don't know, some people are concerned that platform as a service is a place where I move in and then when things get difficult, I have to move out. So I think that needs to change. The platform as a service is a place where you can move in and then when things get difficult, I have the tools I need to get in there and to actually solve my problems. But that's really critical and that's fact. Okay, so I'm going to ask one more question and then I'm going to ask you to ask some questions. So get them ready, good ones. Is OpenStack, if I'm an enterprise looking to adopt DevOps as a change element in my development practice or whatever, is OpenStack ready? When I say ready, I mean enterprise ready to be the platform I deploy to and rely on. For your infrastructure. Yes, as a place for my applications, whether it's through a platform as a service or natively in the VMs, is it ready? Yeah, I believe it is. Yeah, absolutely. There's no question. That's a horrible question. Of course it's ready. That's a great question. It's ready but it's not the only thing that you need. So you need some sort of platform as a service. You do need more tools in just OpenStack to enable this. I'm glad the non-platform as a service guy said that. Questions from the audience? There's mics or you can yell out and I'll repeat it. Sort of two questions. First is Jenkins really the default de facto tool that everyone's using for their pipeline and the big companies that you've been showing have good DevOps practices. And the second question I was wondering in terms of continuous deployment and replacement as you go from one version of an app to a new version of an app. How much is the operations team involved in that versus the developers? And is there a sort of a policy duration of how those updates work? Like they want it to be a replacement over five hours or something like that or I guess kind of the policies of how stuff are replaced. I was wondering if there was any kind of general trends in the industry on that. Yeah, so I'll answer the first question from... Oh, that's the one I wanted. Give that to him. Take it, my friend. Do it. But your answer better be the same as mine. Everyone is using Jenkins. Jenkins is horrible. No, it's good that you use a CI CD tool. Everyone is using it. That's a space that could be disrupted. I look at tools like drone, open source. That's kind of a better way, much more developer centric. But the important thing is that you're doing CI in CD and Jenkins was kind of the first thing there so it is the de facto standard. All software is horrible. But some of it's useful. Some of it's worse. So let's talk about the second one a little bit and that was a long question. So my experience has been primarily in platform as a service over the last couple of years. But before that I actually managed the group that was responsible for www.redhat.com both the developers and the sysadmins. And I will tell you that when we would deploy a new version of code out, it was a month-long process, right? Because we would have to package it up as RPMs because that's how we versioned it, right? Because that's what our sysadmins knew. Sysadmins traditionally, in my experience, don't know the inner workings of the JVM or setting up an application server like developers. So there's kind of this hybrid role. And so to deploy out to different environments, whether that's dev, QA, stage, prod, test, whatever, I think that is a lot of times it comes down to a business decision to where they don't want developers pushing code to production, right? And so what the industry is kind of moving to, I think now, is more developers will create their application in a container, right? And then that container is what moves through environments. They're not necessarily pushing the button to deploy that container, but the same code that in the container developers built or how we're pushing it through. The way I look at the organization of how you solve for that problem is that I actually don't think of operations as being kind of one unit. So in an ideal situation, you've organized around platform operations who take responsibility for the fabric that you're going to be deploying the apps onto, probably also responsible for the infrastructure layer that's servicing the apps. And platform operations is a thing in and of itself, right? It's an application, it's got a lifecycle, it's a complex distributed system. So you need people that can focus on platform operations. And then when you talk about an application lifecycle, you, of course, have your app dev teams. And I agree, right? The artifact, you know, the kind of the currency of the current age is a container that's a result of an app delivery pipeline. And then you have platform, I'm sorry, application operators, right? And that's a very different practice. I've gotten to the question about, what's the process for doing rolling deployments? Are you talking about a blue-green deploy? Are you going to do some canary nodes early on? That stuff is really hard. And it's hard specifically because there's so much variation in the different app frameworks that are out there and the different architectures. And I'll tell you one thing that we as an industry have not actually solved for as elegantly as maybe we have the ephemeral apps and rolling them out is the persistence layer, right? So how many schema migrations work on the first shot? How many schema migrations support the notion of a rollout of multiple types or versions of the application over the course of a period of time? And that is a practice that we just have to get better at as a collective. So it's the process, not necessarily the tool. Yeah, well, okay, so... The tools do help. Having the tools there, not having to. Working tools are always good, but that is what makes the tool valuable. I was just going to say, not having to invent how to build all the mechanics of how you're going to do those blue-green deploys, just having it there and making it really simple for people to start to consume those patterns, honestly, it helps. DevOps isn't supposed to be about the tools, but that helps a lot. Having a docker there so that you can package everything up, having a container repo that you can push to, having a way to pull that down, having that plumbing there definitely makes it simpler for you to do the right things. Question there, and then question there. So I have two questions. One, have you guys seen any measurements or any quantifiable about how much ROI you're getting for investment in DevOps, either in terms of how fast your leads are to production or how much faster your customers are seeing the new features? And second, as part of CICD, what percentage of application you are being deployed directly to production? Or most of them stop at staging or something else? So who wants the ROI question? I'll go first again. So in terms of the numbers, I encourage you to go look at the Puppet Labs, DevOps 2014 survey. Maybe they have a 2015 by now. That has a lot of numbers in there that I would misquote, but they're pretty compelling, and it was a very broad survey. So that to me is like your blueprint for how to start DevOps in your organization or a big step in the right direction. And I want to make sure I understand the second part of the question. How far into the production life cycle are people using the DevOps tools? Is it just for development and test and stop or does it go all the way through? Or are you asking if it's automatic to deploy or whether they're pulling it? It shouldn't be a different process, but I think that it should be a pull, not a push. Yeah, that's like one of the common anti-patterns, is that it is a different process, right? Yeah, it should not be a different process. Oh, production is a whole different environment, right? It's all the way up through staging. And then we burn it to a CD. We ship it over there. That's what you see when you don't have DevOps, that when going back to, I think, maybe one of your first questions, so developers out of frustration will automate the test environments, will automate the staging environments, they'll automate all of it until it gets to production when they have to do the handoff, and they're like, I have no idea how it gets deployed. That is a recipe for failure. Same process, same tools. That's 20 years, and it has to change. Yeah. To me, the difference between production and staging, development, test, whatever, it's frankly a function of the scale, right? And then what data you actually stored in there, because you're not going to pull the PII stuff back from prod, you're going to have to filter that, if you want good samples from prod. But it's a scale question versus an environment question. It should be the exact same environment, just simply scale appropriately for the use. Same team should own them, et cetera. Again, platform operations versus... Yeah. Next question. Okay, so a quick question. You spoke about the business value earlier. We're currently going through a restructure, so I'm working closely with the executive team. I've got two camps here. I've got a product team, and I've got an engineering and IT team. And I've got two schools of thought, Agile and DevOps. Those aren't different. Right. So in the concepts of... We look at Agile, and we look at a product owner and a dev owner. And then we look at DevOps, and we look at dev and operations in terms of how have you seen it fuse really well together and work really well together. That still brings out agility between development and production and operations. I think they're the same thing, to be honest with you. You guys are reorg-ing, and you're asking how to structure your team? No, we're going through some changes right now. We're just working through in terms of our school of thought for development. And it's a cultural change where we're trying to bring together these teams and embed that in the culture and introduce the disciplines behind that. I think one of the most critical things is that you should be aligning around customer value. We've got that. Then you're on the right path to success. So if that's a platform team that's delivering the value to the development teams, that's aligning around customer value. If you're building an open-stack service and it's a compute team, a storage team, an identity team that's aligning around customer value, if you align around customer value, the rest becomes a lot easier. So if you're doing agile development and you've got, let's say your product team is totally bought in, they're doing Scrum, they're constantly delivering it, or maybe they're doing weekly sprints, that means they've got a releaseable product every week, and then it takes you a couple of weeks and it's a little bit more effective if you can actually get it delivered. So to me, you can't really do one without the other if the goal is to get to the business value, which, thankfully, that's your goal, right? So they're not different. They're literally complementary and they relate to both different parts of the architecture but also different parts of the overall delivery value process. And just to add on, DevOps is not about team organization so much, right? I went to this company one time and they're like, the CIO was like, I'm going to do DevOps, so he took an operations guy and put it on every dev team and that's DevOps, right? That's not what it is. It's more the culture of collaboration and working together to automate these deployments out. I gave up arguing about the DevOps team, I mean. Well, that's the DevOps team. They're going to take care of that for us. I gave up. A question in the back. Either that or I'm just not looking to this side. Is there a question there? Okay. Ask your question and then we hopefully have one or two more. So quick question. I do have a come from operational background. I see OpenStack is all about configuration management but troubleshooting aspect is very much, in my mind, forgotten to some degree like you have the root cause analysis portion. It's here and there. So what I've seen so far at the show is the whole idea of VMware in OpenStack and their management tool helping facilitate that troubleshooting. So just to get a thought from you guys what do you think about the future of toolkits and management overlay for the OpenStack-like environment? I mean, I kind of get the question. Yeah, I was just going to maybe summarize the question and make sure that we got it right. So are the toolkits today where they need to be and do they take things like root cause analysis into account or are we just, hey, something failed, let's brush that across and deploy new stuff and forget about why it broke? Like, what are we doing to address that? Is that the question? I think it's mostly around root cause analysis. When you do those fast deployments at scale, how do you account for all the dependencies and the infrastructure from application all the way down to the infrastructure? How mature? I mean, it goes to the point where you said we are ready for OpenStack production. When I hear that, I hear, okay, is my pager going to ring and how is this going to be negotiated now in the new world of the workloads being managed through the controllers? So it would be interesting for me to know if such work is ongoing in terms of framework and OpenStack to push notifications, splunking things to get, is that old world of management changing for the, as we talk with cloud services and OpenStack? I'm going to ask that question in a slightly different way to the panel. Is OpenStack the place where the management of your app should happen like should there be an OpenStack project for application management, notifications, you know, analysis, those types of things, or is the role of OpenStack to provide the hook so customers can use whatever tools they want on top? I think most customers are using their existing tools for management, right? And there's some great management companies out there that just focus on management, right? If, let's take Red Hat, for example, and OpenShift, we actually don't provide management tools for OpenShift. The product I work on for app, for the app tier, because there's tools out there that are much better at it than what my small OpenShift team could create, and so we recommend using the existing best-of-breed tools out there. You guys agree, is that the model that you see? Well, Cloud Foundry does. I mean, we take a similar approach, right? They're tying in that new relic, right? Whoever, right? They handle that. But when I think about the infrastructure platform, what I'd say, first of all, is computers are hard, right? They just are. Distributed systems are exponentially harder. And, you know, the nice thing about a lot of the projects and the platforms that are being built today is that the number of points of introspection is extremely rich, and that presents a lot of opportunity for the management systems to bring some intelligence based on all that data that's flowing out of it, right? That, to me, is actually the keys. Can you get consistent logging out of the system? Can you get consistent visibility into the performance of all of the various components? And then once you do that, yeah, I hand it off to somebody who's kind of spent their life focusing on that. Let's go into a company and say let's deploy OpenStack and let's also replace your application tier. Oh, and by the way, let's replace your entire management suite, right? That's a really tough sell. So you start small, right? Use your existing management suite and then maybe bring in, you know, CloudForm or Red Hat. CloudForms. CloudForms, yes. Later on down the cycle, right? Thank you. Actually, I think that's one of the nice things about OpenStack is that it's not that you have to go all in on that stuff. So to answer your question, I think the OpenStack needs to build out some more operations capabilities. There'll always be companies like AppDynamics and New Relic that are innovating there quicker than the open source can. But yeah, I mean, it's all good. Question from this side. No, I think we actually need to shut it down because we have another session coming in. We're on the stage. All right, hang on. One last question for these guys. The question is, one year from now, it sounds like we'll be sitting in Austin eating hot dogs and hopefully some really good barbecue. I'll take it there, I'll show you. From a DevOps perspective, almost one word answer here because we're out of time. What is the thing you want to see in OpenStack to make the lives of Platform and DevOps and everything else easier? Adoption. Adoption. Consistency across the deployments and the products. We hear that a lot. I would say more automation in the API. All right, that's it. Thank you so much, everyone. Thank you, panelists.